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

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/SKILL.md

@@ -0,0 +1,80 @@
+---
+name: loom-adopt
+description: 负责把仓库接入 Loom 的初始化场景入口。Use when Codex needs to initialize a new repository with Loom or retrofit Loom into an existing repository.
+---
+
+# Loom Adopt
+
+这个 skill 承接初始化与 retrofit 场景。
+
+它只编排已有 root bootstrap 能力，不新增并行事实源，不创建第二套日常执行入口。
+
+## 1. 使用时机
+
+当任务满足以下任一条件时，进入 `loom-adopt`：
+
+- 明确要求初始化新项目
+- 明确要求把既有仓库接入 Loom
+- 明确要求 retrofit Loom 入口、首批工件或初始化事实链
+- 当前任务核心问题是“如何进入 Loom”，而不是“如何恢复、review、handoff、retire 或 merge-ready”
+
+若任务其实是接手当前事项、review 前检查、交接、retire 或 merge-ready，应回到 root route matrix，转向对应场景 skill：
+
+- [../route-matrix.md](../route-matrix.md)
+
+## 2. 读取顺序
+
+按以下顺序读取：
+
+- 目标仓库中的 `AGENTS.md`、`README`、流程文档、模板、验证入口
+- Loom 根级定位文档
+  - `AGENTS.md`
+  - `README.md`
+- 初始化相关稳定规则
+  - [../shared/references/adoption/lightweight-retrofit-default.md](../shared/references/adoption/lightweight-retrofit-default.md)
+  - [../shared/references/adoption/routing-and-checkpoints.md](../shared/references/adoption/routing-and-checkpoints.md)
+  - [../shared/references/harness/fact-chain-contract.md](../shared/references/harness/fact-chain-contract.md)
+  - [../loom-init/references/input-signals.md](../loom-init/references/input-signals.md)
+  - [../loom-init/references/output-contract.md](../loom-init/references/output-contract.md)
+- 本 skill 的场景合同
+  - [references/input-signals.md](./references/input-signals.md)
+  - [references/output-contract.md](./references/output-contract.md)
+
+## 3. 固定编排
+
+本 skill 不新增新 CLI，固定复用：
+
+- `python3 scripts/loom-adopt.py bootstrap --target <repo>`
+- `python3 scripts/loom-adopt.py verify --target <repo>`
+- `python3 scripts/loom-adopt.py fact-chain --target <repo>`
+
+执行顺序固定为：
+
+1. 先判断这是 `新项目`、`小型既有仓库` 还是 `复杂既有仓库`
+2. 再给出本轮启用能力、暂不启用能力与升级触发条件
+3. 若用户要求实际落盘，再执行 `bootstrap --write`
+4. 落盘后必须能用 `verify` 与 `fact-chain` 复读
+
+## 4. 输出要求
+
+输出必须直接遵守初始化输出合同，而不是另写一套 adopt 专属真相：
+
+- [../loom-init/references/output-contract.md](../loom-init/references/output-contract.md)
+
+至少要明确：
+
+- 当前初始化场景判断
+- 本轮启用能力
+- 首批工件与首批事项
+- 事实链入口
+- 验证入口
+- 当前不启用什么，以及为什么
+
+## 5. 完成标准
+
+只有当以下条件同时满足时，才算 `loom-adopt` 完成：
+
+- root route 或显式 skill 调用都能稳定命中 `loom-adopt`
+- `bootstrap` 输出能解释为什么是这条 adoption 路径
+- `verify` 与 `fact-chain` 都能消费落盘结果
+- 结果没有引入新的事实链载体或平行状态源

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Loom Adopt"
+  short_description: "初始化或 retrofit 仓库到 Loom"
+  default_prompt: "判断当前仓库的初始化场景，并复用 loom_init bootstrap/verify/fact-chain 给出首批 Loom 接入结果。"

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/contract.json

