用途：把作者脑中的一条架构规则，变成已登记、可执行的目录条目。它是 LLM 驱动的编写对话，不是标准输入问答循环。
主要能力：六步访谈——1）引出：让作者一句话陈述规则，追问违规后果，提炼为摘要；2）定位：填写 dimension、applies-to（由作者指定 glob，不由框架推断）、phase-affinity、workflow-affinity；3）加权：severity.default（blocking 或 advisory）、可选 severity.by-workflow、integrity-class（面向使用者的规则为 user）、tier 选命名空间（你自己的仓库一律用 user，得到 U-N；dev/INV-N 是 exarchos 保留的 substrate 命名空间，使用者仓库会被拒绝）；4）执行：默认 mode: audit，由你根据规则起草 audit-prompt，mode: check 仅在规则可机械校验时作为高级选项；5）编号：不要手选 id，动词自动分配命名空间内下一个空闲 id；6）提交：先 dry-run 展示渲染条目与文件差异，明确确认后再写入，然后运行 doctor 并查看 invariants_effective 增量；7）修订：已提交条目的更正走 invariants_amend，id 不可改，patch 只列要改的顶层字段，其余原样保留，合并后按完整 v3 schema 重新校验。
使用方式：所有变更必须经过动词，不得手写、追加或编辑目录 YAML。动作包括 invariants_scaffold（幂等注册目录，不覆盖已有文件）、invariants_add（校验并追加一条新条目，dryRun 默认 true，append-only，id 冲突会被拒绝）、invariants_amend（原地更正一条已有条目）、doctor（复用 invariants-catalog 检查）、invariants_effective（查看合并投影的目录）。对应 CLI facade 为 exarchos invariants scaffold/add/amend、exarchos doctor、exarchos view invariants_effective。
限制：不适用于一次性 lint（应用项目 linter）、手工编写 YAML、工作流中途改状态、跑评审或做规划。enforcement DSL 为 .strict() 且仅声明式，没有 script/exec 代码逃生口。若 invariants_add 返回 CATALOG_NOT_FOUND，需先运行 invariants_scaffold；修订时 ENTRY_NOT_FOUND 可参考 validTargets，CATALOG_EMPTY/UNREADABLE 表示目录未解析到条目或被整体读不到。具体 schema 可用 exarchos:exarchos_orchestrate({ action: "describe" }) 或 CLI --help 在运行时查询。