@haaaiawd/loom 1.3.1 → 2.0.0

package/cli/help/capability.md

@@ -1,118 +0,0 @@
-## Capability Graph 指南
-
-Capability Graph 位于 Vision 与 Intent Map 之间：它把项目初衷展开为需要被理解、设计、实现或证明的
-问题面、能力缺口、风险与证据。它不是待办列表，也不替代 Intent Map。
-
-```bash
-loom capability graph
-loom capability frontier
-loom capability get <node-id>
-loom capability coverage
-loom capability compile <intent-id>
-```
-
-## 工作方式
-
-Visionary 给出 outcome、角色、非目标与项目事实。Architect 用项目类型相符的透镜检查用户旅程、
-体验、系统、资产、横切质量和未知；每个透镜必须被展开、覆盖或明确排除。
-
-## Lens Contract：先检查，再命名能力
-
-新建 Graph 必须先写 `lens_contract`。它要求 Architect 对用户旅程、交互与可访问性、视觉与信息表达、内容与沟通、系统与数据、横切质量与风险逐项做出判断：
-
-- 适用：用 `node_refs` 连到具体的 outcome、concern、capability、risk 或 evidence；
-- 不适用：写明基于项目事实的理由；
-- 需要额外维度：可以增补自定义透镜，但不能删掉六项必审方向。
-
-透镜不是能力节点。`CAP-UI`、`CAP-UX`、`CAP-视觉优化` 这类标题没有用户结果，不能代替能力边界。应写成可观察、可取舍的结果，例如“让错误状态与恢复入口保持可理解”或“让长报告中的证据层级能在窄屏扫读”。一个 capability 可以被多个透镜引用，也可以支持多个 outcome；这正是 Graph 不应退化为 Intent 镜像的原因。
-
-## Capability Domains：专业能力从哪里来
-
-`capability_domains` 记录的不是产品功能，而是会改变设计、实现或验证方法的专业领域。UI/UX、3D 建模、光影与材质、网络安全、心理学、生物学等都可以是 domain；是否进入图谱只看一个问题：**若不了解这个领域，当前方案或判断会不会实质不同？**
-
-每个 domain 必须写清专业问题、为什么现在需要，并用 `node_refs` 连接具体 capability；每个 capability 也用 `domain_refs` 回链领域。这样：
-
-- `DOMAIN-INTERACTION-DESIGN` 可以支撑“状态与恢复可理解”；
-- `DOMAIN-3D-LIGHTING` 可以支撑“光影与材质传达空间尺度”；
-- `DOMAIN-WEB-SECURITY` 可以支撑“敏感操作具备可恢复的授权边界”；
-- `DOMAIN-BEHAVIORAL-PSYCHOLOGY` 可以支撑“敏感沟通不以操控性暗示替代用户选择”。
-
-领域不是“我们已经拥有专家”的声明，也不是固定分类表。它只让 Forge 知道：这项具体能力需要什么专业问题、是否应进入外部获取，以及 Keeper 应按什么角度反证。
-
-完整、有共享关系的最小例子见 `templates/CAPABILITY_GRAPH_EXAMPLE.json`。它不是可以照抄的产品方案，而是展示如何让 outcome、concern、capability、risk、evidence 和 capability domain 交叉连接。
-
-## Impact Gate：先判断代价，后写 Intent
-
-在 Graph schema 1.3 中，每个具体 capability 都必须有 `impact_assessment`。它不是形式化打分，而是先把容易被偷懒跳过的问题说清：它影响哪个用户结果？省略或误判的代价是什么？外部知识会不会改变方案或验证？理由是什么？Architect 完成初判后，必须开一个新的 Agent thread / 子代理运行 `loom activate impact-reviewer`，由它将逐项结论写入根级 `impact_review`；同一上下文里的自我复述不算独立审查。
-
-若代价为 `hard_to_reverse`，或外部知识会改变决定，CLI 会要求 `impact: high`；这种节点只允许 `external_required`（或省略该字段、采用默认值）。不能把关键能力标为 medium/low，或写 `adaptive`，来绕过外部获取。并且 `high` 必须至少占具体 capability 的 **30%**（向上取整，至少一个）；分母不包含 outcome、risk、evidence 等节点，避免靠增加陪跑节点稀释比例。
-
-```json
-{
-  "impact": "high",
-  "impact_assessment": {
-    "affected_user_result": "用户能以键盘和文字理解时间带，而非只能依赖颜色与拖拽",
-    "failure_cost": "material",
-    "external_knowledge_changes_decision": true,
-    "rationale": "可访问数据表达会改变交互、备用文本和验收方式；普通图表经验不足以替代。"
-  },
-  "acquisition_mode": "external_required"
-}
-```
-
-高影响节点不能停在 `open`。它必须继续展开、生成 Capability Brief、编译为 Intent，或带理由地
-延后/排除。`loom capability frontier` 显示尚未路由的高影响节点；`loom capability coverage` 检查
-图谱与 Intent 的双向追溯。
-
-高影响 `outcome` 还必须有一条真实的观察链：以 `validated_by` 指向 `evidence` 节点。该 evidence 的
-`verification` 对象必须包含 `method`、`target`、`procedure`、`pass_criteria` 和 `artifact`，并以
-`intent_refs` 回链负责产出该证据的 Intent。`target` 写结果真正要被看见、接收或使用的位置，例如目标
-宿主的渲染面、用户拿到的导出文件、外部系统的接收端或人工验收现场。不要把“HTTP 200”“URL 可访问”或
-“本地生成了文件”当作用户已得到结果。设计阶段可以先声明计划中的本地 `artifact` 路径；只有负责它的
-Intent completed 后，CLI 才要求该证据文件实际存在，避免用空占位文件伪造验证。
-
-不新增媒体、平台或版权专用节点类型：目标宿主与交付链路用 `concern` / `capability` 表达，许可、来源、
-隐私或平台限制用 `risk` 和 `constrains` 关系表达；只有需要项目化判断时才为相关节点创建 Brief，并在其
-“项目约束”和“产出与验证入口”中写清授权边界与实际交付验证。
-
-```json
-{
-  "id": "EVIDENCE-DELIVERY-RENDER",
-  "kind": "evidence",
-  "title": "在目标宿主中实际呈现交付物",
-  "status": "covered",
-  "impact": "high",
-  "route": "intent",
-  "intent_refs": ["INT-004"],
-  "verification": {
-    "method": "manual_visual",
-    "target": "目标桌面客户端的消息渲染面",
-    "procedure": "在干净会话中发送产物并观察实际渲染",
-    "pass_criteria": "用户无需打开外链即可看见完整内容",
-    "artifact": "verifications/INT-004-host-render.png"
-  },
-  "relationships": []
-}
-```
-
-## Capability Brief
-
-只有高影响、需要调研、需要专业方法或将进入当前 Intent 的能力节点才需要 Brief。Brief 位于：
-
-```text
-.loom/vN/07_CAPABILITY_BRIEFS/<node-id>.md
-```
-
-它写当前项目问题、成功判断、约束、能力获取计划、产出/验证入口与非目标。不要复制通用教程，
-也不要用“你是某领域专家”代替项目化能力说明。
-
-## 编译与回流
-
-`loom capability compile <intent-id>` 只读显示会进入当前 Intent 的图谱节点与 Brief。Forge 激活
-Intent 时会获得同一份输入；发现新依赖、风险或能力缺口时必须回流 Architect 更新 Graph，不能静默
-扩展实现。Keeper 以图谱回链检查高影响问题是否真的被兑现。
-
-Capability 节点可选声明 `acquisition_mode: adaptive | external_required | project_only`。
-schema 1.3 的 high capability 只允许 `external_required` 或省略（默认即为 `external_required`）；
-较低影响的 `project_only` 必须附 `acquisition_rationale`。Graph 只保存获取必要性，不保存网站、Skill 名称或
-搜索词；Forge 在本轮 Expertise Pack 中按项目信号派生查询并记录真实来源。

