Retire unused Todo coordination command paths

docs/architecture/rfcs/human-attention-wishlist-v0.md

@@ -59,7 +59,8 @@ The current seams do not compose into that outcome:
 - an open `user_action` can enter the user notification channel even when it is
   non-blocking;
 - `todo suggest` creates a read-only candidate queue that requires later
-  promotion, while `todo capture-followups` writes only agent work;
+  promotion; the retired `todo capture-followups` command wrote only agent
+  work and never provided a human-wish route;
 - the compact turn envelope carries required execution and writeback actions,
   but no signed optional sidecar hint.
 
@@ -168,10 +169,11 @@ It must:
   `duplicate_updated` result;
 - perform no quota spend and claim no delivery progress by itself.
 
-The exact command name is open to implementation review. The behavior above is
-the contract; extending `todo capture-followups` is acceptable only if it keeps
-agent follow-up and human-wish routing explicit and cannot silently change the
-role or task class.
+The exact command shape is open to implementation review. The behavior above
+is the contract. The retired `todo capture-followups` batch command is not an
+extension point; a future implementation must use a typed wish-specific helper
+or an explicit canonical `todo add` option that cannot silently change role or
+task class.
 
 ## 5. Skill and Heartbeat Generation Rule
 
@@ -400,8 +402,8 @@ contract.
 
 ## 14. Open Questions
 
-1. Should the helper be `todo capture-wishes`, or should the existing
-   `capture-followups` command accept an explicit destination kind?
+1. Should the helper be `todo capture-wishes`, or should canonical `todo add`
+   accept an explicit human-attention kind?
 2. Should v0 cap active wishes per agent, per goal, or both?
 3. Should piggyback delivery be part of the initial slice, or should the first
    implementation expose wishes only through status/review packets?

docs/architecture/rfcs/human-attention-wishlist-v0.zh-CN.md

@@ -40,7 +40,8 @@ LoopX 已经区分阻塞性的 `user_gate` todo 与非阻塞的 `user_action` to
 - heartbeat 指南要求记录高价值候选，却没有定义 wishlist 写命令或生命周期；
 - `todo_write_hint` 提供 gate、user-action 和 agent-todo 模板，却没有“不通知的可选人类请求”模板；
 - 一个打开的 `user_action` 即使非阻塞，也可能进入用户通知通道；
-- `todo suggest` 只产生只读候选队列，还需要后续 promotion；`todo capture-followups` 则只写 agent work；
+- `todo suggest` 只产生只读候选队列，还需要后续 promotion；已退役的
+  `todo capture-followups` 只写 agent work，从未提供 human wish 路由；
 - compact turn envelope 带有必须执行的动作和写回，却没有签名过的可选 sidecar 提示。
 
 结果是一种可以避免的生产偏差：agent 要么把可选价值升级成 blocker，要么制造提醒噪音，要么遗忘它。
@@ -124,7 +125,9 @@ loopx todo capture-wishes \
 - 限制每个 agent 的活跃 wish 数，并返回 typed `max_items_exceeded` 或 `duplicate_updated` 结果；
 - 自身不 spend quota，也不声明 delivery progress。
 
-精确命令名留给实现评审。以上行为才是协议；只有在能保持 agent follow-up 与 human wish 路由显式、且不会静默改变 role/task class 时，才可选择扩展 `todo capture-followups`。
+精确命令形态留给实现评审。以上行为才是协议。已退役的
+`todo capture-followups` 批量命令不再作为扩展点；未来实现必须使用 wish 专属的
+typed helper，或为 canonical `todo add` 增加不会静默改变 role/task class 的显式选项。
 
 ## 5. Skill 与 Heartbeat 生成规则
 
@@ -292,7 +295,7 @@ v0 拒绝。它会扩大每个 task-class switch、CLI validator、state project
 
 ## 14. 开放问题
 
-1. Helper 应命名为 `todo capture-wishes`，还是让现有 `capture-followups` 接受显式 destination kind？
+1. Helper 应命名为 `todo capture-wishes`，还是让 canonical `todo add` 接受显式 human-attention kind？
 2. v0 应按 agent、按 goal，还是同时限制 active wish？
 3. Piggyback 呈现应进入初始切片，还是第一版只通过 status/review packet 暴露 wish？
 4. 在专用 typed outcome 出现前，哪一个 public-safe lifecycle field 最适合记录用户的显式 decline？

docs/architecture/rfcs/shared-goal-authority-state-provider-v0.md

@@ -2107,16 +2107,16 @@ Per stage, this increment implements:
   failures, and zero skips.
 - Stage 2C observation foundation: seven `s2c1.*` rows port the local-shadow CLI
   E2E and migration assertions and pin the single-lineage guarantee. The configure round trip previews, enables,
