@haaaiawd/loom 1.3.1 → 2.0.1

package/dimensions/examples/CLI_TOOL/README.md

@@ -1,163 +0,0 @@
-# 参考案例：CLI 工具
-
-> 这份文件提供搜索起点和好实践样本。Weaver 只在相关 Doctrine 问题中使用，
-> 拆解出的部分和这里不同时，以 Weaver 的拆解为准。
-
----
-
-## CLI 工具通常拆解出的实现部分
-
-### 1. CLI 交互设计
-**职责**：参数解析、--help、--version、用法提示、子命令组织
-
-**该做什么**：
-- 支持 `-h`/`--help` 和 `-V`/`--version`，这是 POSIX/GNU 强制要求（GNU Coding Standards §4.8）
-- 无参数运行时显示简洁帮助（clig.dev 原则：描述 + 1-2 个示例 + 常用 flag + 提示 `--help` 看更多）
-- `--help` 显示完整帮助：所有 flag、示例、链接到 web 文档
-- flag 用 dash-case（`--long-option`），短 flag 用单字母（`-h`），不要发明新语法
-- 输入文件用位置参数，输出文件用 `-o`/`--output`（GNU 约定）
-- `--` 表示参数结束，后续都当文件名（POSIX Guideline 10）
-- `-` 表示 stdin/stdout（POSIX Guideline 13）
-
-**不该做什么**：
-- 不要把 `--help` 当文件名处理（md2html 的真实 bug）
-- 不要用 camelCase 或 snake_case 命名 flag
-- 不要让 flag 顺序影响结果（除非显式声明互斥）
-- 不要重载 `-h` 做别的事
-
-**参考实践**：
-- **clig.dev** — Command Line Interface Guidelines，社区维护的 CLI 设计规范，覆盖 help/arguments/errors/output/documentation 全维度。https://clig.dev/
-- **POSIX Utility Conventions** — Guideline 1-13，CLI 参数语法的学术根基。https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap12.html
-- **GNU Coding Standards §4.8** — `--version`/`--help` 强制要求 + long-option 约定。https://www.gnu.org/prep/standards/html_node/Command_002dLine-Interfaces.html
-- **clap (Rust)** / **cobra (Go)** / **commander.js** — 主流参数解析库，看它们的默认 help 输出格式
-- **ripgrep --help** / **fd --help** / **bat --help** — 现代 CLI 工具的 help 文本样本，结构清晰、示例在前
-
-**搜索起点**：
-- "POSIX utility argument syntax conventions"
-- "GNU program argument syntax"
-- "clap help formatting conventions"
-- "CLI subcommand design patterns"
-
----
-
-### 2. CLI 输出美学
-**职责**：成功反馈格式、颜色策略、表格/列表排版、Rule of Silence 的正确理解
-
-**该做什么**：
-- **Rule of Silence 的正确理解**：Eric Raymond 原文是 "When a program has nothing surprising to say, say nothing"——意思是"没意外时别废话"，不是"什么都不说"。转换成功对用户是有价值的信息（文件名、大小、位置），该说就说
-- 颜色策略遵循三约定（ripgrep/fd/bat 都遵守）：
-  - `NO_COLOR` 环境变量设了就禁用颜色（no-color.org，被 ripgrep/fd/bat/npm/cargo/gh/docker 等采纳）
-  - `--color auto`（默认）：TTY 时上色，管道时不上色
-  - `--color always`/`--color never`：强制开/关
-- 进度反馈：长任务显示进度条或 spinner，短任务静默
-- 输出结构：文件名在前，匹配内容在后（ripgrep 格式）
-- 表格输出用对齐排版，不用 ASCII art
-
-**不该做什么**：
-- 不要无脑上色——管道场景颜色码会污染下游工具
-- 不要把成功信息写到 stderr（clig.dev：stdout 是数据，stderr 是消息）
-- 不要输出时间戳/生成时间（破坏可预测性，违反 Unix 哲学）
-- 不要在成功时输出 "Done!" 之类废话——如果用户需要确认，输出有用的信息（文件名、行数、字节数）
-
-**参考实践**：
-- **ripgrep 输出设计** — `--color auto` + TTY 检测 + `--colors TYPE:STYLE:VALUE` 细粒度控制。https://github.com/BurntSushi/ripgrep
-- **bat 输出设计** — `--style` 组件化（numbers/changes/grid/header-filename 可组合），`--decorations=auto` TTY 检测。https://github.com/sharkdp/bat
-- **NO_COLOR 约定** — no-color.org，一个环境变量统一禁色，被整个生态采纳。https://no-color.org/
-- **Eric Raymond《The Art of Unix Programming》** — Rule of Silence 原文。https://www.catb.org/esr/writings/taoup/html/
-- **clig.dev "Output" 章节** — stdout vs stderr 的语义、信噪比原则。https://clig.dev/#output
-
-**搜索起点**：
-- "Unix Rule of Silence original text"
-- "CLI color output best practices NO_COLOR"
-- "bat exa ripgrep output design"
-- "terminal table formatting"
-
----
-
-### 3. CLI 错误呈现
-**职责**：错误结构、修复建议、退出码语义、上下文信息
-
-**该做什么**：
-- 错误信息三要素（Azure CLI 规范）：**What**（什么错了）+ **Why**（为什么错）+ **How**（怎么修）
-- 退出码语义化（POSIX + agent-cli-guide 扩展）：
-  - `0` 成功
-  - `1` 一般错误
-  - `2` 用法错误（POSIX 约定）
-  - `3` 资源不存在 / `4` 权限拒绝 / `5` 冲突已存在（现代扩展，对 Agent 友好）
-- 错误写到 stderr，数据写到 stdout（clig.dev 强制）
-- 可修复的错误带 `suggested_fix`（Rust 编译器的 `Applicability` 标记：`MachineApplicable` / `MaybeIncorrect`）
-- 多个同类错误归组到一个标题下，不要刷屏（clig.dev：信噪比是关键）
-- 最重要的信息放最后——用户视线最后停留的位置（clig.dev）
-
-**不该做什么**：
-- 不要 dump stack trace 给用户（除非 `--verbose` 或 debug 模式）
-- 不要把错误信息写得像公式或编程表达式（Azure CLI 规范）
-- 不要在错误信息里加颜色或样式控制（Azure CLI：错误信息要纯文本）
-- 不要用 `resource group is missing, please provide` 这种模糊说法——用 `please provide a resource group name by --resource-group`（带具体 flag）
-- 不要用 exit code 1 涵盖所有错误——区分用法错误和运行时错误
-
-**参考实践**：
-- **Rust 编译器错误设计** — primary span（红）+ secondary span（蓝）+ `help:` 建议 + `Applicability` 标记。RFC 1644。https://rust-lang.github.io/rfcs/1644-default-and-expanded-rustc-errors.html
-- **Elm 编译器错误** — "Compiler Errors for Humans"，教育性错误信息范本。https://elm-lang.org/blog/compiler-errors-for-humans
-- **Azure CLI 错误处理规范** — What/Why/How 三要素 + actionable message。https://github.com/Azure/azure-cli/blob/dev/doc/error_handling_guidelines.md
-- **jmmv.dev "CLI design: Error reporting"** — usage error vs application error 的区分。https://jmmv.dev/2013/08/cli-design-error-reporting.html
-- **clig.dev "Errors" 章节** — 把错误变成文档、catch and rewrite for humans。https://clig.dev/#errors
-- **agent-cli-guide Principle 6** — 语义化退出码（对 Agent 消费者友好）。https://github.com/Johnixr/agent-cli-guide
-- **RFC 9457 Problem Details** — HTTP 错误结构，可移植到 CLI（zircote 博客）。https://zircote.com/blog/2026/04/cli-error-messages-are-a-dual-consumer-problem/
-
-**搜索起点**：
-- "CLI error message design best practices"
-- "Rust compiler error messages design Applicability"
-- "exit code conventions sysexits.h"
-- "error message actionable suggested fix"
-
----
-
-### 4. 转换/处理引擎（如果是转换类工具）
-**职责**：核心逻辑、纯函数设计、子集 vs 全集策略、透传 vs 报错
-
-**该做什么**：
-- 核心层纯函数——`parse(input): output`，不 IO、不读全局状态、不调 `Date.now()`
-- IO 只在 CLI 层，核心层可独立测试、可被其他入口复用
-- 子集策略要显式声明——支持什么、不支持什么，文档里写清楚
-- 不支持的语法：报错（fail loud）还是透传（pass through）？显式选择，不要意外行为
-
-**不该做什么**：
-- 不要在核心层做 IO（破坏纯函数性 + 可测试性）
-- 不要用全局可变状态（破坏可预测性）
-- 不要"尽量支持"——要么支持要么不支持，模糊地带是 bug 工厂
-
-**参考实践**：
-- 取决于具体领域（Markdown 解析 / JSON 处理 / 文件转换）
-- "pure function design benefits"
-- "subset vs superset API design"
-
----
-
-### 5. 产物设计（如果产出文件）
-**职责**：产物格式、自包含性、可预测性
-
-**该做什么**：
-- 产物自包含——不依赖外部 CSS/JS/字体（离线可用、可邮件发送、可存档）
-- 输出可预测——相同输入永远相同输出（byte-identical），不嵌时间戳、不嵌随机 ID
-- 产物格式稳定——格式是和用户的契约，不能随意变
-
-**不该做什么**：
-- 不要在产物里嵌生成时间/版本号（破坏 diff、破坏可复现）
-- 不要引用外部资源（CDN CSS、Google Fonts）——产物离线就坏
-- 不要输出"漂亮但不可预测"的产物——可预测 > 漂亮
-
-**参考实践**：
-- "self-contained output design"
-- "deterministic output reproducible builds"
-- Reproducible Builds 项目哲学。https://reproducible-builds.org/
-
----
-
-## 搜索时的关键提醒
-
-1. 实践领域的知识在工具和标准里，搜 "best practices" / "design conventions" / 具体工具名，别只搜"哲学"
-2. 看真实工具的输出——`rg --help` / `fd --help` / `bat --help` 本身就是好实践的样本
-3. 读标准文档——POSIX / GNU Coding Standards 是 CLI 设计的根基
-4. 对比不同工具的做法——ripgrep vs grep、bat vs cat、fd vs find，差异里藏着设计决策
-5. 2026 年的新维度：CLI for Agents。CLI 的消费者现在还有 Agent，结构化输出（`--output json`）、语义化退出码、`schema` 命令正在成为新标准（clispec.dev、agent-cli-guide）

