@mc-and-his-agents/loom-installer 0.1.1

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/host-issue-binding.md

@@ -0,0 +1,90 @@
+# Host Issue Binding
+
+本文件定义 Loom 当前消费 `active issue` 与宿主 branch、`git worktree`、PR、merge commit 之间绑定关系的最小合同。
+
+`active issue` 的主定义不在本文件。
+本文件只承接 Loom 为了执行、定位、放行与收口而必须消费的绑定事实。
+
+## 1. 能力定位
+
+本文件回答：
+
+- Loom 在执行侧最少需要读取哪些 host 绑定关系
+- 哪些绑定关系可用于判断实现是否已被 host merge 吸收
+- 单个 host PR 吸收多个 issue 时最少要能表达什么
+- 哪些结论仍不能直接等同于 `closed_out`
+
+## 2. 最小绑定对象
+
+当某正式事项进入实现与收口链路时，Loom 只消费以下绑定关系：
+
+- `active issue -> host branch`
+- `active issue -> git worktree`
+- `active issue -> host PR`
+- `host PR -> merge commit`
+
+这些绑定关系都属于 host control truth 或其派生读取结果。
+Loom 可以读取、校验、汇总并据此阻断，但不在仓内 authored 第二套主定义。
+
+## 3. 最小消费规则
+
+Loom 至少消费这些绑定关系用于以下动作：
+
+- `workspace locate` / recovery
+  - 判断当前执行现场是否仍服务同一正式事项
+- merge-ready / closeout check
+  - 判断实现载体、合并结果与主干事实是否一致
+- cleanup / retire
+  - 判断某 host branch 或 `git worktree` 是否仍被正式事项占用
+
+若绑定关系缺失、指向冲突或无法证明当前实现属于同一事项，结果必须返回 `block` 或显式 drift。
+
+## 4. 单 PR 吸收多事项
+
+单个 host PR 可以吸收多个 issue，但前提是这些 issue 的实现缺口确实都被该 PR 对应的 merge 结果覆盖。
+
+Loom 最少需要能机械回答两件事：
+
+- 这个 host PR 吸收了哪些 issue
+- 哪些相关 issue 仍保留独立剩余缺口，不能被一起判定为 `absorbed`
+
+因此：
+
+- PR body、closing rationale、merge commit 或等价宿主证据中，至少要有一处能稳定表达 issue 与 merged work 的对应关系
+- 若同一 PR 同时涉及 parent / child issue，默认只吸收被明确证明已覆盖的 issue，不得把整棵 tree 一并视为已吸收
+
+## 5. `absorbed`
+
+`absorbed` 是 Loom 在 harness 层定义的实现吸收结论。
+
+它只表示：
+
+- 某正式事项对应的实现已经通过 host merge 进入主干
+- 这一结论可以被宿主事实证明，而不是凭口头判断
+
+最小证明面至少包括：
+
+- 对应 host PR 已 merged
+- 对应 merge commit 可定位
+- merge commit 已被目标主干吸收
+
+`absorbed` 不等于：
+
+- `closed_out`
+- issue 已关闭
+- project 状态已同步完成
+- 恢复主入口或现场已清理完毕
+
+在 issue tree 中：
+
+- child issue
+  - 可以因自身缺口已被其他 merged work 覆盖而形成 `absorbed`
+- parent issue
+  - 可以消费 child 的 `absorbed` 结果，但不得仅因某个 child 被吸收就自动视为自身已 `closed_out`
+
+## 6. 边界约束
+
+- 本文件不主定义 `active issue` 的语义、生命周期或 authored 字段
+- 本文件不把 `workspace` 写成 `git worktree`
+- 本文件不要求每个宿主都必须暴露同名字段；只要求绑定关系可被稳定证明
+- 本文件不接管 branch、PR、`git worktree` 或 merge 的宿主生命周期动作

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/host-lifecycle-boundary.md

