Repository navigation
Decouple Attempt acceptance from Task completion and expose scoped Chief delivery choices #2526
Description
Written-by: Codex
目标与授权边界
- 实现/PR 目标分支：
delivery/ai-centric-development-service；负责人 @zy95-12。 - Owner 在工作会话中确认本方案并要求更新 Issue、直接开发；同步长期记忆、架构/接口文档与测试。
- 本次只交付源码，不授权现场部署/重启、手改任务/binding/凭据、打断前端流程或付费模型测试。
已确认的问题
当前 Chief 的 close → chiefAccept → accept 将 Attempt 验收与 Task 完成耦合；缺少“认可本轮产物但整个 Task 继续”的能力。新一轮 start/rework 又会尝试沿用上一轮 publicationBinding，已合 PR 被正确拒绝。因此只加提示词或 nextActions 不能解决问题。
Owner 确认的设计
1. 分开本轮验收与整个 Task 完成
Chief 可以基于当前候选、测试、Review、provider-confirmed merge、需求与未处理输入证据验收当前 Attempt，记录交付范围/依据和剩余工作，保持原 Task 未完成；不能把 PR 已合入自动等同于业务验收。Task 全部验收条件满足时仍允许 Chief 关闭，不一概禁止 close。
下一轮由 Chief 显式决定，复用原 Task/Task-role 上下文及既有配额/执行入口，创建新 Attempt 和新发布分支；保留旧 PR/候选/验收历史，但不继承已合 PR 的发布绑定。不得通过 reopen 已完成 Task、手清 binding 或重启冒充正常流程，也不另建“切片”领域对象/额外 GitHub Issue。
基线必须是经核验的目标分支提交，并包含已合成果；不能把宿主固定仓 HEAD 自动当作最新目标分支。缺对象/权限/远端结果未知应明确反馈，不能猜测或覆盖草稿。
2. 当前事实快照及动作预检
复用现有 Chief snapshot、Store、作用域与代次/证据哈希。按 Task 复制本地相关事实，必要外部查询后复验相关版本；不混用新旧事实，不追求跨 GitHub/执行器的全局事务。快照是项目事实，不是 SDK 会话历史；详细日志/历史使用既有渐进式披露入口，不重复塞满上下文。
只给已有及本单新增动作展示 ready / blocked / unknown 与原因、缺失证据、可查询信息；ready 只表示预检通过，不是授权令牌、验收结论或穷尽全部业务选项。复用执行端约束，避免平行实现一套合法性规则引擎。执行时重新校验当前权限、需求/Task/Attempt/候选/merge/input 状态；快照过期应反馈变化并让 Chief 重读，不将普通 stale/null 统一当环境故障或强制转人工。
Chief 实际执行上下文必须含 projectFacts.tasks[].repositoryRecovery.nextActions 与 continuationOptions，不能只在提示词/文档声称存在。看板 TaskView.nextActions 是调用人的服务命令列表，不能被 Chief 误当成完整合法决策集合；TaskView.deliveryChoices 复用决策预检。即使前者仅列 chief.inspect，也不因此禁止满足前置条件的 accept-attempt / start-next。已合 PR 的 rework 拒绝不构成清 binding 的授权。补实际 Chief Job 上下文回归，避免 Personal Agent 的文字输入与宿主合法动作层脱节。
3. 推荐及自主性
推荐动作、理由和证据引用由原 Chief 推理轮次给出；宿主提供事实与预检，不另建规划 Agent/评分引擎，不硬编码“已合只能盖章→固定 Dev”。Chief 可以查询、暂缓验收、调整路线，全部条件满足时可关闭 Task。
Chief 优先自主查询、纠正和推进。确实缺权限/必要信息或需要人拍板时，才由 Chief 决定通过对应 Personal Agent 求助，必要时联系本人，作为最后兜底。失败次数/耗时只能作为现有 warning，不自动触发固定角色、人工升级或关闭。
框架可以提供建议的合法动作、依据及前置条件，Chief 保留最终选择。多次在同一事实下操作被拒，应沿用现有配置的无进展阈值与统一 warning 通道，带上最近动作、精确拒因和当前事实供 Chief 纠正；不新增固定次数转人工/固定角色流程。当前事实、历史推荐/拒因与待核验信息必须清晰区分，失效提醒不得继续作为当前阻塞，最终上下文不得前后矛盾。
4. 失败、重放和恢复
复用既有 Effects、请求回执与代次约束。重复请求不重复验收/创建 Attempt；验收提交失败不得留下有效“已验收”或启动后续。验收后重新读取当前快照再决定下一步。外部写入结果未知时先查询原操作，不能盲目重放。权限撤销、worker 退出未知仍拒绝执行；旧代次/证据不能获得放行。
验收
- 可实际走通 provider-confirmed merge → Chief 验收当前 Attempt → 原 Task 保持打开 → 新快照 → Chief 启动新 Attempt → 新分支/新 PR 身份与包含已合成果的核验基线。
- 验收保留交付范围、证据、剩余工作及原历史；整个 Task 的验收/关闭仍独立受约束。
- 已合旧 PR 的 rework/续作仍拒绝；未合 PR 的正常续作不回退。
- Chief 快照显示 scoped ready/blocked/unknown、原因和证据来源；推荐来自 Chief，无新增固定工作流或自动升级。
- 覆盖快照读取中变化、执行前 stale、候选/需求/merge/input 变化、目标分支推进或缺对象、权限撤销、未知退出、重复/迟到回复、保存失败与重启恢复，不重复写、不超配、不丢原上下文/草稿。
- 更新 PROJECT/ROADMAP 长期记忆、匹配架构、操作/API/OpenAPI（如受影响）、生成补丁及 changelog；保留原上下文预算与必读规则。
- 报告缺陷修复前失败、修复后通过、实际隔离运行时/SDK 与现场验证的不同范围。测试通过/源码合入不能冒充现场验收。
非目标与历史说明
不拆已合 PR 不可 rework 的边界；不新建 Task Store/调度器/DAG/规则平台；不清历史 binding；不与已完成 #2519 日志通道混谈。原 Issue “已合待验收只许盖章”“关整单一概非法”“勿升人工”由上述 Owner 讨论结论替代；保留原讨论作为设计演进记录。
补修：需求演进与历史 Attempt 验收
Owner 已确认实施。现场证据见 comment-6660783004；当前交付分支 056cb55 的隔离复现同样被 Current requirements changed 拒绝。
- scoped accept-attempt 依据不可变 Attempt requirement、原候选与测试/Review/merge 证据，不要求其与当前 Task title/criteria/revision 相等；Chief 明确已完成/剩余范围。保留新旧需求版本与差异提示，不自动认可新需求完成。
- 身份、候选与证据 SHA、权限、执行代次、幂等与未知退出等保持硬校验。Chief 读取后需求变化，回灌当前差异要求重读/确认；不把正常历史修订差异当成永久阻塞或自动转人工。
- 实际 Chief 上下文、TaskView 及执行端规则一致，下一轮使用当前 Task requirements。整体 Task close 仍独立验收。
- 真实 Git/Runtime 回归：Attempt rev2 → 当前 Task rev3/rev4 → scoped acceptance → 同 Task 新 Attempt 使用 rev4；旧 PR/历史保留。
- 新需求差异显示、旧判断期间再次修订要求纠正；无代码证据/权限/退出放行。
- 更新长期记忆、架构/API/OpenAPI、canonical patches 与测试，不提高必读预算；上下文包瘦身仍单独处理。
Activity
zy95-12 commentedon Nov 5, 2026
Design note (room 2026-11-05 Asia/Shanghai)
Owner direction: framework should expose as much fact as possible and leave decision to the model among legal choices.
For this issue,
nextActionsshould be:not a single hard-coded script that removes all model choice.
Protocol closes illegal edges; policy/model picks among legal ones.
[-]Post-merge: auto-clear waiting-acceptance / publicationBinding + pin nextActions to accept[/-][+]Post-merge: 按事实快照给出合法选项集（先盖章收片，再新开 Dev）[/+][-]Post-merge: 按事实快照给出合法选项集（先盖章收片，再新开 Dev）[/-][+]Decouple Attempt acceptance from Task completion and expose scoped Chief delivery choices[/+]Separate scoped Attempt acceptance from Task completion and let Chief…
zy95-12 commentedon Nov 5, 2026
Written-by: Codex
已通过 PR #2537 合入
delivery/ai-centric-development-service，实际合入 SHA：a809a7a53eb2fede879888b92667191e1befeaaa。已 fetch 目标分支并核验：合入树与测试提交c0fcf9d7a916921f0b932b8140098dd34feceaaa完全一致。交付范围：
验证：
npm run verify：5128/0，含 8 项实际 DSH runtime。未执行现场 OpenToday 操作、部署/重启、外部 provider 写入或付费模型调用。Owner 已明确把必读上下文包瘦身留作单独工作，不纳入本单。
zy95-12 commentedon Nov 5, 2026
部署含 #2537 后现场复核（OpenToday
task-8cf81a8d/attempt-b573bb83）：deliveryChoices已出现，但accept-attempt仍 blocked：Current requirements changed; inspect fresh delivery facts。根因是
requireAttemptAcceptance要求 Task 当前title/criteria/revision与 Attempt 钉死的requirement（此处projectTaskRevision=2）完全一致；合入后 Chief 已把 Task requirements 推到 rev3/rev4（标注已交付与剩余 MVP），revision 永久偏离 Attempt 快照，导致一经 revise 就无法再 scoped accept。这和「先盖章再 start-next」目标冲突。建议：scoped
accept-attempt以 Attempt requirement 快照 +delivery.{completed,remaining}为准，或允许 Task 现行 requirements 演进后仍验收已合 Attempt；不要用整单 revision 等式卡死。（公开
nextActions仍只有chief.inspect，属调用方命令列表，预期内。）Accept merged Attempt scope after Task requirements evolve (#2549)
zy95-12 commentedon Nov 5, 2026
Written-by: Codex
补修已通过 PR #2549 合入
delivery/ai-centric-development-service：80cf579512237a5affd45b26658f52d784e80cda。已 fetch 并核验合入树与测试提交1f8cff3abcaad9ccf91ebb0a7b0980c4307deae0完全一致。修复了现场反馈的历史需求版本硬阻塞：scoped accept-attempt 依据 Attempt 固定需求和原候选/测试/Review/merge 证据；Task 当前需求演进仅显示版本/字段差异及原值，不要求与历史版本相等。Settlement 记录原需求与验收时当前 Task 版本；Task 保持打开，下一轮复制当前需求。父任务集成过子任务时，也按原父需求版本核对其已提交的原准入记录；准入 Effect/子任务证据缺失仍拒绝。整单关闭仍独立受约束。
Chief 读取后需求又变化，使用已有 stale-snapshot 纠正反馈重新判断。旧拒因是历史操作结果，不构成当前合法性规则；有四条旧“版本不同”拒因时，实际 Chief Job 回归仍可合法验收并启动当前需求下一轮。权限、身份、SHA、代次、退出/外部写入、输入和幂等校验保留，无新框架/自动转人工。
验证：
npm run verify：5167/0，包含 8 项实际 DSH runtime。长期记忆、匹配架构/API/OpenAPI、decision/changelog 和 canonical mirrors 已更新。未部署/重启现场、修改 OpenToday 状态或 binding、进行外部 provider 写入或付费模型调用；隔离协议验证不冒充现场/真实供应商模型验收。必读上下文包瘦身仍单独处理。