package/dimensions/universal/COLLABORATION_PHILOSOPHY.md

@@ -1,28 +0,0 @@
-# Doctrine Lens — Collaboration and Decision Rights
-
-> 按需使用。单人、低冲突项目不需要制造一套治理制度。
-
-## 触发
-
-- 多个角色或团队对同一决定拥有不同责任。
-- 重要分歧反复拖慢或破坏交付。
-- 变更需要明确授权、影响评估或审计。
-- 人类与 Agent 的决策边界不清晰。
-
-## 决策问题
-
-1. 哪类决定由谁负责，谁提供意见，谁最终批准？
-2. 事实分歧、价值分歧和授权分歧分别如何解决？
-3. 什么变更需要影响评估，什么可以直接可逆实验？
-4. 何时必须升级给人类，何时 Agent 应自主推进？
-5. 哪些协作行为会制造虚假共识、责任漂移或文档表演？
-
-## 输出标准
-
-- 只覆盖真实存在的决策类型。
-- 权限与升级条件清楚。
-- 评审标准关注结果、契约和风险，不管理个人风格。
-- 规则包含例外和退出条件。
-- Evidence Map 记录导致规则产生的真实冲突或外部依据。
-
-协作 Doctrine 不复制角色提示词；角色权限由 LOOM System Boundary 管理。