@@ -0,0 +1,56 @@
+# Host Lifecycle Boundary
+
+本文件定义 Loom 与宿主平台在 `workspace`、branch、PR、git worktree 之间的生命周期边界。
+
+宿主动作入口、结果词表与 `fallback_to` 纪律的统一主落点见 [host-action-contract.md](./host-action-contract.md)。
+
+稳定命名与对象分类见 [../governance/host-object-taxonomy.md](../governance/host-object-taxonomy.md)。
+`active issue` 与 branch / `git worktree` / PR / merge commit 的绑定消费见 [host-issue-binding.md](./host-issue-binding.md)。
+
+## 1. 结论
+
+- `workspace`
+  - 属于 Loom execution object，进入 Loom 执行层
+- branch
+  - 属于 host control object，保留给宿主平台
+- PR
+  - 属于 host control object，保留给宿主平台
+- git worktree
+  - 属于 host control object，保留给宿主平台
+
+## 2. Loom 承接什么
+
+Loom 固定承接：
+
+- `workspace_entry` 对应的执行现场语义
+- 对 `active issue -> branch / git worktree / PR / merge commit` 绑定关系的读取与校验
+- recovery 与 checkpoint 对执行现场的绑定
+- branch / PR / worktree 是否已经影响执行正确性的边界检查结果
+- merge 前对 host merge 的统一放行判断
+- host merge 后实现是否已被 `absorbed` 的可证明结论
+
+## 3. Loom 不承接什么
+
+Loom 当前不提供以下原生命令：
+
+- branch create / rename / retire
+- PR create / update / merge / close
+- git worktree create / remove
+
+这些动作继续留给 Git / GitHub 或其他宿主平台。
+
+## 4. 边界读取入口
+
+- `python3 skills/shared/scripts/loom_flow.py host-lifecycle --target <repo> [--item <id>]`
+- `python3 skills/shared/scripts/loom_flow.py workspace create|locate|cleanup|retire --target <repo> [--item <id>]`
+- `python3 skills/shared/scripts/loom_flow.py purity-check --target <repo> [--item <id>]`
+
+更广的 host-facing actions，例如 `checkpoint merge`、`flow merge-ready`、`reconciliation audit|sync`、`closeout check|sync`，统一由 [host-action-contract.md](./host-action-contract.md) 索引。
+
+## 5. 边界约束
+
+- branch / PR purity 可以被 Loom 报告和消费，但不意味着 Loom 接管其生命周期
+- `workspace` 是执行现场抽象，不等于 git worktree
+- Loom 只消费 `active issue` 与宿主对象的绑定，不在这里主定义 `active issue`
+- 宿主对象的 UI、命名、按钮与策略不进入 Loom 默认内核
+- `host-lifecycle` 正常只读边界，不把宿主动作缺口伪装成 `fallback`；回退纪律由 [host-action-contract.md](./host-action-contract.md) 统一承接

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/merge-checkpoint.md

