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

package/payload/skills/loom-merge-ready/references/shared/templates/pull-request.md

@@ -0,0 +1,44 @@
+# Pull Request
+
+本文件定义 Loom 当前最小 PR 模板规则。
+
+本文件当前承接：
+
+- `EXT-0008`
+- `EXT-0028`
+
+## 1. PR 模板必须服务判断
+
+PR 模板的目标是提供最小必要事实，不是把作者变成填表机器。
+
+## 2. 基础必填块
+
+Loom 的基础 PR 模板至少应包含：
+
+- 本次改动解决什么问题
+- 改动范围是什么
+- 如何验证
+- 有哪些风险或未决项
+- 关联事项是什么
+
+## 3. 条件触发块
+
+PR 模板可以有扩展块，但不应默认强加给所有 PR。
+
+默认要求：
+
+- 只有在当前改动确实涉及对应主题时，才启用额外区块
+- 扩展块应围绕特定风险、迁移、回滚、数据变更等主题展开
+
+## 4. Loom 当前约束
+
+Loom 支持结构化 PR 模板，但必须满足：
+
+- 基础模板保持短小
+- 条件块按需触发
+- 模板内容直接服务 review 与 merge 判断
+
+不允许：
+
+- 用超重模板制造机械性噪音
+- 把长期规则真相写死在 PR 模板里

package/payload/skills/loom-merge-ready/references/shared/templates/review-record.md

@@ -0,0 +1,35 @@
+# Review Record
+
+正式 review record 至少应表达：
+
+- `item_id`
+- `kind`
+- `reviewed_head`
+- `reviewed_validation_summary`
+- `decision`
+- `summary`
+- `reviewer`
+- `fallback_to`
+- `findings`
+- `blocking_issues`
+- `follow_ups`
+- `consumed_inputs`
+
+允许结果：
+
+- `allow`
+- `block`
+- `fallback`
+
+约束：
+
+- `fallback_to` 只在 `decision: fallback` 时使用
+- `reviewed_head` 与 `reviewed_validation_summary` 必须对应本次审查基线
+- merge checkpoint 允许 review 之后只新增 Loom 自身的 `review_entry` / recovery / status carriers 提交；除此之外的 `HEAD` 漂移仍视为 stale
+- `findings` 是权威 findings / rebuttal / disposition 数组；每条至少包含 `id`、`summary`、`severity`、`rebuttal`、`disposition`
+- `severity` 当前稳定值为 `warn`、`block`
+- `rebuttal` 当前稳定值为 `null` 或非空字符串
+- `disposition` 当前稳定值为 `null` 或对象；对象内的 `status` 只允许 `accepted`、`rejected`、`deferred`
+- `blocking_issues` / `follow_ups` 仅作为兼容字段保留，默认从 `findings` 投影，不应被当作独立 authored 真相
+- `consumed_inputs.engine_adapter`、`consumed_inputs.engine_evidence`、`consumed_inputs.normalized_findings` 只记录 evidence 来源，不构成第二 authored truth
+- review record 是 merge checkpoint 的正式输入之一，不得只留在会话或 PR 评论里

package/payload/skills/loom-merge-ready/references/shared/templates/spec-suite.md

@@ -0,0 +1,57 @@
+# Spec Suite
+
+本文件定义 Loom 当前最小正式规约套件。
+
+本文件当前承接：
+
+- `EXT-0015`
+- `EXT-0016`
+- `EXT-0017`
+
+## 1. 正式规约套件的最小边界
+
+Loom 当前把正式规约套件的最小内核定义为：
+
+- `spec.md`
+- `plan.md`
+
+这两个工件分别承担不同职责，不得混写。
+
+## 2. `spec.md` 最小要求
+
+`spec.md` 至少应表达：
+
+- 目标
+- 范围
+- 关键场景，优先使用 `GWT`
+- 异常与边界
+- 验收标准
+
+## 3. `plan.md` 最小要求
+
+`plan.md` 至少应表达：
+
+- 实施目标
+- 阶段拆分
+- 约束
+- 验证方式
+- `TDD` 或测试策略
+- 依赖关系
+- 进入实现前条件
+
+## 4. 套件边界规则
+
+Loom 必须区分：
+
+- 正式契约工件
+- 执行或进度工件
+
+默认要求：
+
+- `spec.md` 与 `plan.md` 属于正式最小套件
+- 进度跟踪类工件是否存在，可以按项目需要扩展
+
+Loom 当前不固化：
+
+- 所有项目都必须有同一组附加工件
+- `TODO.md` 或同类文件是永恒必选项

