Reconcile proven execution exit with durable claim retirement before integration admission #2375

Written-by: Codex

目标分支与负责人

• 实现/PR 目标分支：delivery/ai-centric-development-service。
• Assignee：@zy95-12。
• 关联 明确重启恢复窗口与 Chief inspect 失败分类，打通中断 Attempt 的安全恢复路由 #2347（重启恢复与 Chief 恢复路由）、Release project execution slots for confirmed-idle input waits and re-admit resumed work #2328（执行槽位/重新准入）、Reclaim orphaned unbound reserved leases from retired Attempts without releasing unknown executions #2336（租约与准入回滚）、Use role-bound GitHub App identities for SDK development, reviews and delivery reconciliation #2365（App 身份、候选及既有 PR 回写）。
• 本条记录新需求，不中断或替换主会话正在实施的工作，不授权清现场状态、重启服务或修改凭据。

问题与准确根因

用户报告：尝试 attempt.integration-bind 引入外部代码来源时，相关 worker/lease 已 released，但仍收到 Integration input is waiting for confirmed execution exit；现场常依靠重启后再次操作才能继续。

不是 claim.exitConfirmed=false 单独卡死 integration-bind。 核心缺口是：物理执行已有可信退出证明时，逻辑 claim 的责任态可能仍为 active，入口仍认为有执行主动权。应核验退出证明后，执行 claim 持久化退场 + 代次隔离，而非只补写布尔值或直接绕过门禁。

已核对的证据与现场边界

在交付代码 8e477670bb0e1c18383776a36062dc192d18be8c（已通过 PR #2362 合入交付分支）中，只读提取原 integrationReleased 函数，并调用真实 confirmedWorkerExit 做纯内存验证；未改现场/源码或启动服务：

上述最小探针证明 active claim 与退出事实之间的收敛缺口可阻塞准入，不证明现场那一次必然只由此导致。现场最终卡在 claim、退出证明还是其它 Chief 执行，仍需对应 Task/Attempt/worker/lease/Chief Run 快照核验。 不将 reported released 当作实际退出证明。

同时确认：

1. attempt.stop 当前设置 cancelRequested，是取消操作，不是“停一下再绑”；integration-bind 明确拒绝取消中的 Attempt，不能把 stop 用作原 Attempt 的暂停恢复。
2. 资源 reconcile 已由现有 scheduler 调用，并非只在启动时运行。重启解锁可能来自 pool.recover 把 active claim 改为 interrupted 并提升 generation，不得未经证据归因于 Docker reconcile。
3. integration-bind 登记的是 integrationInputs，不会自动创建 publicationBinding 或正式 candidateSha。外开 PR 的候选认领/关联继续由 Use role-bound GitHub App identities for SDK development, reviews and delivery reconciliation #2365 覆盖，本条不把代码来源准入冒充 PR 绑定。

实现范围

1. 退出事实与责任态的统一对账

• 复用现有 worker/lease/原生 Agent 的可信退出核验能力，统一判断物理退出；不以 resource occupied=0、status=released 或 claim.exitConfirmed 单字段代替完整证明。
• 核验精确 Project/Task/Attempt、worker、lease、resource、claim/generation 关联，覆盖正常 SDK stop ack + process exit、已证明未启动的注册、受支持的监督器退出证明及原生执行退出协议。
• 对“物理已退出、原 claim 仍 active”的情形，在合法恢复动作中持久化退场旧 claim、记录退出证据引用与恢复原因，并 fence 旧代次；保留 Handoff/Session/Attempt 历史和候选草稿。
• 模型 turn 完成不等于责任已交出：先对账待处理结果、持久回执和未知外部写入，不能因进程空闲就自动放弃合法责任。
• 退场与代次变化必须有可靠提交边界；保存失败、提交结果未知或并发新 claim 出现时，不放行 integration-bind，不覆盖新责任或伪造完成。
• 旧 Session 的迟到结果、重复退出回调、重复恢复请求和重启必须幂等，不能再推动原代次的业务动作。

