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

package/payload/skills/loom-review/contract.json

@@ -0,0 +1,49 @@
+{
+  "contract_version": "1.4.0",
+  "description": "Run the formal semantic review layer on top of pre-review and return authoritative review findings plus a verdict without replacing merge-ready.",
+  "display_name": "Loom Review",
+  "entrypoint": {
+    "adapter_metadata": "agents/openai.yaml",
+    "orchestration_cli": "scripts/loom-review.py",
+    "skill_markdown": "SKILL.md"
+  },
+  "id": "loom-review",
+  "input_contract": {
+    "reference": "references/input-signals.md",
+    "required_fields": [
+      "target_repository",
+      "current_item_or_active_item",
+      "review_intent"
+    ]
+  },
+  "installation": {
+    "layout_manifest": ".loom-runtime/install-layout.json",
+    "registry": ".loom-runtime/registry.json",
+    "upgrade_contract": ".loom-runtime/upgrade-contract.json"
+  },
+  "output_contract": {
+    "reference": "references/output-contract.md",
+    "required_sections": [
+      "item",
+      "result",
+      "summary",
+      "missing_inputs",
+      "fallback_to",
+      "runtime_state",
+      "steps",
+      "state_check",
+      "runtime_evidence",
+      "build_checkpoint",
+      "review",
+      "engine",
+      "manual_review",
+      "current_checkpoint"
+    ]
+  },
+  "role": "scenario/review",
+  "root_entry": false,
+  "routing": {
+    "explicit_name": "loom-review",
+    "reference": "references/route-matrix.md"
+  }
+}

package/payload/skills/loom-review/references/input-signals.md

@@ -0,0 +1,15 @@
+# Loom Review Input Signals
+
+当任务满足以下任一信号时，进入 `loom-review`：
+
+- 正式 review
+- 语义审查
+- 输出审查结论
+- 输出 findings 和风险等级
+- pre-review 通过后进入审查执行
+
+最小输入：
+
+- 目标仓库
+- 当前事项编号，或允许从事实链定位活跃事项
+- review 意图与关注面（例如正确性、回归风险、合同一致性）

package/payload/skills/loom-review/references/loom-init/input-signals.md

@@ -0,0 +1,16 @@
+# Loom Init Input Signals
+
+`loom-init` 继续使用现有初始化问诊信号作为 root 入参合同。
+
+稳定输入信号见：
+
+- [intake-signals.md](intake-signals.md)
+
+当任务不是初始化，而是执行中的日常动作时，还必须结合：
+
+- [../route-matrix.md](../route-matrix.md)
+
+root skill 只在两种情况下继续留在 `loom-init`：
+
+- 任务明确是初始化 / retrofit
+- 任务信号不足，无法稳定路由到单一场景 skill

package/payload/skills/loom-review/references/loom-init/intake-signals.md

