@haaaiawd/loom 1.2.1 → 1.3.1

package/templates/CAPABILITY_GRAPH_EXAMPLE.json

@@ -0,0 +1,188 @@
+{
+  "_meta": {
+    "_description": "示例：一张能力边界图不是按部门分类，也不是 Intent 的镜像。它先完成透镜审视，再用关系表达共享能力、约束、风险与证据。替换为自己的项目事实，不要复制节点标题。",
+    "_version": "1.2",
+    "_loom_version": "v1",
+    "_generated_by": "architect-example"
+  },
+  "lens_contract": {
+    "selection_basis": "这是一个帮助用户审视复杂选择的对话式产品；交互状态、视觉阅读、论断措辞、证据数据和信任风险都会直接影响结果。",
+    "lenses": [
+      {
+        "id": "journey",
+        "title": "用户旅程",
+        "question": "用户从开始到离开，是否能完成有意义的完整路径？",
+        "status": "applicable",
+        "node_refs": ["OUTCOME-REVISABLE-CHOICE", "CAP-STATEFUL-GUIDANCE"]
+      },
+      {
+        "id": "interaction_accessibility",
+        "title": "交互与可访问性",
+        "question": "状态、反馈、失败恢复和不同使用条件是否真实可用？",
+        "status": "applicable",
+        "node_refs": ["CAP-STATEFUL-GUIDANCE", "EVIDENCE-END-TO-END-USE"]
+      },
+      {
+        "id": "visual_editorial",
+        "title": "视觉与信息表达",
+        "question": "视觉语言、层级、版式与资产是否帮助用户理解并形成该产品的气质？",
+        "status": "applicable",
+        "node_refs": ["CAP-EVIDENCE-READABILITY", "EVIDENCE-END-TO-END-USE"]
+      },
+      {
+        "id": "content_communication",
+        "title": "内容与沟通",
+        "question": "文案、信息呈现或对话是否准确、可理解且符合产品立场？",
+        "status": "applicable",
+        "node_refs": ["CAP-CONDITIONAL-INSIGHT", "RISK-OVERCLAIM"]
+      },
+      {
+        "id": "system_data",
+        "title": "系统与数据",
+        "question": "数据、模型、集成、权限与运行边界是否支撑而非伤害用户结果？",
+        "status": "applicable",
+        "node_refs": ["CONCERN-USER-OWNERSHIP", "CAP-STATEFUL-GUIDANCE"]
+      },
+      {
+        "id": "quality_risk",
+        "title": "横切质量与风险",
+        "question": "可靠性、隐私、安全、性能、素材来源与独立验证是否被处理？",
+        "status": "applicable",
+        "node_refs": ["RISK-OVERCLAIM", "EVIDENCE-END-TO-END-USE"]
+      }
+    ]
+  },
+  "capability_domains": [
+    {
+      "id": "DOMAIN-INTERACTION-DESIGN",
+      "title": "Interaction Design / UX",
+      "question": "怎样让状态、错误、恢复与退出在真实交互中可理解且可操作？",
+      "why_now": "入口和恢复并非视觉润色；它决定用户能否保有会话主导权。",
+      "node_refs": ["CAP-STATEFUL-GUIDANCE", "CAP-EVIDENCE-READABILITY"]
+    },
+    {
+      "id": "DOMAIN-EDITORIAL-INFORMATION-DESIGN",
+      "title": "Editorial & Information Design",
+      "question": "怎样让事实、推断和待验证问题在有限屏幕内保持可分辨的阅读层级？",
+      "why_now": "报告若只显得有权威而不能被扫读，会直接放大过度断言风险。",
+      "node_refs": ["CAP-EVIDENCE-READABILITY", "CAP-CONDITIONAL-INSIGHT"]
+    },
+    {
+      "id": "DOMAIN-APPLIED-EPISTEMICS",
+      "title": "Applied Epistemics / Responsible AI Communication",
+      "question": "怎样在给出有用洞察时保留条件、证据来源、反例与用户修正权？",
+      "why_now": "这里的措辞和推断结构会决定产品是在帮助用户判断，还是冒充裁决者。",
+      "node_refs": ["CAP-CONDITIONAL-INSIGHT"]
+    }
+  ],
+  "nodes": {
+    "OUTCOME-REVISABLE-CHOICE": {
+      "id": "OUTCOME-REVISABLE-CHOICE",
+      "kind": "outcome",
+      "title": "用户带着可修订的选择假设离开，而不是被系统替他下结论",
+      "status": "covered",
+      "impact": "high",
+      "route": "intent",
+      "intent_refs": ["INT-002", "INT-003"],
+      "relationships": [
+        { "type": "refines", "target": "CONCERN-USER-OWNERSHIP" },
+        { "type": "requires", "target": "CAP-STATEFUL-GUIDANCE" },
+        { "type": "requires", "target": "CAP-CONDITIONAL-INSIGHT" },
+        { "type": "requires", "target": "CAP-EVIDENCE-READABILITY" },
+        { "type": "risks", "target": "RISK-OVERCLAIM" },
+        { "type": "validated_by", "target": "EVIDENCE-END-TO-END-USE" }
+      ]
+    },
+    "CONCERN-USER-OWNERSHIP": {
+      "id": "CONCERN-USER-OWNERSHIP",
+      "kind": "concern",
+      "title": "用户始终理解系统现在知道什么、能暂停或修正什么",
+      "status": "covered",
+      "impact": "high",
+      "route": "intent",
+      "intent_refs": ["INT-001", "INT-002"],
+      "relationships": [
+        { "type": "constrains", "target": "CAP-STATEFUL-GUIDANCE" },
+        { "type": "constrains", "target": "CAP-CONDITIONAL-INSIGHT" }
+      ]
+    },
+    "CAP-STATEFUL-GUIDANCE": {
+      "id": "CAP-STATEFUL-GUIDANCE",
+      "kind": "capability",
+      "title": "让会话状态、失败恢复与暂停入口保持可理解",
+      "status": "researched",
+      "impact": "high",
+      "route": "brief",
+      "intent_refs": ["INT-001", "INT-002"],
+      "domain_refs": ["DOMAIN-INTERACTION-DESIGN"],
+      "acquisition_mode": "external_required",
+      "brief_ref": "07_CAPABILITY_BRIEFS/CAP-STATEFUL-GUIDANCE.md",
+      "question": "用户是否能看见当前状态、理解下一步，并在中断后安全恢复或退出？",
+      "relationships": [
+        { "type": "requires", "target": "CAP-EVIDENCE-READABILITY" },
+        { "type": "risks", "target": "RISK-OVERCLAIM" }
+      ]
+    },
+    "CAP-CONDITIONAL-INSIGHT": {
+      "id": "CAP-CONDITIONAL-INSIGHT",
+      "kind": "capability",
+      "title": "把洞察表达为带证据、条件与反例的可修订假设",
+      "status": "researched",
+      "impact": "high",
+      "route": "brief",
+      "intent_refs": ["INT-002", "INT-003"],
+      "domain_refs": ["DOMAIN-EDITORIAL-INFORMATION-DESIGN", "DOMAIN-APPLIED-EPISTEMICS"],
+      "acquisition_mode": "external_required",
+      "brief_ref": "07_CAPABILITY_BRIEFS/CAP-CONDITIONAL-INSIGHT.md",
+      "question": "系统能否给出具体洞察而不越权成为命运裁决者？",
+      "relationships": [
+        { "type": "requires", "target": "CAP-EVIDENCE-READABILITY" },
+        { "type": "risks", "target": "RISK-OVERCLAIM" }
+      ]
+    },
+    "CAP-EVIDENCE-READABILITY": {
+      "id": "CAP-EVIDENCE-READABILITY",
+      "kind": "capability",
+      "title": "让证据、推断与待验证问题在报告中可扫读且不被视觉淹没",
+      "status": "researched",
+      "impact": "high",
+      "route": "brief",
+      "intent_refs": ["INT-002", "INT-003"],
+      "domain_refs": ["DOMAIN-INTERACTION-DESIGN", "DOMAIN-EDITORIAL-INFORMATION-DESIGN"],
+      "acquisition_mode": "external_required",
+      "brief_ref": "07_CAPABILITY_BRIEFS/CAP-EVIDENCE-READABILITY.md",
+      "question": "窄屏和长文本中，用户能否分清事实、推断和下一步，而不是只看到漂亮结论？",
+      "relationships": []
+    },
+    "RISK-OVERCLAIM": {
+      "id": "RISK-OVERCLAIM",
+      "kind": "risk",
+      "title": "流畅、权威的表达掩盖了证据不足，诱导用户把假设当成定论",
+      "status": "covered",
+      "impact": "high",
+      "route": "intent",
+      "intent_refs": ["INT-002", "INT-003"],
+      "relationships": [
+        { "type": "validated_by", "target": "EVIDENCE-END-TO-END-USE" }
+      ]
+    },
+    "EVIDENCE-END-TO-END-USE": {
+      "id": "EVIDENCE-END-TO-END-USE",
+      "kind": "evidence",
+      "title": "独立使用者在真实阅读与中断恢复路径中区分证据、推断与可操作的下一步",
+      "status": "covered",
+      "impact": "high",
+      "route": "intent",
+      "intent_refs": ["INT-003"],
+      "verification": {
+        "method": "independent_human_review",
+        "target": "窄屏和桌面端的真实报告与会话恢复界面",
+        "procedure": "让未参与实现者完成一次中断、恢复、阅读报告并追问一个结论来源的任务。",
+        "pass_criteria": "使用者能指出至少一项证据、一项条件化推断与一个修正入口；恢复过程没有丢失已确认状态。",
+        "artifact": "verifications/INT-003-end-to-end-use.md"
+      },
+      "relationships": []
+    }
+  },
+  "constraints": []
+}

