Refine the xmd repl layout around Transcript and Sidekick #971

A person can follow Sidekick and other agent conversations in a filterable Transcript, inspect selected REPL work in the center, and keep Sidekick chat, TODOs and waiting messages together. With Follow enabled, each execution round returns its outcome to Sidekick so it can decide what to do next and continue working without another human message.

For example, while Sidekick runs an Architect review, the person selects the Architect in the Transcript dropdown, inspects the running review, and queues “When that finishes, explain the requested changes.” The queued message shows its origin and an X for removal. Its position communicates order.

Implementation reference · v8

Use the shared v8 HTML board, JSON fixture and Markdown handoff for this issue's active acceptance criteria. See the ticket-to-scene map. The board should report shared fixture v8 · #4329b607.

• HTML: XMD REPL Terminal Interface – XMD REPL.html
• Fixture: repl-fixture.json
• Handoff: repl-ui-handoff.md

The standalone v2 board records the earlier design. Use v8 for the current tab, queue and layout decisions.

Selected design direction

• Keep the filterable Transcript on the left and selected work in the center. Keep the entry Draft and its execution controls separate from the Sidekick Message composer.
• Select Sidekick by default. Put TODO beside it with the open item count, then Bindings. Sidekick Message receives default keyboard focus.
• Give Sidekick the v8 pane widths. At 72×20, give Sidekick the available width and let the view switcher reach the other panes.
• Place queued messages in their visible order under the conversation when the queue is populated. Each row shows origin, text and an X that removes the message. Keep the notice “Waiting messages are kept only in this REPL.” The list scrolls when needed. Omit the Queue tab, queue count and empty queue block.
• Strip leading empty lines from visible message output while preserving internal spacing. Omit the routine “completed” label in Transcript. Keep active, interrupted and failed states visible.
• Remove the key-hint strip below History. Show errors as notifications and retain the failure in the conversation after dismissal. Coordinate in-REPL usage visibility with Show token usage for REPL Sidekick turns, rounds and totals #1201 and conversation grouping and inspection with Match the xmd repl Sidekick conversation layout to its approved reference #931.

Follow and execution controls

Follow makes execution outcomes part of Sidekick's continuing conversation. For example, Sidekick submits an Architect review, waits for that round to finish, receives its actual result and decides whether to request a correction or proceed to the next task. With the shared TODO capability from #901 available, the current checklist supplies additional context about the intended task sequence and progress. Sidekick interprets that context; the checklist does not enforce a scheduler.

Sidekick
[SIDEKICK] [TODO 4] [BINDINGS]   [x Follow] [Send]
+--------------------------------------------+
| Sidekick draft                             |
+--------------------------------------------+

Entry draft                            [Send]
+--------------------------------------------+
| Executable Markdown                        |
+--------------------------------------------+

• Entry Draft uses its own Send/Stop control. Sidekick Send stays available beside Sidekick Stop during a live exchange.
• With Follow enabled, Sidekick waits for the execution round to settle, then receives its outcome and actual execution output. Completed, failed and interrupted outcomes remain distinguishable.
• Sidekick determines what to do next from that result and the available task context. Follow remains enabled across subsequent rounds, supporting unattended progress without another human Send after each round.
• Entry Stop interrupts the running execution round. With Follow enabled, its interrupted outcome returns control to Sidekick, which decides the next action. Interrupting a round does not itself end Follow.
• Sidekick Stop interrupts Sidekick's current turn. It remains available during generation or a question, including when no entry is running. An already-admitted entry retains its independent execution lifetime.
• Turning Follow off ends automatic continuation after the current round; it does not interrupt that round.
• Follow controls Sidekick continuation. It is separate from following live execution or scrolling to the newest transcript content.

Behavior to reconcile before implementation

Queue admission, ordering, cancellation, failure, continuation and shutdown remain #964's contract. Follow adds continuation from execution outcomes; carry the next eligible waiting message with the round result and keep the remaining messages queued. Preserve one live Sidekick conversation and the existing execution, question, permission and history owners.

Map an execution “round” and the reference's session dropdown, selected-work navigation and compact History to the product's actual entries, conversations, scopes and recorded positions. Missing navigation or controls need an explicit disposition. Sample source, results, timers and status transitions are demonstration data; production presentation comes from actual work.

Visual matching checkpoint