package/payload/skills/loom-merge-ready/scripts/loom-merge-ready.py

@@ -0,0 +1,16 @@
+#!/usr/bin/env python3
+from __future__ import annotations
+
+import os
+import runpy
+import sys
+from pathlib import Path
+
+SCRIPT_PATH = Path(__file__).resolve()
+PACKAGE_ROOT = SCRIPT_PATH.parents[1]
+RUNTIME_ROOT = PACKAGE_ROOT / ".loom-runtime"
+
+os.environ.setdefault("LOOM_INSTALLED_SKILLS_ROOT", str(RUNTIME_ROOT))
+os.environ.setdefault("LOOM_PACKAGE_SKILL_ID", "loom-merge-ready")
+sys.path.insert(0, str(RUNTIME_ROOT / "shared/scripts"))
+runpy.run_path(RUNTIME_ROOT / "shared/scripts/loom_flow.py", run_name="__main__")

package/payload/skills/loom-pre-review/.loom-runtime/install-layout.json

@@ -0,0 +1,77 @@
+{
+  "required_paths": [
+    "registry.json",
+    "upgrade-contract.json",
+    "install-layout.json",
+    "route-matrix.md",
+    "shared/scripts",
+    "shared/assets",
+    "shared/references",
+    "shared/scripts/runtime_paths.py",
+    "shared/scripts/runtime_state.py",
+    "shared/scripts/loom_init.py",
+    "shared/scripts/fact_chain_support.py",
+    "shared/scripts/governance_surface.py",
+    "shared/scripts/loom_flow.py",
+    "shared/scripts/loom_check.py",
+    "shared/assets/review/loom-review-result-schema.json",
+    "shared/assets/templates/scaffold/spec.md",
+    "shared/assets/templates/scaffold/plan.md",
+    "shared/assets/github/PULL_REQUEST_TEMPLATE.md",
+    "shared/references/governance/principles.md",
+    "shared/references/governance/review-model.md",
+    "shared/references/governance/maturity-and-closing.md",
+    "shared/references/governance/state-machine.md",
+    "shared/references/governance/issue-model.md",
+    "shared/references/governance/host-object-taxonomy.md",
+    "shared/references/governance/truth-and-sync-boundary.md",
+    "shared/references/harness/recovery-model.md",
+    "shared/references/harness/fact-chain-contract.md",
+    "shared/references/harness/status-surface.md",
+    "shared/references/harness/runtime-state.md",
+    "shared/references/harness/work-item-contract.md",
+    "shared/references/harness/workspace-model.md",
+    "shared/references/harness/automation-frontload.md",
+    "shared/references/harness/workspace-and-purity.md",
+    "shared/references/harness/execution-context.md",
+    "shared/references/harness/execution-chain.md",
+    "shared/references/harness/merge-checkpoint.md",
+    "shared/references/harness/closeout-gate.md",
+    "shared/references/harness/host-action-contract.md",
+    "shared/references/harness/host-issue-binding.md",
+    "shared/references/harness/host-lifecycle-boundary.md",
+    "shared/references/harness/reconciliation-audit.md",
+    "shared/references/harness/review-execution.md",
+    "shared/references/templates/spec-suite.md",
+    "shared/references/templates/pull-request.md",
+    "shared/references/templates/review-record.md",
+    "shared/references/adoption/lightweight-retrofit-default.md",
+    "shared/references/adoption/deep-existing-repo-default.md",
+    "shared/references/adoption/routing-and-checkpoints.md",
+    "loom-pre-review",
+    "loom-pre-review/scripts/loom-pre-review.py"
+  ],
+  "root": ".",
+  "runtime_state": {
+    "error_surface": "return stable runtime_state.missing_inputs instead of reporting unknown runtime status",
+    "fail_closed_on": [
+      "shared runtime missing",
+      "shared references missing",
+      "shared assets missing",
+      "install layout missing",
+      "registry contract drift",
+      "upgrade contract drift",
+      "skill executable missing",
+      "scene marker conflicts with carrier"
+    ],
+    "installed_runtime": {
+      "evidence": "required_paths"
+    },
+    "recognized_states": [
+      "installed-runtime",
+      "repo-local-demo",
+      "upgrade-rehearsal"
+    ]
+  },
+  "schema_version": "loom-install-layout/v1"
+}