package/templates/CAPABILITY_GRAPH_TEMPLATE.json

@@ -1,11 +1,78 @@
 {
   "_meta": {
-    "_description": "Capability Graph 起点：从项目初衷展开问题面、能力缺口、风险与证据，再编译为 Intent。capability 可选 acquisition_mode=adaptive|external_required|project_only；Graph 不保存网站、Skill 或搜索词。",
-    "_version": "1.0",
+    "_description": "Capability Graph 起点：从项目初衷展开问题面、能力缺口、风险与证据，再编译为 Intent。先完成 lens_contract；再从项目事实派生 capability_domains，让具体 capability 回链其专业领域。每个 capability 先写 impact_assessment：影响的用户结果、错判代价、外部知识会不会改变决定与理由；错判不可逆或外部知识会改变决定即为 high，必须 external_required。Graph 不保存网站、Skill 或搜索词。",
+    "_version": "1.3",
     "_loom_version": "v1",
     "_generated_by": "architect",
     "_template": true
   },
+  "lens_contract": {
+    "selection_basis": "[从愿景、用户、媒介与实际交付方式判断；不要按固定部门表格机械分类。]",
+    "lenses": [
+      {
+        "id": "journey",
+        "title": "用户旅程",
+        "question": "用户从开始到离开，是否能完成有意义的完整路径？",
+        "status": "applicable",
+        "node_refs": []
+      },
+      {
+        "id": "interaction_accessibility",
+        "title": "交互与可访问性",
+        "question": "状态、反馈、失败恢复和不同使用条件是否真实可用？",
+        "status": "applicable",
+        "node_refs": []
+      },
+      {
+        "id": "visual_editorial",
+        "title": "视觉与信息表达",
+        "question": "视觉语言、层级、版式与资产是否帮助用户理解并形成该产品的气质？",
+        "status": "applicable",
+        "node_refs": []
+      },
+      {
+        "id": "content_communication",
+        "title": "内容与沟通",
+        "question": "文案、信息呈现或对话是否准确、可理解且符合产品立场？",
+        "status": "applicable",
+        "node_refs": []
+      },
+      {
+        "id": "system_data",
+        "title": "系统与数据",
+        "question": "数据、模型、集成、权限与运行边界是否支撑而非伤害用户结果？",
+        "status": "applicable",
+        "node_refs": []
+      },
+      {
+        "id": "quality_risk",
+        "title": "横切质量与风险",
+        "question": "可靠性、隐私、安全、性能、素材来源与独立验证是否被处理？",
+        "status": "applicable",
+        "node_refs": []
+      }
+    ]
+  },
+  "capability_domains": [
+    {
+      "id": "DOMAIN-EXAMPLE",
+      "title": "[会改变本项目方案或验证方式的专业领域，例如 Interaction Design / UX]",
+      "question": "[这个领域必须回答什么专业问题？]",
+      "why_now": "[为什么它会实质改变当前项目的设计、实现或验证？]",
+      "node_refs": []
+    }
+  ],
+  "impact_review": {
+    "reviewer_mode": "independent_agent_thread",
+    "assessments": [
+      {
+        "capability_id": "[CAPABILITY-ID]",
+        "recommended_impact": "high",
+        "external_acquisition_required": true,
+        "rationale": "[由新的 Agent thread 判断：错判会伤害哪个用户结果？外部知识会如何改变方案或验收？]"
+      }
+    ]
+  },
   "nodes": {},
   "constraints": []
 }