package/dimensions/universal/ENGINEERING_CREED.md

@@ -1,30 +0,0 @@
-# Doctrine Lens — Engineering Judgment
-
-> 按需使用。它只记录跨多个 Intent 的工程判断，不把常识和局部技术选择永久化。
-
-## 触发
-
-- 多个系统部分需要共享同一数据、错误、依赖或兼容策略。
-- 某类工程失败反复发生，已成为项目级风险。
-- 一个长期取舍会持续影响架构和实现。
-
-如果问题只属于当前技术栈、某个模块或一次实现，让 Architect 定义边界，Forge 在 Expertise Pack 中
-加载相应专业方法。
-
-## 决策问题
-
-1. 项目最需要控制的复杂度来自哪里？
-2. 哪些契约必须显式，哪些实现细节应保持局部？
-3. 错误、降级和恢复应保护什么用户或系统结果？
-4. 何时引入依赖或抽象，什么证据说明它值得？
-5. 哪些工程反模式会让短期速度转化为长期失控？
-
-## 输出标准
-
-- 工程北极星。
-- 少量带触发条件的判断原则。
-- 反模式与可观察失败信号。
-- 允许实验与必须审慎的边界。
-- 决策相关 Evidence Map。
-
-不要规定函数长度、目录风格、测试比例等通用教条；除非它们由项目证据支持且会反复改变决定。

