docs: repair rewritten rationale and stale claims from the ACP reduction
The automation-only rewrite edited many implemented Agent Notes; several edits replaced still-live or historical rationale instead of reframing: - llm-model-catalog: restore the prompt/request consistency section and selection-ownership alternatives — installAgentLlmTarget and the TUI /model selector still ship that design; only the ACP wire is gone. - plan-specific-collaboration-state, acp-multi-session, todo-write, ask-user-question: link the superseding automation-only note instead of silently rewriting the original decision or motivation; drop a paragraph duplicating the Web-provider facts stated two paragraphs up. - sandbox: stop claiming unit coverage for turn-enclosed config writes (that mechanism left with the bridge) and retitle the commit-boundary paragraph accordingly. - Fix the missing blank line before '## Consequences' in the plugin-command-registration pair, the JSON-RPC/Web render-intent consumer misattribution (the second consumer is the host/client runtime), stale bash_output/bash_kill names, and 'optional goals' in architecture.md. - examples/acp-agent/README.md: point at the package contract instead of restating it; packages/ui/permission and plan-mode READMEs record the consumer-less preset service and the exit_plan_mode coverage gap under Known Limitations. - 2026-06-19-acp-snapshot-tests: the new note defers the corpus migration rather than committing to it; say so. Re-record the touched bilingual pairs.
This commit is contained in:
@@ -12,7 +12,7 @@ Add a model-facing `todo_write(todos: [{ content, status }])` tool whose whole-l
|
||||
|
||||
### Whole-list replace, three-state status
|
||||
|
||||
The model sends the entire list every call; the new list replaces the old (last-write-wins on replay). This is the shape claude-code V1, opencode, and codex `update_plan` all use, and the shape the model is most trained on — no per-item ids, no delta protocol. `status` is exactly `pending | in_progress | completed`, the same triple as codex `update_plan`.
|
||||
The model sends the entire list every call; the new list replaces the old (last-write-wins on replay). This is the shape claude-code V1, opencode, and codex `update_plan` all use, and the shape the model is most trained on — no per-item ids, no delta protocol. `status` is exactly `pending | in_progress | completed`, the same triple as codex `update_plan`; it also matched the ACP `PlanEntryStatus` 1:1 while the bridge projected todo lists as `plan` updates, a mapping retired with the [automation-only ACP contract](../simplification/2026-07-23-acp-automation-only-protocol.md).
|
||||
|
||||
### State on the session log, not a service
|
||||
|
||||
@@ -24,7 +24,7 @@ The list is appended as a `todo/write` event carrying the full `{ todos }` snaps
|
||||
|
||||
### Dropped vs claude-code V1: `activeForm`, id, priority
|
||||
|
||||
claude-code V1's item is `{ content, status, activeForm }`; later (V2) it grew ids, dependencies, and ownership — but only to support agent *swarms* (disk-backed, lock-guarded, per-item mutation). This tool keeps the item at the minimum: `{ content, status }`. No `activeForm` (the present-continuous label) — the UI shows `content`; no id — whole-list replace needs no stable identity; no priority — ordering is the only ranking the model controls. Each dropped field is one less thing the model must produce on every call.
|
||||
claude-code V1's item is `{ content, status, activeForm }`; later (V2) it grew ids, dependencies, and ownership — but only to support agent *swarms* (disk-backed, lock-guarded, per-item mutation). This tool keeps the item at the minimum: `{ content, status }`. No `activeForm` (the present-continuous label) — the UI shows `content`; no id — whole-list replace needs no stable identity; no priority — that was only ever an ACP `PlanEntry` wire requirement, synthesized as a constant at the bridge boundary rather than modeled, and it left with that projection. Each dropped field is one less thing the model must produce on every call.
|
||||
|
||||
### Single owner — no swarm machinery (YAGNI)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user