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

package/payload/skills/loom-pre-review/references/shared/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-pre-review/references/shared/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-pre-review/references/shared/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 装配态与治理载体/宿主控制面的落位
+
+这三者不得互相伪装成别名。

package/payload/skills/loom-pre-review/references/shared/harness/status-surface.md

@@ -0,0 +1,121 @@
+# Status Surface
+
+本文件定义 Loom 当前最小状态面合同。
+
+本文件当前承接：
+
+- `EXT-0035`
+
+## 1. 能力定位
+
+状态面用于快速读取当前执行状态和运行事实。
+
+它服务读取，不服务并行记账。
+本文件把“状态读取字段”和“运行时证据入口”明确拆开定义。
+字段归属与派生关系以 [fact-chain-contract.md](fact-chain-contract.md) 为准。
+
+## 2. 状态读取字段
+
+Loom 当前至少要求状态面能展示：
+
+- 当前事项
+- 当前执行路径
+- 当前 checkpoint 阶段
+- 当前工作现场
+- 当前恢复主入口
+- 当前 review 入口
+- 当前环境 lane
+- 当前阻断项
+- 下一步
+- 最近验证摘要
+
+这些字段必须从已有主真相派生，不允许手工维护第二套 authored 值：
+
+- `当前事项`、`当前执行路径`
+  - 从 `work item` 派生
+- `当前 checkpoint 阶段`、`当前阻断项`、`下一步`、`最近验证摘要`、`当前环境 lane`
+  - 从恢复主入口派生
+- `当前工作现场`、`当前恢复主入口`、`当前 review 入口`、`验证入口`
+  - 从 `work item` 与 `init-result` 的 carrier 定位派生
+
+## 3. `Runtime Evidence` 固定区块
+
+状态面若承接运行时证据，必须提供固定标题区块 `Runtime Evidence`。
+
+该区块固定为以下 5 个字段，字段不得缺失：
+
+- `Run Entry`
+- `Logs Entry`
+- `Diagnostics Entry`
+- `Verification Entry`
+- `Lane Entry`
+
+每个字段的值只能是：
+
+- locator 字符串
+- `not_applicable`
+
+## 3.1 字段合同矩阵
+
+| 字段 | 最小语义 | 允许值 | `not_applicable` 允许条件 |
+| --- | --- | --- | --- |
+| `Run Entry` | 告诉执行者去哪启动当前事项运行面 | locator / `not_applicable` | 事项不涉及可运行系统 |
+| `Logs Entry` | 告诉执行者去哪看运行输出或日志 | locator / `not_applicable` | 无运行进程或无日志载体 |
+| `Diagnostics Entry` | 指向指标、trace 或等价诊断入口 | locator / `not_applicable` | 当前事项没有诊断面 |
+| `Verification Entry` | 指向 UI/API/E2E 等可验证入口 | locator / `not_applicable` | 事项不涉及可验证运行结果 |
+| `Lane Entry` | 指向当前 lane 的运行/诊断读取入口 | locator / `not_applicable` | 事项没有 lane 区分 |
+
+判定规则：
+
+- 字段缺失始终是错误，不等同于 `not_applicable`。
+- `not_applicable` 必须按字段判断，不能整组一刀切。
+- 若某字段标记 `not_applicable`，应与 `current_lane`、`execution_path`、`latest_validation_summary` 等事实不冲突。
+
+## 4. 运行时证据入口语义
+
+最小证据类别对应如下：
+
+- `Run Entry`
+  - 当前工作现场对应的运行入口
+- `Logs Entry`
+  - 日志或等价运行输出入口
+- `Diagnostics Entry`
+  - 指标、trace 或其他等价诊断入口至少一种
+- `Verification Entry`
+  - UI、接口或端到端结果中的至少一种 agent 可验证入口
+- `Lane Entry`
+  - 当前环境 lane 对应的诊断或读取入口
+
+Loom 固化的是“可读取、可验证”的能力目标，不固化具体可观测工具栈。
+
+## 5. `not_applicable` 语义
+
+若事项不涉及可运行系统，状态面应明确标出运行时证据为 `not_applicable`，而不是伪造运行入口。
+
+典型场景包括：
+
+- 纯文档事项
+- 纯治理规则调整
+- 仅结构整理、尚无运行载体的事项
+
+`not_applicable` 可以按字段逐项声明。
+
+例如：
+
+- `Verification Entry` 可读
+- `Run Entry`、`Logs Entry`、`Diagnostics Entry`、`Lane Entry` 为 `not_applicable`
+
+`not_applicable` 只说明该字段当前不适用，不说明验证已自动通过。
+
+## 6. 边界约束
+
+- 禁止手工维护第二套平行真相
+- 状态面负责读取，不重复承接正式规则定义
+- 状态面若展示的 `next_step`、`blockers`、`latest_validation_summary` 与恢复主入口不一致，应视为事实链断裂
+- `Runtime Evidence` 的 5 个字段必须全部出现；不允许用“缺字段”表达不适用
+- 运行时证据入口不等于完整 observability 平台设计；本文件只要求最小可读入口
+
+当前仓库中的统一读取入口包括：
+
+- `python3 loom-init/scripts/loom-init.py fact-chain --target <repo>`
+- `python3 shared/scripts/loom_flow.py runtime-evidence --target <repo> [--item <id>]`