package/cli/help/concepts.md

@@ -1,105 +0,0 @@
-## LOOM 核心概念
-
-LOOM 用一条完整链路把长期判断、当前意图、专业能力、创造性探索和独立证明连起来：
-
-```text
-Doctrine → Intent narrative → Capability Graph → 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 与两类契约的唯一负责人。
-
-## Capability Graph
-
-Capability Graph 位于 Vision 和 Intent Map 之间。它将项目初衷展开成 `outcome`、`concern`、`capability`、`risk`、`evidence` 五类节点，描述哪些问题必须被理解、设计、实现或证明。
-
-它不是执行 DAG，也不替代 Intent Map：Graph 保留未知、研究与分叉；Intent 只保留边界明确、能独立验收的承诺。高影响节点必须有明确路由（继续展开、Brief、Intent、延后或排除），每个 Intent 必须回链至少一个图谱节点。只有需要专业方法、调研或即将进入当前 Intent 的节点才创建短小的项目化 Capability Brief。
-
-在 schema 1.3 中，每个具体 capability 先经过 **Impact Gate**：Architect 说明它影响的用户结果、错判代价、外部知识是否会改变决定与理由；新的 Agent thread / 子代理通过 `loom activate impact-reviewer` 独立复审并写入 `impact_review`。若错判不可逆或外部知识会改变决定，节点必须是 high、必须外部获取；high 至少占 capability 的 30%（向上取整，至少一个），不能用大量普通节点稀释。
-
-## System Boundary
-
-LOOM 不假装能够清除宿主 Agent 的既有记忆。`loom activate` 生成有序 Context Pack，
-明确当前角色、当前 Intent、硬约束、成功契约与停止条件；系统和用户指令始终优先。
-
-## Expertise Compiler
-
-Forge 针对当前 Intent 临时组装一个 Expertise Pack。先由 Capability Graph 编译关联节点和 Capability Brief，再回答：
-
-1. 这是什么专业问题。
-2. 优秀作品的判断标准是什么。
-3. 哪些项目事实和约束会改变做法。
-4. 应加载哪些真实能力、资料或工具。
-5. 最可能出现哪些“合格但平庸”的失败。
-6. 如何验证专业质量。
-
-能力名称只表示“可发现”；只有真实加载并转化为任务判断的内容才算进入 Expertise Pack。
-当 External Acquisition Gate 为 required 时，Forge 只能自行派生 Search Plan，内容必须来自
-实际打开的 Skill、网络、官方文档或研究资料；Pack 写入当前 Intent revision 的
-`10_EXPERTISE_PACKS`，每个 Capability Capsule 都直接回链来源。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
-- 图谱遗漏、未路由高影响节点或新的能力缺口 → Architect 更新 Capability Graph
-- 专业能力与实现 → 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,80 +0,0 @@
-## 诊断与恢复
-
-```bash
-loom doctor
-loom context
-```
-
-`doctor` 只检查能够机械判断的系统一致性，不假装用规则替代专业判断。
-
-## 主要诊断
-
-| 类型 | 严重度 | 含义 |
-|---|---|---|
-| `cycle` | fatal | Intent DAG 有环 |
-| `project_document_missing` | high | Vision、Architecture、Verification 或哲学三件套缺失 |
-| `project_document_template` | high | 必需文档仍是初始化模板，尚未成为项目判断 |
-| `orphan_philosophy_ref` | high | Doctrine 引用不存在 |
-| `orphan_philosophy_anchor` | high | Doctrine 文件存在，但 Intent 指向的章节锚点不存在 |
-| `intent_narrative_invalid` | high | Intent 的 narrative_ref 无法解析到当前 Vision |
-| `intent_contract_invalid` | high | Intent 的 acceptance 或其 Verification 引用无法解析 |
-| `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 | 声明的验证方式与复现证据不一致 |
-| `capability_impact_gate_missing` | high | Capability Graph 未完成独立 Impact Review，或试图绕过 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>" \
-  --verified-by "<keeper-thread-or-human>" \
-  --verification-context independent_thread
-```
-
-若只达到完成契约，写 `deviated` 或完整验证记录，不要伪造质量通过。
-
-## 恢复
-
-- Forge 中断：检查真实产物后继续，或把 Intent 回退到 `pending`。
-- Intent Map 损坏：从 Git 恢复，再运行 `loom intent validate`。
-- 哲学锚点失效：运行 `loom philosophy get <file#anchor>`，修正 Intent 引用到实际存在的章节，而不是只确认 Markdown 文件还在。
-- 验证记录丢失：重新独立验证，不从旧会话记忆补写。
-- 所有 Intent 已完成但 Atlas 缺失或过期：运行 `loom atlas --regen` 生成 `loom-atlas.html`，再运行 `loom atlas validate`。
-
-追溯入口：
-
-```bash
-loom intent trace <id>
-loom intent reverse-dep <id>
-loom intent reverse-ref <anchor>
-loom verify history <id>
-```

