@haaaiawd/loom 0.10.0 → 1.0.0

package/cli/help/concepts.md

@@ -1,72 +1,93 @@
-## LOOM 核心概念
-
-## 哲学
-
-项目的价值观和工程原则——为什么存在、什么不做、冲突时谁优先。
-由 Philosophy Weaver 从真实思想体系织造，不是模板填空。
-所有角色激活时强制加载哲学作为共同锚点。
-
-相关命令：
-- \`loom philosophy get <anchor>\` — 加载哲学章节
-- \`loom philosophy list\` — 列出哲学文档
-- \`loom intent reverse-ref <anchor>\` — 哪些 Intent 引用了这个哲学锚点
-
-## Intent
-
-一个意图单元——不是"做什么"（任务），是"为什么做"（意图）。
-每个 Intent 携带：
-- narrative_ref — 意图叙事引用（为什么存在）
-- depends_on — 依赖的 Intent（拓扑序）
-- acceptance — 验收契约（Keeper 据此判定）
-- philosophy_anchors — 哲学锚点（引用哪些哲学原则）
-- status — 状态（pending|in_progress|completed|blocked|needs_review）
-- verification_method — 验证方式（L1 静态|L2 运行时|L3 人类反馈，可选）
-
-相关命令：
-- \`loom intent next\` — 下一个可执行 Intent
-- \`loom intent get <id>\` — Intent 详情
-- \`loom intent narrative <id>\` — 意图叙事
-- \`loom intent trace <id>\` — 完整追溯链
-- \`loom intent reverse-dep <id>\` — 谁依赖这个 Intent
-
-## Intent Map
-
-所有 Intent 的依赖图（JSON）。Architect 绘制，定义拓扑序和依赖关系。
-必须是 DAG（有向无环图），不能有循环依赖。
-
-相关命令：
-- \`loom intent validate\` — 校验结构 + 依赖一致性
-- \`loom intent graph\` — Mermaid 依赖图
-- \`loom intent status\` — 进度概览
-
-## Intent Loop
-
-核心循环：Keeper 选 Intent → Forge 实现 → Keeper 验证 → 闭合或修正。
-每个 Intent 独立走一圈。详细流程见 \`loom help loop\`。
-
-## Keeper
-
-独立验证子代理——不继承 Forge 的实现上下文，从磁盘重新加载意图和契约。
-判定四维度：意图忠实度 / 哲学一致性 / 底线合规 / 验收达成。
-判定结果：passed / deviated / blocked / pending_human。
-
-## 底线
-
-不可妥协的约束（BASELINE.md 5 条 + 项目特定底线）。
-角色激活时强制加载，哲学不能覆盖。违反底线必须立即停止。
-
-## 验证记录
-
-Keeper 每次验证写入一条记录（追加模式），包含：
-- verdict（passed/deviated/blocked/pending_human）
-- 四维度判定
-- 证据
-- 偏离说明（如果 deviated）
-
-deviated 连续 3 轮升级 blocked。pending_human 默认 7 天超时升级 blocked。
-
-相关命令：
-- \`loom verify contract <id>\` — 获取验收契约
-- \`loom verify write --json-file <path>\` — 写入验证记录
-- \`loom verify history <id>\` — 验证历史
-- \`loom verify pending\` — 待验证的 Intent
+## LOOM 核心概念
+
+LOOM 用一条完整链路把长期判断、当前意图、专业能力、创造性探索和独立证明连起来：
+
+```text
+Doctrine → Intent → Contract
+→ Expertise Compiler → Quality Arena → Quality Proof
+→ Reflow
+```
+
+最后三步合称 **LOOM Quality Engine**。
+
+## Doctrine
+
+项目长期使用的判断系统：保护什么、冲突时如何取舍、什么算优秀、哪些反模式不能接受。
+Weaver 从项目事实和决策相关证据中织造 Doctrine；它不预写产品需求、架构或实现步骤。
+
+## Intent
+
+一个需要保护的产品结果，而不是任务清单。每个 Intent 包含：
+
+- `narrative_ref`：为什么存在。
+- `revision`：语义版本。
+- `depends_on`：依赖关系。
+- `acceptance`：完成契约，即 Reliability Floor。
+- `continuity_required`：仅对会修改既有用户或系统状态的 Intent 启用；要求守恒证据，但不另存一份契约。
+- `quality_contract`：可选的质量契约，即 Distinctive Ceiling。
+- `capability_needs`：可选的专业能力需求。
+- `creative_scope`：可选的探索边界。
+- `philosophy_anchors`、`status` 与 `verification_method`。
+
+Architect 是 Intent DAG 与两类契约的唯一负责人。
+
+## System Boundary
+
+LOOM 不假装能够清除宿主 Agent 的既有记忆。`loom activate` 生成有序 Context Pack，
+明确当前角色、当前 Intent、硬约束、成功契约与停止条件；系统和用户指令始终优先。
+
+## Expertise Compiler
+
+Forge 针对当前 Intent 临时组装一个 Expertise Pack，回答：
+
+1. 这是什么专业问题。
+2. 优秀作品的判断标准是什么。
+3. 哪些项目事实和约束会改变做法。
+4. 应加载哪些真实能力、资料或工具。
+5. 最可能出现哪些“合格但平庸”的失败。
+6. 如何验证专业质量。
+
+能力名称只表示“可发现”；只有真实加载并转化为任务判断的内容才算进入 Expertise Pack。
+Pack 仅服务当前任务，不成为长期 Doctrine。
+
+## Quality Arena
+
+Forge 的实现环境。结果显然时走直接路径；当目标是“更好、惊艳、出众”时：
+
+```text
+Baseline → Mechanism-different Candidates → Compare → Realize → Observe → Adjust
+```
+
+候选必须依赖不同机制，而不是同一方案换皮。没有候选真实胜过基线时，保留原方案是合法结论。
+
+## Quality Proof
+
+Keeper 在独立上下文中验证：
+
+- `intent_fidelity`
+- `philosophy_consistency`
+- `baseline_compliance`
+- `acceptance_achievement`
+- `preservation_achievement`（仅 `continuity_required` 时）
+- `quality_achievement`（仅有 `quality_contract` 时）
+
+质量提升声明必须有 Quality Proof：修改前基线、可观察主张、候选选择依据、稳定性证据与代价。
+完成可以通过而质量未通过；此时不得宣称“更好”。
+
+## Reflow
+
+发现问题时回到真正拥有该问题的层：
+
+- 长期价值判断 → Weaver
+- 产品目标与 narrative → Visionary
+- 系统边界、Intent、契约 → Architect
+- 专业能力与实现 → Forge
+- 证据不足或判定偏离 → Keeper
+
+相关入口：
+
+- `loom context`
+- `loom intent next|get|trace|validate`
+- `loom activate <role> --intent <id>`
+- `loom verify contract|write|pass|history`
+- `loom doctor`

package/cli/help/doctor.md

@@ -1,121 +1,71 @@
-## 诊断与恢复指南
-
-## 健康检查
-
-\`\`\`bash
-loom doctor
-\`\`\`
-
-检测 7 类问题：
-
-| 问题类型 | 严重度 | 说明 |
-|---|---|---|
-| cycle | fatal | 循环依赖（Intent Map 有环） |
-| orphan_philosophy_ref | high | 哲学锚点指向不存在的文件 |
-| orphan_dependency | high | depends_on 引用不存在的 Intent |
-| completed_no_record | high | completed 但无验证记录 |
-| completed_depends_blocked | high | completed 依赖 blocked 的 Intent |
-| inspiration_source | high/medium | 灵感来源质量不达标（源太少/全是 Wikipedia/缺理由） |
-| part_decomposition | high/medium | 缺少实现部分拆解清单（Weaver 跳过了拆解步骤） |
-| in_progress_no_record | medium | in_progress 但无验证记录（可能中断） |
-| zombie | medium | in_progress/blocked 超过 7 天无活动 |
-
-## 灵感来源校验
-
-\`\`\`bash
-loom philosophy check
-\`\`\`
-
-单独校验哲学文档的灵感来源质量。防止 Weaver 从训练数据"背"几个名字就交差。
-
-校验规则：
-- 至少 3 个独立源
-- 至少 2 个非 Wikipedia 链接
-- 每个源必须有选取理由（萃取/转译/启发关系）
-- Wikipedia 占比不超过 70%
-
-不达标时，需要重新织造哲学——真正走搜索漏斗，找原著、论文、工程博客等深度源。
-
-## 实现部分拆解校验
-
-\`\`\`bash
-loom philosophy check
-\`\`\`
-
-同时校验哲学文档是否包含"实现部分清单"——Weaver 是否按 PART_DECOMPOSITION.md 拆解了项目的实现部分。
-
-校验规则：
-- 哲学文档中必须有"实现部分清单"章节（或"部分拆解""Part Decomposition"等）
-- 至少识别到 2 个实现部分（小项目建议 3-5 个，大项目 6-10 个）
-
-缺少时，说明 Weaver 跳过了拆解步骤，需要重新织造——按 PART_DECOMPOSITION.md 的方法论识别项目的实现部分。
-
-## 上下文摘要
-
-\`\`\`bash
-loom context
-\`\`\`
-
-一条命令获取：进度 + 下一个 Intent + 待验证 + 不一致项 + 风险。
-Agent 重启后先跑这个，快速知道"我在哪、接下来做什么"。
-
-## 只读阶段诊断
-
-\`\`\`bash
-loom guide --dry-run
-\`\`\`
-
-用于审计、子代理预演、只读探测。它输出和 `loom guide` 同样的阶段判断，但不写 `.loom/heartbeat.json`。
-
-## Preview 新鲜度诊断
-
-\`\`\`bash
-loom preview status
-\`\`\`
-
-检查 `loom-preview.html` 是否比当前 `.loom/v{N}` 源文件更新。人类要求看 preview 时，Agent 先跑这个命令：
-- `fresh=true`：可以 `loom preview`
-- `fresh=false`：不要打开旧投影，先 `loom preview --regen`
-- 必须看旧投影：`loom preview --stale`
-
-## 崩溃恢复
-
-### Forge 崩溃（Intent 留在 in_progress）
-
-1. 跑 \`loom doctor\` 确认哪些 Intent 状态不一致
-2. 跑 \`loom context\` 看整体状态
-3. 用户决定：
-   - 继续：重新激活 Forge，从当前代码接着做
-   - 重置：\`loom intent update <id> --status pending\`，从头来
-
-### Intent Map 文件损坏
-
-1. \`loom intent validate\` 会检测到格式错误
-2. 从 Git 恢复（.loom/ 应纳入版本控制）
-
-### 验证记录丢失
-
-1. \`loom doctor\` 会检测到 completed 无记录
-2. 重新验证该 Intent，或从 Git 恢复
-
-## 追溯工具
-
-\`\`\`bash
-# Intent 完整追溯链（依赖+验证+哲学+叙事）
-loom intent trace <id>
-
-# 反向依赖（谁依赖这个 Intent → 变更影响评估）
-loom intent reverse-dep <id>
-
-# 反向哲学引用（哪些 Intent 引用这个锚点 → 哲学变更影响评估）
-loom intent reverse-ref <anchor>
-\`\`\`
-
-## 版本控制是前提
-
-LOOM 假设项目使用 Git。所有 .loom/ 下的文件都应纳入版本控制：
-- 文件损坏 → 从 Git 恢复
-- 误操作 → 从 Git 回滚
-- 变更追溯 → Git log 就是审计日志
-
-LOOM 不内置备份、审计、回滚——这些是版本控制的职责。
+## 诊断与恢复
+
+```bash
+loom doctor
+loom context
+```
+
+`doctor` 只检查能够机械判断的系统一致性，不假装用规则替代专业判断。
+
+## 主要诊断
+
+| 类型 | 严重度 | 含义 |
+|---|---|---|
+| `cycle` | fatal | Intent DAG 有环 |
+| `orphan_philosophy_ref` | high | Doctrine 引用不存在 |
+| `orphan_dependency` | high | Intent 依赖不存在 |
+| `completed_no_record` | high | completed 没有验证记录 |
+| `completed_verification_not_passed` | high | 最新记录不能闭合当前 revision |
+| `stale_verification` | high | passed 记录早于当前 revision |
+| `quality_dimension_missing` | high | 有质量契约，但缺少通过的质量维度 |
+| `preservation_dimension_missing` | high | 启用了状态守恒门，但缺少通过的守恒维度 |
+| `inspiration_source` | high/medium | Doctrine 证据不可追溯、缺理由或仍是模板 |
+| `verification_method_drift` | high | 声明的验证方式与复现证据不一致 |
+| `in_progress_no_record` | medium | 工作可能中断 |
+| `zombie` | medium | Intent 长时间无活动 |
+
+## Doctrine 证据
+
+```bash
+loom philosophy check
+```
+
+校验只要求：
+
+- 至少有实际使用的证据条目。
+- 每条证据有选择或转译理由。
+- 每条证据有 URL、`file://` 或 `local:` 可追溯位置。
+
+不要求固定数量、不排斥 Wikipedia，也不强制来源多样性。来源是否足以支持主张由 Weaver 与审阅者
+判断；CLI 只阻止空白、装饰性名字和不可追溯引用。
+
+## Quality Proof
+
+有 `quality_contract` 的 Intent 若写入 `passed`：
+
+- `dimensions.quality_achievement` 必须存在并通过。
+- 声明相对提升时，`dimensions.quality_achievement.quality_proof_ref` 指向基线比较与稳定性证据。
+
+快速命令：
+
+```bash
+loom verify pass <id> --summary "<证据>" --quality-proof "<ref>"
+```
+
+若只达到完成契约，写 `deviated` 或完整验证记录，不要伪造质量通过。
+
+## 恢复
+
+- Forge 中断：检查真实产物后继续，或把 Intent 回退到 `pending`。
+- Intent Map 损坏：从 Git 恢复，再运行 `loom intent validate`。
+- 验证记录丢失：重新独立验证，不从旧会话记忆补写。
+- Preview 过期：`loom preview status` 后使用 `loom preview --regen`。
+
+追溯入口：
+
+```bash
+loom intent trace <id>
+loom intent reverse-dep <id>
+loom intent reverse-ref <anchor>
+loom verify history <id>
+```

