x-arch

.claude/arch/business/_index.md 已固化业务域表里，每一行第 2 列反引号里的文档路径（相对 arch/business/）真实存在。

注册表按需登记，登记即承诺有文档；登记了却没建文档，读者照着注册表找过去就是死链。没登记的域不受这一条约束，免得一次性补考古。

新建业务域时先建域目录与 ARCH.md、CHANGELOG.md，再在注册表加一行，第 2 列写反引号包住的「归类层/域/ARCH.md」；下线域时文档与注册表行同批删除。_index.md 与 _context-map.md 留在 business 根，它们是名册与跨域图，不是域文档。

ARCH.md 以 frontmatter 开头，含 title、layer、status、version、describes、specRefs、sourceOfTruth 七个键；layer 写 business；status 只取 active、superseded、deprecated；describes 下 data、server、admin、client 四端键齐全，不涉及的端写 null；specRefs 列的每个名字是 references 下真实存在的规范，并且在正文里出现。

文档头是保鲜闸与注册表读取的结构化入口，缺键就算不出指纹。业务架构对系统规范只点名引用、不复述技术契约；抄进来就是第二份真相，规范一改它就过时。

文档头照这个形状写（subdomain、endScope、lastReviewed 等附加键可以有）：

  ---
  title: 订单业务架构
  layer: business
  status: active
  version: 1.0.0
  describes:
    data: ["x-data/ecommerce/order/**"]
    server: ["x-server/admin/ecommerce/order/**", "x-server/client/ecommerce/order/**"]
    admin: ["x-admin/src/xModules/order/**"]
    client: null
  srcHash: { data: 1a2b3c4d, server: 5e6f7a8b, admin: 9c0d1e2f, client: null }
  specRefs: ["x-api", "x-order"]
  sourceOfTruth: true
  ---

正文讲到技术契约时写「以 x-order 规范为准」，不抄规则内容。

describes 所指的四端代码变了之后，回看本域 ARCH.md、确认设计仍成立，同批升 version、重算 srcHash；某一端 srcHash 写 null，那一端就必须确实没有代码。

业务架构最常见的坏法是随代码演化静默过时。srcHash 把「代码变了」变成机器看得见的事实；null 必须与「确实没代码」一致，否则一个 null 就能绕过保鲜。

业务功能走 /x-feature-dev，收尾的 ARCH-SYNC 派 x-architect 回看、升版、重算。这是跨文件不变量，收尾环的增量检测够不到，提交前跑全量检测才会报出；报出的若不是本会话引入的改动（判据同宪法 §六.6；收尾环按写证据机器判归属，见 harness §八），按并行会话隔离铁律跳过。

有 ARCH.md 的域目录同时有同级 CHANGELOG.md。

日志载体缺了，下一次回看升版时版本记录无处可去，就会被写回文档头（ARCH-A05 防的就是这个）。

含 ARCH.md 的目录就是域目录，不含的中间目录是归类层，可以任意深嵌套，与 x-data 归类层一一对应。新建域目录时两份文件一起建；CHANGELOG.md 的 frontmatter 只放 title、domain、kind，条目分节写成「## v版本 — YYYY-MM-DD」。

日志写回文档头，读设计的人就得先读完历史流水（order 域曾因此让文档头占到全文一半以上）；真相源的身份键出现在日志上是两套账，还会诱使保鲜闸咬错文件。

版本记录只追加到同级 CHANGELOG.md；ARCH.md 的文档头里只留当前 version。

白名单外的文件不受任何 arch 闸保护，却坐在真相源旁边，读者分不清哪份算数。

分支架构放 parts/，架构决策记录放 adr/，图与可视化产物放 assets/；确实需要新形态，先走 /x-meta-dev 扩白名单，再落盘。

references 下每份规范（元规范 x-standard 除外）要么已迁成系统四件套，即有 arch/system/规范名/ARCH.html 与 CHANGELOG.md、规则书是条款书；要么登记在系统组注册表 x-arch-system.json 的迁移名册里。arch/system/ 下每个目录名都有同名规范，目录里只放 ARCH.html、CHANGELOG.md 与 assets/，根下不放文件；名册按名称排序、不重复，登记数等于 ceiling。

设计件与判据一一对应，每份规范才都有地方写设计理由，每份设计也都有判据可锁。名册只减不增，迁移只会往前走，新规范不会悄悄绕开四件套。

新建规范用 /x-meta-dev 的 tetrad 一次建整套，不进名册。迁一份旧规范：tetrad 建目录，按条款书格式改写规则书，写架构页原件与测试床点名，从名册划掉它并同批降 ceiling（名册计入 x-arch 判据指纹，x-arch 同批升补丁版），最后 sync 封版。

派生区从条款书、判据与注册表机械算出，手改一处就与来源分叉。每个区带输出版本、产出指纹与来源指纹：直接改了指纹对不上，来源变了戳记过期，引擎改了输出而页面没刷新版本号也对不上。

改原件（条款书、判据、注册表、assets/ 里的图）后跑 node .claude/skills/x-meta-dev/scripts/meta.js --action=sync --spec=规范名 --execute；普查快照要刷新时加 --census --date=YYYY-MM-DD。派生区以外的原件区照常直接写。

版本号只写在规范简介一处；CHANGELOG.md 的 frontmatter 恰为 title、spec、kind；条目标题写成「## V主.次.补 · YYYY-MM-DD」，自上而下严格递减，每条的下一行是判据指纹；最新条目等于规范简介版本，提交前已封版，且指纹等于当前判据指纹。

