TCP三次握手和四次挥手的全过程
2026/9/17 12:27:39
AI-DLC提交溯源：aidlc attest如何把Commit关联到已评审单元
【免费下载链接】aidlc-workflowsAI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules for AI coding agents项目地址: https://gitcode.com/GitHub_Trending/ai/aidlc-workflows
AI-DLC（AI-Driven Life Cycle）是为 AI 编码代理设计的自适应工作流框架，而aidlc attest正是它的提交溯源（Commit Provenance）命令：能把任意一个 git Commit 反向关联到拥有这些改动的已评审单元（Unit of Work），并验证提交内容与评审批准的内容是否一致——不依赖提交钩子、不解析提交信息，普通的git commit同样适用。
为什么需要提交溯源：代码落地后，谁能回答"这段代码被评审过吗"
AI-DLC 把需求拆分为若干可独立实现的 Unit，每个 Unit 的终端评审通过后，会在审计分片（audit/）里留下一份评审回执（REVIEW_COMPLETED），回执上带有Unit Source Fingerprint字段，把该单元声明的源码路径与清单字节绑定在一起。
问题在于：评审发生在会话里，而提交往往晚得多。常见的三种关联手段都走不通：
- 提交钩子 / 会话期捕获——用户通常在任何机器上用普通
git commit手动提交，可能距会话结束已过去很久； - 指纹无法反查归属——回执证明了"什么内容被评审过"，但从裸克隆和提交范围出发，无法回答"这条改动路径属于哪个单元"；
- 提交信息不是可靠通道——提交格式属于团队约定，trailers、工单前缀都不可依赖。
于是aidlc attest选择了另一条路：让归属成为已提交内容的纯函数（core/tools/aidlc-attest.ts）。任何克隆都能解析出同一份报告，一年后解析历史提交结果也不变。
工作原理一句话：内容指纹做锚点，证据跟着克隆走
机制由三块拼成 🧩：
- 评审回执：每个 Unit 最新的 READY 回执是归属权威，其中的
Unit Source Fingerprint是证据文件的 SHA-256，机制见 docs/guide/10-state-and-audit.md； - 已提交的评审证据：评审时引擎双写一份
reviewed-source-<hash12>.tsv快照到 intent 记录中并提交入库，随每次克隆分发，且与指纹字节完全一致； - 从 git 树读取：
resolve把审计分片、清单和证据都从树对象里读出来，而不是读本地工作区——同一(base, head)在任何克隆上永远得到同一份报告。
这种设计还自带篡改不对称性：验证要求字节必须哈希到回执指纹，所以破坏证据只能让路径变成unverifiable，永远无法伪造出verified。
两个动词：resolve 只读核验 + anchor 可选增强
aidlc attest resolve：把提交改动逐条归因到已评审单元
resolve完全只读：它从不写入、从不发射审计事件，甚至不读 anchor 记录。默认解析HEAD的首父增量，也可以用--diff <base>..<head>解析任意范围（...形式取 merge-base，与合并请求语义一致）。
每一条改动路径都会得到一个状态（定义见 core/tools/aidlc-attest.ts）：
| 状态 | 含义 | 可触发门禁失败 |
|---|---|---|
verified✅ | 属于某个已评审单元，且提交内容与评审内容一致 | ❌ |
drifted | 属于已评审单元，但提交内容相对评审后又改过 | ✅ |
unattested | 没有任何已评审单元声明这条路径 | ✅ |
unverifiable | 有回执声明，但没有可绑定的已提交证据——失败封闭 | ✅ |
indeterminate | 回执时序歧义（如不同分片同时戳）——失败封闭 | ✅ |
excluded | 框架外壳 / 记录路径（不参与归因） | ❌ |
输出是 stdout 上的 JSON 报告：paths[]（逐路径状态与归属）、units[]（获胜回执的详情）、summary（各状态计数）、trust{}（本报告可信到哪一层）以及warnings[]。加上--fail-on就变成 CI 门禁：命中任一指定状态即退出码 3——注意除非你有意放行，否则四个可失败状态应全部列出，因为漏掉unverifiable等于放过了"无人能验证内容"的路径。
aidlc attest anchor：给审计轨迹补一条落地指针
anchor会对提交跑一遍归因，然后为涉及的每个 intent 追加一条SOURCE_COMMITTED审计行（"该提交携带了这些评审单元落地"），事件字段定义见 core/knowledge/aidlc-shared/audit-format.md。
它严格是信息增强：resolve从不读取 anchor，所以只手动提交、从不跑 anchor 的仓库什么也不会失去。两个实用细节：
anchor --reconcile会回扫最近 100 个首父提交，为未打锚的提交补录，已锚定或已被 swarm 合并绑定的提交自动跳过；- 设置
AIDLC_SESSION_ANCHOR=1可让会话启动钩子自动做一次有界的回扫（默认关闭），实现见 core/hooks/aidlc-session-start.ts。
信任阶梯：这份报告到底能信到什么程度
回执、清单、证据都是仓库里的普通文件，能写仓库的人就能写回执。所以报告从不声称超出它实际检查的东西——每份报告都携带trust.level，是四级阶梯（定义见 core/tools/aidlc-attest.ts）：
| 级别 | 含义 |
|---|---|
informational | 记录从工作树读取，只是本地诊断 |
reproducible | 记录从 git 树读取，任何克隆结果一致；但改动可能自带自己的回执（selfAttested） |
independent | 回执不来自被测试的改动本身——用--record-ref <ref>把记录源钉在一个改动写不到的 ref（受保护分支、只记录分支）上即可达到 |
signed | 上述基础上，每个带权威性的输入（回执所在审计分片 + 其指纹选定的证据文件）都来自签名提交 |
两个锚点都由验证者提供，而不是由改动提供：--record-ref决定记录从哪读，--require-trust <level>把级别变成门禁（达不到即退出 3）。典型的分支门禁配方 📌（完整说明见 docs/guide/12-cli-commands.md）：
bun .claude/tools/aidlc-attest.ts resolve --diff origin/main...HEAD \ --record-ref origin/aidlc-records --require-trust independent \ --fail-on drifted,unattested,unverifiable,indeterminate三个容易踩的坑：用...三点而不是..（两点比的是两端 tip，会误报）；浅克隆要先git fetch --deepen或设置fetch-depth: 0（边界提交缺父提交，resolve会直接报错而不是把整棵树当增量）；想清楚自己是报告还是执行——不加--record-ref时，一个自写回执的改动可以自我验证，报告会如实标注reproducible，但不会阻止它。
延伸阅读：相关模块与文档
- 提交溯源参考章节（威胁模型、信任阶梯、边界情况全集）：docs/reference/20-commit-provenance.md
- 工具源码：core/tools/aidlc-attest.ts（
resolve/anchor实现）、证据解析与指纹公共库 core/tools/aidlc-lib.ts - 评审回执与源码指纹机制：docs/guide/10-state-and-audit.md
- CLI 命令速查（attest 一节）：docs/guide/12-cli-commands.md
💡 一句话总结：aidlc attest用"内容即归属"的思路，让提交溯源变成任何克隆上都能重放的确定性检查——resolve回答"落地内容与评审内容是否一致"，anchor让审计轨迹多一条人类可读的落地指针，而trust{}永远诚实标注这份报告的可信边界。
【免费下载链接】aidlc-workflowsAI-Driven Life Cycle (AI-DLC) adaptive workflow steering rules for AI coding agents项目地址: https://gitcode.com/GitHub_Trending/ai/aidlc-workflows
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考