package/cli/help/preview.md

@@ -1,60 +0,0 @@
-## Preview 指南
-
-preview 是给人看的只读投影。它把 `.loom/v{N}` 的哲学、愿景、架构、Intent Map 和验证记录压缩成 `loom-preview.html`。
-
-## 常用命令
-
-```bash
-loom preview status   # 只读检查 preview 是否存在、是否新鲜
-loom preview          # 新鲜则打开；过期则提示重新生成
-loom preview --regen  # 输出生成提示词，让 Agent 重写 loom-preview.html
-loom preview --stale  # 强行打开过期 preview
-loom preview --help   # 查看 preview 命令用法
-```
-
-## Agent 使用规则
-
-当用户说“看看进度”“打开 preview”“让我看全局”时：
-
-1. 先运行 `loom preview status`
-2. 如果 `fresh=true`，运行 `loom preview`
-3. 如果 `fresh=false`，不要打开旧页面，运行 `loom preview --regen`
-4. 按提示词读取 `.loom/`，重写 `loom-preview.html`
-5. 再运行 `loom preview` 打开
-
-只有用户明确说要看旧版时，才使用 `loom preview --stale`。
-
-## 新鲜度判断
-
-LOOM 使用最小 mtime 机制，不做 hash：
-
-```text
-preview_mtime = loom-preview.html 修改时间
-source_latest_mtime = 当前 .loom/v{N} 核心源文件最新修改时间
-
-preview_mtime >= source_latest_mtime → fresh
-否则 → stale
-```
-
-核心源文件包括：
-- `00_PHILOSOPHY/`
-- `01_VISION.md`
-- `02_ARCHITECTURE.md`
-- `03_DECISIONS/`
-- `04_INTENT_MAP.json`
-- `05_VERIFICATION.md`
-- `06_CHANGELOG.json`（Patch 唯一权威来源）
-- `06_CHANGELOG.md`（确定性生成投影）
-- `verifications/`
-
-## 为什么不直接打开旧 preview
-
-旧 preview 是假仪表盘风险：`.loom/` 已经进入 blocked、deviated 或完成新 Intent，但 HTML 仍显示旧状态。
-
-所以普通 `loom preview` 在 stale 时会停止并提示 `loom preview --regen`。
-
-## 生成责任
-
-当前 CLI 不直接生成 HTML。`loom preview --regen` 输出提示词，要求 Agent 读取 `.loom/` 后生成 `loom-preview.html`。
-
-CLI 负责判断是否过期和打开文件，Agent 负责把信息做成高质量视觉投影。

