Execution Log: a readable session stream, a session tree, and a chat bar

Append-only log for issue-230. Ticket: #230.

How this session ran the loop

One cloud session, one pass, no human at the other end — the same posture as issue-208/209/211/217/220/222, with the same two consequences a reviewer should hold:

1. phase-selection was not run as a gate. The session was started by the ticket itself; there was nobody to tick the checklist. Phases assumed: the full spec chain, implementation, verification, self-review. brainstorming was not taken (the ticket plus its three comments state the problem and the wanted surfaces concretely) and neither was the opt-in design-critic-review — no second model was available to this session.
2. The chain was authored before the code, but approved by nobody. The artifacts are a proposal to ratify, not a locked chain; status: draft on all four says so. Risk tier 3 means this PR needs a human approval before it is complete — see requirements.md §Risk tier.

Phase transitions

Phase	Entered	Reviewed/approved by	Notes
phase-selection	2026-08-15	—	Not run as a gate; see above
requirements-definition	2026-08-15		requirements.md — 4 requirements, 4 NFRs, threat-model-lite, risk tier 3
design	2026-08-15		design.md — one projection, one shared component, one screen, one narrowed service change
test-planning	2026-08-15		testing-plan.md — 10 rows in scope, 4 n/a with reasons
tasks-breakdown	2026-08-15		tasks.md — 13 tasks
implementation	2026-08-15		all 13 tasks; one projection, one shared component, one screen, one service change
verification	2026-08-15		plan executed in full — 2102 passed + 1 skipped (python), 104 passed (ui), lint/format/types clean, 4 fixture-rendered screenshots; record in testing-plan.md §Verification record
needs-review	2026-08-15		handed to the PR

Pull requests

PR	Scope / tasks	Status
#237 (claude/github-issue-230-lmqbsb)	the whole work item	open, awaiting human approval

Progress entries

2026-08-15 — orientation

Read the ticket and its three comments (collapsed tool calls like claude.ai/code; the blank-row bug naming Tool Result; the sidebar + two-level tree with no tree for ad-hoc items; the chat bar per outer/inner loop). Confirmed in code:

• transcriptTurns (ui/src/api/model.ts) reads only text/tool_use blocks — a tool_result entry projects to {kind: "tool result", text: ""}, which is exactly the reported blank row; thinking blocks and bookkeeping entries also vanish.
• reply_session (cli/the_loop/core/sessions.py) resolves with find_by_work_item, so a PR ref 404s even though record_owning/endpoint_for (dispatch) and _transcript_endpoint (the transcript route) both already resolve PR endpoints. That asymmetry is the whole service-side change.

Authored the spec chain (this folder), then implemented per the task DAG.

2026-08-15 — implementation

• UI, projection (ui/src/api/model.ts): transcriptTurns → transcriptThread. Results pair to calls by tool_use_id across entries; orphan results, thinking and bookkeeping all become visible rows; per-tool one-line summaries live in a data table (TOOL_SUMMARY_KEYS) with a compact-JSON fallback. sessionTree added for the sidebar (ad-hoc detection on graph.loop).
• UI, renderer (ui/src/components/Transcript.tsx, new): TranscriptView (native <details> disclosure, collapsed by default for tool calls / thinking / meta) and ChatBar (posts replySession(ref, text); disabled with the reason for paused/closed/none). WorkItemDetail's inline TurnRow deleted in favour of the shared renderer; its trace panel gained the chat bar bound to the selected tab.
• UI, screen (ui/src/views/Sessions.tsx, new): #/sessions[/<ref>] route, Nav tab, sidebar → two-level tree → stream + chat bar; event-trail fallback preserved.
• Service (cli/the_loop/core/sessions.py): reply_session resolves via record_owning + endpoint_for with the closed-endpoint fallback — the dispatch rule — instead of find_by_work_item; every issue-208 refusal kept, paused checked on both the record and the resolved endpoint. OpenAPI description updated (shapes untouched; parity test green).
• Demo fixture: transcript now exercises every projected shape (paired results, an error result, an orphan, thinking, a summary line, malformed); an ad-hoc item (loop-lab#223, pdlc-adhoc-loop) added — the dashboard count test moved 8 → 9.

2026-08-15 — verification

Testing plan executed in full; per-row record in testing-plan.md §Verification record, raw output and the four fixture-rendered screenshots in evidence/. Highlights: 13 reply-route tests (4 new PR-endpoint scenarios), 104 UI tests (16 new), whole suites green, ruff/format/pyright/oxlint/tsc/markdownlint clean, production build clean.

2026-08-15 — self-review

Three passes over the full diff before handing to the PR (no second model was available for critic review; noted for the reviewer):

1. Pass 1 (while making the suites green) found Transcript.test.tsx asserting single-element queries on text that legitimately renders twice (collapsed summary + disclosure body) — tests corrected to getAllByText; renderer unchanged (the duplication is the disclosure pattern working as designed).
2. Pass 2 (re-reading the finished projection) found an entry whose only text or thinking block is an empty string would still emit a blank row — the very bug being removed. Fixed by dropping empty blocks at collection; suites re-run green.
3. Pass 3 found nothing new — stopped per reviews.stopOnNoNewFindings.

Capability docs

docs/capabilities/control-plane.md: the reply-route bullet now states the PR-endpoint resolution; two new bullets cover the readable stream and the Sessions screen; a history row links this spec.

Documentation

• ui/README.md: the screens table gained the Sessions row (what it reads, and that the chat bar posts to /sessions/reply).
• docs/api-specs/openapi/the-loop.v1.yaml: /sessions/reply description covers PR-endpoint resolution.
• The docs site and README were left unchanged on purpose: neither describes the dashboard's individual screens or the reply route's resolution order.