The first implementation checkpoint presents one complete screen at 160x36 through the production terminal renderer, using controlled representative content. It includes Transcript, selected work, both drafts, TODO, a populated waiting queue, Follow and Send/Stop. Review this screen with the Product Owner before full behavior integration and before extending the design across other sizes and states.

1. Extract the visual requirements from the pinned reference: column proportions, spacing in terminal cells, panel surfaces, borders, foreground colors, emphasis, control alignment and wrapping. Record the agreed terminal adaptations where browser typography or pixel geometry does not translate directly. Include the accepted control changes above.
2. Render the complete screen and capture images that preserve its actual colors, emphasis and spacing. Present the reference and the rendered screen together, with every remaining visual difference identified.
3. Have the Implementor inspect both images, correct concrete discrepancies and render again. Repeat the comparison until the Product Owner accepts the terminal rendering. Plain text captures and passing behavior tests alone do not establish visual fidelity.
4. Extend the accepted rendering to 120x30 and 72x20, then review running work, questions, completion, failure, interruption and overflow. Keep the reference, captured output and accepted adaptations available with each comparison.
5. Protect the agreed geometry, color roles, spacing and alignment with focused rendered-cell or visual regression checks. Expected values come from the reviewed design; a capture of the current implementation becomes a reference only after review.

Use the existing rendered-cell presentation fixtures and real-terminal bench where appropriate. Controlled content makes visual comparisons repeatable; the completed interface continues to present actual execution state and results.

Verification from Sidekick

Sidekick submits a round in the parent development REPL to run the Markdown acceptance suite for the ticket. The round records the test exit code, a short result and the evidence path. Sidekick reads the saved result with REPL.Entry.Output and uses it to decide what to fix or verify next.

Run the matching visual journey as a second parent round. Use Terminal, XMD.Build and XMD.Repl to drive isolated child REPLs at the pinned baseline and candidate commits. Return screenshot paths and checkpoint details in the round output. Inspect the captured frames in Sidekick and attach the matching mockup, baseline and candidate images to the PR. Record the parent round IDs, revisions and test outcomes.

Render performance

For every PR that affects the REPL UI, run the paired performance journey during test execution. Use pinned baseline and candidate revisions on the same host and runtime. Report median and p95 for small and 52-round histories, measuring a single character edit through the completed emulator write that shows it. Aim for about 12 ms on the reference environment, and retain the deterministic check on off-screen render work. Keep the raw timing receipt with the PR. The shared CI integration is #1308.

Completion evidence

• Produce a complete current-interface-to-v8 change inventory, covering Transcript, its dropdown, selected work, Draft, History, Bindings, Sidekick, TODO, the waiting queue, Follow and both drafts' Send/Stop controls.
• Review representative running, queued, completed, failed and interrupted journeys at 160x36, 120x30 and 72x20, including session selection, resizing, scrolling, input focus and an overflowed queue.
• Show that a queued message stays distinct from newer composer text, that X removes the selected message, and that transition into active work creates no duplicate conversation message.
• Show Follow continuing through consecutive execution rounds without another human Send, using actual outcomes and output. Exercise completed, failed and interrupted results; Entry Stop returns an interrupted outcome to Sidekick while Follow remains enabled.
• Show that turning Follow off prevents automatic continuation after the current round without cancelling that round. Exercise Sidekick Stop during generation and a question with no running entry, independently of Entry Stop.
• With Share an editable TODO checklist with the Sidekick in xmd repl #901 available, show Sidekick receiving current TODO context and using it to choose subsequent work. Keep queued human messages distinct from execution outcomes and show their reconciled ordering.
• Record the accepted controls and Follow behavior in the REPL specification, resolve remaining consequential interaction changes with the Product Owner, and record product verification before an implementation plan is frozen.
• Keep the pinned interactive reference available with the reviewed comparisons so another reader can assess the full design.

Relationships

#827 owns the REPL capability. #881 owns parity with its separately pinned original Terminal Interface reference; the v8 handoff applies to this ticket's UI. #963 owns shared Sidekick dispatch, #964 owns follow-up queue behavior, #901 owns the shared editable TODO checklist and its change consequences, and #961 owns later ACP access. This ticket owns the accepted Follow control and continuation experience; TODO remains additional task context with its own contract.

Use the sequence in the v8 implementation map.