fix(coordination): drop orphaned leases from the candidate head

[songoow]

Behavior

Fixes #4315. With shadow capture enabled, archiving a completed leased Todo no longer leaves orphan lease edges in the candidate head. Subsequent acquire and fenced completion also preserve inspect/qualify/read-candidate availability; retained lease files stay on disk for audit.

Implementation

• Todo partition folds retain lease edges only for the active Todo graph.
• Lease capture filters retained files against the caller's source-stable graph.
• After a Todo write, shadow-enabled fence_close reads fresh authority facts and revalidates their source receipts in TypeScript before capturing the lease release. It does not reuse the pre-write verification snapshot. Default-off cleanup adds no graph read.
• The former pending Stage 2C2 archive row is executable and now continues through successor acquire, fenced completion, drain, qualification and candidate readback.

The bounded ownership pass keeps eligibility and persistence in existing TS owners; Python only collects and transports the existing source facts. No provider defaults, promotion policy, source continuity guards or audit retention rules are relaxed.

Validation

• 30 focused TS tests passed.
• 66 related lease/CLI/fence parity tests passed.
• Extended real CLI/FileAuthorityStore ladder: failed before this correction, passed afterwards, including successor completion.
• LoopX premerge passed with installed pytest; Ruff and diff hygiene passed.
• Local full TS typecheck could not be qualified: available global compiler is older than the repository requirement and dependency installation failed. The exact-head CI typecheck remains the gate.
• This is bounded FileAuthorityStore evidence, not a PostgreSQL qualification or a ten-day soak.

Entry points affected: Todo/task-lease CLI and shadow operator readbacks. No frontend configuration change is needed: the shadow opt-in and payload contracts are unchanged.

[huangruiteng]

结论：REQUEST_CHANGES

审阅绑定的 exact head：e8256e85cbc90957e2f20a7b665fa120ccd14d6e

动机

这个修复瞄准的是一个真实且高成本的 parity 缺口：在 hard_lease 流程中，lease 文件作为审计历史会继续留在磁盘上，但 Todo 被 archive-completed 移出当前图后，source projection 会过滤掉这条 lease；旧的 TypeScript candidate capture 却继续保留它，于是 coordination-shadow inspect 进入 shadow_projection_drift，后续 qualify / read-candidate 被阻断。修复方向是对的，而且没有通过删除审计文件或放宽 source 语义来掩盖问题。

改动思路

本 PR 在两个可能的写入顺序边界上对齐同一条 referential-integrity 规则：lease partition capture 根据调用方已经读取的当前 Todo id 集合过滤历史 lease；Todo partition fold 在 Todo 离开图时同步删除 candidate 中对应的 lease edge。task_lease_acquire 使用同一份 source-stable authority facts，lifecycle 在 authority facts 缺失时传 null，保留旧的严格行为而不猜测图状态。这两个边界都需要：只改 lease capture 会漏掉“先有 lease、后 archive”的 fold，只改 Todo fold又会漏掉后续 lifecycle capture 重新读入历史文件。

具体改动

关键代码讲解

1. readLeasePartition（local_authority_shadow_outbox.ts:177）新增 activeTodoIds，扫描目录时跳过不在当前图中的已存 lease；planned lease 仍由当前已授权写入覆盖。这里使用精确 Todo-id 集合，而不是文本启发式。
2. composeLocalAuthorityShadowHead（local_authority_shadow.ts:698）在 Todo partition 到达时重建 Todo id 集合，并过滤已有 candidate leases，保证无论分区到达顺序如何都不会留下 orphan edge。
3. executeTaskLeaseAcquire / lifecycle capture 将已经解码的 authority Todo 集合传到 outbox；缺少 authority 的 cleanup 路径继续采用 null，避免不完整投影被误当成“没有 Todo”。

本地对 exact head 跑了两个相关 TypeScript 测试文件，30/30 通过；control-plane typecheck 与 git diff --check 通过；远端 25 个检查均成功。运行时实现和单元级 mutant sensitivity 看起来合理。

