Archon SDLC 工作流包的守卫Guard与安全约定Guards、凭据边界与流Stream治理实战【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读.archon/workflows/sdlc/README.md是 Archon 仓库中 SDLC软件开发生命周期工作流包的内部规约文档。它不介绍如何发起一次自动化交付而是规定了写工作流的人必须遵守什么哪些校验值得写成守卫Guard、守卫必须守护节点自身的行为、证据Evidence永远不能携带凭据、工程规范engineering.md如何以 sidecar 形式进入智能体上下文、以及节点的输出流为何是操作员唯一的通信信道。读完本文你将掌握 Archon 工作流语言中守卫的判定标准、凭据安全的落地手法以及如何利用流stderr/stdout让自动化交付在失败时对操作员诚实、在成功时不留冗余。本文以该规约文档为骨架结合.archon/workflows/sdlc/下archon-deliver.yaml、archon-implement.yaml、archon-review.yaml、archon-pr.yaml等真实工作流与测试源码逐条验证规约在实践中的形态。规约文档的定位Pack 内约定与项目级裁决的分工SDLC pack 的 README 开篇先划清了三份文档的职责边界Pack 内约定本文主题仅适用于 SDLC pack 内部的写作规范AGENTS.md项目级的通用判断准则所有 agent 都会加载保持精简.archon/workflow-language-constitution.mdYAML 语言的宪法任何触及 YAML 表面的改动都必须遵守YAML 协调代码计算Agent 判断YAML coordinates. Code computes. Agents judge.的总规则。这种分层是有意为之Pack 的规约解决这套工作流内部怎么写的具体问题而语言宪法解决任何工作流语言特性能否进入 YAML 表面的全局问题。阅读本规约时应把它视为语言宪法在 SDLC 场景下的具体应用。Guards守卫的取舍标准保留守卫的两个条件规约给出的判定标准非常明确一个守卫必须保护它所栖身节点自身执行的动作。两条保留准则验证节点刚刚做出的动作的效果——退出码为 0不是证明。gh pr ready对已经 ready 的 PR 执行同样会成功但什么都没改变对无法获得答案的问题拒绝继续且猜测的代价不可逆。例如archon complete阻止一个无法证明安全的分支删除就是这个形态。裁掉守卫的一个条件当守卫只是重复断言其他环节已经建立的不变量时它就该被裁掉。不变量应该在它被建立的地方出现一次而不是在每个依赖它的节点各写一遍。机械化的检验标准规约给出了一条可以终结大多数争论的判定如果本 Pack 的 fixture 套件无法演练exercise这个守卫它就不是守卫而是注释——请把它写成注释。原因在于dry run 无法执行的节点例如组合式bash:节点永远不会收到调用方传入的with:值只能被 stub任何 fixture 都无法展示守卫工作或抓出它失效。这条标准把威胁模型辩论转化为能否被 fixture 演练的机械检查。案例一次被裁掉的三重校验规约记录了一次真实的重构。Pack 曾在一处审查前 preflight 节点、ready 翻转节点和修正提示prompt三处验证checkout 处于我 PR 所在的分支三种拷贝、两种语言其中一份还依赖模型的自觉性。而事实上引擎给运行提供 worktreePR 就在该 worktree 中创建不变量由构造保证触发那次工作的告警经调查后判定无效关闭从未真正出错三份拷贝甚至没覆盖最容易因 checkout 漂移受损的步骤impl向 checkout 写代码时不检查validate在该 checkout 上跑项目测试也不检查。preflight 一处就花了 31 行代码和 17 个 fixture 里的 stub而没有任何 fixture 能运行该节点。三份拷贝最终全部删除。存活下来的部分恰好通过规则flip-ready节点拒绝无法规范化成owner/repo的 origin remote否则自己的gh调用会指向意外位置、拒绝在任何 check 非绿时翻转、并在翻转后回读 draft 状态因为成功退出不代表状态真的变了。这些都在保护节点自身的动作。守卫在 deliver 工作流中的实际分布在.archon/workflows/sdlc/deliver/archon-deliver.yaml中守卫被收敛到少量专门的script:节点上而不是散落在各 bash 里守卫节点守护的动作说明gate-green首次实现、每轮修正、最终项目门禁同一个脚本消费三次读取implement声明的green/red_cause/summary见下方详解assert-changedimplement是否真的产生了变更拒绝声明完成但没有改动的节点见.archon/workflows/sdlc/implement/archon-implement.yamlgate-ready审查结论是否真的为 ready用none_failed_min_one_success合并初始审查与修正循环的结论if_skipped只为跳过/未决生产者提供默认值gate-validated项目门禁后的最终确认与gate-green同一脚本第四处消费者flip-ready唯一不可逆的公开动作翻转前的 CI 自查、origin 规范化、翻转后回读全部内聚于此gate-green.py.archon/workflows/sdlc/deliver/scripts/gate-green.py的文档字符串明确写道run success never certifies green—this does, deterministically。它只消费三个 bound 输入INPUTS_GREEN、INPUTS_RED_CAUSE、INPUTS_SUMMARY并把每次放行 red 的决定追加写入red-causes.json——放行红色变更却没有任何痕迹是比拒绝更糟的结果。这正是守卫守护自身动作的落地即使放行继承性/环境性红色也要留下证据记录。守卫必须被 fixture 演练测试源码的印证规约fixture 无法演练就不是守卫的判定在.archon/scripts/__tests__/flip-ready-check-read.test.ts中体现得淋漓尽致该测试直接从archon-deliver.yaml中抽取flip-ready节点的 bash 主体替换模板引用后用伪造的gh与git可执行文件运行它从而证明失败的 check 读取必须在调用gh pr ready之前拒绝。测试注释点明flip-ready的输出被 fixture 直接 stub因此没有任何 fixture 能观察到失败的gh读取——这正是规约说节点只能被 stub的具体案例而测试通过抽取真实 bash 主体绕过了这一限制让守卫本身成为被测单元。Evidence never carries credentials证据永不携带凭据引擎的留存机制带来的责任引擎会保留每个 exec 节点打印的所有内容因此节点的输出就是记录无论节点是否打算保留它。这带来一条硬性规则永远不要打印可能包含秘密的值在它被规范化的地方读取它只传递规范化后的形式。最常见的例子就是 remote URL——https://tokenhost/repo是完全普通的 origin。因此flip-ready在读取 remote 的替换表达式内部就把 origin 规范化为owner/repo只有这个值会到达命令行。失败消息是同一块表面把原始值插值进错误消息泄露效果等同。凭据保护在 flip-ready 中的具体实现查看.archon/workflows/sdlc/deliver/archon-deliver.yaml中flip-ready节点的 bash 主体可以看到三层防护ORIGIN_REPO$(git remote get-url origin 2/dev/null | sed -E s#^.*:/$#\1#; s#\.git$##) case $ORIGIN_REPO in *[!A-Za-z0-9_.-]*/* | */*[!A-Za-z0-9_.-]* | */*/* | /* | */ | ) printf %s\n flip-ready: origin remote does not resolve to an owner/repo. 2 exit 1 ;; esac读取时即规范化正则把https://tokenhost/owner/repo.git截取为owner/repo凭据永远不会进入后续的变量白名单校验case 语句拒绝任何含有非常见字符、多级路径、绝对路径或空值的形式保证后续gh --repo调用指向确定的目标--repo显式固定目标注释解释了 fork clone 场景下gh的默认解析会指向上游父仓库--repo会禁用分支推断并要求显式选择器——这既是正确性要求也是防呆。转录取代手工日志因为引擎保留节点输出节点不再需要自己的日志。规约记录flip-ready曾经手工维护一份日志——把每条执行过的命令回显进一个 artifact。而现在这份内容由转录transcript免费提供。换言之节点自述这件事交给引擎的留存机制作者只需要保证自己撰写的信息出现在流中。工程规范 sidecarengineering.md 的读取约定sidecar 机制仓库可以在根目录或配置目录如.archon/声明一个engineering.md作为工程规范。写代码的 prompt 在写码前会读取它——目前implement命令携带这行约定就像任何工作流都可以读取仓库的方向性 sidecar 一样。在 Archon 仓库中.archon/engineering.md就是这样的文件。它的定位在文档开头写得很清楚本文件是工作被检查所依据的标准而不是做工作的指令。它之所以能写得更深是因为它只通过AGENTS.md的指针或评估者评审者、提问者、门禁设计者的显式简报到达 agent不会作为环境上下文被每个节点加载。其核心原则包括机器可检查的规则会毕业能被 lint 规则、类型或 CI 检查执行的条款会离开本文档本文档只保留需要判断力的内容目标函数正确优先成本效率其次速度最后风险分类学不可逆/破坏性路径、生命周期所有权、模式与持久化契约、凭据与认证边界、提供者与适配器边界、并发与共享资产worktree、session、lease——这些区域获得对抗性评审深度。值得注意的是.archon/engineering.md明确说明SDLC pack 在自己的 prompt 内部声明了一份通用版本的风险清单因为可复用 pack 无法读取本仓库独有路径那是一份有意的 fork而非同步镜像编辑一处不会改变另一处。条件式检查保证可移植性sidecar 的检查以文件存在为条件因此 pack 保持可移植没有该文件的仓库不会损失任何能力。任何新的写代码 pack 工作流都应携带同样的读取行。这与语言宪法中项目指导应可获取而非到处喷洒project guidance should be available, not sprayed everywhere的原则一脉相承——AGENTS.md是项目指导通道节点只应获得其职责所需的上下文。节点的流是操作员的信道stderr 的实时广播与不脱敏副本留存不是唯一的读者。节点写入 stderr 的任何内容都会在运行过程中实时发送给操作员即使节点成功——而且这份副本不做脱敏。因此节点要为自己发声捕获内部命令打印的内容只让自己撰写的消息到达流命令失败且其输出就是诊断时重新输出它命令只是工具在自说自话narrating itself时丢弃它捕获某个值的 stderr 时要分开捕获而不是合并——gh的更新通知如果被合并进一次读取就会变成那个值本身。flip-ready 中的流纪律flip-ready节点从头到尾贯彻了这条纪律代码注释逐行标注了理由if ! FLIP$(gh pr ready $PR_NUMBER --repo $ORIGIN_REPO 21); then printf %s\n flip-ready: the ready flip failed: $FLIP 2 exit 1 figh pr ready的输出不是值确认信息对节点无用因此两个流一起捕获只在翻转失败时重新输出——此时gh自己的话就是诊断读回 draft 状态与 URL 时捕获的是值gh pr view ... --json isDraft与--json url的 stderr 被丢弃2/dev/null因为gh的通知绝不能变成draft 状态或交付 URLGraphQL 检查计数的读取gh api graphql的退出码是结构化信号失败读取会拒绝翻转——失败的观察不等于没有 CI 存在的证据。值读取失败必须具名两条读回路径draft 状态、URL的失败信息都具名了它们无法完成的读取flip-ready: PR was flipped but its draft state could not be read back.——没有一条失败是静默的。从规约反推的实践清单把规约折叠成可操作的清单供编写或评审 SDLC pack 工作流时使用守卫Guards守卫必须保护所在节点自身的动作验证退出码 0之外的实际效果对无法获得答案且猜测不可逆的问题拒绝继续而不是猜不重复断言其他环节已建立的不变量——把不变量留在它建立的地方无法被 fixture 演练的守卫只是注释请写成注释。凭据Credentials5. 绝不打印可能含秘密的值在规范化处读取只传递规范化形式 6. remote URL 在读取表达式中就地规范化为owner/repo只有它到达命令行 7. 失败消息与 stdout 是同一块泄露表面插值原始值等于泄露 8. 引擎已留存转录节点不需要自己的日志。工程规范Sidecar9. 写代码的 prompt 在写码前读取存在的engineering.md检查以文件存在为条件保持 pack 可移植。流Streams10. stderr 实时到达操作员且不脱敏——只让自己撰写的信息进入流 11. 命令失败且其输出即诊断时重新输出工具自述时丢弃 12. 捕获值时分开捕获 stderrgh通知绝不能变成值本身。总结.archon/workflows/sdlc/README.md看似只是 Pack 的内部注释实际上浓缩了 Archon 自动化交付最核心的三条安全工程原则守卫要有可证明的价值——能被 fixture 演练且守护的是节点自己的动作而不是重复别人的不变量。flip-ready、gate-green、assert-changed这些存活的守卫全部落在节点自身动作这一侧而三重校验的 preflight 则被机械标准裁掉。凭据安全靠边界处理不靠纪律提醒——remote URL 在读取处规范化、白名单校验、--repo固定目标、失败消息不插值原始值全部内聚在.archon/workflows/sdlc/deliver/archon-deliver.yaml的flip-ready节点中且有.archon/scripts/__tests__/flip-ready-check-read.test.ts用伪造gh验证失败的读取必须拒绝翻转。流是操作员唯一的信道——stderr 实时、不脱敏地到达操作员节点用重新输出诊断 / 丢弃自述 / 分开捕获值的三段式纪律让自己成为可读、诚实、无冗余的自述者。这套约定与.archon/workflow-language-constitution.md的语言宪法、AGENTS.md的项目准则形成三层治理语言层面YAML 协调、代码计算、Agent 判断项目层面输入即契约Pack 层面守卫、凭据与流各守其位。对任何想要基于 Archon 构建可复现、可审计、可安全交付的自动化流程的开发者这份规约本身就是最值得先读的实现蓝图。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/13 8:06:46 · 阅读 1.2k Archon SDLC 工作流包的守卫（Guard）与安全约定：Guards、凭据边界与流（Stream）治理实战
Archon SDLC 工作流包的守卫Guard与安全约定Guards、凭据边界与流Stream治理实战【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon导读.archon/workflows/sdlc/README.md是 Archon 仓库中 SDLC软件开发生命周期工作流包的内部规约文档。它不介绍如何发起一次自动化交付而是规定了写工作流的人必须遵守什么哪些校验值得写成守卫Guard、守卫必须守护节点自身的行为、证据Evidence永远不能携带凭据、工程规范engineering.md如何以 sidecar 形式进入智能体上下文、以及节点的输出流为何是操作员唯一的通信信道。读完本文你将掌握 Archon 工作流语言中守卫的判定标准、凭据安全的落地手法以及如何利用流stderr/stdout让自动化交付在失败时对操作员诚实、在成功时不留冗余。本文以该规约文档为骨架结合.archon/workflows/sdlc/下archon-deliver.yaml、archon-implement.yaml、archon-review.yaml、archon-pr.yaml等真实工作流与测试源码逐条验证规约在实践中的形态。规约文档的定位Pack 内约定与项目级裁决的分工SDLC pack 的 README 开篇先划清了三份文档的职责边界Pack 内约定本文主题仅适用于 SDLC pack 内部的写作规范AGENTS.md项目级的通用判断准则所有 agent 都会加载保持精简.archon/workflow-language-constitution.mdYAML 语言的宪法任何触及 YAML 表面的改动都必须遵守YAML 协调代码计算Agent 判断YAML coordinates. Code computes. Agents judge.的总规则。这种分层是有意为之Pack 的规约解决这套工作流内部怎么写的具体问题而语言宪法解决任何工作流语言特性能否进入 YAML 表面的全局问题。阅读本规约时应把它视为语言宪法在 SDLC 场景下的具体应用。Guards守卫的取舍标准保留守卫的两个条件规约给出的判定标准非常明确一个守卫必须保护它所栖身节点自身执行的动作。两条保留准则验证节点刚刚做出的动作的效果——退出码为 0不是证明。gh pr ready对已经 ready 的 PR 执行同样会成功但什么都没改变对无法获得答案的问题拒绝继续且猜测的代价不可逆。例如archon complete阻止一个无法证明安全的分支删除就是这个形态。裁掉守卫的一个条件当守卫只是重复断言其他环节已经建立的不变量时它就该被裁掉。不变量应该在它被建立的地方出现一次而不是在每个依赖它的节点各写一遍。机械化的检验标准规约给出了一条可以终结大多数争论的判定如果本 Pack 的 fixture 套件无法演练exercise这个守卫它就不是守卫而是注释——请把它写成注释。原因在于dry run 无法执行的节点例如组合式bash:节点永远不会收到调用方传入的with:值只能被 stub任何 fixture 都无法展示守卫工作或抓出它失效。这条标准把威胁模型辩论转化为能否被 fixture 演练的机械检查。案例一次被裁掉的三重校验规约记录了一次真实的重构。Pack 曾在一处审查前 preflight 节点、ready 翻转节点和修正提示prompt三处验证checkout 处于我 PR 所在的分支三种拷贝、两种语言其中一份还依赖模型的自觉性。而事实上引擎给运行提供 worktreePR 就在该 worktree 中创建不变量由构造保证触发那次工作的告警经调查后判定无效关闭从未真正出错三份拷贝甚至没覆盖最容易因 checkout 漂移受损的步骤impl向 checkout 写代码时不检查validate在该 checkout 上跑项目测试也不检查。preflight 一处就花了 31 行代码和 17 个 fixture 里的 stub而没有任何 fixture 能运行该节点。三份拷贝最终全部删除。存活下来的部分恰好通过规则flip-ready节点拒绝无法规范化成owner/repo的 origin remote否则自己的gh调用会指向意外位置、拒绝在任何 check 非绿时翻转、并在翻转后回读 draft 状态因为成功退出不代表状态真的变了。这些都在保护节点自身的动作。守卫在 deliver 工作流中的实际分布在.archon/workflows/sdlc/deliver/archon-deliver.yaml中守卫被收敛到少量专门的script:节点上而不是散落在各 bash 里守卫节点守护的动作说明gate-green首次实现、每轮修正、最终项目门禁同一个脚本消费三次读取implement声明的green/red_cause/summary见下方详解assert-changedimplement是否真的产生了变更拒绝声明完成但没有改动的节点见.archon/workflows/sdlc/implement/archon-implement.yamlgate-ready审查结论是否真的为 ready用none_failed_min_one_success合并初始审查与修正循环的结论if_skipped只为跳过/未决生产者提供默认值gate-validated项目门禁后的最终确认与gate-green同一脚本第四处消费者flip-ready唯一不可逆的公开动作翻转前的 CI 自查、origin 规范化、翻转后回读全部内聚于此gate-green.py.archon/workflows/sdlc/deliver/scripts/gate-green.py的文档字符串明确写道run success never certifies green—this does, deterministically。它只消费三个 bound 输入INPUTS_GREEN、INPUTS_RED_CAUSE、INPUTS_SUMMARY并把每次放行 red 的决定追加写入red-causes.json——放行红色变更却没有任何痕迹是比拒绝更糟的结果。这正是守卫守护自身动作的落地即使放行继承性/环境性红色也要留下证据记录。守卫必须被 fixture 演练测试源码的印证规约fixture 无法演练就不是守卫的判定在.archon/scripts/__tests__/flip-ready-check-read.test.ts中体现得淋漓尽致该测试直接从archon-deliver.yaml中抽取flip-ready节点的 bash 主体替换模板引用后用伪造的gh与git可执行文件运行它从而证明失败的 check 读取必须在调用gh pr ready之前拒绝。测试注释点明flip-ready的输出被 fixture 直接 stub因此没有任何 fixture 能观察到失败的gh读取——这正是规约说节点只能被 stub的具体案例而测试通过抽取真实 bash 主体绕过了这一限制让守卫本身成为被测单元。Evidence never carries credentials证据永不携带凭据引擎的留存机制带来的责任引擎会保留每个 exec 节点打印的所有内容因此节点的输出就是记录无论节点是否打算保留它。这带来一条硬性规则永远不要打印可能包含秘密的值在它被规范化的地方读取它只传递规范化后的形式。最常见的例子就是 remote URL——https://tokenhost/repo是完全普通的 origin。因此flip-ready在读取 remote 的替换表达式内部就把 origin 规范化为owner/repo只有这个值会到达命令行。失败消息是同一块表面把原始值插值进错误消息泄露效果等同。凭据保护在 flip-ready 中的具体实现查看.archon/workflows/sdlc/deliver/archon-deliver.yaml中flip-ready节点的 bash 主体可以看到三层防护ORIGIN_REPO$(git remote get-url origin 2/dev/null | sed -E s#^.*:/$#\1#; s#\.git$##) case $ORIGIN_REPO in *[!A-Za-z0-9_.-]*/* | */*[!A-Za-z0-9_.-]* | */*/* | /* | */ | ) printf %s\n flip-ready: origin remote does not resolve to an owner/repo. 2 exit 1 ;; esac读取时即规范化正则把https://tokenhost/owner/repo.git截取为owner/repo凭据永远不会进入后续的变量白名单校验case 语句拒绝任何含有非常见字符、多级路径、绝对路径或空值的形式保证后续gh --repo调用指向确定的目标--repo显式固定目标注释解释了 fork clone 场景下gh的默认解析会指向上游父仓库--repo会禁用分支推断并要求显式选择器——这既是正确性要求也是防呆。转录取代手工日志因为引擎保留节点输出节点不再需要自己的日志。规约记录flip-ready曾经手工维护一份日志——把每条执行过的命令回显进一个 artifact。而现在这份内容由转录transcript免费提供。换言之节点自述这件事交给引擎的留存机制作者只需要保证自己撰写的信息出现在流中。工程规范 sidecarengineering.md 的读取约定sidecar 机制仓库可以在根目录或配置目录如.archon/声明一个engineering.md作为工程规范。写代码的 prompt 在写码前会读取它——目前implement命令携带这行约定就像任何工作流都可以读取仓库的方向性 sidecar 一样。在 Archon 仓库中.archon/engineering.md就是这样的文件。它的定位在文档开头写得很清楚本文件是工作被检查所依据的标准而不是做工作的指令。它之所以能写得更深是因为它只通过AGENTS.md的指针或评估者评审者、提问者、门禁设计者的显式简报到达 agent不会作为环境上下文被每个节点加载。其核心原则包括机器可检查的规则会毕业能被 lint 规则、类型或 CI 检查执行的条款会离开本文档本文档只保留需要判断力的内容目标函数正确优先成本效率其次速度最后风险分类学不可逆/破坏性路径、生命周期所有权、模式与持久化契约、凭据与认证边界、提供者与适配器边界、并发与共享资产worktree、session、lease——这些区域获得对抗性评审深度。值得注意的是.archon/engineering.md明确说明SDLC pack 在自己的 prompt 内部声明了一份通用版本的风险清单因为可复用 pack 无法读取本仓库独有路径那是一份有意的 fork而非同步镜像编辑一处不会改变另一处。条件式检查保证可移植性sidecar 的检查以文件存在为条件因此 pack 保持可移植没有该文件的仓库不会损失任何能力。任何新的写代码 pack 工作流都应携带同样的读取行。这与语言宪法中项目指导应可获取而非到处喷洒project guidance should be available, not sprayed everywhere的原则一脉相承——AGENTS.md是项目指导通道节点只应获得其职责所需的上下文。节点的流是操作员的信道stderr 的实时广播与不脱敏副本留存不是唯一的读者。节点写入 stderr 的任何内容都会在运行过程中实时发送给操作员即使节点成功——而且这份副本不做脱敏。因此节点要为自己发声捕获内部命令打印的内容只让自己撰写的消息到达流命令失败且其输出就是诊断时重新输出它命令只是工具在自说自话narrating itself时丢弃它捕获某个值的 stderr 时要分开捕获而不是合并——gh的更新通知如果被合并进一次读取就会变成那个值本身。flip-ready 中的流纪律flip-ready节点从头到尾贯彻了这条纪律代码注释逐行标注了理由if ! FLIP$(gh pr ready $PR_NUMBER --repo $ORIGIN_REPO 21); then printf %s\n flip-ready: the ready flip failed: $FLIP 2 exit 1 figh pr ready的输出不是值确认信息对节点无用因此两个流一起捕获只在翻转失败时重新输出——此时gh自己的话就是诊断读回 draft 状态与 URL 时捕获的是值gh pr view ... --json isDraft与--json url的 stderr 被丢弃2/dev/null因为gh的通知绝不能变成draft 状态或交付 URLGraphQL 检查计数的读取gh api graphql的退出码是结构化信号失败读取会拒绝翻转——失败的观察不等于没有 CI 存在的证据。值读取失败必须具名两条读回路径draft 状态、URL的失败信息都具名了它们无法完成的读取flip-ready: PR was flipped but its draft state could not be read back.——没有一条失败是静默的。从规约反推的实践清单把规约折叠成可操作的清单供编写或评审 SDLC pack 工作流时使用守卫Guards守卫必须保护所在节点自身的动作验证退出码 0之外的实际效果对无法获得答案且猜测不可逆的问题拒绝继续而不是猜不重复断言其他环节已建立的不变量——把不变量留在它建立的地方无法被 fixture 演练的守卫只是注释请写成注释。凭据Credentials5. 绝不打印可能含秘密的值在规范化处读取只传递规范化形式 6. remote URL 在读取表达式中就地规范化为owner/repo只有它到达命令行 7. 失败消息与 stdout 是同一块泄露表面插值原始值等于泄露 8. 引擎已留存转录节点不需要自己的日志。工程规范Sidecar9. 写代码的 prompt 在写码前读取存在的engineering.md检查以文件存在为条件保持 pack 可移植。流Streams10. stderr 实时到达操作员且不脱敏——只让自己撰写的信息进入流 11. 命令失败且其输出即诊断时重新输出工具自述时丢弃 12. 捕获值时分开捕获 stderrgh通知绝不能变成值本身。总结.archon/workflows/sdlc/README.md看似只是 Pack 的内部注释实际上浓缩了 Archon 自动化交付最核心的三条安全工程原则守卫要有可证明的价值——能被 fixture 演练且守护的是节点自己的动作而不是重复别人的不变量。flip-ready、gate-green、assert-changed这些存活的守卫全部落在节点自身动作这一侧而三重校验的 preflight 则被机械标准裁掉。凭据安全靠边界处理不靠纪律提醒——remote URL 在读取处规范化、白名单校验、--repo固定目标、失败消息不插值原始值全部内聚在.archon/workflows/sdlc/deliver/archon-deliver.yaml的flip-ready节点中且有.archon/scripts/__tests__/flip-ready-check-read.test.ts用伪造gh验证失败的读取必须拒绝翻转。流是操作员唯一的信道——stderr 实时、不脱敏地到达操作员节点用重新输出诊断 / 丢弃自述 / 分开捕获值的三段式纪律让自己成为可读、诚实、无冗余的自述者。这套约定与.archon/workflow-language-constitution.md的语言宪法、AGENTS.md的项目准则形成三层治理语言层面YAML 协调、代码计算、Agent 判断项目层面输入即契约Pack 层面守卫、凭据与流各守其位。对任何想要基于 Archon 构建可复现、可审计、可安全交付的自动化流程的开发者这份规约本身就是最值得先读的实现蓝图。【免费下载链接】ArchonThe first open-source harness builder for AI coding. Make AI coding deterministic and repeatable.项目地址: https://gitcode.com/GitHub_Trending/archon3/Archon创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考