@@ -0,0 +1,155 @@
+# Intake Signals
+
+使用本文件组织 `loom-init` 的初始化问诊与场景判断。
+
+## 1. 输入目标
+
+本合同只负责两件事：
+
+- 把目标仓库稳定判到以下三类场景之一：
+  - `新项目`
+  - `小型既有仓库`
+  - `复杂既有仓库`
+- 基于场景判断导出默认装配路径，而不是停留在零散提示
+
+本合同服务入口判断，不替代 `governance`、`harness`、`templates` 的规则真相。
+
+## 2. 最小必判字段
+
+初始化前，至少要完成以下字段的判断：
+
+- 仓库类型
+  - `新项目`
+  - `既有仓库`
+- 根级边界文档是否清晰
+  - 例如 `AGENTS.md`、同类规则入口或等价边界文档
+- 是否已有 CI / 基础测试
+- 是否已有统一的仓库级验证入口
+- 当前主要缺口属于哪一类：
+  - 治理入口 / review 合同 / 条件化 spec 路径
+  - 恢复 / 状态 / 执行支撑
+- 是否有明显长任务恢复痛点
+- 是否存在共享契约 / 共享数据模型 / 核心抽象 / 高风险链路
+- 是否存在分支混杂、PR 混题、脏现场叠加
+- merge 前是否承担第一次高质量语义判断
+
+若以上任一字段未完成判断，不得直接给出初始化路径结论。
+
+## 3. 每项字段的取证来源
+
+默认按以下顺序取证：
+
+1. 目标仓库现状
+   - 根级规则文档
+   - README、流程文档、模板
+   - CI、测试、统一验证入口、PR 习惯、issue / PR 载体
+2. Loom 现有规则与 adoption 文档
+   - 用于映射信号，不用于替代目标仓库事实
+3. 用户补充信息
+   - 仅在仓库现状不能稳定推断时再问
+
+取证约束：
+
+- 优先从仓库现状读取
+- 缺失时再问用户
+- 不允许靠临场经验补脑
+- 不能把单次会话中的猜测当成稳定信号
+
+## 4. 三类场景判定规则
+
+### 4.1 `新项目`
+
+满足以下条件时，判为 `新项目`：
+
+- 仓库尚未形成稳定工程基线
+- 当前目标是建立最小起步结构，而不是 retrofit 既有流程
+
+默认装配路径：
+
+- 最小装配
+- 不预装重 harness
+- 只建立后续可升级入口
+
+### 4.2 `小型既有仓库`
+
+满足以下条件时，判为 `小型既有仓库`：
+
+- 已有清晰根级边界文档
+- 已有 CI / 基础测试
+- 已有统一的仓库级验证入口
+- 当前缺口主要在治理入口、review 合同、条件化 spec 路径
+- 尚无明显长任务恢复痛点
+- 当前没有需要立即进入更重路径的共享边界或高风险核心抽象信号
+- 当前主产物本身不是共享 contract、shared skill 或 governance module
+
+默认装配路径：
+
+- 直接采用 [../shared/adoption/lightweight-retrofit-default.md](../shared/adoption/lightweight-retrofit-default.md)
+- 默认 `companion docs` 接入
+- 默认装配最小治理包
+- 默认不装配完整 recovery、work item、状态面与重 harness
+- 若需要轻量跨轮承接，默认 `checkpoint-lite`
+
+### 4.3 `复杂既有仓库`
+
+满足以下任一条件时，判为 `复杂既有仓库`：
+
+- 属于既有仓库，但不满足 `小型既有仓库` 的轻量条件
+- 无可见 CI / workflow 且无统一验证入口
+- 已出现明显长任务恢复痛点
+- 已出现共享契约、共享数据模型、运行模型或高风险核心抽象变化
+- 仓库主产物本身是共享 contract、shared skill 或 governance module
+- 已出现现场混杂、PR 混题、脏现场叠加等明显纯度问题
+- merge 前 review 仍在承担第一次高质量语义判断，且已成为结构性瓶颈
+
+默认装配路径：
+
+- 进入更完整装配
+- 纳入恢复主入口、执行上下文、work item 或等价执行入口、状态读取、隔离现场与纯度规则
+- 对高风险边界事项纳入正式规约套件与前移 checkpoint
+
+若同时满足以下条件，则 `复杂既有仓库` 默认优先走 `deep-existing-repo`：
+
+- 根级边界文档清晰
+- 已有统一的仓库级验证入口
+- 已出现 `merge_review_semantic_overload`
+
+这条路径的含义是：
+
+- 保留 `repository_mode = complex-existing`
+- 保留 root rules、retained host actions 与 repo-native carriers
+- 先做 `recognize-and-attach`
+- 不在第一轮直接写入 Loom-owned recovery/status carriers
+
+## 5. 冲突处理规则
+
+当信号之间出现冲突时，按以下规则处理：
+
+- 若同时满足“小型既有仓库已有基线”和“恢复痛点 / 共享边界风险明显”，优先判为 `复杂既有仓库`
+- 若缺少统一验证入口，或仓库主产物本身是共享 contract、shared skill 或 governance module，优先判为 `复杂既有仓库`
+- 任何共享契约、运行模型或高风险核心抽象变化，优先提升到更重路径
+- 任何多轮恢复成本明显升高或出现多个入口并行记录，优先从 `checkpoint-lite` 升级到标准恢复形态
+- 只有在缺口主要集中于治理入口、review 合同、条件化 spec 路径，且恢复痛点不明显时，才保持轻量路径
+
+## 6. 场景到默认装配映射
+
+- `新项目`
+  - 最小装配
+  - 重点是建立后续可升级入口
+- `小型既有仓库`
+  - 轻量 retrofit 默认策略
+  - 重点是最小治理闭环与 `companion docs` 接入
+- `复杂既有仓库`
+  - 更完整装配
+  - 重点是恢复、执行支撑、状态读取与高风险事项准入
+  - 若同时满足“根规则清晰 + 统一验证入口 + `merge_review_semantic_overload`”，默认优先走 `deep-existing-repo`
+
+## 7. `lightweight retrofit default` 的消费关系
+
+`loom-init` 对小型既有仓库的默认入口不是临场经验，而是直接消费 [../shared/adoption/lightweight-retrofit-default.md](../shared/adoption/lightweight-retrofit-default.md)。
+
+这意味着：
+
+- `companion docs` 接入是默认动作，不是可有可无的建议
+- 默认装配项、默认不装配项、`checkpoint-lite` 都必须进入入口层判断逻辑
+- 若判断结果偏离该默认策略，必须显式写出偏离原因与升级信号