-  reads back, and disables the observer; every writer family (handoff-mode,
-  todo add/update/complete/supersede/capture-followups/archive-completed,
+  reads back, and disables the observer; every retained writer family (handoff-mode,
+  todo add/update/complete/supersede/archive-completed,
   task-lease acquire/renew/transfer) captures with
   `primary_writeback_preserved`, `provider_to_local_writes=false`, and
   `candidate_read_for_decision=false`, while an idempotent re-acquire does not
   observe; default-off goals stay isolated; candidate failure preserves the
   primary commit; a POSIX SIGKILL in the crash gap loses only that
   observation; a `--runtime-root` override that differs from
-  `common_runtime_root` keeps todo add, task-lease acquire, todo update,
-  follow-up capture, and a leased completion in one store identity while the
+  `common_runtime_root` keeps two todo adds, task-lease acquire, todo update,
+  and a leased completion in one store identity while the
   registry root gains neither a candidate lineage nor lease state; and
   `migrate-state` seeds a fresh lineage without legacy bytes.
 - Stage 2C parity half: ten `s2c2.*` rows drive one explicitly enabled
@@ -2133,8 +2133,8 @@ Per stage, this increment implements:
   as `bootstrap_required`, rebootstraps a fresh lineage and replays; three
   cycles of interleaved writers (add, note update with a no-change repeat,
   explicit exclusion set and clear with a no-change repeat, acquire, renew,
-  transfer, leased complete and supersede with their fence closes,
-  capture-followups) keep every bounded qualification matched with
+  transfer, leased complete and supersede with their fence closes, and a
+  second add) keep every bounded qualification matched with
   `sustained_parity_verdict=not_evaluated`; a
   direct primary edit reports `shadow_projection_drift`, a later write holds
   on `source_partition_continuity_unproved`, and only rollback plus rebootstrap
@@ -2802,6 +2802,15 @@ one-way projections. Do not add a third TS-Markdown backend, bidirectional
 live synchronization, or per-command split authority. Unsupported post-cutover
 commands fail closed; they do not fall back to the old writer.
 
+The 2026-09-19 command-retirement checkpoint removes the unconsumed
+`coordination.local_authority.mutate` and Todo compatibility-edit execution
+wrappers while retaining `prepareCoordinationProjectionCommit` and the shared
+reducer used by live domain transactions. It also removes the unrelated public
+`todo capture-followups` product command. That command retirement does not
+remove, weaken, or rename the runtime shadow-capture mechanism described here.
+`todo suggest` remains a manual read-only discovery entrypoint and is not part
+of provider promotion qualification.
+
 #### Refactoring roadmap overview
 
 The Monitor state owner now lives in TS and is composed with authoring scope,

docs/architecture/rfcs/shared-goal-authority-state-provider-v0.zh-CN.md

@@ -1678,14 +1678,14 @@ CLI runner、observation-lock 窗口、候选回读）、只读 TypeScript 探
   PostgreSQL 集成测试文件，要求至少九个 pass、零 fail、零 skip。
 - Stage 2C 观察基础：七个 `s2c1.*` 行移植本地 shadow CLI E2E 与迁移断言，并钉住单一
   lineage 保证。
-  configure 往返先预览、再开启、回读、最后关闭 observer；每个 writer family
-  （handoff-mode、todo add/update/complete/supersede/capture-followups/
+  configure 往返先预览、再开启、回读、最后关闭 observer；每个保留的 writer family
+  （handoff-mode、todo add/update/complete/supersede/
   archive-completed、task-lease acquire/renew/transfer）都以
   `primary_writeback_preserved`、`provider_to_local_writes=false`、
   `candidate_read_for_decision=false` 完成 capture，而幂等 re-acquire 不产生
   observation；default-off goal 保持隔离；候选失败不推翻主写；POSIX SIGKILL
   落在崩溃间隙时只丢失该次 observation；`--runtime-root` 与 `common_runtime_root`
-  不同时，todo add、task-lease acquire、todo update、follow-up 捕获与带 lease 的
+  不同时，两次 todo add、task-lease acquire、todo update 与带 lease 的
   complete 仍落入同一个 store identity，registry root 既不产生候选 lineage 也不
   产生 lease 状态；`migrate-state` 在不携带 legacy 字节的前提下建立新 lineage。
 - Stage 2C parity 后半段：十个 `s2c2.*` 行只通过公开 CLI 驱动一个显式开启
@@ -1699,7 +1699,7 @@ CLI runner、observation-lock 窗口、候选回读）、只读 TypeScript 探
   条目、把 capture 置于 `bootstrap_required`、重新 bootstrap 出新 lineage 并可重放；
   三轮交错 writer（add、note update 及其无变化重复、显式 exclusion 设置与清除及其
   无变化重复、acquire、renew、transfer、带 lease 的 complete 与 supersede 及其
