Story
As a person using xmd repl, I want to discuss a task with a Sidekick inside the REPL, so it can inspect my working state, write a program into the entry input, run it, and revise it from the results.
For example, an earlier entry publishes names = ["Ada", "Grace", "Linus"]. I ask the Sidekick, “Use the names binding to greet each person.” It reads the available bindings, fills the shared entry input with XMD, and submits the program through the REPL. I can inspect and edit that draft. The run becomes an ordinary immutable transcript entry. The Sidekick receives the execution result and can revise the next draft. If it needs a choice from me, it asks through <Elicit>.
Current gap
The REPL presents Agent sessions created by executing entries. It has no dedicated conversational helper with a separate chat input and operations for controlling the active REPL. Observing an Agent session does not provide this interaction.
Accepted experience
- The Sidekick has a dedicated Agent session attached to the active REPL. Its conversation continues across entry submissions. It can be identified in Sessions, while its chat lives in the right pane.
- The right pane has Bindings and Sidekick tabs. Only the selected tab's content is visible. Switching tabs preserves the conversation, pending interactions, chat text, shared program draft, and running work.
- The Sidekick can inspect bindings while either tab is selected. Inspection and background activity do not automatically change the tab, selected entry, inspected history position, or keyboard focus.
- The Sidekick chat composer sends a conversational message. The main entry input contains executable XMD for the next entry. Labels and focus make the destination of typing clear.
- Agent identity is selected independently through the requested
--sidekit-agent option. --default-agent continues to select the default Agent used by REPL entries. Broader model, provider, and settings design is deferred.
XMD controls and feedback
The host evaluates each complete Sidekick response as an XMD program by default. The agent does not need to wrap its response in <Evaluate>.
The agreed operation shapes are:
This inspects the active REPL's bindings and returns the result to the Sidekick.
<REPL.EntryInput>{code}</REPL.EntryInput>Here, code denotes the proposed program's source text. This places that source in the real shared entry input, where the person can inspect and edit it. Filling the input does not execute it. Submission is a separate operation whose exact public spelling remains to be settled.
<Output>
I have prepared a greeting program in the entry input.
</Output>
<Output> explicitly selects text shown to the person in the Sidekick conversation. It does not provide the feedback channel to the agent. The host routes operation results, failures, submitted-entry outcomes, and validated answers back to the owning Sidekick conversation separately from user-facing rendering.
Questions use the existing contextual <Elicit schema={responseSchema} as="response">…</Elicit> contract. The schema defines the answer, and the validated answer reaches the Sidekick. This feature preserves ordinary <Output> and <Elicit> language semantics; it does not introduce a new generic message component or make <Output> a streaming progress channel.
Visual reference
Use the XMD REPL Sidekick Claude Design project, exported as XMD REPL Sidekick.html.
The accepted refinement makes the three columns easy to distinguish: visible continuous vertical dividers, distinct dark backgrounds for sidebar, transcript, and right pane, stronger header bands, and a clear full-width History footer boundary. These relationships are part of the design contract. The browser mockup's fixed canvas dimensions and scripted behavior do not establish terminal sizing or runtime semantics.
Architecture boundaries
The REPL's root remains the owner of application state and admission. Sidekick operations reach it through semantic requests, using the same draft and submission path as the person. Submitted source remains immutable; entries execute sequentially under the existing admission rules. A Sidekick operation cannot bypass a running entry, unfinished teardown, or read-only History inspection.
Presentation receives immutable views and returns typed actions. Changing tabs does not own or cancel the Sidekick session. Rendering and historical inspection do not execute Sidekick programs or contact a provider.
Product verification proposal
- Run the greeting journey against an actual published binding, then request a revision such as a table. Check the shared draft, admitted source, rendered result, and feedback received by the Sidekick. A scripted chat that never controls the REPL fails this comparison.
- Inspect bindings while the Bindings tab is visible and while Sidekick is visible. The result reaches the agent without a forced tab or focus change.
- Fill the entry input, edit it by hand, and submit it. Filling alone admits no entry; submission records the exact source admitted.
- Show selected
<Output> text to the person and deliver operation results to the agent independently. A binding dump appearing as the chat response is not sufficient evidence of feedback routing.
- Ask a schema-backed question, reject an invalid answer, and continue from a valid answer. Closing the interaction does not fabricate an answer.
- Exercise an entry failure, a refused submission, and tab switching during work. The agent receives the actual failure or refusal, the draft remains available, and work has an observable owner.
- Compare column separation, chat/input destinations, and tab state in production terminal captures at the supported wide, intermediate, and narrow profiles.
The Architect and Product Owner refine this proposal before the Planner freezes implementation acceptance.
Decisions before implementation
Settle the submission operation; the exact feedback payload, correlation, and delivery sequence; binding selection while reading another entry or History; shared-draft conflicts; Sidekick elicitation placement; and session lifetime, cancellation, durable history, and cold reconstruction. Also settle responses with no explicit <Output> and the narrow-terminal composition. The mockup demonstrates intent rather than resolving these contracts.
Relationships and exclusions
Follow-on REPL work related to Quest #827. Complete original Terminal Interface parity in #881 before implementing features from this newer mockup; this Story does not change #881's accepted scope.
Exclude settings screens, broader model/provider configuration, general session management, History forks, native Agent TUI synchronization, and a renderer or UI framework replacement.
Story
As a person using
xmd repl, I want to discuss a task with a Sidekick inside the REPL, so it can inspect my working state, write a program into the entry input, run it, and revise it from the results.For example, an earlier entry publishes
names = ["Ada", "Grace", "Linus"]. I ask the Sidekick, “Use the names binding to greet each person.” It reads the available bindings, fills the shared entry input with XMD, and submits the program through the REPL. I can inspect and edit that draft. The run becomes an ordinary immutable transcript entry. The Sidekick receives the execution result and can revise the next draft. If it needs a choice from me, it asks through<Elicit>.Current gap
The REPL presents Agent sessions created by executing entries. It has no dedicated conversational helper with a separate chat input and operations for controlling the active REPL. Observing an Agent session does not provide this interaction.
Accepted experience
--sidekit-agentoption.--default-agentcontinues to select the default Agent used by REPL entries. Broader model, provider, and settings design is deferred.XMD controls and feedback
The host evaluates each complete Sidekick response as an XMD program by default. The agent does not need to wrap its response in
<Evaluate>.The agreed operation shapes are:
This inspects the active REPL's bindings and returns the result to the Sidekick.
<REPL.EntryInput>{code}</REPL.EntryInput>Here,
codedenotes the proposed program's source text. This places that source in the real shared entry input, where the person can inspect and edit it. Filling the input does not execute it. Submission is a separate operation whose exact public spelling remains to be settled.<Output>explicitly selects text shown to the person in the Sidekick conversation. It does not provide the feedback channel to the agent. The host routes operation results, failures, submitted-entry outcomes, and validated answers back to the owning Sidekick conversation separately from user-facing rendering.Questions use the existing contextual
<Elicit schema={responseSchema} as="response">…</Elicit>contract. The schema defines the answer, and the validated answer reaches the Sidekick. This feature preserves ordinary<Output>and<Elicit>language semantics; it does not introduce a new generic message component or make<Output>a streaming progress channel.Visual reference
Use the XMD REPL Sidekick Claude Design project, exported as
XMD REPL Sidekick.html.The accepted refinement makes the three columns easy to distinguish: visible continuous vertical dividers, distinct dark backgrounds for sidebar, transcript, and right pane, stronger header bands, and a clear full-width History footer boundary. These relationships are part of the design contract. The browser mockup's fixed canvas dimensions and scripted behavior do not establish terminal sizing or runtime semantics.
Architecture boundaries
The REPL's root remains the owner of application state and admission. Sidekick operations reach it through semantic requests, using the same draft and submission path as the person. Submitted source remains immutable; entries execute sequentially under the existing admission rules. A Sidekick operation cannot bypass a running entry, unfinished teardown, or read-only History inspection.
Presentation receives immutable views and returns typed actions. Changing tabs does not own or cancel the Sidekick session. Rendering and historical inspection do not execute Sidekick programs or contact a provider.
Product verification proposal
<Output>text to the person and deliver operation results to the agent independently. A binding dump appearing as the chat response is not sufficient evidence of feedback routing.The Architect and Product Owner refine this proposal before the Planner freezes implementation acceptance.
Decisions before implementation
Settle the submission operation; the exact feedback payload, correlation, and delivery sequence; binding selection while reading another entry or History; shared-draft conflicts; Sidekick elicitation placement; and session lifetime, cancellation, durable history, and cold reconstruction. Also settle responses with no explicit
<Output>and the narrow-terminal composition. The mockup demonstrates intent rather than resolving these contracts.Relationships and exclusions
Follow-on REPL work related to Quest #827. Complete original Terminal Interface parity in #881 before implementing features from this newer mockup; this Story does not change #881's accepted scope.
Exclude settings screens, broader model/provider configuration, general session management, History forks, native Agent TUI synchronization, and a renderer or UI framework replacement.