package/cli/help/expertise.md

@@ -1,52 +0,0 @@
-# External Acquisition 与 Expertise Pack
-
-LOOM 把“知道任务需要某项能力”和“真正获得了这项能力”分开。Capability Graph 只决定是否
-需要外部获取；Forge 在当前 Intent 中派生查询、实际检索，再把有来源的核心信息编译成
-Capability Capsules。
-
-```bash
-loom capability compile <intent-id>
-loom expertise init <intent-id>
-# 编辑 .loom/vN/10_EXPERTISE_PACKS/<intent-id>.json，并实际执行检索
-loom expertise validate <intent-id>
-loom activate forge --intent <intent-id>
-```
-
-## 什么时候强制
-
-- capability 显式声明 `acquisition_mode: external_required`；
-- 或高影响 capability 没有显式声明模式（默认即为 `external_required`）。
-
-Graph schema 1.3 中，高影响 capability 不允许 `adaptive` 或 `project_only`：它必须实际检索。
-中低影响任务默认为 `adaptive`；仅依赖未公开内部协议、外部知识不会改变做法的机械任务可以用
-`project_only`，但必须写 `acquisition_rationale`。若外部知识仍可能改变方案，应回流 Impact Gate 上调，
-而不是把检索省掉。
-
-## Search Plan
-
-Forge 根据 capability question、Capability Brief、Intent narrative、质量契约、creative
-scope、媒介约束和基线缺口派生查询。每个 `external_required` capability 都是一项主动探索：先写清它需要回答的专业决定，再记录哪一条来源会让设计、实现或验证路径不同。关键词是运行时证据，不写回 Graph。
-
-必须实际使用 Skill registry、网络、官方文档或研究资料。模型自行生成的原则、没有打开的
-搜索摘要和只看标题的结果都不能登记为来源。首个来源如果只是通用建议、无法改变具体决定或与另一来源冲突，继续探索或回流，不得把它凑成 Capsule。每个计划必须写停止条件，避免无边界浏览。
-
-## Capability Capsule
-
-每个 required capability 至少有一个 Capsule，包含：
-
-- 专业问题与适用时机；
-- 规则和工作流；
-- 决策门与失败模式；
-- 可观察验证信号；
-- 至少一个直接外部来源引用。
-
-Pack 只保存项目化综合和定位信息，不复制第三方 Skill 或网页正文，也不会自动变成 Doctrine
-或通用 Skill。Intent revision 改变后，旧 Pack 自动失效。
-
-## Keeper
-
-CLI 能检查 Pack 当前、来源可定位、Capsule 直接引用外部资料，但不能仅凭 JSON 判断来源是否
-真的支持结论。Keeper 必须在独立 task 中重新打开至少一个关键来源，核对规则与判断门，并让
-`loom verify pass` 将当前 Pack 的内容摘要绑定进验证记录；之后 Pack 内容发生变化必须重验。
-
-更多设计边界见 `EXTERNAL_ACQUISITION_DESIGN.md`。