对主干的风险

仍有一个阻塞交付的问题：PR 正文声称“closes s2c2.archive_after_leased_completion_parity”，但仓库当前仍把这个 exact case 保留在 PENDING_ROWS / PENDING_ROW_IDS，PARITY_REQUIRED_WRITE_CLASSES 的注释也仍明确排除 todo archive-completed，README/correctness 文档继续宣告该缺口未关闭。也就是说，当前全部 CI 可以在从未执行 acquire -> fenced complete -> archive -> inspect/qualify 这条真实 CLI 链路的情况下变绿；两个 helper 测试不能覆盖 source snapshot、outbox drain、candidate compare 与 qualify 的组合。

最低修复是把 s2c2.archive_after_leased_completion_parity 从 pending declaration 转成 deterministic executable LadderRow，从 pending expectations 中移除，更新对应 README/correctness 说明，并证明删除 capture filter 或 Todo-fold filter 任意一个都会让该真实路径失败。这样“关闭 gap”才是仓库可持续验证的事实，而不是只存在于 PR 描述里的手工观察。

我的整体评价

实现本身小而聚焦，状态/权限边界也基本正确；我没有发现需要扩大生产机制的理由。当前不能批准的原因是 delivery completeness：这个 PR 要关闭的就是既有 Stage 2C2 gap，但它没有把 gap 变成可执行回归，甚至保留了“仍 pending”的机器事实。补齐真实 CLI row 和 stale declarations 后，我会按同一 exact head 重点复审该 row 的 baseline/head 与 mutant 证据。

English verdict: REQUEST_CHANGES — the runtime fix is well-scoped, but the exact Stage 2C2 archive-after-leased-completion case remains explicitly pending and unexecuted, so green CI does not yet prove the claimed gap is closed.

[huangruiteng]

Additional exact-head blocker (distinct from the existing Stage 2C2 coverage finding), verified at e8256e85cbc90957e2f20a7b665fa120ccd14d6e:

composeLocalAuthorityShadowHead builds graphTodoIds from every record in projection.todos. That array can retain canonical archived Todo records (archive_state: "archive"), while both build_todo_runtime_shadow_projection and the TypeScript source verification define the current graph as archive_state === "active". Therefore an archived Todo id still matches its retained lease, the candidate keeps the lease, and source/head parity can continue to report shadow_projection_drift.

I reproduced this directly against the production function: passing {todo_id: "t", archive_state: "archive"} plus the released lease returns the lease unchanged. The new test uses projection([]), so it misses the actual archived-record representation.

Minimum repair: construct the candidate-head set from only archive_state === "active" Todos (preferably through the same typed membership rule as the source projection), and change the regression test to keep an archived Todo record while asserting the lease is removed. This should be fixed alongside the executable Stage 2C2 row requested in the existing review.

[songoow]

Rebased onto current main and addressed both blocking points at new head fe6843fe9.

1. Archived Todo records retained in the candidate set. You were right that composeLocalAuthorityShadowHead built its id set from every record in projection.todos, and that array can retain canonical archived rows (archive_state: "archive"), so an archived Todo id still matched its retained lease. The fold now derives the current graph from archive_state === "active" through one shared currentGraphTodoIds helper, matching the rule build_todo_runtime_shadow_projection and the TypeScript source verification already apply. The regression test now keeps an archived Todo record and asserts the lease is removed; the old test used projection([]) and missed the real representation, so it could not have caught this.

2. The Stage 2C2 gap is now an executable deterministic row. s2c2.archive_after_leased_completion_parity moved out of PENDING_ROWS into LADDER_ROWS as a real-CLI row. It drives todo add -> task-lease acquire -> todo complete (fenced) -> todo add -> todo archive-completed -> todo add -> task-lease acquire and asserts matched parity, no drift reason, a bounded qualification that requires the archive event kind, a qualified candidate read of a co-resident open Todo, and that both the archived Todo's audit lease and the successor's live lease stay on disk. The stale declarations in the README, correctness doc, both RFC copies and PARITY_REQUIRED_WRITE_CLASSES are updated.

