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-workflowsAI-DLCAI-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_ANCHOR1可让会话启动钩子自动做一次有界的回扫默认关闭实现见 core/hooks/aidlc-session-start.ts。信任阶梯这份报告到底能信到什么程度回执、清单、证据都是仓库里的普通文件能写仓库的人就能写回执。所以报告从不声称超出它实际检查的东西——每份报告都携带trust.level是四级阶梯定义见 core/tools/aidlc-attest.ts级别含义informational记录从工作树读取只是本地诊断reproducible记录从 git 树读取任何克隆结果一致但改动可能自带自己的回执selfAttestedindependent回执不来自被测试的改动本身——用--record-ref ref把记录源钉在一个改动写不到的 ref受保护分支、只记录分支上即可达到signed上述基础上每个带权威性的输入回执所在审计分片 其指纹选定的证据文件都来自签名提交两个锚点都由验证者提供而不是由改动提供--record-ref决定记录从哪读--require-trust level把级别变成门禁达不到即退出 3。典型的分支门禁配方 完整说明见 docs/guide/12-cli-commands.mdbun .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.tsresolve/anchor实现、证据解析与指纹公共库 core/tools/aidlc-lib.ts评审回执与源码指纹机制docs/guide/10-state-and-audit.mdCLI 命令速查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），仅供参考 AI-DLC提交溯源：aidlc attest如何把Commit关联到已评审单元
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-workflowsAI-DLCAI-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_ANCHOR1可让会话启动钩子自动做一次有界的回扫默认关闭实现见 core/hooks/aidlc-session-start.ts。信任阶梯这份报告到底能信到什么程度回执、清单、证据都是仓库里的普通文件能写仓库的人就能写回执。所以报告从不声称超出它实际检查的东西——每份报告都携带trust.level是四级阶梯定义见 core/tools/aidlc-attest.ts级别含义informational记录从工作树读取只是本地诊断reproducible记录从 git 树读取任何克隆结果一致但改动可能自带自己的回执selfAttestedindependent回执不来自被测试的改动本身——用--record-ref ref把记录源钉在一个改动写不到的 ref受保护分支、只记录分支上即可达到signed上述基础上每个带权威性的输入回执所在审计分片 其指纹选定的证据文件都来自签名提交两个锚点都由验证者提供而不是由改动提供--record-ref决定记录从哪读--require-trust level把级别变成门禁达不到即退出 3。典型的分支门禁配方 完整说明见 docs/guide/12-cli-commands.mdbun .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.tsresolve/anchor实现、证据解析与指纹公共库 core/tools/aidlc-lib.ts评审回执与源码指纹机制docs/guide/10-state-and-audit.mdCLI 命令速查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），仅供参考