package/payload/skills/loom-review/references/loom-init/output-contract.md

@@ -0,0 +1,208 @@
+# Output Contract
+
+使用本文件约束 `loom-init` 的输出。
+
+输出目标不是给出泛建议，而是形成可继续执行的初始化产物模型。
+
+## 必须输出的区块
+
+### 1. 项目判断
+
+必须说明：
+
+- 初始化场景：
+  - `新项目`
+  - `小型既有仓库`
+  - `复杂既有仓库`
+- 装配强度：
+  - `轻量`
+  - `标准`
+  - `强化`
+- 当前最主要的结构性问题是什么
+- 为什么推荐这条路径，而不是另外两条路径
+
+### 2. 推荐装配
+
+至少列出：
+
+- 本轮启用的能力清单
+- 每项能力分别映射到哪些 `governance`、`harness`、`templates`、`adoption` 规则
+- 这次采用的是最小装配、轻量 retrofit 还是更完整装配
+- 若命中成熟治理重仓 attach path，必须显式写出 `recommended_adoption.path = deep-existing-repo`
+- 接入方式是根级重写还是 `repo companion`（历史表述：`companion docs`）
+- 恢复形态是 `checkpoint-lite` 还是标准恢复形态
+
+### 3. 暂不引入
+
+必须显式写出：
+
+- 当前不引入哪些 Loom 能力
+- 不引入的原因是什么
+- 这些能力未来的升级触发条件是什么
+
+### 4. 首批工件
+
+至少说明：
+
+- 初始能力清单的承载位置
+- 首批 work item 或等价事项清单的承载位置
+- 恢复主入口是什么
+- progress / checkpoint 载体是什么
+- 验证入口是什么
+- 状态读取入口是什么
+- `Runtime Evidence` 区块的落位方式是什么，且至少覆盖：
+  - `Run Entry`
+  - `Logs Entry`
+  - `Diagnostics Entry`
+  - `Verification Entry`
+  - `Lane Entry`
+- 初始 clean state 的定义是什么
+- 首个稳定提交或等价回退边界是什么
+- 事实链 carrier 如何定位
+- 统一事实链读取入口是什么
+- `governance_surface` 是什么，并至少稳定给出：
+  - `repository_mode`
+  - `loom_state`
+  - `carrier_summary`
+    - `work_item`
+    - `recovery`
+    - `review`
+    - `status_surface`
+    - `spec_path`
+    - `plan_path`
+  - `execution_entry`
+  - `validation_entry`
+  - `review_merge_surface`
+    - `pr_template`
+    - `validation_surface`
+    - `merge_surface`
+  - `github_control_plane`
+    - `repository`
+    - `default_branch`
+    - `branch_protection`
+    - `required_checks`
+    - `pr_reviews`
+  - `repo_interface`
+    - `availability`
+    - `manifest`
+    - `companion_entry`
+    - `repo_specific_requirements`
+    - `specialized_gates`
+    - `summary`
+    - `missing_inputs`
+  - `summary`
+  - `missing_inputs`
+
+若本轮不装配标准恢复或状态面，也必须写清现有载体如何承接这些职责。
+
+若本轮走 `deep-existing-repo`，还必须显式写出：
+
+- attach-only 必备工件是什么
+- 哪些 repo-native carriers 继续保留
+- 哪些 Loom-owned carriers 本轮不会生成
+
+`init-result` 只允许承接 locator-only 信息，不并行复制实时停点、下一步、阻断项或最近验证摘要。
+
+`Runtime Evidence` 的五个字段必须逐项给出 locator 或 `not_applicable`，不得留空；若使用 `not_applicable`，必须给出可复核原因。
+
+### 4.1 `runtime_state`
+
+初始化输出还必须显式给出当前 Loom 入口自己的 `runtime_state`，至少包含：
+
+- `scene`
+  - `repo-local-demo | installed-runtime | upgrade-rehearsal`
+- `carrier`
+  - `repo-local-wrapper | installed-skills-root | bootstrapped-target-runtime`
+- `failure_reason`
+  - 当前无法继续运行时的稳定阻断原因数组
+- `evidence`
+  - 判定依据来自 `install-layout.json`、`upgrade-contract.json`、bootstrap manifest 或当前入口解析结果
+
+这里的 `runtime_state` 只回答 Loom 入口自身处于什么安装/运行场景，不是 `governance_surface.loom_state` 的别名。
+`governance_surface.loom_state` 回答的是仓库 Loom 装配程度；`runtime_state` 回答的是当前入口能否被视为 installed runtime 并继续运行。
+
+### 5. 首批事项
+
+至少拆出：
+
+- 每个事项的：
+  - 事项标识
+  - 目标
+  - 范围
+  - 执行路径
+  - 关联工件
+  - 关闭条件
+- 恢复主入口与工作现场入口
+- 若事项已进入轻量跨轮承接，必须说明谁负责回写停点、下一步、阻断项与最近验证摘要
+
+## `governance_surface` 的公共约束
+
+`governance_surface` 是 `loom-init`、`loom-adopt` 与 `loom-resume` 共享的稳定公共读面。
+
+它只回答“当前仓库属于哪种执行模式、Loom 装配到什么程度、治理载体和宿主控制面分别位于哪里”，不复制实时 authored 状态。
+
+固定要求：
+
+- 字段命名保持 `governance_surface`
+- 字段命名保持：
+  - `repository_mode`
+  - `loom_state`
+  - `carrier_summary`
+  - `execution_entry`
+  - `validation_entry`
+  - `review_merge_surface`
+  - `github_control_plane`
+  - `repo_interface`
+  - `summary`
+  - `missing_inputs`
+- `carrier_summary` 的 6 个子项固定为：
+  - `work_item`
+  - `recovery`
+  - `review`
+  - `status_surface`
+  - `spec_path`
+  - `plan_path`
+- `carrier_summary` 每个子项固定为 `{status, locator, source}`，`status` 只允许 `present | missing | planned`
+- `github_control_plane` 缺失时允许用 `unknown`，但不得猜测
+- `repo_interface` 只允许承接 `repo companion` 的 locator 和机读 requirements / gates 摘要，不得复制 authored state
+- `repo_interface.availability` 只允许：
+  - `absent`
+  - `companion_docs_only`
+  - `incomplete`
+  - `present`
+- `repo_interface.manifest`、`repo_interface.companion_entry`、`repo_interface.repo_specific_requirements`、`repo_interface.specialized_gates` 固定为 `{status, locator, source}`
+
+禁止事项：
+
+- 把 `governance_surface` 写成第二套事项进度真相
+- 改名或拆出并行的治理读面字段
+- 在 `governance_surface` 中并行复制实时停点、下一步、阻断项或验证摘要
+- 用 `governance_surface` 覆盖 `work item`、恢复入口、PR 或规则文档的 authored 事实
+- 把 `repo_interface` 变成第二套 review / recovery / closeout authored state
+
+### 6. 验证与收口
+
+至少说明：
+
+- 如何验证初始化输出已经可直接承接执行
+- 三个 checkpoint 的承接关系是什么（固定命名为 `admission -> build -> merge`，不再使用 `commit checkpoint` 命名）
+- 什么状态算“说明已清楚”
+- 什么状态算“已进入主干并收口”
+- 何时 issue 可以关闭
+
+## 初始化产物模型的最低要求
+
+无论场景轻重，初始化输出都必须让后续执行者能直接回答以下问题：
+
+- 当前属于哪条初始化路径
+- 当前启用了哪些能力，暂不启用哪些能力
+- 首批执行从哪里进入
+- 恢复主入口在哪里
+- 验证入口在哪里
+- 当前 clean state 如何识别
+- 首个稳定提交或等价回退边界如何识别
+- 相关信息分别落在哪个载体上
+
+若这些问题仍需要靠临场解释补齐，说明输出合同未达标。
+
+对 `deep-existing-repo` 而言，这组问题的答案允许由 attach metadata、repo companion 入口与 repo-native carriers 共同承接；它不要求第一轮就生成 Loom-owned `work-item` / `progress` / `status-surface`。