package/dimensions/universal/PRODUCT_PHILOSOPHY.md

@@ -1,32 +0,0 @@
-# Doctrine Lens — Product Judgment
-
-> 按需使用。只有判断会跨多个 Intent 反复生效时，才写入 Project Doctrine。
-
-## 触发
-
-- 项目需要长期保护的用户结果尚不清楚。
-- 多个功能之间存在价值冲突。
-- 团队对“合格”和“优秀”的产品结果没有共同判断。
-- 反复出现表面完成、实际伤害用户结果的方案。
-
-单个页面、一次功能或局部体验技巧留给当前 Intent 的 Expertise Pack。
-
-## 决策问题
-
-1. 项目长期保护的用户结果是什么，什么证据表明它重要？
-2. 当速度、控制、清晰、灵活性等价值冲突时如何取舍？
-3. 什么可观察信号区分普通、可靠和出众？
-4. 哪些反模式会让产品看似完成，却破坏用户结果？
-5. 哪些方向允许大胆且可逆的探索，哪些边界不能改变？
-
-## 输出标准
-
-只保留能够改变未来行动的内容：
-
-- 一句可用于取舍的北极星。
-- 少量带适用条件和例外的原则。
-- 卓越标准与失败信号。
-- 创作空间。
-- Evidence Map：事实或来源 → 机制 → 项目后果。
-
-不设置原则或来源数量，不复述 BASELINE，不预写功能和架构。

package/meta/BASELINE.md

@@ -1,91 +0,0 @@
-# BASELINE — LOOM 不可妥协的系统底线
-
-底线只规定什么不能失守，不规定怎样做到优秀。
-
-项目哲学负责定义取舍与质量；角色负责在边界内发挥专业能力；CLI 负责机械执行能够被程序保证的约束。底线不能替代这三者。
-
-## B1：改变之前必须理解结构
-
-任何实质修改都必须建立在对当前系统结构、职责边界和依赖关系的理解上。
-
-最低要求：
-
-- 先检查真实代码与现有约定，不凭想象创建平行体系。
-- 修改范围与结构说明的详细程度应和风险相称。
-- 新增边界、模块或跨系统依赖时，必须写明职责和依赖方向。
-- 探索性原型可以先验证关键假设，但不得伪装成已完成的正式实现。
-
-违反信号：未读现有实现便重写、复制出第二套系统、用“以后再整理”掩盖边界混乱。
-
-## B2：环境与秘密不得固化进实现
-
-密钥、凭证、环境专属地址和可变配置不得写死在代码中。
-
-最低要求：
-
-- 秘密通过安全的环境或凭证机制提供。
-- 环境差异进入配置层。
-- 业务常量集中且具有语义；算法常量和协议常量可以保留，但必须能解释来源。
-- 新增配置要有类型、默认策略和错误语义。
-
-违反信号：真实密钥进入仓库、随机路径或 URL 散落、无法解释的数值控制业务行为。
-
-## B3：可观察契约必须显式
-
-用户、模块或外部系统能够观察到的行为必须有明确契约。
-
-契约至少覆盖适用项：
-
-- 输入、输出和状态变化。
-- 错误、失败和降级行为。
-- API、CLI、配置、文件格式或交互语义。
-- 兼容边界与变更影响。
-
-局部实现细节不需要全部文档化；会影响其他部分的行为不能只存在于作者记忆里。
-
-## B4：重要判断必须可追溯
-
-会改变产品方向、架构边界、公共契约、关键依赖或安全姿态的判断必须留下理由和证据。
-
-记录应回答：
-
-- 为什么现在需要这个决定。
-- 考虑过哪些替代方案。
-- 选择依据和代价是什么。
-- 影响哪些 Intent、契约或系统部分。
-- 什么证据会使我们重新评估。
-
-普通局部实现选择不必制造 ADR；可逆且低风险的探索可以先做小实验，再用结果决定是否升级为正式决策。
-
-## B5：完成必须可回溯、可验证
-
-任何“完成”都必须能回溯到原始意图，并有当前 revision 的验证证据。
-
-最低要求：
-
-- 实现单元关联清晰的意图叙事。
-- 完成契约描述可观察结果和关键失败边界；若声明质量提升，另有质量契约与基线相对证据。
-- 实现者可以自测，但不能只凭自己的解释宣告通过。
-- Keeper 独立验证；需要人类判断的部分明确标为 `pending_human`。
-- 声称质量提升时，必须提供修改前基线、选择依据和稳定性证据。
-- 没有当前 revision 的最后一条 `passed` 记录，不得闭合 Intent。
-
-## 项目特定底线
-
-Weaver 可以在 `.loom/v{N}/00_PHILOSOPHY/PROJECT_BASELINE.md` 追加领域不可妥协项，例如隐私、安全、合规、可访问性或模型治理。
-
-项目底线必须：
-
-- 有明确触发条件和合规判定。
-- 只追加，不豁免通用底线。
-- 与版本和影响范围一起演进。
-
-## 比例原则
-
-LOOM 的流程成本必须小于它降低的风险。
-
-- 小改动：简短结构判断、局部契约、直接验证。
-- 中等能力：清晰 Intent、必要设计、自动验证。
-- 高风险系统：完整边界、决策记录、多层验证与回滚方案。
-
-当两条规则冲突时，优先保护真实用户结果、系统完整性和可恢复性；不要为了“流程正确”牺牲交付本身。

