[salon] Tracker: multiplayer plan review and sequential execution (no Fountain changes required)

[jhgaylor]

Carried over from the archived managoat/salon#10 when the demo suite
was consolidated into this repository. The original repo has been deleted, so
this is the surviving copy.

• Originally opened by @jhgaylor on 2026-09-02 (issue https://github.com/managoat/salon/issues/10)
• Now lives at: apps/salon
• Status: carried over as-is

---

Outcome

Make Salon the multiplayer place where a team agrees on intent, authorizes execution and verifies that the agent followed the agreement.

The core loop is:

Discuss → Draft plan → Review/edit/comment → Approve revision
        → Execute nodes sequentially → Attach evidence → Check conformance

This tracker is deliberately limited to work Salon can ship with Fountain's current conversation, event, sandbox-file and diff APIs. None of the Fountain issues in the follow-on tracker block this work.

Product decisions

• The plan is authoritative Salon data, durable across parked/archived/restored computers. It is not only a file in the repository.
• The primary surface is an editable outline of nodes. Dependencies form a DAG underneath; a visual graph is a secondary view.
• Code remains evidence. Humans review plan conformance, failures, unexplained changes and risky areas rather than treating a final cumulative diff as the only review surface.
• Human comments and room notes do not become model turns until somebody explicitly sends them.
• Begin with sequential execution in the root conversation. Do not fan agents into one checkout.

1. Multiplayer intent and control

• Extend Salon's chat SSE channel with ephemeral presence, typing and viewing events.
• Show who is online, who is editing/viewing a plan node and who started the active model turn.
• Add human-only room notes/comments that cost no model turn.
• While a turn runs, let a participant save a note for the next turn instead of submitting into conversation_busy.
• Route interrupt and permission-answer actions through Salon-owned endpoints.
• Persist control actions: actor, action, conversation/turn when known, request/option where relevant and timestamp.
• Initial authority policy: the turn author or host can interrupt and answer its permission requests. Keep the policy isolated so it can become project-configurable later.
• Preserve Fountain's first-answer-wins behavior and surface who got there first.

2. First-class plan data

• Add plans, plan_nodes, plan_edges, plan_events, plan_approvals and execution records.
• Give nodes stable IDs, outcome, description, acceptance criteria, dependencies, status and ordering.
• Validate dependencies server-side and refuse cycles.
• Use operation-based mutations with expected_revision; make independent-node edits commute and return a useful conflict for the same field/revision.
• Keep an immutable event log recording author and before/after revision for every mutation.
• Bind approvals to an exact plan revision. A material edit invalidates the affected approval.
• Default execution gate: the chat/project host approves a revision; collaborators can show support, comment and propose edits.
• Provide a portable Markdown/JSON export, but never treat an agent-writable repository copy as the approval authority.

3. Plan review UI

• Add a Plan pane beside the thread, visible by default for project chats.
• Render an editable outline/card view with status, dependencies, acceptance criteria and unresolved feedback.
• Add the optional dependency graph view after the outline works well.
• Generalize review-comment anchors from only diff lines to diff_line | plan_node | plan_field.
• Reuse the existing resolve/delete/send lifecycle for plan comments.
• Add “Send plan feedback to the model” as one attributed turn, grouped by node and author.
• Show plan revision history and approval invalidation without turning the UI into a project-management board.

4. Drafting with current Fountain capabilities

• Add an explicit “Draft a plan” action that prompts the selected model for the plan schema and validates the structured result before adopting it.
• Invalid model output remains transcript text and can be retried; it must never corrupt the current plan.
• Agent revisions arrive as proposed operations and do not silently replace human-approved content.
• Serialize the current plan/revision into execution and feedback prompts so every runtime receives the same intent even before cross-runtime Salon MCP tools exist.

5. Sequential plan execution

• “Run approved plan” dispatches only dependency-ready nodes, one node/turn, through the current root conversation.
• Record a Salon execution ID and client-side submission sequence before sending the prompt.
• Capture starting branch, HEAD and changes sequence before each node.
• Refresh on tool completion events (debounced) and at turn completion using the existing sandbox diff/file APIs.
• Capture ending branch, HEAD, changes sequence, result summary and error/interruption state.
• Require the execution prompt to commit a completed node so its evidence has a stable boundary where practical.
• Show node-specific evidence by diffing from the recorded starting HEAD rather than only showing the cumulative base-branch diff.
• Preserve evidence beyond the current global twenty-snapshot pruning policy.
• Infer the resulting Fountain turn conservatively from serialized user-turn order for now; mark the binding as inferred so it can be upgraded by the follow-on issue.

6. Conformance, not blanket code review

• After execution, evaluate every acceptance criterion as pass | fail | unknown, with links to evidence.
• Separate deterministic evidence (branch, diff, checks, test output when present) from the model's claims.
• Highlight files changed outside the node's declared scope and unexplained changes.
• Keep the existing Changes/Files pane as the detailed evidence view.
• Add an explicit exception-review state for failures, sensitive files, unknown criteria and plan drift.

Acceptance test

Two members in one project chat can:

1. see and edit the same mutable plan;
2. comment without creating model turns;
3. approve an exact revision;
4. execute one approved node;
5. see who approved, launched, interrupted or answered a permission;
6. inspect that node's resulting changes rather than only the cumulative branch diff; and
7. see pass/fail/unknown for every acceptance criterion.

Explicitly deferred

• Exact prompt-response-to-turn identity: Conversations: return a durable turn identity when a prompt is accepted BinaryBourbon/fountain#1406.
• Removing the MCP substitution workaround: ACP: send the substituted MCP configuration on session/new BinaryBourbon/fountain#1404.
• Agent-native plan tools on every runtime: Runtimes: conversation-authenticated HTTP MCP servers across every ACP runtime BinaryBourbon/fountain#1405.
• Concurrent child agents in isolated worktrees and a surfaced execution tree: follow-on Salon issue.
• A full editor, terminal, CRDT document or freeform-canvas-first planner.