封面：代码完成是局部实现声明；项目完成还需要可核对的证据、接受权限与明确边界。
从 Project Knowledge Lifecycle 继续追问：一次 Agent 的完成声明，怎样才有资格成为项目状态？
Agent 说“完成”之后，Lifecycle 还缺什么
图 1：测试通过不等于项目完成。完成判断还需明确工作与版本、获得必要接受，并处置当前证据范围内的已知矛盾。
一个 Coding Agent 改完代码，运行测试，看到绿色结果，然后说：完成了。这句话可能准确地描述了它被分配的局部工作，却没有自动回答另一件事：项目是否已经可以接受这次变更，并让下一位行动者据此继续？
上一篇《项目知识需要生命周期》讨论过这个缺口：Patch 可以正确，Project State 仍然可能彼此矛盾。需求、范围、实现、验证、评审、知识与交接，需要沿着同一项工作的 Lifecycle 持续更新。否则，下一次 Session 得到的就可能是一组各自看似合理、合在一起却不一致的上下文。
第 4 篇提出了“什么需要持续维护”。这篇向前推进的问题是：已经做过的实践暴露了哪些完成条件？一个局部 Implementation Claim，何时足以支持可信且获得授权的项目状态？
我把 Code Complete 理解为局部实现声明，把 Project Complete 理解为多个相关状态的收敛声明。这里的“项目完成”指一次修复、一项需求或一个发布候选等明确工作单元达到约定终态，不是整个产品从此不再变化。
本文从已记录的 Lifecycle Drift、现有 Finish Contract 与几个 Runtime 边界中推导一个仍待验证的 Completion Contract。它不是行业标准，也不是一套已经完成的 Completion Runtime。
谁能提出 Claim，谁有权接受它
图 2：领域方法、工作流、连续性与接受权限是不同职责。这是目标责任模型，不代表完整链路已经实现；报告证据也不等于有权接受结果。
要研究完成条件，首先要拆开“做了什么”和“谁能据此关闭什么”。运行测试的人或 Agent 可以报告结果，但测试执行权并不自动包含接受范围变化、残余风险或业务结果的权限。
沿着前几篇提出的目标架构，我把这项责任分给四层：
- Skill / 领域方法解释 Acceptance 与验证的含义：这类任务应该检查什么，什么证据与领域风险有关。它提供判断方法，不能靠一段指令为调用者创造接受权限。
- Harness承载具体 Workload 的 Lifecycle：把工作身份、变更版本、各方声明与 Evidence 关联起来，依据已定义的 Gate 推进、阻塞或交接工作。如何恢复这类工作，也需要由具体流程定义。
- Agent Runtime需要提供或协调可复用的 Identity、State 与 Evidence 连续性 Contract，使这些关系能够跨 Session 保留和核对。这是目标职责；现有局部 Runtime 能力尚未构成完整完成链路。
- Human / Domain Owner确定重要范围、风险与语义接受边界，也可以事先显式授权某些规则内的判定。正在产出完成声明的 Agent 不能临时替自己生成这份授权。
因此，“有测试证据”和“有权接受结果”是两个不同条件。Skill 可以解释证据，Harness 可以组织流程，Runtime 的目标是保存可核对的关系；但不能把这些能力的组合直接等同于某个主体已经获得最终 Completion Authority。
这也把本文接回研究主线：问题不只是怎样让 Agent 更会写完成总结，而是领域方法、工作流与通用 Runtime 之间，需要保留哪些语义，才能让一次完成声明被其他获得授权的行动者继续使用。
一次 Lifecycle Drift 暴露的完成缺口
图 3：实现向前推进，不代表项目表示已经共同收敛。这是一次有边界的 Drift 记录，既不证明 Patch 正确，也没有测量自动化对漂移的影响。
一个有边界的证据来自公开工作流 Skill Project Develop Copilot。其维护者记录过一次 Lifecycle Artifact Drift：实现推进后，Handoff 路径、子工作身份、共享引用与 Dashboard Projection 没有共同对齐。记录还提出了子 Change Brief、Canonical Handoff Path、Flow Record / Dashboard 对齐及回归搜索等后续检查（失败记录与预期检查）。
这份记录没有证明 Patch 正确，也不是对所有 Agent 项目的统计。它暴露的是一个具体缺口：实现状态向前推进，并没有带来工作身份、交接路径和状态投影的共同收敛。于是，下一次执行需要处理的，不只是“代码在哪里”，还有“哪些项目表示仍然可信”。
这个实现的 Finish 文档规定：至少存在一项 Verification Result，或被明确接受的 Verification Limitation，才进入完成与知识同步。它也区分 Review 与 Doctor：前者关注代码、测试、范围、知识和 Artifact 风险，后者处理更适合机器检查的漂移与一致性问题（Finish Contract，Review / Doctor 责任）。这里能确认的是规则与记录的存在，不是每次运行都已成功强制执行这些规则。
我从这些材料中提取的研究问题是：哪些检查只证明局部事实，哪些关系还需要在工作结束前重新对账？答案不应被绑定在某几个文件名上，而应描述这些文件共同承担的工作身份、证据、接受决定与交接语义。
关于 Agent 协作，我进一步提出一个待验证的假设：当多个状态独立更新、又缺少统一对账机制时，并行自动化可能增加不一致状态向下游传播的机会。这仍待验证，不能从执行速度或 Agent 数量直接推出不一致程度。
局部任务目标是否遗漏了项目接受条件、跨 Session 交接是否丢失限制，以及读者或下游 Agent 是否会把流畅的完成说明误当作充分证据，也都需要分别检验。本文没有测量这些效应。自动化同样可能通过锚点核对与显式限制减少漂移，因此需要研究的是具体机制，而不是预设“自动化越多，问题越大”。
同一工作、同一版本下的 Evidence、Authority 与对账
图 4：围绕同一工作与版本，Evidence 支撑事实，Authority 界定谁能接受什么。图中表示的是关系而非执行顺序；依据或范围变化后仍需重新核对。
基于上述责任划分和失败记录，我提出的对账单元不是一个孤立的 Done 标签，而是：一项工作、一个版本，以及一组各有依据和接受边界的状态声明。
为此，本文区分六类状态：Scope 说明被接受的目标与授权范围；Implementation 说明实际变更；Verification 说明已检查的行为与限制；Decision 说明必要的评审和接受决定；Knowledge 说明需要长期保留的项目表示；Handoff 说明下一位行动者可以怎样继续。Evidence 不是第七份状态表，而是支撑这些声明的关系。
首先需要明确两个锚点。**Work Identity（工作身份）**回答“正在完成哪一项工作”，可以是 Issue、Requirement 或 Change；**Change Anchor（变更锚点）**回答“这些声明对应哪个版本”，可以是 Commit、Pull Request head 或 Artifact Digest。前者命名工作对象，后者绑定具体变更；二者都不能被一个模糊的“当前项目”替代。
有了锚点，“Tests Passed”才成为可以解释的 Evidence。测试记录应能追溯到命令、结果与环境，说明针对哪个 Revision、覆盖哪些 Acceptance 或风险，以及哪些部分没有验证。在本文模型里，可追溯、新鲜、相关、与完成层级相称，是审查证据的四个维度。一次旧版本测试即使真实通过，也不能不经核对就支撑后续变更；局部单元测试也不能自动升级为集成验证或发布就绪。
软件供应链中的一个窄范围旁证是：SLSA 1.2 的分发规范 建议 Attestation 绑定具体 Artifact，而不是笼统绑定 Release。这里只借它说明“证据要跟它证明的对象绑定”，不把它当作完整 Completion Contract 的依据。
对象与版本对齐后，还要回答 Authority 问题。Evidence 说明哪些事实得到支持；Authority 说明谁可以在多大范围内接受某个决定。范围调整、验证限制或残余风险如果需要接受，就应保留接受者、授权依据、适用工作与版本，以及具体接受了什么。测试成功不会替代这份决定；有权者接受限制，也不会把未执行的测试变成已经通过。
最后才是 Reconciliation（对账）：让范围、实现、验证、决定、知识与交接对同一项工作给出相容的答案。我用三个方向检查这组关系：
- 向后追溯：从完成 Claim 找回当前变更、原始 Evidence、被接受的目标与授权范围。
- 横向对账：检查 Issue、代码、Review、文档和状态投影是否对版本与终态给出冲突答案。Dashboard 的 Done 不能覆盖 Handoff 中尚未处理的验证要求。
- 向前续接：让下一位行动者能重建结论、看到限制，并知道哪一项仍需决定；这是一项交接可用性检查，不是通用 Workload Recovery 已实现的声明。
对象一致、版本一致、语义相容和缺口有归宿，共同构成本文的收敛条件。缺口可以被修复；在任务边界允许时，也可以由有权者接受或明确转为后续工作。若仍属于本次必须完成的条件，就不能仅因创建了后续任务而将其关闭。
我把 Project Complete 理解为：对于明确的工作身份、变更锚点和完成层级，关键声明有当前证据支持，必要的接受决定已由有权者作出，并且在当前证据覆盖范围内，没有已知且未处置的矛盾。
这不是对未知的消除保证。有限 Evidence 不能证明项目绝对正确；新的证据、Acceptance 或 Change Anchor 变化，都可能要求重新审查相关结论。
我提出的最小 Completion Contract
图 5：五部分描述的是必要语义，不是五份文件或五个步骤。“带已接受限制的完成”需要边界允许和有权者接受，不能等同于集成验证通过或发布就绪。
如果把上述机制压缩成一个可以继续验证的 Contract，我会保留五部分。它们是必要语义的提案，不是通用 Schema，也不要求每个任务新建五份文件。
- Completion Target：工作身份与声明的完成层级。Code Complete、Task Complete、Integration Verified、Release Ready 和 Deployed 不能默认视为同一声明。
- Change Anchor：声明所针对的代码或 Artifact 版本，以及 Evidence 与这个版本的关联。
- State Claims：范围、实现、验证、决定、知识和交接各自声明了什么；哪些是执行者报告，哪些已获得所需接受。
- Evidence and Gaps：关键 Claim 的可追溯依据、覆盖范围与已知限制，以及每项缺口的处置。
- Terminal Disposition：本轮是 completed、completed with accepted limitations、blocked，还是 handed off for further work；必要接受决定的主体、授权依据与适用范围必须可核对。
Authority 没有被省略为“默认同意”，而是进入决定与终态的语义。记录这些信息也不等于通用 Authority 引擎已经存在：谁有资格接受哪些决定，仍需要具体 Domain 的规则与授权来回答。
以一个假设的协议修改为例：单元测试通过，但任务要求的集成验证因环境不可用而没有执行。这时可以保留局部实现声明，项目工作则应保持 Blocked，或者连同缺口一起 Handoff 给下一位执行者。交接得清楚，不等于工作已经完成。
只有任务边界允许这种限制、限制及其风险被明确披露，并且有权者针对相应工作与版本接受时，才可以使用“带已接受限制的完成”。执行者不能自行把验收门槛降下来；这个状态也不能被下游误读成 Integration Verified 或 Release Ready。
这些语义可以存在于 Pull Request、Issue、CI Result、Change Record 或 Lifecycle Artifact 中。低风险修改需要的记录可以很少；跨模块迁移需要的 Evidence 与接受决定可能更多。研究重点不是统一文档数量，而是验证：换一个执行者或 Session，这些关系是否还足以支持同一个、边界清楚的完成判断。
已有的是局部证据，缺的仍是完成链路
图 6：按文中引用版本，已有能力仍是分散切片，完整完成链路尚未实现。知识访问隔离不等于最终接受权，Trace / Eval 的发布门禁也仍未完成。
前面的分层与 Contract 是从实践推导出的研究模型。回到当前实现，能够支持它的证据仍分散在不同项目，不能直接相加为一套 Completion Runtime。
Project Develop Copilot 提供了 Finish / Review Contract 和 Drift 记录，但所引用的 Static Lifecycle Review 仍把完整 End-to-End Lifecycle Dry Run 列为未证明部分。文档规则存在，不等于完整运行链路已经验证（成熟度边界）。
llm-wiki-runtime 与 AI Research Observatory 的集成材料提供另一类局部证据：不同 Principal 可以读取同一条 accepted knowledge，但 Skill 不能借用 Harness 所拥有的 Mapping 写入。跨仓库测试覆盖共享读取、拒绝越权写入与 Record checksum 不变。这是 Principal / Mapping 的知识访问边界，不是项目最终接受权（跨仓库测试，Runtime reference example）。
Agent Runtime Modules 已有本地 Trace / Eval 能力切片和用于 attribution 的 PrincipalRef；PrincipalRef 并不等于完整持久 Agent Identity 或接受权限。所引用版本的 Trace / Eval release 仍 gated：这些能力已有实现，正式发布门禁仍未完成（实现状态与 North Star）。
在这些引用版本所构成的研究进展中，通用 Completion Authority、持久跨 Host Agent Identity、完整 Workload Recovery，以及从 PDC Completion Claim 到 Runtime Evidence、Authority、Terminal Receipt 的完整链路尚未实现。完整 Vertical Domain Agent 也仍是目标架构。
下一步可以把记录 Anchor、关联 Evidence、发现过期声明和生成可复核 Handoff 作为目标自动化方向，逐项放进具体 Workload 验证。需要检验的不只是能否写出 Contract，还包括锚点变化后旧声明能否被重新打开、不同主体的证据能否对账，以及流程能否在缺少接受权限时诚实停止。
Trusted Next Context：可复核的下一步
图 7：可信上下文不等于已完成。诚实保留缺口的 Blocked 或 Handoff，也能支持可复核的下一步；这些可能去向不是自动状态机。
现在可以更精确地接上第 4 篇：Project Knowledge Lifecycle 关心项目知识怎样随工作变化；本文提出的 Completion Contract 关心，这些变化何时足以支撑一次有边界的结束判断。
按这个模型，Project Complete 多出来的不是一批固定 Artifact，而是下一位行动者可以重新核对的关系：完成了哪项工作与哪个版本、哪些 Claim 有证据、哪些限制由谁接受、什么变化会使当前结论不再适用。
Trusted Next Context 不要求盲目信任，也不只属于 Completed。一个如实保留缺口的 Blocked 或 Handoff，同样可以成为可信的下一次上下文；它只是不能被包装成已完成。可信的下一步有时是继续执行，有时是等待验证或向有权者请求决定。
因此，我留下的开放问题是：当实现、验证、知识同步与交接由不同的人和 Agent 分别完成时，怎样的组合规则，才能让局部 Claim 形成可复核、受授权的项目终态？当依据或范围改变时，又由谁重新打开这份结论？
代码停止变化，是一个事件。
项目可以继续，需要一个能够说明依据、权限与边界的判断。
