Archify deployment-ownership 工程档案失败关闭的部署拓扑审查契约完整详解【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archifyArchify 是一个面向 AI Agent 的架构图绘制技能而它的 deployment-ownership 工程档案engineering profile把部署拓扑审查变成了一份可执行、失败关闭fail-closed的契约只要负责人、区域边界或跨边界机制有一处缺失验证立即失败。本文带你快速看懂这套契约的全部规则、诊断码与交付保证。为什么需要一份失败关闭的部署审查契约普通架构图有一个隐性风险图看起来很完整但关键事实其实是作者没填。谁负责哪个组件数据库在不在私有网络里跨区域链路走的是什么机制这些问题在没有契约时全靠自觉——AI 甚至可能编造一个看起来合理的答案。Archify 的设计哲学是不画什么和画什么同样重要这一点在官方对比图中体现得很直观deployment-ownership 契约就是针对这个问题的答案默认不启用一旦显式启用事实不全就直接失败而不是悄悄降级通过。 契约定义见 archify/schemas/README.md验收证据在 docs/deployment-ownership-profile-acceptance-2026-07-23.md。如何启用一行配置的可选契约启用方式极简——在 JSON 的meta中加一个字段{ meta: { engineering_profile: deployment-ownership } }三个关键设计约束只属于 Architecture 模式Workflow、Sequence、Data Flow、Lifecycle 四种图会直接拒绝该字段architecture.schema.json 中engineering_profile只允许这一个枚举值纯可选不写这个字段v1 输入走原有验证与渲染路径零破坏启用后不许删字段蒙混过关authoring-contract.md 明确规定失败时要么修复事实、要么如实报告诊断不能为了过验证而摘掉画像。六条失败关闭规则逐条拆解契约的核心实现只有 engineering-profiles.mjs 一个模块规则如下#规则违反时的诊断码1每个非外部组件必须在tag中写明负责人团队/ownerdeployment-owner-missing2每个非外部组件必须恰好属于一个Region 边界deployment-region-scope/deployment-region-ambiguous3文档中必须同时存在region和security-group两类边界deployment-boundary-kind4每个database必须位于某个私有安全组内deployment-private-state5每个安全组的成员必须来自同一个Region禁止跨区私网deployment-private-region-consistency6任何穿越Region 或安全组的连接必须在label中写明真实机制如 VPC route、cross-region WALdeployment-crossing-mechanism第 6 条的穿越判定值得注意它只看成员归属关系authored membership不看点谁画在哪里、线怎么绕——同范围的关系和自环不会产生虚假的标签要求这一点由 engineering-profile.test.mjs 中的交叉矩阵测试逐一覆盖outside→region、region→region、public→private、private→public 四类。每条诊断都附带精确的定位集合 下标 ID、证据如crossedBoundaries列表和一条可直接执行的修复建议例如set /connections/2/label to the real cross-boundary mechanism。交付保证回执、确定性与失败不覆盖通过验证只是开始Archify 还给了三层交付契约如实回执validate --json和deliver --json都会输出engineeringProfile: deployment-ownership生成的 HTML 根节点携带data-engineering-profile属性cli.mjs画廊卡片显示一条紧凑的DEPLOYMENT OWNERSHIP · PASS条带确定性同一份源文件重复交付HTML 的 SHA-256 完全一致——你可以把指纹当图没被偷偷改过的证明失败保留旧产物档案验收记录证实profile 校验失败的交付不会覆盖上一次的好产物last known good测试用preserved.html字节比对验证了这一点。渲染产物是这样一个自包含的暗色查看器可直接离线打开边界声明这份契约不做什么这是全文最容易被忽略、却最关键的一点验收档案第 29 行原话验证器只读你写下来的 IR。通过结果不是对仓库、IaC、云账号、运行时影响、可用性或线上部署状态的验证。也就是说契约保证的是这张图把该回答的问题都回答了而不是你的云上真的这么部署。事实未知时正确做法是不启用画像或去核实事实而不是让 AI 猜一个。上手试一试以官方生产部署样例 production-deployment.architecture.json 为例它包含 12 个组件platform / app team / data team / SRE 四类 owner、2 个 Regionus-east-1 生产 eu-west-1 灾备、2 个安全组以及 3 个引导视图请求边界、状态归属、异步运维。克隆仓库后即可验证git clone https://gitcode.com/GitHub_Trending/arch/archify cd archify/archify node bin/archify.mjs validate architecture examples/production-deployment.architecture.json --json看到engineeringProfile: deployment-ownership且ok: true说明六条规则全部通过。相关文件清单契约实现archify/renderers/shared/engineering-profiles.mjs示例数据archify/examples/production-deployment.architecture.json、v1 基线快照完整测试套件archify/test/engineering-profile.test.mjs作者契约archify/references/authoring-contract.md模式场景提示词archify/recipes/scenarios.mjs研究与设计动机docs/research-next-stability-delight-slice-2026-07-23.md验收档案472 项测试通过的发布门docs/deployment-ownership-profile-acceptance-2026-07-23.md一句话总结deployment-ownership 不是一张更漂亮的图而是一份部署事实不许缺席的可执行合同——启用它的那一刻起缺失就是错误错误就有精确位置而产物永远可复现。【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考