Two things I want to flag rather than overstate.

First, mutation evidence, because it changed my understanding of the fix. I applied the patch to a clean upstream checkout and mutated each rule separately:

• clean upstream: drifted / qualify: False
• fold filter only (raw id set, no active check): matched / qualify: True
• outbox filter removed, fold present: matched
• both removed: drifted

So the fold is load-bearing for the archive path, and the archived-row active check is defensive, not load-bearing — an archived row does not reach the published Todo partition in this chain (todo_archive_completed publishes todos: [] when the archived Todo was the only one, because the capture carries only current-graph rows). I kept the active check because it is the rule the source applies and it costs nothing, but I am not claiming it fixes an observed failure. The row does pin both rules: removing either the fold filter or the outbox filter fails it.

Second, your reproduction note about --max-active-done. The issue's steps omit it, and the default threshold is 10, so archiving a single completed Todo is a no-op (changed: false) and no drift appears. The row passes --max-active-done 0 explicitly for that reason.

Verification at fe6843fe9: the row fails on the unfixed tree and passes with the fix; the two shadow TS files are 30/30; test_shared_goal_authority_e2e.py is 23 passed, 8 skipped; Ruff findings are unchanged from the upstream baseline (6 pre-existing, none in the changed files).

[songoow]

Rebased onto e743f2404 (head 2edda6666) after #4348 landed canonical lease renewal, since that PR changes task_lease_lifecycle.ts — the same file this one touches.

No conflict, and I checked the interaction rather than assuming: #4348's canonical renew path reaches the outbox through the existing captureLeaseWrite, which is one of four call sites that already carry the active_todo_ids graph this PR added, and beginLeaseOutboxEntry still has exactly two callers (task_lease_acquire.ts and task_lease_lifecycle.ts), both passing it. So the new renew path inherits the filter rather than bypassing it.

Re-verified on the new base: both scenarios still report matched parity through the real CLI (complete-then-archive, and archive-then-acquire-a-new-lease), the two shadow TypeScript files are 30/30, and the executable ladder row plus the registry vocabulary test pass.

[songoow]

Request changes conclusion (author-owned PR; GitHub blocks formal self-review)

审查 head：2edda6666cc5368e8e3882e89b3d6cc1de0b2904。结论：REQUEST_CHANGES。

动机

归档释放后的租约 Todo 不应破坏 shadow 候选头的引用完整性，更不能阻断后续 qualify/read-candidate。两处过滤确实修复了初次归档以及归档后再 acquire 的场景。相比删除审计文件或放宽 source 校验，在既有捕获/折叠边界修复是合理方向；但“后续租约生命周期仍可持续运行”的承诺尚未成立。

改动思路

完整路径为公开 Todo/task-lease CLI → authority facts → TS lease capture → outbox drain/partition fold → FileAuthorityStore → inspect/qualify。源侧当前图仍是权威，候选状态不参与执行授权。本轮相对上次评审已经加入 active membership 条件，并把 pending 行改成真实 CLI ladder 行；这些修改已核实。仍需检查没有 authority facts 的 fence-close 分支，它也是普通 Todo completion 的必经生产路径。

具体改动

运行时改动覆盖 local_authority_shadow.ts、local_authority_shadow_outbox.ts 与 acquire/lifecycle 两个调用方；ladder/row 实现、Python/TS 测试与四份 RFC/示例文档同步更新。没有改变 provider 默认开关或删除磁盘审计记录。

关键代码讲解

