封面代码完成是局部实现声明项目完成还需要可核对的证据、接受权限与明确边界。从 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 ContractReview / 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 的 PrincipalRefPrincipalRef 并不等于完整持久 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 形成可复核、受授权的项目终态当依据或范围改变时又由谁重新打开这份结论代码停止变化是一个事件。项目可以继续需要一个能够说明依据、权限与边界的判断。