package/payload/skills/loom-pre-review/.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-pre-review/.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-pre-review/.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-pre-review/.loom-runtime/loom-pre-review/SKILL.md

@@ -0,0 +1,69 @@
+---
+name: loom-pre-review
+description: 负责统一 review 前检查。Use when Codex needs a single pre-review gate before entering semantic review.
+---
+
+# Loom Pre Review
+
+这个 skill 承接 review 前统一检查场景。
+
+它只包裹既有 `flow pre-review`，不生成语义 review 结论，也不新增并行状态源。
+
+## 1. 使用时机
+
+当任务满足以下任一条件时，进入 `loom-pre-review`：
+
+- 明确要求 review 前检查
+- 明确要求进入 review 前先做统一预检
+- 明确要求确认当前事项是否已经可 review
+- 明确要求先看阻断项、运行时证据与 admission checkpoint 是否齐全
+
+如果任务其实是在做初始化、恢复执行、handoff、retire 或 merge-ready，应回到 root route matrix，让 `loom-init` 路由到对应场景：
+
+- [../route-matrix.md](../route-matrix.md)
+
+## 2. 固定入口
+
+统一入口固定为：
+
+- `python3 scripts/loom-pre-review.py flow pre-review --target <repo> [--item <id>]`
+
+## 3. 固定编排
+
+`flow pre-review` 固定只编排以下读取链路：
+
+1. `fact-chain`
+2. `state-check`
+3. `runtime-evidence`
+4. `checkpoint admission`
+5. `workspace locate`
+
+这个 skill 不做以下事情：
+
+- 不替代 reviewer 的语义判断
+- 不直接执行 merge
+- 不回写事实链、恢复入口或状态面
+
+## 4. 输出要求
+
+输出必须是统一的 pre-review 摘要 JSON，至少要让执行者能读出：
+
+- 当前事项是什么
+- 当前是否可进入 review
+- 哪一步阻断了继续进入 review
+- 若阻断，应回退到哪里
+- 当前 steps 的机械结果是什么
+
+## 5. 完成标准
+
+只有当以下条件同时满足时，`loom-pre-review` 才算完成：
+
+- 显式调用 `loom-pre-review` 与 root 隐式路由都能稳定命中
+- `flow pre-review` 的步骤顺序稳定为 `runtime-state -> fact-chain -> state-check -> runtime-evidence -> checkpoint-admission -> workspace-locate`
+- 输出 JSON 能直接支撑“是否进入 review 前语义审查”的判断
+- skill 自身不复制治理真相，也不冒充 reviewer 结论
+
+输入信号与输出合同见：
+
+- [references/input-signals.md](./references/input-signals.md)
+- [references/output-contract.md](./references/output-contract.md)

package/payload/skills/loom-pre-review/.loom-runtime/loom-pre-review/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Loom Pre Review"
+  short_description: "统一 review 前机械检查入口"
+  default_prompt: "执行 Loom 的统一 pre-review flow，并输出阻断、回退或通过判断。"