• composeLocalAuthorityShadowHead 在 todos 分区折叠时按 active Todo 图移除孤立 lease，初次归档验证通过。
• readLeasePartition 在 activeTodoIds != null 时过滤历史文件，并用同一集合计算当前/之前分区摘要。
• captureLeaseWrite（task_lease_lifecycle.ts:523-525）在 authority 缺失时传 null。上游 Python adapter 的 needs_authority 包含 terminal_verify/holder_verify，却不包含 fence_close；因此此处的 null 是正常完成路径会走到的分支，而不只是异常环境兜底。
• 新 ladder 行结束于 successor acquire，未继续完成 successor，恰好漏掉该分支。

对主干的风险

[P1] 归档后第二个 Todo 的 fenced completion 再次堵塞 outbox。

在此 exact head，用 disposable fixture 和真实 FileAuthorityStore/公开 CLI 执行：

1. Todo A：acquire → fenced complete → archive-completed（--max-active-done 0 --execute）。inspect 为 matched。
2. Todo B：add → acquire。仍正常。
3. Todo B：fenced complete，命令返回 ok=true。
4. inspect 变成 drifted / outbox_pending；显式 authority-shadow drain 返回 source_partition_continuity_unproved、pending_after=1；qualify 的 ok 和 parity_matches 均为 false。

原因是 B 的 fence-close 不带 authority，capture 又把 A 的历史租约读回之前分区，与此前已过滤的候选分区不一致。它不是 transient drain 延迟，显式 drain 也不能清掉。

最小修复：让 fence-close 获得与捕获时源状态一致、可验证的当前图，或在现有 TS owner 内统一派生该图；保持清理权限和源连续性守卫，不放宽摘要验证。把现有 ladder 扩展到 successor complete → drain → inspect/qualify。此处的有界后续重构应统一图规则的来源，而非继续增加独立补偿分支。

我的整体评价

本轮独立执行：相关 TS 30/30；新增 archive ladder 1/1；额外完整生命周期反例可复现。第一次 TS 调用的 Python 子进程落在旧解释器，换用 Python 3.11 的 PATH 后上述 30 项全过。远端此 head 的 checks 无失败，但测试成功未覆盖 successor fence-close。

实现范围合理，原评审修复确实落地；新的 P1 表明 #4315 尚不能宣告完整关闭。未执行十天 soak 或真实 PostgreSQL qualification，不把本次 FileAuthorityStore 证据扩展为 provider promotion。请修复上述生命周期缺口后重新审查。

English verdict: REQUEST_CHANGES at 2edda6666cc5368e8e3882e89b3d6cc1de0b2904. After archiving leased Todo A, acquiring and completing Todo B reintroduces A's retained lease through the authority-less fence-close capture. Explicit drain stops with source_partition_continuity_unproved; qualification fails. The 30 focused TS tests and new ladder row pass, but the real CLI continuation counterexample fails. Extend that row through successor completion and fix the shared capture boundary without weakening continuity checks.

[songoow]

修复提交：86640c16d11ffe390d3c9ebd8db80c6a284cf69f

已修复归档后 successor fenced completion 再次阻塞 drain：shadow-enabled fence_close 使用 Todo 写入后的 source-stable 图，并在 TS capture 前复核 source receipts。默认关闭路径不新增图读取；现有 ladder 已覆盖 successor complete → drain → qualify/read-candidate。

验证：30 个 TS + 66 个 lease/CLI/fence 测试、扩展 ladder 和 LoopX premerge 通过。

已重写 PR 正文以反映当前实现与边界。全部提交带 DCO sign-off；新的 CI 已触发，尚未宣告合并或批准。请按此 head 复审。

Fix follow-up: the reproduced findings are addressed at this exact head with regression coverage and repository-native premerge validation. CI is rerunning; this is a fix report, not an approval.

[steven-kid]

动机

合并后审计：发现新的 P1 回归，需要后续修复。 审查 head 为 86640c16d11ffe390d3c9ebd8db80c6a284cf69f，完整 base 为 e743f2404d4a17d52cbf2d15db1f879ff46caea8。该 PR 在本轮评审期间被合并，故发布审计，不提交合并前批准或请求修改状态。