package/meta/INTENT_LOOP.md

@@ -1,296 +0,0 @@
-# INTENT LOOP — LOOM Quality Engine Runtime
-
-Intent Loop 将一个产品意图变成可验证结果，并在证据不足时回流到真正负责的层。
-
-```text
-Doctrine → Intent narrative → Capability Graph → Contract
-→ Expertise Compiler → Quality Arena → Quality Proof
-→ Close or Reflow
-```
-
-## 1. 权威边界
-
-| 内容 | 唯一负责人 |
-|---|---|
-| 长期价值、卓越标准、反模式 | Weaver |
-| 产品目标、非目标、Intent narrative | Visionary |
-| Capability Graph、系统边界、Intent DAG、完成/质量契约 | Architect |
-| Expertise Pack、Authorial Stance、Atelier 候选、实现、自测 | Forge |
-| 独立判定、Quality Proof | Keeper |
-
-Keeper 不修改契约；Forge 不以实现困难改写 Intent；Visionary 不写 acceptance；Weaver 不拆实施模块。
-
-## 2. Intent Schema
-
-必需字段：
-
-- `title`
-- `narrative_ref`
-- `depends_on`
-- `philosophy_anchors`
-- `acceptance`
-- `continuity_required`：仅在会变更既有用户或系统状态时启用；保留规则与时序验证仍写在 acceptance。
-- `status`
-- `revision`
-
-可选质量字段：
-
-- `quality_contract`：相对基线可观察的质量主张与最小有意义差异。
-- `capability_needs`：任务需要的专业认知、工具或审美能力。
-- `creative_scope`：允许探索与不得改变的边界。
-- `quality_strategy`：`adaptive | atelier`，缺失等价于 `adaptive`；Atelier 只用于明确需要作者命题、媒介原型与独立候选比较的结果。
-- `verification_method`：可复现验证方法。
-
-`acceptance` 是 Reliability Floor；`quality_contract` 是 Distinctive Ceiling。二者不能合并成一串模糊
-“高质量要求”，否则完成与卓越都无法诚实判定。
-
-### 2.1 Capability Graph Gate
-
-Capability Graph 在 Vision 与 Intent Map 之间展开：`outcome`、`concern`、`capability`、`risk`、`evidence` 节点及其关系。它不是执行 DAG；未知、调研和分叉留在 Graph，只有边界清楚、可独立验收的结果才进入 Intent。
-
-- 所有高影响节点必须路由为 `expand`、`brief`、`intent`、`defer`、`exclude` 或 `covered_by`，不能停留在 `open`。
-- 每个高影响 `outcome` 必须以 `validated_by` 连接到一个有验证计划的 `evidence` 节点。该计划至少声明：结果在何处被观察（`target`）、怎么复现（`procedure`）、什么算通过（`pass_criteria`）、留下什么证据（`artifact`）和由哪个 Intent 产出它。`artifact` 必须是当前版本内 `verifications/` 或 `08_ASSET_LIBRARY/files/` 下真实存在的普通文件；接口可用、文件存在于版本外或 URL 可访问都不能替代目标宿主、用户界面、外部接收方或交付物中的实际可观察结果。
-- 每个当前 Intent 必须由至少一个 Graph 节点的 `intent_refs` 回链；Graph 是这份关联的唯一真相源，避免双写漂移。
-- 需要专业方法、外部知识、研究或即将进入当前 Intent 的能力节点，才使用 `.loom/vN/07_CAPABILITY_BRIEFS/<node-id>.md` 写项目化 Brief。
-- `loom capability coverage` 是 Architect 完成图谱后的门；`loom capability compile <id>` 是 Forge 的只读编译入口。Forge 发现新的缺口必须回流 Architect，不能把猜测静默变成实现范围。
-
-## 3. 状态与 revision
-
-状态：
-
-```text
-pending → in_progress → completed
-                     ↘ blocked
-completed → needs_review → in_progress
-```
-
-- 语义、契约、依赖或引用变化时递增 `revision`。
-- 纯状态变化不递增。
-- 只有当前 revision 的最新记录为 `passed` 才能 completed。
-- 连续三轮 `deviated` 升级为 blocked。
-- 旧版缺失 revision 兼容为 1。
-
-## 4. Context Pack
-
-`loom activate <role> --intent <id>` 生成：
-
-1. Execution Envelope
-2. Active Objective
-3. Hard Invariants
-4. Success Contracts
-5. Project Judgment
-6. Expertise Inputs（含当前 Intent 编译得到的 Capability Graph 节点与 Brief）
-7. Working Facts
-8. Role Contract / Output / Reflow / Stop
-
-这是一种结构化注意力控制，不是内存擦除。宿主 system/developer/user 指令优先；旧会话事实与磁盘冲突时，
-以当前项目事实为准并报告冲突。
-
-## 5. Select
-
-```bash
-loom intent next
-loom intent update <id> --status in_progress
-```
-
-只选择 pending、所有依赖 completed、未弃用的 Intent。一次 Forge 作用域只包含一个当前 Intent。
-进入选择前，Graph coverage 必须没有未路由的高影响节点、无计划能力节点和未映射 Intent。
-
-## 6. Expertise Compiler
-
-Forge 在实现前形成临时 Expertise Pack：
-
-- **Domain**：领域机制、失败边界和项目事实。
-- **Taste**：什么区分普通、可靠和出众。
-- **Author**：这次提出什么可反驳的创作命题，选择什么并拒绝什么。
-- **Critic**：最可能出现的平庸方案、自我欺骗与反例。
-- **Verifier**：如何观察、比较和复现。
-
-这五项是认知功能，不是必须创建五个角色或五份文档。
-
-Capability Graph 先提供当前 Intent 相关的项目事实、风险、约束和 Capability Brief；Expertise Compiler 再按 Brief 的获取计划加载真实技能、工具或资料。它不把整张图或历史会话当成当前任务上下文。
-
-当 capability 显式为 `external_required`，或高影响 capability 未显式豁免时，External
-Acquisition Gate 启用。Forge 只能自行生成 Search Plan，必须实际使用 find skill、
-网络、官方文档或研究资料获取内容，再把可回查来源与项目化 Capability Capsules 写入
-`.loom/vN/10_EXPERTISE_PACKS/<intent-id>.json`。Graph 不保存固定站点、Skill 或关键词。
-模型记忆、未打开的搜索摘要和自生成原则不能替代来源。Pack 绑定 Intent revision；Keeper
-不继承 Capsule 结论，而是重新打开关键来源并在 passed 记录中绑定当前 Pack。
-
-`quality_strategy=atelier` 时运行 Identity Compiler：将项目判断编译为可执行的 Authorial
-Stance，而不是模仿名人的 Persona。Forge 在 `.loom/vN/09_ATELIER/<intent-id>.json`
-保存唯一 Atelier Record；普通 Intent 不创建该文件。
-
-### 2.2 Graph Change Proposal Gate
-
-新用户要求是 `outcome` 或 `constraint` 候选；论文、资料与运行发现是带 provenance 的 `capability`、`risk` 或 `evidence` 候选。它们先写入 `.loom/vN/07_GRAPH_PROPOSALS/CGP-*.json`，必须记录来源、观察时间、具体证据、为什么现在需要处理。Proposal 不是正式 Graph，Forge/Keeper 不得借它静默扩大当前 Intent。
-
-Architect 必须把每个 proposal 判定为：已覆盖、Graph 更新、Intent 变更、acceptance 变更、Minor、Major 或拒绝；关闭时必须提交与决策相符的结构化 resolution，CLI 会从决策时磁盘基线验证 Graph / Intent / acceptance / 决策记录的真实变化或现有有效覆盖，不能以任意 implementation_ref 文本关闭。`constraint` 若决定为 Graph 更新，必须进入正式 Graph 的 `constraints` 字段并回链受影响节点。`covered_by` 必须显式指向另一个已覆盖、非 `covered_by` 路由的节点，并同时保留同目标的关系。`loom guide` 与 `loom doctor` 对未闭合 proposal 回流 Architect。
-
-Author 的自我更正不得绕过该门：局部命题、机制、媒介语法或候选选择变化写入 Atelier
-Record `corrections[]` 并递增 `stance_revision`；只有新的用户结果、约束、能力缺口、风险
-或项目证据才提交 Graph proposal。Architect 裁决并修订磁盘真相源后，Capability compile
-把新输入交回 Author。Author 不得裁决自己的 proposal，也不得修改考纲后自证通过。
-
-### 2.3 Asset Library Protocol
-
-若项目使用图片、音频、视频、模型或其他交付素材，`.loom/vN/08_ASSET_LIBRARY/manifest.json` 与同目录 `files/` 是版本化的一等真相源。每条资产必须有内容派生稳定 ID、kind、中文/其他标签、来源/作者/许可、SHA-256、库内相对路径、status 与 approval。`loom asset import` 只接受明确的本地普通文件、复制后校验哈希，并拒绝路径逃逸、重复字节和未批准/缺少许可元数据。
-
-素材字节能下载不等于素材可呈现；远程 URL 不是呈现证据。资产若用于 Capability Graph 的 evidence，资产 `evidence_refs` 与 evidence 节点 `asset_refs` 必须双向一致，Keeper 仍需在目标宿主验证实际呈现。
-
-技能、工具和资料必须经历：
-
-```text
-Discover → Load → Translate → Use
-```
-
-只看到名字不算拥有能力；真正使用时要说明它改变了哪条判断、候选或验证方法。
-
-## 7. Quality Arena
-
-### Direct Path
-
-当正确方案明显、质量契约不要求比较、探索不会增加实质价值时，直接实现并验证。
-
-### Arena Path
-
-当目标要求“更好、出众、惊艳”或存在关键质量选择时：
-
-1. **Baseline**：记录改动前可观察状态。
-2. **Candidates**：生成少量机制不同的方案。
-3. **Compare**：对照完成契约、质量契约、Doctrine、成本与风险。
-4. **Realize**：实现最强候选。
-5. **Observe**：检查真实界面、运行结果、性能或用户信号。
-6. **Adjust**：根据新证据修正。
-7. **Self-check**：Forge 先排除明显失败，再交 Keeper。
-
-候选不强制落盘，不设置固定数量。没有候选胜过基线时，保留原方案或回流契约。
-
-### Atelier Path
-
-当 `quality_strategy=atelier` 时，Arena 增加明确作者命题与落盘证据：
-
-1. 编译 Authorial Stance 并冻结修改前基线。
-2. 定义质量差异轴，独立形成机制不同的媒介原型。
-3. 候选先过 Reliability Floor，再匿名比较或保留基线。
-4. 每个候选绑定 `stance_revision`；Stance 改变后重新资格检查或归档旧候选。
-5. 选择证据、主要代价和 corrections 写入唯一 Atelier Record，再进入完整实现。
-
-## 8. Independent Quality Proof
-
-Keeper 在独立任务中只加载当前 revision、真实产物、契约、Doctrine 和必要验证工具。不要加载 Forge 的
-隐藏推理或 Expertise Pack，以避免共享偏见。
-
-基础维度：
-
-- `intent_fidelity`
-- `philosophy_consistency`
-- `baseline_compliance`
-- `acceptance_achievement`
-
-若 `continuity_required` 为 true，额外增加：
-
-- `preservation_achievement`
-
-有 `quality_contract` 时增加：
-
-- `quality_achievement`
-
-每个维度格式：
-
-```json
-{
-  "verdict": "passed",
-  "evidence": "对照了什么、在哪里观察到、如何复现"
-}
-```
-
-质量契约声明相对提升时，`quality_achievement` 还必须提供 `quality_proof_ref`，其指向的证据至少包含：
-
-- 改动前 Baseline。
-- 精确质量主张与最小有意义差异。
-- 候选依赖的不同机制。
-- 选择证据。
-- 回归与稳定性证据。
-- 代价、限制和保留风险。
-
-若比较依赖主观模型评分，至少使用顺序交换或同等的偏差检查；高风险主观质量保留
-`pending_human`。不得把单次 LLM 偏好包装成客观事实。
-
-## 9. Write and Close
-
-完整记录：
-
-```bash
-loom verify write --json-file verification.json
-```
-
-快捷记录：
-
-```bash
-loom verify pass <id> \
-  --summary "<具体证据>" \
-  --reproduction-command "<命令>" \
-  --quality-proof "<ref>"
-```
-
-没有质量契约时省略 `--quality-proof`。CLI 自动绑定当前 revision 并追加历史。
-
-```bash
-loom intent done <id>
-```
-
-如果完成契约通过但质量契约未通过，可以诚实记录完成证据，但不能写整体 passed 或宣称提升；
-回流 Arena、修订质量契约，或由用户接受当前边界。
-
-### 9.1 Goal 对齐与状态守恒
-
-当前 Intent 是一次 Codex goal 的可闭合单元，而不是一句“完成了”的主观声明。只有以下门同时通过，goal
-才应完成、Intent 才能 `done`：
-
-1. **结果**：完成契约中的本轮结果成立。
-2. **守恒**：若启用 `continuity_required`，旧状态 → 本轮操作 → 新状态的序列证明未发生未授权丢失。
-3. **证据**：验证可复现，且记录属于当前 revision。
-4. **品质**：仅在存在 `quality_contract` 时，Quality Proof 证明达到所声明水准。
-
-Codex 的 goal/status 用于驱动循环与恢复工作，不是替代上述证据的通行证。对状态型 Intent，默认语义是保留或合并；
-删除、替换、重置和清空必须在 acceptance 中显式授权。
-
-## 10. Reflow
-
-| 发现 | 回流 |
-|---|---|
-| 长期价值或质量观缺失 | Weaver |
-| 产品目标、非目标或 narrative 错误 | Visionary |
-| 系统边界、依赖、契约不可成立 | Architect |
-| 图谱分支遗漏、能力缺口或高影响节点未路由 | Architect 更新 Capability Graph |
-| 专业能力、候选或实现不足 | Forge |
-| 证据不足、验证偏差或需人类感知 | Keeper |
-
-回流只修改问题拥有者的权威文件，并评估受影响 Intent。不要为了让当前实现通过而降低契约。
-
-## 11. 收敛
-
-一趟结束时：
-
-- 全部当前 Intent completed 且没有 `needs_review` → 收敛。
-- 有 deviated → 修正并重验。
-- 修改影响其他 Intent → 标记 needs_review。
-- 三趟后仍持续产生 needs_review → 视为系统性问题，回流 Architect 或创建新版本。
-
-## 12. 演进
-
-- Patch 不改变 Intent 语义；验证后记录 `06_CHANGELOG.json`。
-- Minor 使用 draft：`intent add|revise` → scoped Visionary/Architect → `intent finalize`。
-- Major 在 Doctrine、北极星或主要架构边界变化时 `version new`。
-- 跨版本承接通过 `lineage.predecessors` 显式声明；旧版本 passed 不转移到新版本。
-
-## 13. 停止条件
-
-当以下条件同时满足时停止：
-
-- 当前目标真实完成。
-- Reliability Floor 有可复现证据。
-- 如声明质量提升，Distinctive Ceiling 有 Quality Proof。
-- 没有未处理的高影响回流。
-- 继续探索不会实质提高结果或降低风险。