@@ -0,0 +1,45 @@
+{
+  "contract_version": "1.4.0",
+  "description": "Route initialization and retrofit work to the existing Loom bootstrap, verify, and fact-chain entry points.",
+  "display_name": "Loom Adopt",
+  "entrypoint": {
+    "adapter_metadata": "agents/openai.yaml",
+    "orchestration_cli": "scripts/loom-adopt.py",
+    "skill_markdown": "SKILL.md"
+  },
+  "id": "loom-adopt",
+  "input_contract": {
+    "reference": "references/input-signals.md",
+    "required_fields": [
+      "task_is_initialization_or_retrofit",
+      "target_repository",
+      "adoption_scope",
+      "write_intent"
+    ]
+  },
+  "installation": {
+    "layout_manifest": "../install-layout.json",
+    "registry": "../registry.json",
+    "upgrade_contract": "../upgrade-contract.json"
+  },
+  "output_contract": {
+    "reference": "references/output-contract.md",
+    "required_sections": [
+      "scenario_judgment",
+      "enabled_capabilities",
+      "deferred_capabilities",
+      "first_artifacts",
+      "first_work_items",
+      "runtime_state",
+      "governance_surface",
+      "fact_chain",
+      "validation_entry"
+    ]
+  },
+  "role": "scenario/adopt",
+  "root_entry": true,
+  "routing": {
+    "explicit_name": "loom-adopt",
+    "reference": "../route-matrix.md"
+  }
+}

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/references/input-signals.md

@@ -0,0 +1,17 @@
+# Loom Adopt Input Signals
+
+当任务满足以下任一信号时，进入 `loom-adopt`：
+
+- 明确要求初始化新项目
+- 明确要求把既有仓库接入 Loom
+- 明确要求 retrofit Loom 入口、首批工件或初始化事实链
+- 明确要求判断某个仓库应该采用哪条 Loom 初始化路径
+
+最小输入：
+
+- 目标仓库
+- 当前接入范围
+- 是否需要实际落盘
+- 当前任务是否仍属于初始化，而不是恢复/交接/review/merge-ready
+
+若缺少最后一项，必须先回到 [../../route-matrix.md](../../route-matrix.md) 重新判断场景。

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/references/output-contract.md

@@ -0,0 +1,17 @@
+# Loom Adopt Output Contract
+
+`loom-adopt` 不定义新的输出真相。
+
+它必须直接复用：
+
+- [../../loom-init/references/output-contract.md](../../loom-init/references/output-contract.md)
+
+对场景入口本身，最少还要让执行者能直接读出：
+
+- 当前初始化场景判断
+- 本轮启用能力
+- 当前暂不启用能力与升级触发条件
+- 首批工件与首批事项
+- 事实链入口
+- 验证入口
+- 是否已经实际落盘

package/payload/skills/loom-adopt/.loom-runtime/loom-adopt/scripts/loom-adopt.py

@@ -0,0 +1,14 @@
+#!/usr/bin/env python3
+from __future__ import annotations
+
+import os
+import runpy
+import sys
+from pathlib import Path
+
+SCRIPT_PATH = Path(__file__).resolve()
+SKILLS_ROOT = SCRIPT_PATH.parents[2]
+
+os.environ.setdefault("LOOM_INSTALLED_SKILLS_ROOT", str(SKILLS_ROOT))
+sys.path.insert(0, str(SKILLS_ROOT / "shared/scripts"))
+runpy.run_path(SKILLS_ROOT / "shared/scripts/loom_init.py", run_name="__main__")

package/payload/skills/loom-adopt/.loom-runtime/loom-init/references/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-adopt/.loom-runtime/loom-init/references/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/references/adoption/lightweight-retrofit-default.md](../../shared/references/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/references/adoption/lightweight-retrofit-default.md](../../shared/references/adoption/lightweight-retrofit-default.md)。
+
+这意味着：
+
+- `companion docs` 接入是默认动作，不是可有可无的建议
+- 默认装配项、默认不装配项、`checkpoint-lite` 都必须进入入口层判断逻辑
+- 若判断结果偏离该默认策略，必须显式写出偏离原因与升级信号

package/payload/skills/loom-adopt/.loom-runtime/loom-init/references/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-adopt/.loom-runtime/registry.json

@@ -0,0 +1,15 @@
+{
+  "entries": [
+    {
+      "contract_version": "1.4.0",
+      "executable": "loom-adopt/scripts/loom-adopt.py",
+      "id": "loom-adopt",
+      "manifest": "loom-adopt/contract.json",
+      "role": "scenario/adopt"
+    }
+  ],
+  "install_layout": "install-layout.json",
+  "registry_version": "1.3.0",
+  "root_entry": "loom-adopt",
+  "upgrade_contract": "upgrade-contract.json"
+}

package/payload/skills/loom-adopt/.loom-runtime/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-adopt/.loom-runtime/shared/assets/github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,22 @@
+## Summary
+
+- Problem:
+- Scope:
+
+## Validation
+
+- [ ] Verified locally
+- [ ] Verified by automation
+- [ ] Not applicable
+
+Validation details:
+
+## Risks And Follow-ups
+
+- Risks:
+- Follow-ups:
+
+## Related Work
+
+- Issue:
+- Spec / plan: