@haaaiawd/loom 0.10.0 → 1.0.0

package/dimensions/PART_DECOMPOSITION.md

@@ -1,203 +1,42 @@
-# 实现部分拆解方法论
-
-> 这份文档给 Agent 一套拆解方法，让它自己识别"这个项目由哪些实现部分组成"，
-> 然后对每个部分走搜索漏斗，织造该部分的哲学约束。
->
-> 项目千变万化，预填维度文件覆盖不了所有情况。方法不会过时，清单会。
-
----
-
-## 核心思路
-
-传统维度库靠预填——CLI 工具该有哪些维度、Agent 系统该有哪些维度、Web 前端该有哪些维度，全部写死在文件里。这样有三个问题：
-
-1. 项目类型太多，预填永远追不上
-2. 新项目类型出现时，维度库来不及更新
-3. 预设的"UX 哲学"对 CLI 工具没意义，预设的"CLI 美学"对 Agent 系统也没意义——错配
-
-LOOM 换了个方向：预设"怎么拆部分"，不预设"有哪些部分"。Agent 拿到项目特征后，自己拆解出实现部分，每个部分独立织造哲学。
-
----
-
-## 拆解流程
-
-### Step 1：识别项目类型
-
-先判断项目属于哪个大类。判断结果用来确定拆解的起点，不用来查预设清单。
-
-常见类型（非穷举——Agent 自行判断）：
-
-| 类型 | 特征 | 用户接触面 |
-|---|---|---|
-| CLI 工具 | 命令行交互，输入→输出 | 终端输出、参数、退出码 |
-| Agent 系统 | 自主决策，工具调用 | 对话、工具调用结果、状态反馈 |
-| Web 前端 | 浏览器渲染，用户交互 | 页面、交互、视觉 |
-| 后端服务 | API 驱动，多客户端 | API 响应、错误码、文档 |
-| 游戏引擎 | 实时渲染，物理模拟 | 画面、操作反馈、性能 |
-| 嵌入式系统 | 资源受限，硬件交互 | 设备行为、指示灯、串口 |
-| 数据管道 | ETL/流处理，数据变换 | 数据质量、吞吐量、延迟 |
-| 混合型 | 以上多种组合 | 按子系统拆分，各走各的类型 |
-
-**判断方法**：看项目的用户接触面和核心交互方式。如果项目跨多个类型（如 Agent 系统 + Web 前端），按子系统分别判断。
-
-**用户提到的特殊类型**：上面这张表只列了常见类型。用户可能提出表里没有的系统——编译器、数据库、操作系统内核、游戏引擎、实时渲染管线、分布式共识系统、密码学库、嵌入式固件、区块链协议、消息队列、时序数据库……遇到表里没有的类型，按 Step 2 的三个问题自己拆，不要硬套。`examples/` 目录下有参考案例的才几个，没参考案例的类型更要认真走搜索漏斗——这类系统的实践知识往往在论文、标准文档、源码注释里，不在博客里。
-
-### Step 2：拆解实现部分
-
-对项目类型，问三个问题，每个答案是一个"实现部分"：
-
-**问题 A：用户接触面是什么？**
-- CLI 工具 → 终端输出、参数解析、帮助信息、错误呈现
-- Agent 系统 → 对话格式、工具调用展示、状态反馈、进度提示
-- Web 前端 → 页面布局、交互反馈、视觉风格、动效
-
-**问题 B：内部由哪些子系统组成？**
-- CLI 工具 → 转换引擎、文件 IO、配置管理（如果有）
-- Agent 系统 → 编排器、工具调度、上下文管理、提示词构造、验证器
-- Web 前端 → 路由、状态管理、组件层、数据获取、样式系统
-
-**问题 C：每个子系统的职责边界在哪？**
-- 问的是"每个模块该怎么做、什么标准"——"有哪些模块"是架构的事，不是哲学的事
-- 职责边界 = 这个部分"做什么"和"不做什么"的划分
-
-**拆解原则**：
-1. **按职责拆，不按文件拆**——"CLI 输出美学"是一个部分，"cli.js 这个文件"不是
-2. **粒度适中**——太粗（"整个 CLI"）没有约束力，太细（"每个函数"）变成架构了
-3. **每个部分能独立回答"该怎么做"**——如果一个部分的"怎么做"完全依赖另一个部分，合并它们
-4. **用户接触面优先**——用户能看到、能感知的部分，哲学约束最重要
-
-### Step 3：对每个部分走搜索漏斗
-
-每个识别出的实现部分，独立走"搜索 → 萃取 → 转译 → 落地"漏斗（见 PHILOSOPHY_WEAVER.md "织造漏斗"章节）。
-
-搜索时问的问题要具体：**"这个部分该怎么做、什么标准、有什么好实践"**。别问"这个领域的哲学是什么"——实践领域的知识很少叫"哲学"。
-
-例如对 CLI 工具的"帮助信息"部分：
-- 搜 "CLI help text design best practices"
-- 搜 "ripgrep --help output design"
-- 搜 "clap help formatting conventions"
-- 搜 "POSIX utility argument syntax conventions"
-- 从结果中萃取：帮助信息的结构、示例的放法、链接的放法、退出码的说明
-
-### Step 4：产出部分哲学文档
-
-每个实现部分产出一个哲学文档（或融入通用层文档的对应章节）。文档必须包含：
-
-1. **部分北极星**：这个部分的判断基准——"遇到冲突时，拿这句话量一下"
-2. **该做什么**：可执行原则，不是口号
-3. **不该做什么**：反模式清单，每条有"为什么"
-4. **参考实践**：至少 2 个真实工具/系统是怎么做这个部分的（要一手实践——源码、文档、工程博客，不要 Wikipedia）
-5. **灵感来源**：满足 LOOM 的源多样性校验
-
----
-
-## 拆解示例
-
-### 示例 1：CLI 工具（md2html）
-
-```
-项目类型：CLI 工具
-用户接触面：终端
-
-拆解出的实现部分：
-├── CLI 交互设计 — 参数解析、--help、--version、用法提示
-├── CLI 输出美学 — 成功反馈格式、颜色策略、Rule of Silence 的正确理解
-├── CLI 错误呈现 — 错误结构、修复建议、退出码语义
-├── 转换引擎 — 纯函数、子集策略、透传 vs 报错
-└── 产物设计 — HTML 结构、CSS 内联、可预测性
-```
-
-每个部分独立搜索：
-- CLI 交互设计 → 搜 POSIX 参数约定、clap/cobra 设计、ripgrep/fd 的 --help
-- CLI 输出美学 → 搜 "CLI output design color"、bat/exa 的输出风格、Unix Rule of Silence 原文
-- CLI 错误呈现 → 搜 "CLI error message design"、Rust 的 error message 传统、Go 的 error-as-value
-- 转换引擎 → 搜 Markdown 解析策略、纯函数设计、子集 vs 全集
-- 产物设计 → 搜 "self-contained HTML"、CSS 内联策略、可预测输出
-
-### 示例 2：Agent 系统
-
-```
-项目类型：Agent 系统
-用户接触面：对话 + 工具调用结果
-
-拆解出的实现部分：
-├── 系统架构 — 编排 vs 控制、进程边界、IPC 机制
-├── 工具调用哲学 — 委托边界、失控收回、工具描述怎么写
-├── 上下文压缩 — 什么时候压缩、压缩什么、保留什么
-├── 提示词工程 — 角色激活、约束注入、上下文窗口管理
-├── 验证哲学 — 怎么信、怎么验、自动化 vs 人类
-└── 失败与恢复 — 崩溃恢复、状态一致性、回滚策略
-```
-
-每个部分独立搜索：
-- 系统架构 → 搜 "agent orchestration architecture"、LangChain/AutoGPT/CrewAI 架构设计
-- 工具调用 → 搜 "tool calling philosophy"、OpenAI function calling 设计、MCP 协议
-- 上下文压缩 → 搜 "LLM context window management"、conversation summarization 策略
-- 提示词工程 → 搜 "prompt engineering philosophy"、system prompt 设计、role activation
-- 验证哲学 → 搜 "AI agent verification"、human-in-the-loop 设计、automated verification
-- 失败与恢复 → 搜 "agent failure recovery"、state management、checkpoint 设计
-
-### 示例 3：Web 前端
-
-```
-项目类型：Web 前端
-用户接触面：浏览器
-
-拆解出的实现部分：
-├── 视觉设计哲学 — 排版、色彩、留白、层次
-├── 交互反馈哲学 — 加载状态、错误提示、成功反馈、动效
-├── 数据获取哲学 — 缓存策略、乐观更新、错误重试、loading 边界
-├── 组件设计哲学 — 组件粒度、状态边界、复用策略
-└── 性能哲学 — 首屏速度、包体积、渲染策略
-```
-
----
-
-## 拆解的元原则
-
-1. **不预设结果**——拆解出的部分由 Agent 根据项目特征判断，不是查表
-2. **用户接触面优先**——用户能看到的部分，哲学约束最重要
-3. **每个部分独立可搜索**——"CLI 输出美学"能独立搜到好实践，"整个 CLI 的哲学"太泛搜不到有用的
-4. **部分之间可以有依赖**——"CLI 错误呈现"依赖"CLI 交互设计"的参数约定，这是正常的
-5. **部分数量适中**——小项目 3-5 个部分，大项目 6-10 个，超过 10 个考虑合并
-6. **拆解结果要记录**——在哲学文档里显式列出"本项目拆解出哪些实现部分"，供 Architect 和 Forge 引用
-
----
-
-## 与通用层的关系
-
-通用层（产品哲学 / 工程哲学 / 协作哲学）回答"**为什么**"——产品为什么存在、代码怎么写、团队怎么协作。
-
-实现部分层回答"**怎么做**"——CLI 的帮助信息怎么做、Agent 的工具调用怎么做、前端的交互反馈怎么做。
-
-两层正交，缺一不可：
-- 通用层是地基。没有产品哲学，实现部分的哲学就没有判断基准
-- 实现部分层是落地。没有部分哲学，通用层就飘在空中，Forge 实现时不知道该对照什么
-
----
-
-## 与 Architect 的接口
-
-Weaver 拆解出的实现部分，是 Architect 设计架构的输入：
-
-1. Weaver 产出"实现部分清单"（在哲学文档里显式列出）
-2. Architect 读这个清单，为每个部分设计对应的模块/子系统
-3. 每个模块的接口设计，对照该部分的哲学约束
-4. Forge 实现某个模块时，引用该部分的哲学文档作为约束
-
-从哲学到架构到实现，每个环节都有约束传递链。
-
----
-
-## 搜索时的关键提醒
-
-对每个实现部分搜索时，别只搜"哲学"——实践领域的知识很少叫"哲学"，但就是哲学：
-
-- 搜 "best practices"
-- 搜 "design conventions"
-- 搜 具体工具名 + "design"（如 "ripgrep output design"）
-- 搜 具体库的文档（如 clap 的 README、cobra 的 design doc）
-- 搜 标准文档（如 POSIX、IEEE）
-- 搜 工程博客（如 Stripe engineering blog、Cloudflare blog）
-
-实践驱动的领域，知识在工具和标准里，在论文里的反而少。按 `SEARCH_METHODOLOGY.md` 的领域形态判断走对应路径。
+# Responsibility and Intent Slicing
+
+> 这是 Architect 的按需方法，不是 Weaver 的必填清单，也不是 CLI 通过条件。
+
+## 何时使用
+
+只有在以下情况使用拆分：
+
+- 一个目标跨越多个独立系统责任。
+- 不同部分可以单独验证或具有明确依赖。
+- 一次实现会产生过大风险、上下文或回滚成本。
+
+如果拆分不会改善边界、验证或交付顺序，就保持一个 Intent。
+
+## 三种不能混淆的结构
+
+1. **Doctrine 领域**：会反复影响未来决策的长期判断，由 Weaver 负责。
+2. **系统责任**：模块、数据、接口与依赖边界，由 Architect 负责。
+3. **Intent 切片**：能够独立保护和验证的用户结果，由 Architect 负责。
+
+不要从技术目录直接推导 Intent，也不要让 Doctrine 文档变成模块清单。
+
+## 最小拆分法
+
+对候选切片逐一询问：
+
+- 它保护的用户结果能否独立描述。
+- 它是否有独立的完成契约。
+- 它失败时能否独立回流或回滚。
+- 它与其他切片的依赖是否单向且必要。
+- 合并后是否更简单，且不会模糊验证。
+
+只有前三项明确、依赖可解释时才创建独立 Intent。
+
+## 输出
+
+拆分结果只进入：
+
+- `02_ARCHITECTURE.md` 的系统责任与依赖说明。
+- `04_INTENT_MAP.json` 的 Intent DAG。
+
+它不进入 Project Doctrine，也不以“数量足够多”作为质量信号。