package/cli/help/loop.md

@@ -1,135 +1,120 @@
-## Intent Loop 详细流程
-
-每个 Intent 独立走一圈。Loop 终止条件：所有 Intent 为 completed 且无 needs_review（不动点达成）。
-
-## Step 1：Keeper 选 Intent
-
-\`\`\`bash
-loom intent next          # 返回下一个可执行 Intent（pending 且依赖都 completed）
-loom context              # 当前状态摘要（进度+下一步+风险）
-\`\`\`
-
-如果没有可执行的 Intent：
-- 全部 completed → 项目阶段完成
-- 有 blocked → 需要人工介入
-- 有 in_progress 但无验证记录 → 可能上次中断，跑 \`loom doctor\` 诊断
-
-## Step 2：更新状态
-
-\`\`\`bash
-loom intent update <id> --status in_progress
-\`\`\`
-
-## Step 3：Forge 实现
-
-\`\`\`bash
-loom activate forge
-\`\`\`
-
-Forge 加载：意图叙事 + 哲学锚点 + 验收契约，在约束下自主实现代码。
-辅助命令（三个命令的分工）：
-- \`loom intent narrative <id>\` — 读意图叙事（"为什么做"）
-- \`loom verify contract <id>\` — 读验收契约（"做成什么样才算数"）
-- \`loom intent trace <id>\` — 完整追溯链（叙事+契约+哲学锚点一次性加载，最常用）
-- \`loom philosophy get <anchor>\` — 读哲学原则（遇到取舍时查）
-
-## Step 4：Keeper 验证
-
-\`\`\`bash
-loom activate keeper
-loom verify contract <id>     # 重新加载验收契约
-\`\`\`
-
-Keeper 独立验证四维度：
-1. 意图忠实度 — 实现是否忠于原始意图叙事
-2. 哲学一致性 — 实现是否符合哲学原则
-3. 底线合规 — 是否违反 BASELINE
-4. 验收达成 — 是否满足验收契约
-
-写入验证记录：
-\`\`\`bash
-loom verify write --json-file verification.json
-\`\`\`
-
-验证记录格式（\`loom verify write\` 的输入）：
-\`\`\`json
-{
-  "intent_id": "INT-001",
-  "verdict": "passed",
-  "timestamp": "2026-06-28T12:00:00.000Z",
-  "summary": "具体证据描述——不是'看起来没问题'",
-  "reproduction_command": "LLM_API_KEY=mock npm test",
-  "dimensions": {
-    "intent_fidelity": {
-      "verdict": "passed",
-      "evidence": "对照意图叙事第 2 段，extract.js 实现了完整编排"
-    },
-    "philosophy_consistency": {
-      "verdict": "passed",
-      "evidence": "AI_PHILOSOPHY 反模式逐条对照：JSON.parse 有 try/catch、fetch 有超时、无硬编码密钥"
-    },
-    "baseline_compliance": {
-      "verdict": "passed",
-      "evidence": "B1-B5 逐条合规"
-    },
-    "acceptance_achievement": {
-      "verdict": "passed",
-      "evidence": "6 条契约全部达成，npm test 6/6 pass"
-    }
-  }
-}
-\`\`\`
-CLI 自动包装成 \`{ intent_id, records: [{ round, ... }] }\` 追加到验证文件。
-\`dimensions\` 每个维度必须是 \`{ verdict, evidence }\` 对象——不允许只写"合规"，必须写具体证据。
-\`reproduction_command\` 是复现验证的命令——别人跑这个命令能复现你的验证结果。L2 必填。
-
-**evidence 写法参考**：
-- 长度：每条 evidence 50-300 字符为宜。太短（"合规"）不达标，太长难读。
-- 哲学一致性维度：按哲学锚点逐条对照反模式（见 keeper.md 的"承诺验证法"）
-- 其他维度：写"对照了什么 + 在代码哪里看到/没看到"
-- \`reproduction_command\` 注意平台差异：
-  - Unix/Mac: \`LLM_API_KEY=mock npm test\`
-  - Windows PowerShell: \`$env:LLM_API_KEY='mock'; npm test\`
-  - Windows cmd: \`set LLM_API_KEY=mock && npm test\`
-- \`node --test\` 在 Windows 上不能用目录路径（\`node --test test/\` 会报错），用 glob：\`node --test test/*.test.js\`
-
-## Step 5：根据判定结果
-
-| verdict | 处理 |
-|---|---|
-| passed | \`loom intent update <id> --status completed\`，回到 Step 1 |
-| deviated | 与 Forge 对话修正，重新实现重新验证。连续 3 轮升级 blocked |
-| blocked | \`loom intent update <id> --status blocked\`，停下报告用户 |
-| pending_human | **手动模式**：等用户补充判定（L3 人类反馈）。7 天超时升级 blocked |
-
-**AUTO 模式下的判定规则**（关键差异）：
-- AUTO 模式开启时（\`loom auto on\`），**不允许 pending_human**
-- Keeper 遇到 L3 verification_method 时，用 L1+L2 能耐自主判定所有维度
-- 要么 passed（有证据），要么 deviated（有偏离说明），不停下等人类
-- **持续运行，除非出意外否则不允许私自停止**
-- "出意外" = blocked（依赖阻塞/契约无法判定/连续 3 轮 deviated 升级）、fatal 错误
-
-## 变更回流
-
-如果 Forge 发现验收契约不合理、或 Architect 的设计需要调整：
-1. Keeper 评估变更范围（微调 vs 结构性变更）
-2. 微调（验收措辞、验证方式）→ Keeper 直接改
-3. 结构性变更（增减 Intent、改依赖）→ 重新激活 Architect
-4. 受影响的已完成 Intent 标记为 needs_review
-
-## 不动点收敛
-
-默认单趟：所有 Intent 按拓扑序验证完毕且全 passed → done。
-
-触发收敛：Pass 1 结束后还有 needs_review 的 Intent → 自动进入 Pass 2。
-- Pass 2: 重验所有 needs_review 的 Intent
-  - deviated → 修 → 重验
-  - 修的时候又影响别的 → 标记 needs_review
-  - passed → completed
-- Pass 2 结束还有 needs_review → Pass 3
-- Pass 3 结束还有 needs_review → blocked，报告"无法收敛"
-
-收敛达成 = 一趟完整 pass 没有产生任何新的 needs_review（不动点）。
-最大 3 趟，超过判定为系统性问题，需 Architect 介入。
-
-详细规则见 .loom/v{N}/ 下的 INTENT_LOOP.md。
+## Intent Loop 与 Quality Engine
+
+每个 Intent 独立运行，直到当前 revision 被证据闭合。
+
+```text
+Select → Compile Expertise → Explore/Direct → Realize
+→ Self-check → Independent Proof → Close/Reflow
+```
+
+## 1. 选择与锁定
+
+```bash
+loom intent next
+loom intent update <id> --status in_progress
+loom activate forge --intent <id>
+```
+
+Context Pack 只注入当前角色和当前 Intent 的相关事实，但不会、也无法清除宿主会话的旧记忆。
+Forge 必须以磁盘事实和当前 Pack 为准，发现冲突时报告。
+
+## 2. Expertise Compiler
+
+Forge 先形成任务级 Expertise Pack：
+
+- 专业问题与任务类型。
+- 卓越判断标准和反模式。
+- 项目事实、硬约束与可变空间。
+- 已实际加载的技能、资料、工具及其用途。
+- Critic 视角与验证方法。
+
+Pack 是临时认知配置，不写成新的长期规范。明显任务可以很短；高质量任务应足以解释为什么
+某个专业手法适合这个项目。
+
+## 3. Quality Arena
+
+完成目标明确且不存在实质质量选择时，走直接路径。
+
+当 `quality_contract` 要求相对提升时：
+
+1. 记录修改前 Baseline。
+2. 产生少量机制不同的候选。
+3. 按完成契约、质量契约、Doctrine 和实际成本比较。
+4. 实现最优候选并观察真实产物。
+5. 不胜过基线就保留原方案或回流契约，不强改。
+
+## 4. Quality Proof
+
+```bash
+loom activate keeper --intent <id>
+loom verify contract <id>
+```
+
+Keeper 独立检查基础四维；有质量契约时增加第五维：
+
+```json
+{
+  "intent_id": "INT-001",
+  "verdict": "passed",
+  "timestamp": "2026-07-28T12:00:00.000Z",
+  "summary": "具体、可定位、可复现的判定摘要",
+  "reproduction_command": "npm test",
+  "dimensions": {
+    "intent_fidelity": {
+      "verdict": "passed",
+      "evidence": "对照 narrative 的用户结果，真实产物保持了目标与非目标"
+    },
+    "philosophy_consistency": {
+      "verdict": "passed",
+      "evidence": "对照引用原则与反模式，关键取舍和例外均有项目依据"
+    },
+    "baseline_compliance": {
+      "verdict": "passed",
+      "evidence": "B1-B5 与项目底线逐项检查，未发现失守"
+    },
+    "acceptance_achievement": {
+      "verdict": "passed",
+      "evidence": "完成契约的可观察行为均已复现"
+    },
+    "quality_achievement": {
+      "verdict": "passed",
+      "evidence": "相对修改前基线，目标信号达到契约阈值且回归保持稳定",
+      "quality_proof_ref": "artifacts/quality-proof.md#INT-001"
+    }
+  }
+}
+```
+
+若 Intent 声明 `continuity_required: true`，Keeper 还必须写入并通过：
+
+```json
+"preservation_achievement": {
+  "verdict": "passed",
+  "evidence": "复现旧状态 → 本轮操作 → 新状态；列出保留的旧值、完成状态或可见行为。"
+}
+```
+
+这不是第二份契约：具体保留规则和操作序列仍写在 `acceptance`。通过快捷命令闭合时，必须显式提供
+`--preservation-evidence "..."`。
+
+存在 `quality_contract` 时强制 `quality_achievement`；只有声明相对提升时才需要
+`quality_proof_ref`。Quality Proof 至少说明基线、主张、候选机制、选择证据、稳定性和代价。
+
+## 5. 判定与回流
+
+| verdict | 动作 |
+|---|---|
+| `passed` | `loom intent done <id>` |
+| `deviated` | 回到真正的问题拥有者，修正后重验 |
+| `blocked` | 标记阻塞并报告缺失条件 |
+| `pending_human` | 只在确需人类感知或授权时使用 |
+
+完成通过但质量未通过时，结果可以保留为可靠完成，但不得声称质量提升；由用户决定继续 Arena、
+降低或修订质量契约，还是接受当前结果。
+
+Intent 语义变化必须递增 revision；任何完成态 Intent 回流也会递增验证 epoch。旧 revision 或旧 epoch 的 passed 记录都不会闭合当前 Intent；修订 Intent 时必须完整分类全部直接和传递下游，已完成下游会一并回流复验。
+
+## 6. Goal 与闭环
+
+把当前 Intent 视为一次 Codex goal 的可闭合单元。goal 只能在“结果、适用时的状态守恒、可复现证据、按需的质量证明”同时成立后完成；
+goal/status 不能替代 Keeper 验证。状态型任务默认保留或合并旧内容，删除和覆盖必须在 acceptance 中显式授权。

package/cli/help/patch.md

@@ -0,0 +1,33 @@
+## Patch 审计工作流
+
+Patch 只处理不改变 Intent 或验收契约的实现修正。`06_CHANGELOG.json` 是唯一权威来源，`06_CHANGELOG.md` 是 CLI 确定性生成的只读投影，不要手工编辑。
+
+```bash
+# 修改并自行运行验证后，准备输入文件
+loom patch record --json-file patch.json
+loom patch list
+loom patch get PATCH-001
+loom patch validate
+```
+
+输入格式：
+
+```json
+{
+  "summary": "修复空输入崩溃",
+  "reason": "解析器遗漏空字符串边界",
+  "affects": ["INT-001"],
+  "files": ["src/parser.js", "test/parser.test.js"],
+  "verification": [
+    { "command": "npm test", "result": "passed" },
+    { "method": "agent-browser screenshot", "result": "passed", "evidence": "浅色和深色背景下均清晰可读" }
+  ]
+}
+```
+
+- `affects` 可省略；提供时每个 ID 必须存在于当前 Intent Map。
+- `files` 必须是安全的项目相对路径。
+- `verification` 每项提供 `command` 或 `method`，可附具体 `evidence`；至少有一个 `passed`。CLI 只记录结果，绝不执行命令。
+- Patch 只能在当前版本全部 Intent 完成后记录；未完成的能力变化必须走 Intent Loop。
+- `id` 和 `timestamp` 由 CLI 分配，输入中不要提供。
+- `loom patch validate` 校验 JSON 全量记录及 Markdown 是否与 JSON 完全一致。