package/payload/skills/loom-pre-review/references/shared/harness/work-item-contract.md

@@ -0,0 +1,104 @@
+# Work Item Contract
+
+本文件定义 Loom 当前最小 work item / `exec-plan` 合同。
+
+本文件当前承接：
+
+- `EXT-0037` 的初始化产物模型
+
+完整执行顺序见 [execution-chain.md](execution-chain.md)。
+
+## 1. 能力定位
+
+work item 是进入正式执行的入口。
+若项目使用 `exec-plan` 或等价工件，它只承接执行与恢复。
+
+本文件同时定义初始化后至少应落位哪些执行产物。
+字段归属见 [fact-chain-contract.md](fact-chain-contract.md)。
+
+## 2. work item 最小合同
+
+进入正式执行的事项，必须有可追踪的 work item，并至少表达：
+
+- 事项标识
+- 目标
+- 范围
+- 当前执行路径
+- 关联工件
+- 工作现场入口
+- 恢复主入口路径
+- review 结论入口
+- 当前验证入口
+- 关闭条件
+
+一个 work item 对应一个清晰目标，不得承载多个无关正式事项。
+
+## 3. 初始化产物模型
+
+当 Loom 初始化一个仓库或一条正式执行链路时，最小产物应包括：
+
+- 可进入执行的首批 work item 或等价事项清单
+- 至少一个 `progress` / `checkpoint` 载体
+- 与事项关联的唯一恢复主入口约定
+- 可定位的执行路径与工作现场入口
+- 后续验证或执行支撑的入口约定
+- 首个稳定提交或等价回退边界，用于界定初始化后的首轮 clean state
+
+Loom 不固化这些产物的具体文件名，但要求它们在初始化完成后已可读取、可回写、可继续执行。
+
+## 4. `exec-plan` 的职责边界
+
+如果项目使用 `exec-plan`，其职责应限制为：
+
+- 记录当前停点
+- 记录下一步
+- 记录已验证事实
+- 记录阻断项
+- 记录与正式工件的关联
+
+禁止事项：
+
+- 用 `exec-plan` 替代正式需求真相
+- 用 `exec-plan` 替代长期状态真相
+- 用 `exec-plan` 吞并多个无关事项
+
+## 5. 与执行链路的关系
+
+work item / `exec-plan` 至少要能被以下环节消费：
+
+- 每轮读取
+- 工作现场定位
+- 每轮回写
+- 验证汇总
+- merge checkpoint 放行
+
+不同执行路径可以有不同最小输入强度：
+
+- 轻量事项
+  - work item 可直接进入实现与 PR
+- 中等事项
+  - work item 应关联简化设计说明
+- 正式规约事项
+  - work item 应关联 `spec.md` 与 `plan.md`
+
+无论路径轻重，都必须能被 [execution-context.md](execution-context.md)、[recovery-model.md](recovery-model.md) 与 [merge-checkpoint.md](merge-checkpoint.md) 消费。
+
+## 6. 事实链约束
+
+- `work item` 只承接静态执行真相，不并行 authored 当前停点、下一步、阻断项或最近验证摘要
+- `work item` 可以 authored `review_entry` 这类 locator，但不得 authored review 结论本身
+- 当前 checkpoint 属于恢复主入口，而不是 `work item`
+- 状态面若展示 `goal`、`scope`、`execution_path` 等字段，必须从 `work item` 派生
+
+## 7. 最小 author/update 入口
+
+静态事项 authoring 由日常 CLI 显式承接：
+
+- `python3 shared/scripts/loom_flow.py work-item create --target <repo> --item <id> ...`
+- `python3 shared/scripts/loom_flow.py work-item update --target <repo> --item <id> ...`
+
+边界固定如下：
+
+- `create` / `update` 只写静态字段与关联工件
+- 是否切换为当前活跃事项，必须显式使用 `--activate`
+- `--activate` 只允许改 locator truth，不得顺手写 recovery 动态字段

package/payload/skills/loom-pre-review/references/shared/harness/workspace-and-purity.md

