Archify deployment-ownership 工程档案：失败关闭的部署拓扑审查契约完整详解-二趣网

Archify deployment-ownership 工程档案：失败关闭的部署拓扑审查契约完整详解

【免费下载链接】archifyAgent skill for beautiful, verifiable architecture, workflow, sequence,>项目地址: https://gitcode.com/GitHub_Trending/arch/archify

Archify 是一个面向 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`中写明负责人（团队/owner）	`deployment-owner-missing`
2	每个非外部组件必须恰好属于一个Region 边界	`deployment-region-scope`/`deployment-region-ambiguous`
3	文档中必须同时存在`region`和`security-group`两类边界	`deployment-boundary-kind`
4	每个`database`必须位于某个私有安全组内	`deployment-private-state`
5	每个安全组的成员必须来自同一个Region，禁止跨区私网	`deployment-private-region-consistency`
6	任何"穿越"Region 或安全组的连接必须在`label`中写明真实机制（如 VPC route、cross-region WAL）	`deployment-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 个 Region（us-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，说明六条规则全部通过。

企业官网建设流程全解析