@@ -0,0 +1,95 @@
+# Merge Checkpoint
+
+本文件定义 Loom 当前 merge checkpoint 的执行侧合同。
+
+本文件当前承接：
+
+- `#27` 的稳定落点
+- harness 侧放行承接语义
+
+## 1. 能力定位
+
+merge checkpoint 是执行侧的最终放行层。
+
+它只回答三类问题：
+
+- 当前 head 是否仍在已批准范围内
+- 当前执行材料是否已经完整到足以进入主干
+- 当前自动检查、验证摘要与运行证据是否支持放行
+
+它不承担第一次高质量语义判断，也不替代 governance 的前置准入与 reviewer 的审查职责。
+字段归属以 [fact-chain-contract.md](./fact-chain-contract.md) 为准。
+
+## 2. 放行前必读输入
+
+进入 merge checkpoint 前，至少应能读取以下事实：
+
+- 当前变更范围与目标
+- 关联事项、规格或等价正式工件
+- 自动检查结果
+- 正式 review record
+- 最近验证摘要
+- 运行时证据或 `not_applicable` 声明
+- 风险与回滚边界
+- 未决阻断项
+- 当前 head 是否仍在批准范围内
+
+这些事实通常分别来自：
+
+- [work-item-contract.md](./work-item-contract.md)
+- [recovery-model.md](./recovery-model.md)
+- [status-surface.md](./status-surface.md)
+- [review-execution.md](./review-execution.md)
+- [automation-frontload.md](./automation-frontload.md)
+
+其中：
+
+- 范围、目标、执行路径、验证入口定位
+  - 只能从 `work item` 读取
+- 当前 checkpoint、停点、下一步、阻断项、最近验证摘要、回退边界
+  - 只能从恢复主入口读取
+- 正式 review 结论
+  - 只能从 `work item.review_entry` 指向的 review record 读取
+  - 其中 `findings` 是 review/disposition 的权威字段；`blocking_issues` / `follow_ups` 只作兼容投影
+  - 即使 formal review 由默认 engine 产出，merge checkpoint 也只消费回写后的 review record，不直接读取 engine raw output 或 evidence 文件
+- 状态面
+  - 只允许作为派生汇总读面，不得替代上述主真相
+
+## 3. 唯一允许结果
+
+merge checkpoint 只允许输出以下三类结果：
+
+- `允许放行`
+  - 执行材料完整，自动检查与验证结果足以承接进入主干
+- `阻断待补`
+  - 仍有未补齐材料，但不必回退到更早 checkpoint 重做方向判断
+- `退回前序 checkpoint`
+  - 当前 head 已超出批准范围，或关键事实缺失到必须回退到前序 checkpoint 重新收口
+
+不允许输出模糊结果，例如“基本可以”“先合再说”“口头同意”。
+
+## 4. 回退承接
+
+当 merge checkpoint 给出非放行结果时，回退方向必须清晰：
+
+- 缺自动检查、结构检查或基础状态一致性
+  - 回到 [automation-frontload.md](./automation-frontload.md) 对应检查面
+- 缺验证摘要、运行证据或 `not_applicable` 声明
+  - 回到 [status-surface.md](./status-surface.md) 与实际验证入口
+- 缺 formal review、review stale 或 reviewer 明确要求回退
+  - 回到 [review-execution.md](./review-execution.md) 或 `build checkpoint`
+  - 若 review 之后只提交了 `review_entry`、recovery 主入口或状态面这类 Loom carrier 更新，不应误判成 stale
+- 缺停点、下一步、风险或回滚边界
+  - 回到 [recovery-model.md](./recovery-model.md)
+- head 已超出批准范围或事项边界失真
+  - 退回前序 checkpoint，重新做范围与方向收口
+
+## 5. 边界约束
+
+- merge checkpoint 消费 reviewer、自动检查和运行证据的结果，不重新发明第二套审查体系
+- merge checkpoint 只消费单一 review record，不为 findings / disposition 再引入第二 authored artifact
+- merge checkpoint 不直接消费 Codex output、prompt、logs 或其他 review evidence 文件
+- merge checkpoint 只回答“是否可进入 host merge”，进入主干后的 issue / project / main 收口由 [closeout-gate.md](./closeout-gate.md) 承接
+- merge checkpoint 不负责定义成熟度、关闭语义或事项是否值得做；这些属于 `governance/`
+- merge checkpoint 不得补读另一份 authored 状态摘要来替代恢复主入口
+- 本文件不规定宿主平台的按钮、合并策略或 CI 产品，只定义 Loom 必须承接的最小放行语义

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/reconciliation-audit.md

@@ -0,0 +1,64 @@
+# Reconciliation Audit
+
+本文件定义 Loom 当前 `reconciliation audit` 的最小执行合同。
+
+本文件当前承接：
+
+- `#177`
+
+## 1. 能力定位
+
+`reconciliation audit` 用来回答三件事：
+
+- merged PR 是否已经吸收了仍然 open 的 issue
+- parent issue 是否仍与 child 的真实状态一致
+- issue / PR / project 的控制面状态是否已经漂移
+
+它只读 GitHub 控制面真相并输出审计结论，不做任何写回。
+
+## 2. 稳定入口
+
+- `python3 skills/shared/scripts/loom_flow.py reconciliation audit --target <repo> [--issue <n>] [--pr <n>] [--project <n>]`
+
+## 3. 稳定 findings
+
+第一版固定三类 finding：
+
+- `absorbed_but_open`
+  - merged PR 已进入主干，但 issue 仍 open
+- `parent_drift`
+  - parent issue 的开关状态与 child 的真实剩余缺口不一致
+- `project_drift`
+  - issue / PR 的 Project 状态与当前控制面结论不一致
+
+每条 finding 至少表达：
+
+- `kind`
+- `severity`
+- `subject`
+- `evidence`
+- `recommended_action`
+
+## 4. 结果语义
+
+`reconciliation audit` 只允许以下结果：
+
+- `pass`
+  - 没有 drift finding
+- `warn`
+  - 只有低严重度观察结论
+- `fix-needed`
+  - 已发现必须同步但尚未阻断的 drift
+- `block`
+  - 已发现不能继续视为 closeout-ready 的 drift，或必需输入缺失
+
+## 5. 边界约束
+
+- 本入口只生成审计结论，不执行 GitHub 修改
+- issue tree 关系通过 GitHub GraphQL 读取，不回写到仓内 docs
+- `absorbed` 的宿主证明继续由 [host-issue-binding.md](./host-issue-binding.md) 承接
+- 修复 drift 的正式入口由后续 reconciliation sync 承接，本文件不提前定义写路径
+
+## 6. 一句话结论
+
+Loom 先用 `reconciliation audit` 明确报出 absorbed-but-open、parent drift 和 project drift，再决定是否允许后续 closeout 或进入专门 sync。

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/recovery-model.md

