Cross-RFC implementation checkpoint¶
Moved without content change from capable-manager-semantic-handoff-v0.md (former section "4.1 Cross-RFC implementation checkpoint") on 2026-09-26; RFC baseline 3e443ad7c. Checkpoint records live in this ledger, not in the RFC body.
Rechecked origin/main at the implementation baseline above on 2026-09-13. These are source/history findings, not fresh deployment qualification. RFC status and shipped slices must be reported separately; an old index or a merged refactor title is insufficient.
| Contract | Verified foundation at this baseline | Still outside this RFC's delivery claim |
|---|---|---|
| TS migration | Accepted; Stage 1/2A foundations and active Stage 2B transaction cutovers. todos/public_update.ts, coordination/todo_update.ts, todo_monitor_poll.ts and structured consumers already own substantial semantics. |
T0–T4 are a continuing execution plan, not all completed. Native field/lease/monitor support remains bounded. Moving a planner to TS is not moving its commit. |
| Shared authority | Draft with implemented foundations. AuthorityStore defines conditional durable state/events/receipt commit, readback and scan. #4280, #4283, #4287 consolidate transaction, presentation and retained-journal semantics. File/NoKV and SQLite/PostgreSQL candidate paths exist. |
A provider implementation is not default promotion or a shared service. D1 projection, D2 profile qualification/soak and D3 fenced cutover retain their own evidence and approval conditions. |
| Shared Goal alignment/amendment | Draft with Stage 1/2 foundations: goals/shared_goal_alignment.{py,ts} reads the current work basis; goal_amendment_proposal.{py,ts} validates/retains proposals with no canonical effect. Their source basis includes canonical Todo/lease revision when promoted. |
Complete Goal-intent versioning, governed Stage 3 commit, verifier/lease-impact handling and its qualification are not supplied by proposal admission. An event sequence or Todo provider revision is not the full Goal revision. |
| Manager and handoff (#4330) | Existing manager inbox/context/tracking/return paths are the migration source; Section 4 identifies their owners. | Capable profile promotion, the general collaboration transaction and A1–A16 remain proposed. This RFC must consume the other owners rather than implement them again. |
Supplemental checkpoint at 6b337bcbde8457bc3268ec7d2780367ace3c6147: merged #4286 (c0b572d2d508bb10c32701057dd71ff4f8eb663c) adds coordination/command_receipt.ts as the shared recovery owner for canonical Todo commands and separates archive transactions into todo_archive.ts. Its File/SQLite/PostgreSQL/NoKV conformance matrix is reusable M2 foundation, not a capability to design again. Use the original-operation ambiguous recovery semantics when reconciling request/work commits. This removes duplicate TS transaction rules, not Python writers, T1/T2 gaps or D1–D3 promotion requirements.