2. 集成准入与安全恢复动作

• integration-state/bind 与 Chief 恢复使用同一份当前对账事实；区分逻辑责任未退场、worker 退出未知、lease 未释放、其它 Chief 执行、preparation 未确认退出及状态/代次过期。
• 提供/复用不取消原 Attempt 的受权恢复动作，使授权主体在退出已证实后能让原未封候选 Attempt 进入可绑定来源的状态；具体接口在实现中与现有恢复能力收敛，不另造任务存储或调度器。
• attempt.stop 保持明确的取消语义；已取消 Attempt 不被本条悄悄复活。继续交付需要现有明确恢复/后继 Attempt 契约。
• 放行前后重新核验当前权限、Task/Attempt、generation、workspace snapshot、输入 ref/SHA 和已有来源；不能用历史退出证明关闭新启动的 worker。
• 整体动作完成后，再用当前 generation 和 workspace snapshot 执行 integration-bind；不得沿用退场前的过期快照。
• 不自动选择下一角色或转人工。向 Chief 提供事实与合法动作，由 Chief 判断后续；不以重启/直接编辑 state JSON 作为正常恢复步骤。
• 不把新的外部代码来源自动当作已封候选、测试通过、PR 认领或 publicationBinding。

3. stop/reconcile 的可观察性

• 单次 stop/恢复调用如不能完成，返回具体尚未满足的对象、阶段、证明与可行动作；不能仅返回笼统“waiting for confirmed execution exit”。
• 区分 stop-requested、执行已退出、lease 已释放、claim 已退场、可集成、取消完成，保持 activeSlots 与 occupied 的不同语义。
• 确认现有 scheduler 的持续 reconcile 能收敛已确认退出后的逻辑责任，不要求 host restart；真实独立 Docker/SDK 退出未知时仍保留安全门禁。
• 私有进程/工作区证据按现有权限暴露，不返回凭据、其它 Task 的上下文或任意宿主操作入口。

验收与测试

• 有可信退出证明且 lease released、claim 仍 active 的最小复现：受权恢复后旧 claim 持久退场/代次失效，更新快照后可 integration-bind，无需重启。
• 单改 exitConfirmed=true 无法绕过；假 released、缺失/不匹配的 worker/lease/resource/generation 证明继续拒绝。
• waiting-human/interrupted/incomplete 等状态按当前退出事实判断，不因缓存 false 误拒；仍存活/退出未知的执行不误释放。
• stop 是取消；stop 后不能偷偷在原取消 Attempt 上继续绑定，恢复/后继路径及错误提示明确。
• 活跃或退出未知的其它 Chief、未结束 preparation、权限撤销、workspace/ref 移动和过期快照都有明确拒绝原因。
• 保存失败、重启、重复恢复、退出回调与准入并发、新 claim 已出现、旧结果迟到及未知外部写入不导致重复派工、越权或证据丢失。
• 隔离本地/Docker 执行链验证“退出 → 责任对账 → 重新取快照 → 来源准入”，记录 actual SDK 与 fixture 的界限；不修改现场，不以 occupied=0 代替退出验证。
• integrationInputs 与 candidateSha/publicationBinding 的语义分离有回归用例，Use role-bound GitHub App identities for SDK development, reviews and delivery reconciliation #2365 的外部 PR 回写通过明确契约衔接。
• 更新长期记忆、Task/claim/退出与集成架构、恢复运维说明、错误/状态接口及受影响的 OpenAPI。

不在本条授权范围

不清空 bindings，不强制标记未知 worker released，不复活已取消 Attempt，不用重启掩盖状态缺口，不绕过候选/测试/Review 门禁；不修改 control-plane/UI、现场资源、凭据、仓库保护或部署。现场那次根因在证据补齐前保持待核实。