@@ -0,0 +1,101 @@
+# Recovery Model
+
+本文件定义 Loom 当前最小恢复模型。
+
+本文件当前承接：
+
+- `EXT-0003`
+- `EXT-0013`
+- `EXT-0038` 的每轮回写部分
+
+完整执行顺序见 [execution-chain.md](./execution-chain.md)。
+
+## 1. 能力定位
+
+恢复模型用于让长任务在多轮执行后仍有唯一可读主入口。
+
+它负责：
+
+- `checkpoint`
+- `resume`
+- `handoff`
+- 每轮结束后的状态回写
+
+字段归属见 [fact-chain-contract.md](./fact-chain-contract.md)。
+
+## 2. 唯一恢复主入口
+
+每个正式事项必须有唯一恢复主入口。
+
+默认要求：
+
+- 继续执行前，先回到该入口
+- 其他工件只能补充，不得并行充当主入口
+- 恢复主入口必须与当前事项直接绑定
+- merge checkpoint 消费最近恢复事实，但不替代该入口
+
+## 3. 最小恢复事实集
+
+恢复主入口至少应能回答：
+
+- 当前事项是什么
+- 当前停点在哪里
+- 下一步是什么
+- 当前 checkpoint 阶段是什么
+- 已验证了什么
+- 当前阻断项是什么
+- 最近一次稳定提交点或等价回退边界是什么
+- 当前 lane 是什么
+
+`handoff` 还应额外指明：
+
+- 接手所需上下文入口
+- 当前主要风险或待确认点
+
+## 4. 每轮回写最小事实集
+
+正式执行轮次结束后，默认回写：
+
+- 当前 `progress` / `checkpoint`
+- 本轮完成的单一推进单元
+- 新的下一步
+- 本轮新增验证事实或验证摘要
+- 仍未解除的阻断项
+- 在需要时形成明确提交点或等价可恢复边界
+
+当前稳定回写入口为：
+
+- `python3 shared/scripts/loom_flow.py recovery writeback --target <repo> [--item <id>] ...`
+
+边界固定如下：
+
+- `resume` / `handoff` 只读，不得隐式写 recovery authored 字段
+- `recovery writeback` 只写恢复主入口，再同步重渲染状态面
+- 状态面不接受独立 authored 修改
+
+## 5. `checkpoint-lite` 与标准恢复形态
+
+Loom 默认承认两种恢复形态：
+
+- `checkpoint-lite`
+  - 停点、下一步、阻断项寄存在 issue / PR 等现有载体
+  - 仅适用于低复杂度、低恢复成本、且已有单一稳定宿主载体的场景
+- 标准恢复形态
+  - 使用明确恢复工件承接 `checkpoint`、`resume`、`handoff`
+  - 必须有唯一恢复主入口
+
+一旦出现以下任一信号，应从 `checkpoint-lite` 升级到标准恢复形态：
+
+- 事项经常跨多轮推进
+- 中断恢复成本明显升高
+- 出现多个入口并行记录
+- merge checkpoint 已需要稳定消费风险、验证摘要与回退边界
+- 不存在单一稳定宿主载体，或当前仓库同时存在多个运行 / 状态入口
+
+## 6. 边界约束
+
+- 不得只依赖聊天记录、分支名或个人记忆恢复
+- 不得在多个文档中并行维护“下一步”
+- 恢复主入口是动态执行真相的唯一主入口；状态面与 merge checkpoint 只允许派生消费
+- `exec-plan` 或等价恢复工件只承接执行与恢复，不替代正式需求真相
+- 本文件不重复定义回写后如何进入验证汇总与放行；该顺序由 [execution-chain.md](./execution-chain.md) 与 [merge-checkpoint.md](./merge-checkpoint.md) 承接

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/review-execution.md