@@ -0,0 +1,73 @@
+# Workspace And Purity
+
+本文件定义 Loom 当前最小纯度与范围控制规则。
+
+本文件当前承接：
+
+- `EXT-0029`
+
+## 1. 能力定位
+
+纯度与范围控制用于约束正式执行现场、分支和 PR 不发生职责漂移。
+
+它服务的是执行边界，不替代需求分流或方案判断。
+
+## 2. 最小纯度目标
+
+Loom 当前至少要求以下纯度：
+
+- 分支目标纯度
+  - 一个正式分支服务一个主要事项
+- PR 范围纯度
+  - 一个 PR 只承载同一语义目标下的改动
+- 工作现场职责纯度
+  - 当前现场不混入无关事项的执行残留
+
+## 3. 范围控制边界
+
+以下情况视为范围越界信号：
+
+- 为完成当前事项，顺手推进无关目标
+- 在同一分支或 PR 中并入另一事项的正式改动
+- 为规避拆分成本，把多个目标包装成一个执行单元
+
+纯度机制只判断是否越界，不直接判断新增目标本身是否合理。
+新增目标是否成立，应回到 work item 或治理分流处理。
+
+## 4. 默认处理
+
+发现纯度异常时，默认动作应是：
+
+- 停止继续叠加改动
+- 先拆分、清理或重新分流
+- 再进入后续审查或提交流程
+
+## 5. 与自动化前置的关系
+
+纯度和明显范围越界信号应尽量前置暴露。
+但是否需要新建事项、拆分 PR 或调整目标，仍属于执行与治理决策，不由纯度脚本单独裁决。
+
+## 6. `purity-check` 最小输出语义
+
+`python3 loom-retire/scripts/loom-retire.py purity-check --target <repo> [--item <id>]` 的输出至少包含：
+
+- `runtime_state`
+  - 当前 Loom 入口自己的 scene / carrier 判定
+  - install layout / shared runtime / shared references 漂移时必须直接 `block`
+
+- `hard_failures`
+  - 第一版硬失败项，包含事实链断裂、现场冲突、残留未分流、明显多事项共享现场等
+- `report_only`
+  - 第一版只报告不阻断项，当前包含 branch purity 与 PR purity
+- `scope_assessment`
+  - `mode: constrained | unconstrained`
+  - `declared_paths`
+  - `out_of_scope_changes`
+
+当 `scope_assessment.mode` 为 `constrained` 且出现 `out_of_scope_changes` 时，应视为范围越界阻断信号。
+
+`python3 shared/scripts/loom_flow.py state-check --target <repo> [--item <id>]` 会复用同一纯度结果，并额外检查活跃状态与 checkpoint 完整性。
+
+`python3 shared/scripts/loom_flow.py workspace cleanup|retire --target <repo> [--item <id>]` 同样必须先消费 `runtime-state`；若当前 carrier 不再可执行，不得继续清理或退休现场。
+
+branch / PR purity 的宿主生命周期边界见 [host-lifecycle-boundary.md](host-lifecycle-boundary.md)。

package/payload/skills/loom-pre-review/references/shared/harness/workspace-model.md

@@ -0,0 +1,56 @@
+# Workspace Model
+
+本文件定义 Loom 当前最小工作现场模型。
+
+本文件当前承接：
+
+- `EXT-0025`
+- `EXT-0012`
+- `EXT-0037` 的 clean state 部分
+
+## 1. 能力定位
+
+工作现场用于承接正式执行，而不是临时试探。
+
+它负责：
+
+- 为单一正式事项提供隔离现场
+- 为恢复动作提供可定位目标
+- 为该事项消费的 host branch / `git worktree` / PR 绑定提供执行侧锚点
+- 为初始化后的 clean state 提供承载边界
+
+## 2. 最小现场规则
+
+正式执行链路默认使用隔离工作现场，并满足：
+
+- 单现场单事项
+- 同一现场只服务一个主要目标
+- 恢复动作应能回到同一现场
+- 新事项不得默认复用脏现场继续推进
+
+现场标识可以参数化，但必须由稳定输入确定性生成，不能只依赖人工记忆。
+
+## 3. clean state 要求
+
+初始化或现场创建完成后，应处于可继续执行的 clean state。
+
+最小要求：
+
+- 现场与目标事项已明确绑定
+- 进入执行所需的初始工件已经落位
+- 当前现场不存在未分流的无关正式改动
+- 后续恢复不需要重新猜测应进入哪个现场
+
+## 4. 边界约束
+
+Loom 只固化现场隔离、单事项和可恢复定位。
+必要时，Loom 会读取 `active issue` 与 host branch / `git worktree` / PR 的绑定来校验现场是否仍服务同一事项。
+
+Loom 当前不固化：
+
+- 具体目录命名格式
+- 是否必须使用 worktree
+- 具体命令、脚本或平台命名约定
+
+branch、PR 与 git worktree 的宿主边界见 [host-lifecycle-boundary.md](host-lifecycle-boundary.md)。
+`active issue` 绑定消费见 [host-issue-binding.md](host-issue-binding.md)。