版本号写在多处必然漂。判据指纹把「这一版的判据长什么样」钉死，封版后判据再变而版本没升，就是没有留痕的改判据。

改判据（规范正文或同前缀注册表）时，规范简介升版本，变更历史顶部加新条目，指纹行写「> 判据指纹：（待同步）」；施工中跑 sync 刷新；本版写完跑 sync 加 --seal 封版。迁入前没有指纹的旧条目写「（迁入前无记录）」。

架构页原件区不残留骨架占位符；每颗闸都出现在测试床点名里，有床写床的路径，没有床写「待补床」；点名引用的「规范名:规则号」真实存在，点名引用的「规范名:ARCH-条款号」在该规范的条款书里真实存在；点名的床位于 x-test、真实存在，内文写着它守的每个「规范名:规则号」与「规范名:ARCH-条款号」；床的种类要写实 —— 跑本规范判据的床不写 data-bed-kind，床文件剥掉注释后就必须按调用形态出现引擎令牌（调用 extractNsRuleDetector(、buildDetectorTools(、checkStandardFormat( 之一，或把 check.js 作为路径段写出，或在注释以外写出 X-RULE-BEGIN-SLOT），守不变量、不跑判据的床写 data-bed-kind="invariant"；两者都不是的点名判红。

骨架没写完的架构页只是空壳。点名让每颗闸的验证追得到具体测试床，待补床在页面上标红，债务一眼可见；床里写明闸号，防止随手点一张不相干的床充数。床的种类必须写实，是因为 V1.3.0 之前这颗闸只证「床存在、写了闸号」，一行头注即满足 —— 于是守不变量却不跑判据的床（资损域回归床、装配对拍床）可以合法登记为「守这颗闸」，页面上的「已登记床」比它字面承诺的弱一档，读的人分不出哪些床真跑过判据（令牌因此按剥掉注释后的调用形态认，否则注释里一句 check.js、一个恰好含这段文字的文件名 access-check.js 都能充数）；条款号进点名是因为无机器闸的条款里有一批实际由床承接（逐字等值断言、导出面锁），此前无处登记。

在架构页「测试床」一节，每张床写一个带 data-bed 与 data-guards 属性的列表项，例如：

  <li data-bed="x-test/tetrad-arch-gates.test.js" data-guards="x-arch:NS-COMMON-0007 x-arch:NS-COMMON-0008">这张床测什么</li>
  <li data-bed="x-test/refund-order-update/refund-order-update.test.js" data-guards="x-api:NS-SERVER-0141 x-api:ARCH-F04" data-bed-kind="invariant">守锁配对与双分支逐字等值，不跑判据</li>

床文件头注释写「本床守护：x-arch:NS-COMMON-0007 x-arch:NS-COMMON-0008」（条款号同样写进去）。判据床用 require 引擎的 scanners 取 extractNsRuleDetector 喂样本，或调引擎真 STD 执行器 checkStandardFormat，或直接跑 check.js，或手抠判据的 X-RULE-BEGIN-SLOT 块再经 buildDetectorTools 喂 tools 跑（都算真跑判据）；闸只认注释以外的调用形态，头注里提一句不算，调用经别名改名（const { extractNsRuleDetector: ext } = … 后只写 ext(）它也认不出。只守不变量的床把 data-bed-kind="invariant" 写在点名上，不要为了显得「真跑了」去凑一次无意义的引擎调用。

系统架构页遵循《系统架构标准》可机判的那一面 —— 节只取自标准名册且顺序与名册一致、必填节齐全（s-census 与 s-ops 是条件节，不适用的域不建）、每节带 data-index 与 data-kicker 编号属性、页面挂共用表达层（body 带页面类、head 引共用样式表）。判定依据是名册 x-arch-standard.json，散文版住 .claude/arch/standards/system-architecture-standard.html，两者的关系与条款书和判据相同。

标准立起来之后，「按它长成一个样」这件事此前零机器强制 —— 实测过：一份还是旧骨架、没有任何编号属性、没挂表达层的架构页，四颗架构闸跑下来十项全过。于是三十多页可以各长各的而报表全绿，跨域对比失效，读者每翻一页都要重新学一遍这一页的结构。名册只收可判的形态（节、属性、引用），不碰「写得对不对」；标准里「不许发明第二套设计语言」「整页只有一种底色」这类要求判据够不着，仍由写页时读标准与人审兜底。名册里的 pending 是棘轮：立闸当轮把尚未改造的域全部登记进去整条静默，否则所有架构页同时爆红、一页也改不动。

改造一页 → 从 pending 划掉它并把 ceiling 降到登记数 → 跑 sync 升版封版（名册同前缀，计入 x-arch 判据指纹）→ 对那一页跑本规范扫描验零。新建的规范直接按标准写，不进名册。节的顺序与必填态改动属于改标准：先改散文版说清为什么，再改名册，两者同一轮。

arch/business/** 由 x-architect 在开发流收尾的 ARCH-SYNC 里撰写；arch/system/**、规则书与规范由 x-meta-governor 经 /x-meta-dev 撰写；开发流不写 arch/system/。

业务架构跟着代码走，在开发流收尾回看；系统架构跟着判据走，改它就是改治理，要过升版与封版。混着写，一个改动就能同时躲开两个环的把关。

开发中发现系统规范或它的设计要改，回头触发 /x-meta-dev；改了业务域代码，在收尾派 x-architect 回看对应域文档。