@@ -0,0 +1,99 @@
+# Review Execution
+
+本文件定义 Loom 当前最小正式 review 执行层。
+
+## 1. 能力定位
+
+Loom 把 review 分成三层：
+
+- `pre-review`
+  - 机械预检，判断是否具备进入正式审查的最低条件
+- `review`
+  - 正式语义审查，输出 reviewer 结论
+- `merge-ready`
+  - merge 前统一放行聚合
+
+`review` 不替代前后两层，也不把语义判断硬编码成脚本。
+默认开箱即用路径固定为：
+
+1. `flow review`
+   - 只读基线；确认是否具备进入 formal review 的条件
+2. `review run`
+   - 调用默认 Codex-backed reviewer，产出结构化 review evidence 与 Loom-normalized findings
+3. `review record`
+   - 把 formal review 结论写入单一 authored review record
+
+## 2. 唯一 review 载体
+
+正式 review 结论必须落在唯一 `review_entry` 指向的 review record。
+
+默认入口：
+
+- `python3 skills/loom-review/scripts/loom-review.py flow review --target <repo> [--item <id>]`
+- `python3 skills/shared/scripts/loom_flow.py review run --target <repo> [--item <id>]`
+- `python3 skills/shared/scripts/loom_flow.py review record --target <repo> [--item <id>] --decision <allow|block|fallback> --kind <general_review|code_review|spec_review> --summary <text> --reviewer <id>`
+
+其中：
+
+- `flow review` 固定保持只读，不触发 engine，也不产生副作用
+- `review run` 只负责运行默认 reviewer、落盘 evidence、生成 normalized findings，并显式 fail-closed
+- `review record` 仍只写入单一 `review_entry` 指向的 JSON
+- 结构化审查结论可通过 `--findings-file <path>` 写入同一 review record
+- `--blocking-issue` / `--follow-up` 只保留兼容 authored 入口，不得与 `--findings-file` 混用
+
+默认 engine 当前固定为 Codex。
+若 engine 不可用、schema 漂移、runtime 冲突或运行后改动了 tracked repo 内容，`review run` 必须返回 `block`，并指向 manual review 继续写回同一 `review record`；不得把这类失败伪装成 checkpoint fallback。
+
+## 3. review record 最小字段
+
+review record 至少应包含：
+
+- `item_id`
+- `kind`
+- `reviewed_head`
+- `reviewed_validation_summary`
+- `decision`
+- `summary`
+- `reviewer`
+- `fallback_to`
+- `findings`
+- `blocking_issues`
+- `follow_ups`
+
+模板见 [../templates/review-record.md](../templates/review-record.md)。
+
+其中：
+
+- `findings` 是正式审查结论的权威数组
+- 每条 finding 至少应包含 `id`、`summary`、`severity`、`rebuttal`、`disposition`
+- `severity` 当前稳定值为 `warn`、`block`
+- `rebuttal` 当前稳定值为 `null` 或非空字符串
+- `disposition` 当前稳定值为 `null` 或对象；对象内的 `status` 只允许 `accepted`、`rejected`、`deferred`
+- `blocking_issues` / `follow_ups` 只是从 `findings` 投影出的兼容字段，不构成第二真相源
+- `consumed_inputs.engine_adapter`、`consumed_inputs.engine_evidence`、`consumed_inputs.normalized_findings`
+  - 只记录 evidence 来源，不构成第二 authored truth
+
+## 4. 与 merge checkpoint 的边界
+
+`merge checkpoint` 固定只做机械消费：
+
+- 读取 `work item.review_entry`
+- 校验 `item_id` 是否匹配当前事项
+- 校验 `reviewed_head` 是否仍匹配当前 `HEAD`
+  - 若 `HEAD` 在 review 之后只新增了 Loom 自身的 review / recovery / status carriers 提交，允许继续消费
+  - 一旦 `HEAD` 还包含其他路径漂移，仍按 review stale 处理
+- 校验 `reviewed_validation_summary` 是否仍匹配当前 recovery 的 `latest_validation_summary`
+- `decision: allow` 才算 review 已通过
+- `decision: block` 返回 `block`
+- `decision: fallback` 按 `fallback_to` 返回 `fallback`
+- 如需读取阻断或后续事项，只能优先消费同一 review record 内的 `findings`
+
+它不得直接消费 engine raw output、prompt、日志或其他 evidence 文件。
+
+## 5. 非目标
+
+- 不把 review 结论写回 recovery entry 或 status surface
+- 不让 PR 模板充当正式 review 真相
+- 不让 merge-ready 替代正式 review
+- 不为 rebuttal / disposition 再创建第二份 review artifact 或新状态机
+- 不把 Loom 扩写成 multi-engine marketplace