package/dimensions/SEARCH_METHODOLOGY.md

@@ -1,97 +1,101 @@
-# 哲学织造器检索方法论
-
-> Weaver 不是"背一个源列表去查"，是"掌握怎么找到优质思想的方法"。
-> 源会过时，方法不会。
-
----
-
-## 1. 先判断领域的形态
-
-不同领域的哲学存在形态不同，检索路径也不同。搜索前先判断这个维度属于哪种：
-
-| 形态 | 特征 | 哲学存在于哪里 | 检索入口 |
-|---|---|---|---|
-| 学术建制化 | 有专门期刊、学会、数据库 | 论文、专著、学术会议 | 学术数据库 |
-| 实践驱动 | 没有专门学科，思想从工程中沉淀 | 标准文档、工程博客、会议演讲、宣言 | 标准机构、公司工程博客、会议存档 |
-| 交叉融合 | 思想来自多个学科 | 分散在源学科中 | 先追溯到源学科，再按源学科形态检索 |
-
-判断方法：搜一次 `{领域名} philosophy`，看结果集中在哪——学术论文多就是学术建制化，博客和标准文档多就是实践驱动，跨多个学科就是交叉融合。
-
----
-
-## 2. 分层检索
-
-### 基础层（任何维度都查）
-
-- **斯坦福哲学百科全书（SEP）**、**PhilPapers** —— 查这个概念的哲学根基和学术脉络
-- 通用学术搜索 —— 查跨学科交叉点
-
-### 领域层（按形态走）
-
-- 学术建制化 → 该领域的专门数据库和期刊
-- 实践驱动 → 标准机构（IEEE / NIST / OWASP 等）、顶级公司工程博客、行业会议存档
-- 交叉融合 → 先识别源学科，再按源学科的路径检索
-
-### 动态层（思想迭代快的领域必须查）
-
-- 思想领袖的个人博客 / 平台专栏
-- 行业会议最新演讲
-- GitHub 上的宣言和 awesome list
-
----
-
-## 3. 源质量分级
-
-| 层级 | 类型 | 可信度 | 用法 |
-|---|---|---|---|
-| T1 | 同行评审学术（期刊、SEP 条目、学术专著） | 最高 | 直接引用 |
-| T2 | 专业组织标准（IEEE / NIST / OWASP 等发布的框架） | 高 | 直接引用 |
-| T3 | 关键人物原作（书籍、演讲、论文原文） | 高（一手） | 直接引用 |
-| T4 | 思想领袖博客 / 平台专栏 | 中（鲜活但可能未经验证） | 交叉验证后引用 |
-| T5 | 社区宣言 / awesome list | 低 | **只当入口**——从中发现 T1-T3 的源，不直接引用 T5 |
-
-### 分级不是绝对的——领域形态决定优先级
-
-源质量分级按"学术建制化"的标准设计，但不是所有领域都适用：
-
-- **学术建制化领域**（哲学、计算机科学理论、语言学）：T1/T2 优先，T3/T4 补充
-- **实践驱动领域**（游戏设计、UX 设计、DevOps、产品管理）：T3/T4 是主要源，T5 可当入口。这些领域的核心知识往往在 GDC 演讲、开发者博客、行业会议中，按学术标准会被划到 T4/T5，但它们是领域的一手知识
-- **交叉融合领域**（AI/ML 工程、数据工程）：混合取——理论部分按学术建制化走，工程实践部分按实践驱动走
-
-Weaver 在判断领域形态后，调整源的优先级。不要因为一个源是 T4 就降权——在实践驱动领域，T4 可能是最权威的源。
-
----
-
-## 4. 实体提取与关系追踪
-
-从任何源中提取四类实体：
-
-- **人物** —— 谁提出了这个思想
-- **著作** —— 这个思想在哪本书 / 哪篇论文里
-- **流派** —— 属于哪个学派 / 运动
-- **原则** —— 凝练成的可执行原则
-
-然后追踪关系，沿关系网扩展：
-
-- "A 继承了 B" → 顺藤摸到 B
-- "A 批判了 B" → 两边都看，理解张力
-- "A 和 C 同属 D 流派" → 找 D 流派的其他代表
-
-一个优质源会自然引出更多源。Weaver 不需要预先知道所有源——从几个种子源出发，沿关系网扩展。
-
----
-
-## 5. 交叉验证
-
-- 一个思想在**多个独立源**中出现 → 高可信，可纳入织造
-- 一个思想只在**一个人博客**里出现 → 找更多证据，不急于采纳
-- 一个思想**有争议** → 保留张力，记录双方立场，交给 DECISION_RUBRIC 定取舍
-
----
-
-## 6. 搜索纪律
-
-- **优先原始来源**：原著、作者本人博客、机构官方文档
-- **其次高质量二手解读**：权威书评、深度访谈、学术综述
-- **拒绝**：泛泛而谈、无出处、AI 生成内容、营销文案
-- **不发散**：每次搜索都有明确问题（"这个领域的核心信念是什么"），不是自由浏览
+# Decision-Relevant Research
+
+研究的目的不是展示看过多少资料，而是减少一个真实决定中的错误与平庸。
+
+## 触发条件
+
+满足任一条件才外部研究：
+
+- 当前事实不足以支持高影响或不可逆决定。
+- 任务需要专门领域知识、质量判断或安全边界。
+- 已有方案“合格但普通”，需要寻找不同机制。
+- 证据互相冲突，需要确定适用条件。
+
+低风险、可逆、项目内已有充分事实的决定可以直接实验。
+
+## 搜索回路
+
+```text
+Decision Question
+→ Project Grounding
+→ Targeted Search
+→ Extract Mechanism
+→ Translate to Project Consequence
+→ Test or Record
+```
+
+### 1. Decision Question
+
+把未知写成会改变行动的问题，例如：
+
+- 哪一种交互机制能让首次使用者更快建立正确心智模型？
+- 该库在当前数据规模下的失败边界是什么？
+- 什么信号能区分视觉新鲜感与长期可用性？
+
+“了解行业最佳实践”不是问题。
+
+### 2. Project Grounding
+
+先读真实仓库、用户反馈、现有产物、约束和历史决策。外部资料不能替代项目事实。
+
+### 3. Targeted Search
+
+选择与主张匹配的来源：
+
+- 协议、行为、接口 → 官方规范与实现文档。
+- 风险、效果、因果 → 原始研究、测量或真实案例。
+- 品味与作品质量 → 代表作品、设计批评、成熟实践者的可验证方法。
+- 当前工具能力 → 当前官方文档和真实运行结果。
+
+来源数量不设下限或配额。一个直接原始证据可以足够；多个间接来源也可能仍不够。
+
+### 4. Extract Mechanism
+
+不要只抄结论或名字，提取：
+
+- 在什么条件下成立。
+- 通过什么机制产生结果。
+- 可能在哪些条件下失败。
+- 它能否迁移到当前项目。
+
+### 5. Translate
+
+每条保留证据都要落成项目后果：
+
+```text
+Evidence → Mechanism → Project Decision → Verification Signal
+```
+
+无法改变决定、候选或验证方式的资料不进入正式上下文。
+
+### 6. Stop
+
+满足以下任一条件停止：
+
+- 新证据不再改变候选排序或边界。
+- 一个低成本实验比继续阅读更有信息量。
+- 已有证据足够支持可逆决定。
+- 不确定性只能由用户授权或真实反馈消除。
+
+## Evidence Map
+
+长期判断写入 Doctrine 的 Evidence Map；任务级专业资料进入临时 Expertise Pack；实现后的比较结果进入
+Quality Proof。三者不要互相复制成第二真相源。
+
+最低记录：
+
+- 来源或项目事实。
+- 为什么与当前问题相关。
+- 提取的机制或边界。
+- 它改变了什么决定。
+- 可追溯位置。
+
+## 失败模式
+
+- 固定凑来源数量。
+- 用权威名字代替适用性。
+- 先搜索后定义问题。
+- 把“大家都这样做”当证据。
+- 搜到熟悉答案就停止。
+- 把任务级技巧永久写入 Doctrine。
+- 只有结论，没有基线、反例或验证信号。

package/dimensions/examples/AGENT_SYSTEM/README.md

@@ -1,6 +1,6 @@
 # 参考案例：Agent 系统
 
-> 这份文件提供搜索起点和好实践样本。Weaver 按 PART_DECOMPOSITION.md 自行拆解，
+> 这份文件提供搜索起点和好实践样本。Weaver 只在相关 Doctrine 问题中使用，
 > 拆解出的部分和这里不同时，以 Weaver 的拆解为准。
 
 ---

package/dimensions/examples/CLI_TOOL/README.md

@@ -1,6 +1,6 @@
 # 参考案例：CLI 工具
 
-> 这份文件提供搜索起点和好实践样本。Weaver 按 PART_DECOMPOSITION.md 自行拆解，
+> 这份文件提供搜索起点和好实践样本。Weaver 只在相关 Doctrine 问题中使用，
 > 拆解出的部分和这里不同时，以 Weaver 的拆解为准。
 
 ---

package/dimensions/universal/COLLABORATION_PHILOSOPHY.md

@@ -1,77 +1,28 @@
-# 维度指引：协作哲学
-
-> 所有项目都需要。回答"怎么决策、怎么处理冲突、谁说了算"。
-> 产出融入 DECISION_RUBRIC.md 或独立文档。
-
----
-
-## 触发条件
-
-**必跑**——通用层三个维度之一，所有项目都激活。
-
----
-
-## 引导问题
-
-1. **谁做决策？** 单人决策？共识决策？权威决策？不同类型的决策（技术选型、接口变更、架构调整）分别由谁拍板？
-2. **冲突怎么处理？** 两个人对同一个设计有不同意见，怎么解决？投票？权威？数据驱动？
-3. **变更怎么管理？** 谁能发起变更？变更需要什么审批？变更的影响怎么评估？
-4. **代码审查的标准是什么？** 审查看什么——风格？逻辑？架构？安全？审查不通过怎么办？
-5. **文档和代码的关系？** 文档先行？代码先行？同步更新？文档过时了怎么办？
-
----
-
-## 参考源指引
-
-### 决策哲学
-
-- **Amazon"Disagree and Commit"** — Jeff Bezos 的股东信。搜 "Amazon disagree and commit"。核心：分歧可以，但定了就全力执行。
-- **Google"Design Docs"** — 搜 "Google design doc culture"。核心：设计先行、文档驱动决策、异议记录在文档里。
-- **RFC 文化** — Rust/IETF 的 RFC 流程。搜 "Rust RFC process"。核心：提案-评审-决策的显式流程。
-
-### 代码审查哲学
-
-- **Linux Kernel Review 文化** — Linus Torvalds 的 review 风格（有争议，批判性阅读）。搜 "Linux kernel code review philosophy"。
-- **Google Code Review Guidelines** — 搜 "Google code review guide"。核心：事实 > 偏好、 kindness + technical rigor。
-- **Conventional Comments** — https://conventionalcomments.org/。核心：评论带标签（praise/nitpick/question/issue）。
-
-### 冲突处理
-
-- **Crucial Conversations** — Patterson 等（2011）。核心：安全氛围、事实先行、共同目标。
-- **Nonviolent Communication (NVC)** — Marshall Rosenberg。核心：观察-感受-需要-请求。适用于团队冲突。
-
-### 文档哲学
-
-- **Docs as Code** — 搜 "docs as code philosophy"。核心：文档和代码同生命周期、同审查流程。
-- **The Bitter Lesson of Documentation** — 搜 "documentation bitter lesson"。核心：文档过时比没有文档更危险。
-
-### ADR（架构决策记录）
-
-- **Michael Nygard"Documenting Architecture Decisions"** — 原文：https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions。ADR 的原始定义。
-- **ADR GitHub Organization** — https://adr.github.io/。ADR 的变体和实践。
-
----
-
-## 落地要求
-
-织造出的协作哲学融入 DECISION_RUBRIC.md 或独立文档，必须包含：
-
-1. **决策权限矩阵**：哪些决策由谁做（单人/共识/权威）
-2. **冲突处理规则**：分歧升级路径、仲裁机制
-3. **变更管理流程**：变更发起、审批、影响评估
-4. **代码审查标准**：审查看什么、不通过怎么办
-5. **维度冲突取舍规则**：当产品哲学和工程哲学冲突时，谁优先？什么条件下可以覆盖？
-6. **灵感来源**：至少 2 个独立源，每个源说明"为什么选它"
-
-### DECISION_RUBRIC.md 的特殊要求
-
-- 维度冲突的取舍规则（如"性能 vs 体验冲突时，体验优先"）
-- 取舍规则的适用条件（什么时候规则生效）
-- 例外条件（什么时候规则可以被覆盖）
-- 覆盖规则需要什么（如"需要用户显式批准"）
-
-### 禁止
-
-- 禁止"共识决策"这种没有操作性的规则——必须说明"共识达不成怎么办"
-- 禁止冲突处理只有"讨论解决"——必须有升级路径和仲裁机制
-- 禁止维度冲突取舍规则没有例外条件——所有规则都应有可覆盖的场景
+# Doctrine Lens — Collaboration and Decision Rights
+
+> 按需使用。单人、低冲突项目不需要制造一套治理制度。
+
+## 触发
+
+- 多个角色或团队对同一决定拥有不同责任。
+- 重要分歧反复拖慢或破坏交付。
+- 变更需要明确授权、影响评估或审计。
+- 人类与 Agent 的决策边界不清晰。
+
+## 决策问题
+
+1. 哪类决定由谁负责，谁提供意见，谁最终批准？
+2. 事实分歧、价值分歧和授权分歧分别如何解决？
+3. 什么变更需要影响评估，什么可以直接可逆实验？
+4. 何时必须升级给人类，何时 Agent 应自主推进？
+5. 哪些协作行为会制造虚假共识、责任漂移或文档表演？
+
+## 输出标准
+
+- 只覆盖真实存在的决策类型。
+- 权限与升级条件清楚。
+- 评审标准关注结果、契约和风险，不管理个人风格。
+- 规则包含例外和退出条件。
+- Evidence Map 记录导致规则产生的真实冲突或外部依据。
+
+协作 Doctrine 不复制角色提示词；角色权限由 LOOM System Boundary 管理。