Share an editable TODO checklist with the Sidekick in xmd repl #901

Story

As a person using the Sidekick in xmd repl, I want a shared checklist inside its drawer, so we can add, reorder and complete tasks together without keeping a separate plan in conversation.

For example, the Sidekick writes three tasks. I move a task earlier and check another off. The drawer immediately reflects those edits. An idle human edit starts a Sidekick response through its existing dispatcher; an edit made while busy adds change context to the next eligible prompt. The Sidekick infers what the changes mean for our work. Reordering does not itself interrupt a running task or enforce a scheduler.

Current gap

#883 establishes the conversational Sidekick. It does not provide a shared editable artifact, a visual checklist, or prompt context that lets Sidekick act on a committed change. #896 provides shared component authoring and tests; #897 covers execution-event middleware. Neither owns this shared checklist experience.

Approved visual reference

The Product Owner approved XMD REPL Sidekick Checklist-final.html (download the ZIP and open the HTML). The original exported mockup is also attached in this issue's comments.

• The drawer contains the conversation, then a shared TODO/QUEUE tab row and the selected list, then the Sidekick message input. Switching views preserves task and queued-message state; background activity changes neither the selected tab nor keyboard focus.
• Each task has a checkbox, text and same-row ↑ / ↓ / x actions for move up, move down and remove. Completed tasks stay in their existing order, with strikethrough and the approved more subdued gray treatment. Focus and selection keep them readable and actionable.
• The list uses only the space its content needs. Adding, removing or wrapping task text can change its height. Focusing, selecting, checking or unchecking an existing task introduces no extra rows or spacing.
• A stationary + sits at the right of the TODO header. It opens the new-task editor. Down from the last task opens the same editor; Enter commits and Escape cancels.
• The TODO section collapses to its header. Click or Enter/Space on the focused header toggles it. Collapsing preserves tasks; task changes do not automatically expand it.
• The Sidekick message input is multiline, approximately three visible lines by default.
• Actions are accessible through keyboard focus and selection and mouse clicks, without depending on hover.
• Keep the flat checklist simple: no Now/Next/Done groups, priority numbers, counts, progress, ownership badges, file/source views, or change-policy controls. todo.md is internal storage and has no label or reference in the checklist UI.

The HTML is a visual and interaction reference. Its browser implementation, demo controls, localStorage, hardcoded colors, and incidental key handling do not define terminal runtime architecture. Coordinate focus regions with #895 and narrow-terminal behavior with #883.

Shared file and evaluation

One todo.md in the session workspace is authoritative for this checklist. It is shared across entries and preserved on cold reopen; a fresh session starts with a fresh list. The UI reflects the actual file, including while follow-up work is held or fails. There is no independent task store that can disagree with it.

Read the ordered {text, completed} items with <Sidekick.Todo as="items" />. Edit the same file with a paired <Sidekick.Todo as="items"> containing one fenced unified diff; the edit returns its committed items. Both forms require assignment and render no text. Every hunk must match the current source exactly; a stale or malformed edit refuses the whole change without changing the file. A human editor likewise refuses to save over a competing edit.

The checklist uses flat UTF-8 Markdown tasks with inline Markdown labels. Context lines match source directly; no persistent task IDs or separate line-reference language is introduced.

Human checklist actions and Sidekick edits converge on the same file. Checking a task means done; unchecked means not done. Reordering conveys intent that the Sidekick interprets from context rather than a host-enforced scheduling instruction.

Context after a change

A successful file mutation commits first, so the UI shows it even if subsequent Sidekick work is held, fails or stops. A refused or unchanged edit creates no successful-change context or response.

The TODO plugin retains ordered change observations and enriches existing prompts through Agent.prompt middleware. Normal prompts carry the changes, without repeatedly including the whole list. Sidekick can read the current list explicitly through <Sidekick.Todo as="items" />. Successful canonical completion retires only the observations included in that prompt; edits made afterward stay pending.

After a failed or stopped request, the next independently allowed prompt rereads and includes the full current checklist. Success returns later prompts to changes only. This recovery starts no work, retries no failed message or effect, and bypasses no Stop, queue hold, question, permission or unknown-outcome refusal.

An eligible human edit while idle can start one response through the existing dispatcher. Busy edits consume no message-queue slot, and becoming idle alone starts nothing. Sidekick component edits retain ordinary component feedback without a second change-policy turn. External file edits refresh the visible list without adding change context or starting Sidekick.

The plugin installs its live service once through Repl.initialize(workspace) for the logical REPL lifetime. Reopening restores only todo.md, without replaying completed work, restoring pending observations or automatically retrying interrupted requests. Historical inspection invokes nothing. There is no separate Sidekick.Todo.Changed policy component, session override or shipped fallback.

Product verification

• Add tasks through the human editor and through Sidekick evaluation; both update the same file and rendered checklist. Complete, reopen, rename, remove and reorder tasks without recreating a second authority.
• Show the approved drawer at wide, intermediate and narrow terminal sizes. Completed items use the subdued strikethrough treatment, remain readable on focus, and keep their order. Focusing or toggling a task creates no layout jump; adding/removing/wrapping content changes height naturally. The taller message input stays usable.
• Collapse the checklist, change tasks, and show that the header stays collapsed. Expand to see current file content. Exercise +, Down from the last item, Enter and Escape without hover.
• Commit a file change and hold its consequence. The UI already shows the changed task. Fail or cancel consequences and verify the committed edit remains. Refuse a mutation and verify there is no successful-change continuation.
• While Sidekick is busy, commit edits and verify that each eligible prompt receives the covered changes without using another queue slot. After failure or Stop, verify a fresh full checklist on the next allowed prompt, then deltas after success. External edits refresh only the list.
• Reopen the session and demonstrate preserved tasks plus the approved consequence recovery behavior. Historical inspection does not mutate the current checklist or invoke the Sidekick.

The accepted journeys cover shared edits, atomic refusal, prompt context and recovery, reopening, and layout/focus. The REPL and component specifications own the detailed contract; PR #1038 carries the implementation and delivery evidence. Implementation screens still require their separate product acceptance.

Relationships and scope

Follow-up to #883, related to REPL Quest #827. Coordinate shared component resolution with #896, middleware ownership with #897, and focus-region navigation with #895. Do not change their active implementation targets merely to add this feature.

The REPL root owns application state and semantic requests. Presentation receives immutable views and returns typed actions; Freedom owns focus. Components and subscriptions have owned lifetimes. Preserve contextual host adapters and the existing continuation contract; do not mutate next or attach metadata to it.

Update the relevant REPL and component-resolution specifications as part of delivery. A general shared-artifact framework, plugin installer, scheduler, in-progress task state and automatic interruption of running work are outside this Story.