package/payload/skills/loom-review/references/output-contract.md

@@ -0,0 +1,57 @@
+# Loom Review Output Contract
+
+输出固定为正式 review 摘要 JSON，至少需要给出：
+
+- `item`
+  - 当前事项编号、目标、范围、执行路径
+- `result`
+  - `pass`、`block` 或 `fallback`
+- `summary`
+  - 当前是否已具备正式 review 条件的单句结论
+- `missing_inputs`
+  - 当前阻断正式 review 的缺口；无阻断时为空数组
+- `fallback_to`
+  - 若当前不能继续正式 review，应回退到哪个 checkpoint；无回退时为 `null`
+- `runtime_state`
+  - 当前 Loom 入口自己的 scene / carrier 判定，以及 fail-closed 原因
+- `steps`
+  - 固定按 `runtime-state -> fact-chain -> state-check -> runtime-evidence -> checkpoint-build -> review-entry` 顺序列出
+- `state_check`
+  - 活跃状态、checkpoint 完整性与范围信号
+- `runtime_evidence`
+  - 当前 review 可读的运行时证据入口
+- `build_checkpoint`
+  - build checkpoint 的结果、摘要、缺失输入与回退语义
+- `review`
+  - 唯一 `review_entry` review record 的定位、已记录结论，以及权威 findings / disposition 摘要
+- `engine`
+  - 默认 reviewer adapter、evidence 路径、运行结果与 fail-closed 原因
+- `manual_review`
+  - engine block 时如何继续写回同一 `review record`
+- `current_checkpoint`
+  - 当前 recovery checkpoint 的原始值与归一化值
+
+`review` 段至少应让执行者读出：
+
+- 读取的是哪一个 `review_entry`
+- review record 中的 `decision`
+- review record 中的权威 `findings`
+- 每条 finding 的 `id`、`severity`、`rebuttal` 与 `disposition`
+- `blocking_issues` / `follow_ups` 只是兼容字段，而不是第二份审查工件
+
+`engine` 段至少应让执行者读出：
+
+- 当前默认 engine 是什么
+- 当前 adapter 标识是什么
+- 当前结果是 `pass`、`block` 还是 `not_run`
+- 若 fail-closed，稳定 failure reason 是什么
+- raw result、normalized findings、prompt 与元数据 evidence 在哪里
+
+`manual_review` 段至少应让执行者读出：
+
+- engine block 时仍应写回哪一个 `review record`
+- 推荐沿用哪个 `kind`
+- 若已有 normalized findings，应从哪个 `findings_file` 继续
+- 最小 `review record` 写回命令骨架是什么
+
+这个 skill 负责正式 review 执行层，不替代 `loom-pre-review` 的机械预检，也不替代 `loom-merge-ready` 的 merge 前聚合放行判断。