-  fence close、capture-followups）让每次有界 qualification 都保持 matched，且
+  fence close，以及第二次 add）让每次有界 qualification 都保持 matched，且
   `sustained_parity_verdict=not_evaluated`；
   直接改主文件会报告 `shadow_projection_drift`，其后的写入以
   `source_partition_continuity_unproved` 挂起，只有 rollback 加重新 bootstrap 才能恢复；
@@ -2223,6 +2223,13 @@ CLI / Agent / Dashboard → 唯一 TS Todo 事务 owner → canonical authority
 供数；cutover 后，所选 canonical provider 向单向投影供数。不增加第三种 TS-Markdown
 backend、实时双向同步或按命令拆开的权威；晋升后不支持的命令 fail closed，不能回退旧 writer。
 
+2026-09-19 命令退役检查点删除了无人消费的
+`coordination.local_authority.mutate` 与 Todo compatibility-edit 执行包装，同时保留
+实际领域事务仍复用的 `prepareCoordinationProjectionCommit` 与共享 reducer；另行删除
+无关的公开产品命令 `todo capture-followups`。后一个命令的退役不删除、不削弱、也不
+重命名本 RFC 的 runtime shadow-capture 机制。`todo suggest` 继续作为人工触发的只读
+发现入口，不纳入 provider promotion 资格。
+
 #### 重构主线总览
 
 Monitor 状态 owner 现位于 TS，并与 authoring scope、external-wait 校验及字段更新

docs/architecture/rfcs/typescript-control-plane-migration-v0.md

@@ -975,6 +975,16 @@ readers but does not finish Todo writers, retention/compaction or promotion.
 
 **T4 — collect full-writer retirement after durability cutover.**
 
+- The 2026-09-19 command audit retires two already-typed but unconsumed
+  execution surfaces: `coordination.local_authority.todo_compatibility_edit`
+  and `coordination.local_authority.mutate`. Shared projection reduction and
+  commit preparation remain because live claim, lease, update, archive,
+  monitor, and team-plan transactions use them. The same audit retires the
+  unused public `todo capture-followups` batch command instead of migrating it;
+  ordinary `todo add` remains available but is not claimed to preserve the
+  retired command's atomic batch, deduplication, or replay contract. The
+  read-only, manually invoked `todo suggest` surface remains, but is not a
+  provider-default prerequisite.
 - Depends on T1–T3 and the shared RFC's [D1–D3](shared-goal-authority-state-provider-v0.md#durability-execution-cards), including owner approval
   and the explicit legacy migration window. Search remaining imports and
   public command routes before deleting old Markdown business writers,

docs/architecture/rfcs/typescript-control-plane-migration-v0.zh-CN.md

@@ -757,6 +757,14 @@ T3/D1 reader，未完成全部 Todo writer、retention/compaction 或 promotion
 
 **T4 — durable cutover 后兑现完整 writer 删除。**
 
+- 2026-09-19 命令审计退役两条已经 typed、但没有实际消费者的执行面：
+  `coordination.local_authority.todo_compatibility_edit` 与
+  `coordination.local_authority.mutate`。claim、lease、update、archive、monitor
+  和 team-plan 事务仍复用 projection reduction 与 commit preparation，因此这些
+  公共内核保留。同一审计直接退役无实际调用的公开批量命令
+  `todo capture-followups`，不再为它继续迁移；普通 `todo add` 仍可用，但不宣称保留
+  已退役命令的批量原子性、去重或 replay 合同。人工触发、只读的 `todo suggest`
+  保留，但不是 provider 默认切换的前置条件。
 - 前提是 T1–T3 和 shared RFC 的 [D1–D3](shared-goal-authority-state-provider-v0.zh-CN.md#持久化执行卡)，包括 owner 批准及明确的 legacy 迁移窗口。
   搜索剩余 import 和公开路由后，删除旧 Markdown 业务 writer、capture-only adapter、
   重复 reference aggregate。

docs/reference/protocols/todo-suggestion-prompt-v0.md

@@ -9,6 +9,12 @@ frequency limits. The project agent reads the current repo and returns
 `suggested_todos`; those candidates are not formal LoopX todos until the user
 or primary controller promotes one.
 
+This is intentionally a manual, read-only discovery surface. It is retained
+even without automatic product callers because an explicit operator request is
+its product entrypoint. It is not a provider-default or TypeScript-migration
+prerequisite, and it should not gain a dedicated write path unless a real
+replacement interaction is first accepted.
+
 ## Command
 
 ```bash