#4315 的实际问题是：归档一个已完成且保留 released lease 文件的 Todo 后，source 当前图已去掉它，candidate 却仍保留该 lease，导致 parity/qualification 失效。保留审计文件而修正候选投影，比删除 lease 文件或放宽 continuity 校验更合理。相对旧评审 head 2edda6666cc5368e8e3882e89b3d6cc1de0b2904，本次补上 successor completion 的 source 图及真实回归；我独立确认原反例已修复，但新的 source revalidation 与 fence 重试生命周期不兼容。

改动思路

修改沿用两个既有 owner：Todo partition fold 按当前 active 图去掉孤立 lease；lease outbox capture 用调用方已读取的 authority Todo 集合过滤历史文件。源事实继续决定执行，FileAuthorityStore candidate 只做旁路观察，文档没有宣告 provider promotion 或十天 soak 完成。

搜索并比较 base/head 的 build_todo_runtime_shadow_projection、TS source verification、composeLocalAuthorityShadowHead、beginLeaseOutboxEntry 两个生产调用点，以及 Python/native fence close：图成员属于 canonical Todo 的派生事实，不是用户新增声明；active_todo_ids=null 仍表示来源不可用，不能当作空图。归档过滤和后续 lease capture 两处都需要修正，但源快照失效应能安全重试，不能破坏已经持有的 primary fence。最近相关 #4348 的 renew 已在 base 中，继续经过同一 capture owner；没有把它当作独立权限来源。

正向真实链路为 add A → acquire → fenced complete → add anchor → archive（显式 --max-active-done 0）→ inspect/qualify/read-candidate → add/acquire/complete successor → drain/qualify。新增 ladder 在 head 通过；把完全相同的行放到 base 的真实 CLI/backend 上执行，在 archive 后 parity 断言失败。修复确实有价值。

具体改动

关键代码讲解

1. local_authority_shadow.ts::currentGraphTodoIds/composeLocalAuthorityShadowHead 使用 archive_state === "active"，Todo partition 更新时过滤已有 leases；保留的 archived Todo 记录不应重新带回 live edge。它是 source 图规则的投影，不删除磁盘审计记录。
2. local_authority_shadow_outbox.ts::readLeasePartition/beginLeaseOutboxEntry 新增当前图参数；对 previous 与 planned partition 使用相同集合，以维持摘要连续性。acquire 从已解码 authority.todos 传入集合，lifecycle 复用同一入口；null 保持原有严格读取。
3. task_lease_acquire_adapter.py::execute_native_task_lease_lifecycle 为启用 shadow 的 committed/release fence_close 新读 source-stable authority；关闭功能时不增加这次图读取。task_lease_lifecycle.ts::captureLeaseWrite 随后复核 source receipts。下述回归发生在这次复核抛错后的锁清理和 adapter retry 之间。
4. authority_e2e_rows_stage2c2.py::row_archive_after_leased_completion_parity 已从 pending 变为真实 CLI 行，并延伸到 successor complete/drain/readback；authority_e2e_ladder.py、pytest row 注册同步。两个 TS 测试覆盖 archived-row fold 和 capture membership。两份 RFC、示例 README/correctness 更新 executable/pending 数量，保留 sustained soak 未验证边界。

全 diff 14 个文件 +272/-40，覆盖五个运行时文件、两个 ladder 实现文件、三个测试文件及四份文档。新机制主要是派生图过滤与 source 验证，没有新增持久 schema、CLI 或手工 lease 同步状态。

对主干的风险

[P1] source receipt 失效后，fence-close 重试失去原锁，完成的 Todo 留下 active lease。 定位：loopx/control_plane/work_items/task_lease_lifecycle.ts:513–514，并联看 fenceClose 的 finally 和 Python adapter 的 authority_source_changed retry。

真实 public CLI 对照：启用 runtime shadow，创建并 acquire 一个 Todo，再执行 fenced complete。在 fence_close RPC 发出前，用一个调度钩子对临时 registry JSON 追加换行，模拟 snapshot 读取后发生等价的并发 registry 重写。没有修改 authority 决策事实，没有替换 RPC 返回值或磁盘 lease；同一注入程序分别运行 base/head：