package/payload/skills/loom-review/references/route-matrix.md

@@ -0,0 +1,63 @@
+# Skills Route Matrix
+
+本文定义 `loom-init` 作为 root entry 时的显式 / 隐式路由矩阵。
+
+## 1. 优先级
+
+1. 显式 skill 名称调用优先
+2. 若无显式 skill，则按任务信号做隐式路由
+3. 若无法稳定判断，回退到 `loom-init`，输出最小补充信号
+
+## 2. 场景矩阵
+
+| 场景 | 任务信号 | 目标 skill | 依赖 CLI |
+| --- | --- | --- | --- |
+| 初始化 / retrofit | 初始化、新项目接入、既有仓库 retrofit、引入 Loom | `loom-adopt` | `loom-init/scripts/loom-init.py bootstrap\|verify\|fact-chain` |
+| 恢复执行 | 接手当前事项、恢复上下文、问下一步、继续推进 | `loom-resume` | `loom-resume/scripts/loom-resume.py flow resume` |
+| review 前统一检查 | review 前检查、进入 review、确认是否可 review | `loom-pre-review` | `loom-pre-review/scripts/loom-pre-review.py flow pre-review` |
+| 正式 review | 正式 review、语义审查、输出 review 结论、code review、spec review | `loom-review` | `loom-review/scripts/loom-review.py flow review` + `shared/scripts/loom_flow.py review run` + `loom-review/scripts/loom-review.py review record` |
+| 交接 | 交接、回写停点、移交当前事项 | `loom-handoff` | `loom-handoff/scripts/loom-handoff.py flow handoff` |
+| 清理 / retire | 清理现场、退休现场、结束当前事项现场 | `loom-retire` | `loom-retire/scripts/loom-retire.py workspace cleanup\|retire` |
+| merge 前放行 | merge-ready、最终放行前预检、确认是否可合并 | `loom-merge-ready` | `loom-merge-ready/scripts/loom-merge-ready.py flow merge-ready` |
+
+## 3. `governance_surface` 公共合同
+
+以下三类入口对外暴露的公共治理读面固定命名为 `governance_surface`：
+
+- `loom-init`
+  - 输出初始化后的治理承接面，说明 Issue、PR、规则、规格、执行工件分别由谁承接
+- `loom-adopt`
+  - 不另造新合同，直接复用 `loom-init` 的 `governance_surface`
+- `loom-resume`
+  - 输出当前事项的治理承接面摘要，但不回写或复制 authored 真相
+
+稳定约束：
+
+- 只读，不新增第二套治理状态源
+- 字段名保持：
+  - `repository_mode`
+  - `loom_state`
+  - `carrier_summary`
+  - `execution_entry`
+  - `validation_entry`
+  - `review_merge_surface`
+  - `github_control_plane`
+  - `summary`
+  - `missing_inputs`
+- `carrier_summary` 子项固定为 `work_item`、`recovery`、`review`、`status_surface`、`spec_path`、`plan_path`
+- 只回答 locator 与职责边界，不复制实时停点、下一步、阻断项、验证摘要
+
+## 4. fallback 语义
+
+出现以下任一情况时，root skill 不做猜测，直接回退到 `loom-init`：
+
+- 没有明确 skill 名称，也没有稳定任务信号
+- 同时命中多个场景，且无法根据任务语义收敛为单一路由
+- 目标仓库或事项标识缺失，无法稳定执行下游入口
+
+回退输出必须至少包含：
+
+- `selected_skill: "loom-init"`
+- `result: "fallback"`
+- `missing_inputs`
+- `fallback_to: "loom-init"`