package/cli/help/loop.md

@@ -1,134 +0,0 @@
-## 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 是任务级认知配置，不写成新的长期规范。高影响 capability 默认进入 External Acquisition Gate；若明确选择 `adaptive`，也必须写明为何此处不启用外部获取。Pack
-必须落盘到 `10_EXPERTISE_PACKS/<intent-id>.json`：Search Plan 可由 AI 派生，但 Capsule 内容
-必须来自实际打开的外部来源，并写出判断门、失败模式和验证信号。明显的机械任务可以保持
-`adaptive`；高质量任务必须足以解释为什么某个专业手法适合这个项目。
-
-## 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": "具体、可定位、可复现的判定摘要",
-  "verification_provenance": {
-    "verified_by": "keeper thread 或人类复核标识",
-    "context": "independent_thread"
-  },
-  "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"
-    }
-  }
-}
-```
-
-快捷写入 `passed` 时，也必须声明这一来源：
-
-```bash
-loom verify pass INT-001 --summary "..." \
-  --verified-by "keeper-run-123" \
-  --verification-context independent_thread
-```
-
-若 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

@@ -1,33 +0,0 @@
-## 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 完全一致。

package/cli/help/proposals.md

@@ -1,21 +0,0 @@
-# Capability Graph Change Proposals
-
-New user requirements, research findings, and implementation discoveries are candidates, not silent changes to the official Capability Graph or current Intent.
-
-```bash
-loom capability proposal submit --json-file ./CGP-NEW-REQUIREMENT.json
-loom capability proposal list
-loom capability proposal get CGP-NEW-REQUIREMENT
-loom capability proposal decide CGP-NEW-REQUIREMENT graph_update --rationale "..."
-loom capability proposal close CGP-NEW-REQUIREMENT --resolution-file ./CGP-NEW-REQUIREMENT-resolution.json
-```
-
-Each proposal records an origin, provenance (source, observation time, concrete evidence), candidate kind, title and why-now. Candidate kinds are `outcome`, `constraint`, `capability`, `risk`, and `evidence`.
-
-Only Architect decides whether it is already covered, needs a Graph update, changes an Intent or acceptance contract, belongs in Minor/Major, or is rejected. A decision still blocks the loop until a structured resolution closes it; an arbitrary path or prose string is not evidence.
-
-The resolution is decision-specific and is checked against the current version after the decision baseline: `graph_update` names changed Graph nodes (which must carry the proposal ID); `intent_change` names changed Intents; `acceptance_change` names Intents whose acceptance artifact changed; `covered` names the already-effective Graph coverage plus a rationale; and `minor`, `major`, or `reject` references a newly written `03_DECISIONS/` artifact naming the proposal. A `constraint` decided as `graph_update` must additionally appear in the formal Graph `constraints` array with its affected node IDs.
-
-For `covered_by`, use both `covered_by: "NODE-ID"` and a `{ "type": "covered_by", "target": "NODE-ID" }` relationship. The target must be a different, currently covered node with a direct route; chained or self-referential coverage is rejected.
-
-Forge and Keeper may submit candidates but cannot use them to expand their active scope.