• base：fence_close 成功，Todo done，独立读取的 lease 为 released。
• head：首次返回 authority_source_changed，随后重试及 cleanup 返回 fence_token_invalid。外层仍返回 ok=true, completed=true，但 task_lease_fence.released=false，磁盘 lease 仍为 active。
• 相同输入关闭 shadow：base/head 均正常释放。故这是新增启用路径的行为回归，不是任意未持有 token 的非法调用。

原因是 revalidation 位于 fenceClose 已 claim 锁后的 capture 中；抛错进入 finally 释放该 token，adapter 随后却用同一个 held fence token 重试。既有 _close_native_fence 的 best-effort cleanup 保留 primary completion，并把失败表示为 released=false。此时 inspect/qualify 甚至仍能 matched/true，因为双方都看到同一 active lease；只看 parity 无法证明 primary lease 生命周期正确。恢复需要显式 release 或等待 TTL，不应由一次等价 registry 重写新增这种成本。

最小修复是在既有 fence owner 内保持 source 失效重试所需的 fence 生命周期，例如在消耗 claim 前完成可重试复核，或提供安全的同一 held fence 重试；不能跳过 continuity/source 校验，也不能把 shadow 失败作为 primary lease 残留的正常结果。增加真实 CLI 并发/失效回归，断言 lease 的独立磁盘读回，而非只断言候选 matched。

验证：相关 TS 30/30；lease Python/CLI 35 passed；新增 archive ladder 与 vocabulary 2 passed；Ruff 改动 Python 文件、diff check 通过。另执行了上述 base/head × shadow on/off 对照，以及同一 archive harness 的 base 失败。未执行完整 provider 矩阵、真实 PostgreSQL 或十天 soak，不把本次 FileAuthorityStore 证据扩展到 promotion。

我的整体评价

原 archive/fence-close gap 已经有可执行覆盖，生产修复方向和规模合理。但只读 shadow 增加的 source 检查现在改变了 primary fence 的失败恢复，仍需修复。该问题是本轮新复现的合并后发现，不重复旧评审已解决的问题；建议在既有 fence owner 中小范围处理重试并补上真实落盘断言。本审计不撤销既有合并，也不声称整体 provider qualification 完成。

English verdict: POST_MERGE_AUDIT_COMMENT at 86640c1. New P1: when the registry is equivalently rewritten after the fence-close authority snapshot, revalidation returns authority_source_changed after claiming the held lock; finally releases it, so retries return fence_token_invalid. Real CLI base/head comparison shows completed=true but released=false and an active on-disk lease only on head with shadow enabled. Both disabled paths release normally. Inspect/qualify can remain matched, so parity alone misses this primary-lifecycle regression. Preserve safe fence retry ownership without weakening source checks. The original archive/successor-completion row now passes; 30 TS tests, 35 lease/CLI tests, 2 ladder/vocabulary tests, Ruff and diff checks passed. Live providers/soak were not validated. The PR was merged by others during review; this is a new actionable post-merge audit.

[steven-kid]

English verdict: POST_MERGE_AUDIT_COMMENT at 86640c1. New P1: when the registry is equivalently rewritten after the fence-close authority snapshot, revalidation returns authority_source_changed after claiming the held lock; finally releases it, so retries return fence_token_invalid. Real CLI base/head comparison shows completed=true but released=false and an active on-disk lease only on head with shadow enabled. Both disabled paths release normally. Inspect/qualify can remain matched, so parity alone misses this primary-lifecycle regression. Preserve safe fence retry ownership without weakening source checks. The original archive/successor-completion row now passes; 30 TS tests, 35 lease/CLI tests, 2 ladder/vocabulary tests, Ruff and diff checks passed. Live providers/soak were not validated. The PR was merged by others during review; this is a new actionable post-merge audit.