package/payload/skills/loom-review/references/shared/adoption/deep-existing-repo-default.md

@@ -0,0 +1,64 @@
+# Deep Existing Repo Default
+
+本文件定义 Loom 面向成熟既有治理重仓的默认接入策略。
+
+它不替代 `lightweight-retrofit-default`，而是作为 `complex-existing` 下的保守 attach path，服务已经拥有稳定根规则、统一验证入口与沉重 repo-specific gates 的仓库。
+
+## 1. 适用场景
+
+当目标仓库同时满足以下条件时，默认采用本策略：
+
+- 属于既有仓库，且 `loom-init` 判断仍为 `复杂既有仓库`
+- 已有清晰的根级边界文档
+- 已有统一的仓库级验证入口
+- 已出现 `merge_review_semantic_overload`
+- 当前复杂度主要来自 review / guardian 负载、repo-specific gates、retained host actions 或 repo-native carriers，而不是 Loom 缺少 recovery/status carriers
+
+## 2. 默认目标
+
+第一轮接入的目标不是把成熟治理栈重写成 Loom 自己的 recovery / status 体系，而是让 Loom 先稳定挂到既有入口与读面上。
+
+默认先解决：
+
+- 让 `loom-init` 对这类仓库不再误走 `full-bootstrap`
+- 让 Loom 有稳定的 `recognize-and-attach` 入口
+- 让 repo companion 成为 Loom 读取 repo-specific rules 的正式入口
+- 让 root rules、retained host actions 与 repo-native carriers 明确保留在原 ownership
+
+## 3. 默认装配
+
+本策略默认优先装配：
+
+- `.loom/bootstrap/*` attach metadata
+- `.loom/README.md`
+- `.loom/companion/README.md`
+- companion-owned 的最小 repo-specific read surfaces
+- repo-local `.loom/bin/*` 读取与验证入口
+
+## 4. 默认接入方式
+
+本策略固定采用 `recognize-and-attach`：
+
+- 保留原有 root rules
+- 保留 retained host actions 的宿主 ownership
+- 保留 repo-native carriers
+- 只追加 Loom-owned attach metadata 与 companion 入口
+
+## 5. 默认不装配
+
+第一轮默认不装配：
+
+- `.loom/work-items/*`
+- `.loom/progress/*`
+- `.loom/status/current.md`
+- Loom-owned recovery/status carriers 的 bootstrap placeholder
+- 对 branch / PR / worktree / merge / ruleset 的底层宿主重写
+
+## 6. 升级信号
+
+以下任一条件出现时，不应继续停留在 attach-only 默认路径：
+
+- 当前仓库需要 Loom-owned recovery carrier 承接多轮执行停点
+- repo-native carriers 无法稳定承接 recovery / review / closeout 真相
+- companion 之外还需要 Loom-owned status surface 承接统一读面
+- repo-local attach 入口已经稳定，但下一轮需要 typed machine contract、interop 或 shadow parity