package/cli/src/preview-prompt.md

@@ -1,337 +0,0 @@
-# LOOM Preview 生成提示词
-
-你的任务：读 `.loom/` 目录下当前版本的所有文件，把信息**拆解成关键要点**，用最合适的视觉和交互手段呈现成一份 HTML 页面，写到 `loom-preview.html`。
-
-## 核心原则：信息密度靠视觉手段，不靠文字堆砌
-
-类比 PPT——PPT 不是把报告文字排成幻灯片，是用图表、图示、对比、交互把信息密度压缩到人类一眼能消化的程度。能用图就不表，能交互就不静态，能一句话就不写一段。
-
-### 错误 vs 正确
-
-| 错误（文字堆砌） | 正确（视觉手段） |
-|---|---|
-| 哲学全文渲染成 HTML | 北极星一句话 + 信念用图标网格 + 反模式用红色警告卡 |
-| Intent 列表表格 | SVG 依赖图，节点颜色=状态，一眼看出阻塞链 |
-| 验证记录 JSON 列表 | 时间轴，通过绿色偏离红色，点击节点看证据 |
-| 进度用文字描述 | 环形进度图 + 大数字仪表盘 |
-| 状态分布用表格 | 堆叠条形图，一段横条按状态颜色分段 |
-| 决策原则用列表 | 对比表，两列并排突出差异 |
-| 意图叙事全文展示 | 卡片网格，每张卡片一句话，点击展开详情 |
-
-### 拆解粒度
-
-每个信息块回答一个问题，人类 3 秒内能消化：
-- 产品为什么存在？→ 北极星一句话
-- 产品信什么？→ 3-5 个图标 + 关键句
-- 什么绝对不做？→ 红色警告卡，每张一句
-- 项目推进到哪了？→ 环形进度图 + 数字仪表盘
-- 谁阻塞谁？→ SVG 依赖图
-- 这个 Intent 为什么存在？→ 一句话叙事
-- 验证历史怎么样？→ 时间轴
-
-如果一个块需要读超过 3 行文字才能理解，它太长了——换一种视觉形式。
-
----
-
-## 去读哪些文件
-
-当前版本目录在 `.loom/current` 指针里（通常是 `.loom/v1/`）。读：
-
-| 文件 | 拆解出什么 |
-|---|---|
-| `00_PHILOSOPHY/*.md` | 北极星、核心信念、反模式、决策原则 |
-| `01_VISION.md` | 北极星、问题空间、意图叙事、不做什么 |
-| `02_ARCHITECTURE.md` | 关键决策、trade-offs |
-| `04_INTENT_MAP.json` | 依赖关系、状态、完成/质量契约、专业能力需求 |
-| `verifications/*.json` | 验证时间轴、基础维度、按需的质量维度与 Quality Proof |
-| `06_CHANGELOG.json` | Patch 历史（唯一权威来源）；不要从生成的 Markdown 反推数据 |
-| `06_CHANGELOG.md` | JSON 的确定性只读投影，仅用于交叉检查 |
-
-文件还是模板（含 `<!-- LOOM_TEMPLATE -->` 标记）时，对应区域显示提示："等待 {角色} 填充"。
-
----
-
-## 一、视觉手段库——什么信息用什么呈现
-
-不同信息适合不同视觉手段。不要什么都用卡片或列表——选最能压缩信息密度的方式。
-
-### 图表类（数据可视化）
-
-**环形进度图** — 适合：整体完成度
-一个圆环，填充比例 = completed/total。中心显示百分比。比横条进度条更紧凑、更视觉化。纯 SVG 实现。
-
-**堆叠条形图** — 适合：状态分布
-一段横条，按状态颜色分段（完成绿/进行中黄/待执行灰/阻塞红）。一段条形展示所有状态比例，比 4 个数字卡片更紧凑。
-
-**柱状图** — 适合：各 Intent 的验证轮数、各系统的 Intent 数量
-SVG 矩形，高度=数值。适合比较多个项的数量。
-
-**燃尽图风格折线** — 适合：剩余 Intent 随时间变化（如果有历史数据）
-SVG 折线，横轴时间，纵轴剩余数。
-
-### 图示类（关系和结构）
-
-**SVG 依赖图** — 适合：Intent 之间的依赖关系
-节点是 Intent，边是 depends_on。拓扑排序布局，无依赖的在左，依赖链向右。节点颜色按状态编码。节点可点击，点击后侧边面板显示详情。
-
-**热力图网格** — 适合：Intent × 验证轮次的通过/偏离矩阵
-行是 Intent，列是验证轮次，格子颜色=通过(绿)/偏离(红)/未验证(灰)。一眼看出哪个 Intent 反复偏离。
-
-**树状图** — 适合：架构的系统层级、Intent 的依赖树
-展开/折叠的树形结构，点击节点展开子项。
-
-### 交互类（探索和筛选）
-
-**过滤面板** — 适合：Intent 列表、验证记录
-复选框按状态过滤（全部/待执行/进行中/完成/阻塞），输入框模糊搜索。过滤后实时更新视图。
-
-**点击下钻** — 适合：从概览到详情
-概览页点击某个 Intent → 展开详情面板或跳到详情区。不在一页摊开所有详情，按需展开。
-
-**Hover 工具提示** — 适合：图表上的额外信息
-鼠标悬停在依赖图节点上 → 显示 tooltip（ID + 状态 + 一句话叙事）。不点击就能预览。
-
-**Tab 切换** — 适合：大板块切换
-概览 / Intent Map / 哲学 / 愿景 / 架构。所有内容先渲染堆叠，JS 切换显示。
-
-**可折叠面板** — 适合：分层信息
-默认折叠显示标题，点击展开内容。用 `max-height` 过渡，不要 `display: none`。
-
-### 布局类（组织和对比）
-
-**仪表盘** — 适合：关键指标概览
-大数字 + 颜色编码。数字 24-32px，标签 12-13px。一眼看到状态。
-
-**对比表** — 适合：trade-offs、做什么 vs 不做什么
-两列或三列并排，突出差异。每列一个方向，行是对比维度。
-
-**卡片网格** — 适合：核心信念、意图叙事
-每张卡片一个要点，标题 + 一句话。网格排列，大小一致。卡片内不超过 3 行。
-
-**时间轴** — 适合：验证历史、项目演进
-横向或纵向，每个节点一个事件。通过绿色偏离红色，附证据摘要。
-
-**看板列** — 适合：按状态分组的 Intent
-四列：待执行 / 进行中 / 完成 / 阻塞。每列下面是该状态的 Intent 卡片。一眼看出分布。
-
-**清单** — 适合：反模式、不做什么、决策原则
-每条一行 + 一句话理由。反模式用红色警告样式。
-
-### 标记类（状态和强调）
-
-**状态徽章** — 适合：Intent 状态
-颜色 + 图标 + 文字（不只靠颜色，色盲友好）：
-- 完成 = 绿色 + ✓
-- 进行中 = 黄色 + ◐
-- 待执行 = 灰色 + ○
-- 阻塞 = 红色 + ✕
-- 需复审 = 蓝色 + ?
-
-**高亮引用** — 适合：北极星、关键宣言
-大字号 + 左侧色条 + 引用样式。视觉上从周围内容跳出来。
-
----
-
-## 二、页面结构
-
-### 顶部：一屏概览
-
-人类打开第一眼看到全局：
-
-- 项目名 + 版本号
-- 北极星一句话（高亮引用样式，最醒目）
-- **环形进度图**：完成 X/Y（百分比）
-- **堆叠条形图**：状态分布（一段条形展示所有状态比例）
-- **数字仪表盘**：进行中 N、阻塞 M（大数字 + 颜色）
-
-### Intent Map 区域
-
-项目推进到哪了——用多种手段呈现不同维度：
-
-- **SVG 依赖图**：依赖链和阻塞点
-- **看板列**：按状态分组的 Intent 卡片（待执行/进行中/完成/阻塞）
-- **过滤面板**：状态过滤 + 模糊搜索（Intent 多时）
-- **点击下钻**：点击节点或卡片 → 侧边详情面板（叙事、完成/质量契约、能力需求、验证历史）
-
-### 哲学区域
-
-"我们信什么"——拆解成视觉块：
-
-- **北极星**：高亮引用，一句话
-- **核心信念**：卡片网格，每张一个图标 + 关键句
-- **不可妥协的价值**：清单，每条一句话 + 一句话理由
-- **反模式**：红色警告卡，每张一句
-- **决策原则**：对比表或清单，遇到冲突时怎么取舍
-- **灵感来源**：哲学文档里的"灵感来源"章节——展示参考的艺术家、机构、流派、著作。这是 LOOM 哲学织造的核心机制：从真实思想体系萃取核心思想。每个来源用卡片或标签展示：名字（如 Dieter Rams / Stripe / Unix Philosophy / Anthropic）+ 一句话说明"从这个体系萃取了什么原则" + 来源引用（著作/URL）。这些名字是"思想压缩包的索引"——人类看到名字就能激活对这套哲学的理解。不要把灵感来源藏在正文里，要作为独立视觉块展示。
-
-### 愿景区域
-
-"我们要去哪"——拆解：
-
-- **北极星**：和哲学呼应
-- **问题空间**：一段话
-- **意图叙事**：卡片网格，每个意图一张卡片，一句话"为什么存在"，点击展开详情
-- **不做什么**：清单，和"做什么"同样醒目
-
-### 架构区域（如果有）
-
-"怎么实现"——拆解：
-
-- **关键决策对比表**：每个决策两列对比（选了什么 / 放弃了什么）
-- **trade-offs 清单**：每条一句话
-
-### 验证历史区域（如果有）
-
-"质量怎么样"——拆解：
-
-- **时间轴**：每次验证一个节点，通过/偏离用颜色区分，点击看证据
-- **热力图网格**（Intent 多时）：Intent × 验证轮次矩阵，一眼看出哪个反复偏离
-- **偏离清单**：哪些 Intent 偏离了，证据是什么
-
-### Patch 历史区域（如果有）
-
-- 从 `06_CHANGELOG.json` 展示 Patch 时间轴：摘要、原因、影响的 Intent、文件和已记录的验证结果
-- 明确区分 Patch 与 Intent 验证；`06_CHANGELOG.md` 是生成文件，不是另一份真相
-
-### 底部
-
-- 提醒：这是只读投影，修改请编辑源文件后运行 `loom preview` 重新生成
-- 可选：一个"复制项目状态"按钮
-
----
-
-## 三、符合人类直觉
-
-### 视觉权重
-
-最重要的信息最大、最醒目。次要信息小、灰、退后：
-- 北极星 → 全页最大字号
-- 进度数字 → 大数字 + 颜色
-- Intent ID → 中等字号，等宽字体
-- 完成契约正文 → 小字，可展开才显示；质量契约与 Quality Proof 使用相邻但可区分的区域
-- 辅助说明 → 最小字，灰色
-
-不要所有文字一样大。人类靠大小判断重要性。
-
-### 渐进披露
-
-不要一次把所有信息摊开。先给摘要，想看详情再展开：
-- Intent 卡片默认折叠，只显示 ID + 状态 + 一句话
-- 点击展开后显示：意图叙事、验收契约、哲学锚点、验证历史
-- 图表上 Hover 显示 tooltip 预览，点击才展开完整详情
-
-### 信息分组
-
-相关信息放一起，不相关的用空间分隔：
-- 进度概览自成一个区块
-- Intent 依赖图 + 详情面板自成一个区块
-- 哲学、愿景、架构各自独立区块
-- 区块之间用足够留白分隔（32-48px），不要挤
-
----
-
-## 四、视觉设计原则
-
-参考 Anthropic 和 CopilotKit 的 Generative UI 设计系统：
-
-### 平面克制
-
-- **无渐变**：纯色背景
-- **无阴影**：用边框区分层次
-- **无模糊**：不要 filter: blur
-- **无发光**：不要 text-shadow 或 glow
-- **无装饰性 emoji**：用 CSS 形状或 SVG 路径做图标
-
-### 字体克制
-
-- 只用两种字重：400（正文）和 500（标题/强调）
-- 不要 600、700——太重，破坏平面感
-- 标题用句首大写，不要全大写
-- 正文不要句中加粗，用 `code style` 标记实体名
-- 最小字号 12px
-
-### 边框和间距
-
-- 边框 `1px solid`
-- 卡片圆角 8-12px
-- 卡片内边距 16-20px
-- 卡片之间间距 16-24px
-- 区块之间间距 32-48px——大间距区分大板块
-
-### CSS 变量
-
-```css
-:root {
-  --bg: ...;
-  --surface: ...;
-  --border: ...;
-  --text: ...;
-  --text-muted: ...;
-  --accent: ...;
-  --success: ...;
-  --warning: ...;
-  --danger: ...;
-}
-```
-
-不要在 HTML 里硬编码颜色。所有颜色引用变量。
-
-### 配色自定
-
-不要求暗色也不要求亮色。选你觉得让信息最易读的方案。关键是：
-- 背景和文字对比度足够（WCAG AA 标准）
-- 状态颜色区分明显
-- 不要花哨——信息是主角，视觉是配角
-
----
-
-## 五、技术约束
-
-- **单文件**：所有 HTML/CSS/JS 内联，零外部依赖
-- **零构建**：双击即可在浏览器打开
-- **内联 SVG**：图表和依赖图直接写 `<svg>`，不用 `<img>` 或外部库
-- **语义化 HTML**：用 `<section>` `<nav>` `<article>` `<button>`
-- **响应式**：手机宽度下布局不崩（`@media (max-width: 768px)`）
-
----
-
-## 六、质量检查清单
-
-生成前逐项确认：
-
-**信息密度**
-- [ ] 每个信息块用最合适的视觉手段，不是什么都用卡片或列表
-- [ ] 能用图表展示的数据不用表格
-- [ ] 能用图示展示的关系不用文字描述
-- [ ] 每个块 3 秒内能消化，不超过 3 行文字
-
-**功能**
-- [ ] 双击能在浏览器打开，不需要任何外部资源
-- [ ] SVG 依赖图节点颜色按状态编码
-- [ ] 点击 Intent 能展开详情
-- [ ] Tab 切换正常
-- [ ] 图表 Hover 有 tooltip（如果适用）
-
-**视觉**
-- [ ] 无渐变、无阴影、无模糊、无发光
-- [ ] 字重只有 400 和 500
-- [ ] 所有颜色用 CSS 变量
-- [ ] 边框统一 1px
-- [ ] 信息层次清晰（大字重要，小字次要）
-
-**可访问性**
-- [ ] `@media (prefers-reduced-motion: reduce)` 禁用动画
-- [ ] 对比度足够
-- [ ] 点击区域 ≥ 44px
-- [ ] 不仅靠颜色传达信息（颜色 + 图标 + 文字）
-
-**响应式**
-- [ ] 手机宽度下布局不崩
-- [ ] SVG 依赖图横向滚动
-- [ ] Tab 导航横向滚动
-
----
-
-## 输出
-
-把 HTML 写到 `loom-preview.html`。完成后告诉用户文件路径。