package/payload/skills/loom-adopt/.loom-runtime/shared/references/harness/runtime-state.md

@@ -0,0 +1,103 @@
+# Runtime State
+
+本文件定义 Loom installed-skills 的最小运行态识别与 fail-closed 合同。
+
+## 1. 能力定位
+
+`runtime-state` 只回答 Loom 当前入口自己处于什么运行场景、依附什么 carrier、以及为什么可以或不可以继续执行。
+
+它不回答：
+
+- 当前事项进度
+- 目标仓库的运行/日志/验证入口
+- `governance_surface` 所承接的治理装配状态
+
+## 2. 固定词表
+
+`scene` 固定只允许：
+
+- `repo-local-demo`
+- `installed-runtime`
+- `upgrade-rehearsal`
+
+`carrier` 固定只允许：
+
+- `repo-local-wrapper`
+- `installed-skills-root`
+- `bootstrapped-target-runtime`
+
+`entry_family` 固定只允许：
+
+- `loom-init`
+- `loom-flow`
+
+## 3. 最小读面
+
+`runtime-state` 至少应暴露：
+
+- `scene`
+- `carrier`
+- `entry_family`
+- `install_root`
+- `runtime_root`
+- `registry_path`
+- `layout_or_manifest_path`
+- `source_repo_root`
+- `checks`
+
+其中 `checks` 至少固定给出：
+
+- `scene_marker`
+- `carrier_layout`
+- `registry_contract`
+- `shared_runtime`
+- `referenced_resources`
+
+每项检查只允许：
+
+- `pass`
+- `block`
+- `not_applicable`
+
+## 4. 场景与 carrier 关系
+
+- `repo-local-demo`
+  - 只能来自 `repo-local-wrapper`
+- `installed-runtime`
+  - 默认来自 `installed-skills-root`
+  - `bootstrapped-target-runtime` 若未显式声明 rehearsal，也归入此场景
+- `upgrade-rehearsal`
+  - 必须由显式 `LOOM_RUNTIME_SCENE=upgrade-rehearsal` 进入
+  - 只允许来自 `installed-skills-root` 或 `bootstrapped-target-runtime`
+
+若 `scene` 与检测到的 `carrier` 冲突，必须直接 `block`。
+
+## 5. Fail-Closed 纪律
+
+以下任一条件都必须 `block`，不得继续伪装成可运行：
+
+- shared runtime 缺失
+- shared references / assets 缺失
+- `install-layout.json` 缺失或 required paths 不齐
+- `registry.json` / `upgrade-contract.json` 漂移
+- skill-local executable 不可达
+- `.loom/bootstrap/manifest.json` 缺失或与 `.loom/bin` runtime 文件不一致
+- 显式 `LOOM_RUNTIME_SCENE` 与检测到的 carrier 冲突
+
+顶层 `fallback_to` 固定只允许：
+
+- `refresh-install`
+- `rebootstrap-runtime`
+- `manual-runtime-reconciliation`
+- `null`
+
+## 6. 与其他读面的边界
+
+- `runtime-state`
+  - 回答 Loom 入口自身是否处于稳定安装/运行态
+- `runtime-evidence`
+  - 回答目标仓库当前事项的运行/日志/诊断/验证入口
+- `governance_surface`
+  - 回答仓库 Loom 装配态与治理载体/宿主控制面的落位
+
+这三者不得互相伪装成别名。