@haaaiawd/loom 0.9.0 → 1.0.0

package/dimensions/universal/ENGINEERING_CREED.md

@@ -1,74 +1,30 @@
-# 维度指引：工程哲学
-
-> 所有项目都需要。回答"怎么写代码、什么不做、什么是好代码"。
-
----
-
-## 触发条件
-
-**必跑**——通用层三个维度之一，所有项目都激活。
-
----
-
-## 引导问题
-
-1. **什么是好代码？** 不是"能跑的代码"，是"五年后的人能看懂的代码"。具体到这个项目，好代码的标准是什么？
-2. **数据流是怎样的？** 单向还是双向？有状态还是无状态？纯函数还是有副作用？为什么这样选？
-3. **错误怎么处理？** 静默吞错？抛异常？返回错误码？透传？每种错误类型的处理策略是什么？
-4. **依赖策略是什么？** 零依赖？最小依赖？依赖什么、不依赖什么、为什么？
-5. **抽象到什么程度？** YAGNI 还是预留扩展？什么时候加抽象，什么时候不加？
-6. **测试策略是什么？** 单元测试？集成测试？契约测试？测什么、不测什么、为什么？
-
----
-
-## 参考源指引
-
-### 通用工程哲学
-
-- **Clean Code** — Robert C. Martin（2008）。核心：函数短小、单一职责、命名清晰。但注意：Martin 的某些主张有争议（函数不超过 20 行等），需要批判性阅读。
-- **The Pragmatic Programmer** — Andy Hunt & Dave Thomas（1999/2019 修订）。核心：DRY、正交性、曳光弹、契约式设计。比 Clean Code 更务实。
-- **A Philosophy of Software Design** — John Ousterhout（2018）。核心：深模块 vs 浅模块、接口设计、复杂度管理。Ousterhout 和 Martin 在"函数大小"上有分歧——对比阅读。
-- **SICP** — Abelson & Sussman（MIT 经典）。核心：抽象、组合、元语言抽象。理论根基。
-
-### 函数式编程哲学
-
-- **Structure and Interpretation of Computer Programs** — 见上。
-- **Pure Function-based Architecture** — 搜 "pure function architecture"。核心：纯函数 + 不可变数据 + 副作用隔离。
-- **Haskell 设计哲学** — 搜 "Haskell philosophy pure functional"。核心：纯函数、惰性求值、类型系统。
-
-### 系统设计哲学
-
-- **A Philosophy of Software Design** — 见上（深模块部分）。
-- **Designing Data-Intensive Applications** — Martin Kleppmann（2017）。核心：数据流、一致性、容错。
-- **The Twelve-Factor App** — https://12factor.net/。核心：配置外置、无状态进程、一次性。
-
-### 错误处理哲学
-
-- **Joel Spolsky"Exceptions vs Error Codes"** — 搜 "Joel Spolsky exceptions"。经典争论。
-- **Go 的 error-as-value 哲学** — 搜 "Go error handling philosophy"。核心：错误是值，不是控制流。
-- **Rust 的 Result/Option** — 搜 "Rust error handling philosophy"。核心：类型系统强制错误处理。
-
-### 测试哲学
-
-- **TDD** — Kent Beck *Test-Driven Development*（2002）。核心：红-绿-重构。
-- **Property-based Testing** — 搜 "property based testing philosophy"。核心：测不变量，不测具体案例。
-- **The Way of Testivus** — 搜 "testivus testing philosophy"。核心：测试够用就好，不要过度。
-
----
-
-## 落地要求
-
-织造出的 ENGINEERING_CREED.md 必须包含：
-
-1. **工程北极星**：一句话，工程层面的判断基准
-2. **代码原则**：编号（E1, E2...），每条有理由
-3. **工程反模式清单**：编号（EAP1, EAP2...），每条有"不做"和"为什么"
-4. **灵感来源**：至少 2 个独立源，每个源说明"为什么选它"
-5. **底线内化声明**：与 PRODUCT_PHILOSOPHY.md 一致
-6. **章节锚点**：每个章节有 `{#english-anchor}` 标识
-
-### 禁止
-
-- 禁止照搬 Clean Code 的条目不加工——必须转译为本项目的具体约束
-- 禁止"好代码是可读的"这种废话——必须具体到"什么场景下可读性优先于性能"
-- 禁止抽象层和产品层重复——工程哲学聚焦"怎么写"，产品哲学聚焦"为什么存在"
+# Doctrine Lens — Engineering Judgment
+
+> 按需使用。它只记录跨多个 Intent 的工程判断，不把常识和局部技术选择永久化。
+
+## 触发
+
+- 多个系统部分需要共享同一数据、错误、依赖或兼容策略。
+- 某类工程失败反复发生，已成为项目级风险。
+- 一个长期取舍会持续影响架构和实现。
+
+如果问题只属于当前技术栈、某个模块或一次实现，让 Architect 定义边界，Forge 在 Expertise Pack 中
+加载相应专业方法。
+
+## 决策问题
+
+1. 项目最需要控制的复杂度来自哪里？
+2. 哪些契约必须显式，哪些实现细节应保持局部？
+3. 错误、降级和恢复应保护什么用户或系统结果？
+4. 何时引入依赖或抽象，什么证据说明它值得？
+5. 哪些工程反模式会让短期速度转化为长期失控？
+
+## 输出标准
+
+- 工程北极星。
+- 少量带触发条件的判断原则。
+- 反模式与可观察失败信号。
+- 允许实验与必须审慎的边界。
+- 决策相关 Evidence Map。
+
+不要规定函数长度、目录风格、测试比例等通用教条；除非它们由项目证据支持且会反复改变决定。

package/dimensions/universal/PRODUCT_PHILOSOPHY.md

@@ -1,70 +1,32 @@
-# 维度指引：产品哲学
-
-> 所有项目都需要。回答"这个产品为什么存在、北极星是什么、什么不能妥协"。
-
----
-
-## 触发条件
-
-**必跑**——通用层三个维度之一，所有项目都激活。
-
----
-
-## 引导问题
-
-织造时依次回答：
-
-1. **这个产品为什么存在？** 不是"它能做什么"，是"如果没有它会怎样"。如果答案是"用户会用别的工具"，那这个产品没有存在理由。
-2. **北极星是什么？** 一句话。不是愿景陈述，是判断基准——遇到冲突时，拿这句话量一下。
-3. **什么不能妥协？** 3-5 条。不是"想要"的，是"没有就不行"的。每条必须有理由——为什么这条不能妥协，妥协了会怎样。
-4. **反模式是什么？** 和"做什么"同样重要。每个反模式必须说明"不做"和"为什么不做"。
-5. **决策原则是什么？** 当价值冲突时怎么取舍。不是口号，是可执行的判断规则。
-
----
-
-## 参考源指引
-
-### 实践驱动领域（CLI 工具、开发者工具、基础设施）
-
-- **Unix Philosophy** — Doug McIlroy, 1978。原著：*The UNIX Time-Sharing System*（论文）。延伸：Eric Raymond *The Art of UNIX Programming*（2003）、Mike Gancarz *The UNIX Philosophy*（1995）。不要只引 Wikipedia——读 Raymond 的书，里面有 17 条具体原则。
-- **Plan 9 设计原则** — Rob Pike, Ken Thompson。和 Unix Philosophy 有继承也有分歧（"一切皆文件"走得更远）。对比阅读能产生张力。
-- **Dieter Rams"好设计十诫"** — 原文在 Vitsoe 官网（https://www.vitsoe.com/eu/about/good-design），不是 Wikipedia 摘要。
-- **Stripe API 设计哲学** — Stripe 工程博客。搜 "Stripe API design philosophy"。核心：API 是产品契约、一致性 > 灵活性。
-- **Jeff Atwood / Joel Spolsky 的工具哲学** — Stack Overflow / Fog Creek 创始人。搜 "Joel Spolsky software philosophy"。
-
-### 2C 产品领域（面向终端用户）
-
-- **Steve Jobs 产品哲学** — 原著：Walter Isaacson *Steve Jobs*（2011）。核心：减法优先、体验 > 功能。
-- **John Maeda"减法法则"** — *The Laws of Simplicity*（2006）。MIT Press 出版。
-- **Don Norman"以用户为中心的设计"** — *The Design of Everyday Things*（1988/2013 修订版）。
-
-### 2B / 平台领域
-
-- **Amazon Working Backwards** — 搜 "Amazon working backwards document"。核心：从 PR/FAQ 倒推技术方案。
-- **Google Design Docs** — 搜 "Google design doc template"。核心：设计先行、文档驱动。
-
-### 学术建制化领域（如果有理论根基需求）
-
-- **SEP"Philosophy of Technology"** — 斯坦福哲学百科全书条目。搜 "SEP philosophy of technology"。
-- **Hubert Dreyfus** — *What Computers Still Can't Do*（技术哲学视角）。
-
----
-
-## 落地要求
-
-织造出的 PRODUCT_PHILOSOPHY.md 必须包含：
-
-1. **北极星**：一句话，可被 Intent 的 `philosophy_anchors` 引用
-2. **不可妥协的价值**：3-5 条，每条有理由
-3. **反模式清单**：编号（AP1, AP2...），每条有"不做"和"为什么"
-4. **决策原则**：编号（P1, P2...），每条有适用条件和判断标准
-5. **灵感来源**：至少 3 个独立源，至少 2 个非 Wikipedia 链接，每个源说明"为什么选它"
-6. **底线内化声明**：显式声明已内化 BASELINE
-7. **章节锚点**：每个章节有 `{#english-anchor}` 标识
-
-### 禁止
-
-- 禁止只有 Wikipedia 链接——Wikipedia 是常识入口，不是深度源
-- 禁止"灵感来源"只有名字没有理由——必须说明萃取/转译关系
-- 禁止北极星是口号（如"做最好的工具"）——必须是判断基准
-- 禁止反模式没有"为什么"——"不做"和"为什么不做"同样重要
+# Doctrine Lens — Product Judgment
+
+> 按需使用。只有判断会跨多个 Intent 反复生效时，才写入 Project Doctrine。
+
+## 触发
+
+- 项目需要长期保护的用户结果尚不清楚。
+- 多个功能之间存在价值冲突。
+- 团队对“合格”和“优秀”的产品结果没有共同判断。
+- 反复出现表面完成、实际伤害用户结果的方案。
+
+单个页面、一次功能或局部体验技巧留给当前 Intent 的 Expertise Pack。
+
+## 决策问题
+
+1. 项目长期保护的用户结果是什么，什么证据表明它重要？
+2. 当速度、控制、清晰、灵活性等价值冲突时如何取舍？
+3. 什么可观察信号区分普通、可靠和出众？
+4. 哪些反模式会让产品看似完成，却破坏用户结果？
+5. 哪些方向允许大胆且可逆的探索，哪些边界不能改变？
+
+## 输出标准
+
+只保留能够改变未来行动的内容：
+
+- 一句可用于取舍的北极星。
+- 少量带适用条件和例外的原则。
+- 卓越标准与失败信号。
+- 创作空间。
+- Evidence Map：事实或来源 → 机制 → 项目后果。
+
+不设置原则或来源数量，不复述 BASELINE，不预写功能和架构。

package/meta/BASELINE.md

@@ -1,276 +1,91 @@
-# BASELINE — LOOM 不可妥协的底线
-
-> **"哲学可以自由织造，底线不可协商。"**
->
-> 这份文件列出 LOOM 系统中所有角色、所有哲学文档、所有项目都必须遵守的底线。
-> Philosophy Weaver 织造的哲学必须内化这些底线——它们不是建议，是地基。
-> 任何角色在任何阶段违反底线，必须立即停止。
-
----
-
-## 底线的性质
-
-底线不是"最佳实践"，不是"推荐做法"。
-
-底线是**不可妥协的约束**——违反它们会导致系统不可维护、不可理解、不可信任。
-
-哲学文档可以自由决定"怎么做好"，但底线决定"什么不能不做"。
-
----
-
-## 底线清单
-
-### B1：必须有结构设计
-
-**约束**：任何项目在编码之前，必须有明确的结构设计。
-
-**为什么**：没有结构设计的编码是盲人摸象。Agent 会把代码堆成一团浆糊，后续无法维护、无法理解、无法扩展。
-
-**最低要求**：
-- 项目有明确的目录结构
-- 每个模块/系统有定义的职责边界
-- 模块之间的依赖关系是显式的，不是隐式的
-- 结构设计是写下来的，不是停留在"脑子里"
-
-**哲学内化方式**：Philosophy Weaver 织造工程哲学时，必须包含"结构设计是编码前提"这一条。具体设计多详细、用什么格式，由哲学决定。
-
-**粒度自由**：
-- 小项目：一个文件说清楚结构就够
-- 大项目：需要完整的架构文档 + 系统设计文档
-- 粒度由 Philosophy Weaver 根据项目规模决定
-
----
-
-### B2：禁止硬编码
-
-**约束**：禁止在代码中硬编码密钥、配置、环境特定值、魔法数字。
-
-**为什么**：硬编码是技术债的源头。它让代码不可移植、不可测试、不可维护。弱模型尤其容易犯这个错误——给它们自由度，它们会把所有东西写死。
-
-**最低要求**：
-- 密钥、凭证：环境变量或集中配置模块，绝不进代码
-- 环境特定值（URL、端口、路径）：配置层管理
-- 魔法数字：命名常量，附注释说明来源
-- 业务规则常量：集中管理，不散落在代码各处
-
-**哲学内化方式**：Philosophy Weaver 织造工程哲学时，必须包含"配置与代码分离"原则。具体分离方式由哲学决定（环境变量 / 配置文件 / 配置中心）。
-
-**例外**：
-- 纯算法常量（如数学公式中的系数）且其含义在代码中有清晰注释
-- 框架约定的常量（如 HTTP 状态码）且使用语义化命名
-
----
-
-### B3：接口契约必须显式
-
-**约束**：任何对外可观察的接口——API、CLI 参数、配置结构、文件格式、错误语义、跨系统协议——必须有显式定义。
-
-**为什么**：隐式契约是混乱之源。当接口没有显式定义时，每个调用方都会对接口有自己的理解，导致集成时出现不可预测的冲突。
-
-**最低要求**：
-- API：有参数定义、返回结构、错误码定义
-- CLI：有参数语义、选项定义、退出码定义
-- 配置：有字段定义、类型、默认值、取值范围
-- 跨系统协议：有消息格式、时序约束、错误处理约定
-- 契约变更：必须可追溯（记录在决策日志中）
-
-**哲学内化方式**：Philosophy Weaver 织造工程哲学时，必须包含"接口契约是承诺"原则。具体契约格式由哲学决定（OpenAPI / JSON Schema / TypeScript 类型 / 自定义文档）。
-
----
-
-### B4：决策必须可追溯
-
-**约束**：任何影响架构、接口、技术栈、依赖的决策，必须记录下来，且记录可被后续引用。
-
-**为什么**：不可追溯的决策是"为什么这么做"的黑洞。三个月后没人记得为什么选了这个技术、为什么这个接口长这样。Agent 重新加载上下文时，只能看到"做了什么"，看不到"为什么做"。
-
-**最低要求**：
-- 决策记录包含：决策内容、背景、候选方案、取舍理由、影响范围
-- 决策记录是写下来的，不是停留在"聊天记忆"里
-- 决策记录有稳定标识，可被其他文档引用
-- 决策变更时，旧记录保留，新记录说明"为什么变了"
-
-**哲学内化方式**：Philosophy Weaver 织造协作哲学时，必须包含"决策是组织记忆"原则。具体记录格式由哲学决定（ADR / 决策日志 / Git commit message）。
-
----
-
-### B5：意图必须可回溯
-
-**约束**：任何实现都必须能回溯到它的原始意图——"为什么存在"。
-
-**为什么**：这是 LOOM 的核心命题。信息在传递链中会损失——从产品意图到系统设计到任务到代码，每一层翻译都可能扭曲原始意思。如果实现不能回溯到意图，就无法验证"是否忠实于原始目标"。
-
-**最低要求**：
-- 每个实现单元（Intent / 功能模块）有意图叙事——"为什么存在，服务什么目标"
-- 意图叙事不是"做什么"的描述，是"为什么做"的叙事
-- 意图叙事可被验证角色（Keeper）引用和对照
-- 意图叙事在传递链中不丢失——从愿景到实现，每个环节都能追溯到原始意图
-
-**哲学内化方式**：这条底线是 LOOM 的灵魂，Philosophy Weaver 织造产品哲学时必须包含"意图是实现的灵魂"原则。具体叙事格式由哲学决定。
-
----
-
-## 底线与哲学的关系
-
-```
-底线（这份文件）        哲学（Weaver 织造）
-  ↓                      ↓
-"什么不能不做"    +    "怎么做好"
-  ↓                      ↓
-  └─────────┬────────────┘
-            ↓
-       角色内化
-            ↓
-       角色行动
-```
-
-底线划出边界，哲学填充边界内的内容。角色在边界内自主发挥，越界被拦截。
-
-**底线不可被哲学覆盖**。如果 Philosophy Weaver 织造的哲学与底线冲突，底线优先。Weaver 在织造时必须将底线作为硬约束输入。
-
----
-
-## 底线的演进
-
-底线不是永恒不变的。随着 LOOM 系统的演进，底线可能需要调整。
-
-但底线的变更必须：
-- 有明确的变更理由
-- 记录在版本历史中
-- 经过审慎评估——底线变更是系统级决策，不是随手调整
-
-底线变更跟随 LOOM 的版本（v{N}），与哲学演进机制一致。
-
----
-
-## 适配与扩展
-
-BASELINE 的 5 条底线是通用约束，适用于所有项目。但不同领域、不同规模的项目对底线的理解和执行方式不同。以下机制让 BASELINE 在保持不可妥协的同时适配现实。
-
-### 底线澄清
-
-底线约束本身不变，但"怎么算合规"在不同领域有不同理解。以下澄清不改变约束，只明确适用边界：
-
-**B1 澄清：原型验证阶段**
-
-对于需要验证核心可行性的项目（如游戏核心玩法、AI 模型效果），允许先做可运行原型。原型是结构设计的一部分，不是"跳过设计的编码"——原型验证通过后，必须补结构设计文档再进入正式 Intent Loop。
-
-**B3 澄清：非确定性系统**
-
-接口契约定义输入输出的**结构边界和约束条件**（schema、长度限制、字段必填、错误码），不要求内容本身确定性。LLM 的输出每次不同，但输出结构可以契约化（如"返回 `{answer: string, sources: Source[]}`，answer 长度 1-500 字，sources 非空"）。
-
-### 项目特定底线
-
-BASELINE 的 5 条是通用底线，适用于所有项目。但不同领域有额外的"不可妥协"——2B 需要安全合规、AI/ML 需要模型版本管理、医疗需要隐私保护。
-
-Philosophy Weaver 织造哲学时，可以产出 `PROJECT_BASELINE.md`，声明项目特定底线。
-
-**规则**：
-- 项目特定底线和 BASELINE 一样不可妥协——角色激活时和 BASELINE 一起强制加载
-- 项目特定底线只能**追加**，不能**豁免**通用底线
-- 项目特定底线必须有明确的"合规/违规"判定标准（和通用底线一样可被 Keeper 验证）
-- 项目特定底线跟随版本演进，变更时记录理由
-
-**角色激活时加载的底线** = `meta/BASELINE.md`（通用 5 条）+ `.loom/v{N}/00_PHILOSOPHY/PROJECT_BASELINE.md`（项目特定，如果有）
-
-### 流程复杂度
-
-LOOM 是元规范，不是固定流程。Agent 根据项目规模自主调整复杂度：
-
-| 项目规模 | 哲学维度 | Intent 粒度 | 验证层级 |
-|---|---|---|---|
-| 小项目（< 1 个月） | 只通用层（产品 + 工程） | 粗粒度（3-5 个 Intent） | 全用 L1 静态审查 |
-| 中项目（1-3 个月） | 通用层 + 1-2 个领域层 | 中粒度（5-15 个 Intent） | 关键 Intent 用 L2 |
-| 大项目（3+ 个月） | 所有需要的维度 | 细粒度（15+ 个 Intent） | 关键 Intent 用 L2/L3 |
-| 维护期 | 沿用已有哲学 | 直接加 bug 修复 Intent | L1 为主 |
-
-这不是规则，是参考。Agent 自主判断，不按这个分级也行。核心原则是：**文档开销不应超过开发开销**。
-
----
-
-## 版本演进
-
-LOOM 用 `.loom/v{N}/` 目录支持多版本共存与演进。
-
-### 版本指针
-
-- `.loom/current` 文件记录当前版本号（如 `v1`）
-- CLI 优先读指针；指针缺失时回退到自动探测最新版本（向后兼容）
-- `loom version list` 列出所有版本并标记当前
-- `loom version use <v>` 切换当前版本
-
-### 旧版本只读
-
-**旧版本是只读的——最新版本（current 指针指向的）是当前真相。**
-
-- 角色激活时只加载当前版本
-- CLI 写操作（intent update、verify write）只作用于当前版本
-- 旧版本保留作为历史参考，不修改
-
-### 演进分级
-
-变更分两级，判定由用户 + Agent 对话完成，CLI 不做决策：
-
-| 级别 | 判定标准 | 处理方式 |
-|---|---|---|
-| **Minor** | 不改哲学前提、不改愿景北极星、不改架构边界 | 当前版本内改（LOOM 已有的变更回流机制） |
-| **Major** | 哲学前提变了、愿景北极星变了、架构边界变了 | 创建新版本 |
-
-### Major 升级流程
-
-```
-[Agent / 用户判断需要 Major 升级]
-  ↓
-loom version new              → 创建 v{N+1}（空目录 + 模板），自动切换为当前
-  ↓
-loom version diff v{N} v{N+1} → 看看旧版本有什么（Agent 决定参考什么）
-  ↓
-Weaver  读 .loom/v{N}/00_PHILOSOPHY/ → 织造 v{N+1} 哲学，记录"相对 v{N} 变了什么"
-  ↓
-Visionary 读 .loom/v{N}/01_VISION.md → 定义 v{N+1} 愿景
-  ↓
-Architect 读 .loom/v{N}/02_ARCHITECTURE.md + 04_INTENT_MAP.json → 设计 v{N+1}
-  ↓
-进入 v{N+1} 的 Intent Loop
-```
-
-**关键设计**：`loom version new` 创建空目录 + 模板，**不自动复制旧版本内容**。强制 Agent 重新思考——参考 ≠ 复制。如果直接复制 v1 哲学到 v2，Agent 可能懒得重织造，版本演进就变成"在旧版本上打补丁"了。
-
-### 代码迁移
-
-v1 已完成的代码保留在项目代码库中。v2 的 Intent Map 引用已有代码时：
-- 如果代码仍适用 → Intent 状态直接设为 `completed`，验收契约引用已有代码
-- 如果代码需要调整 → 新建 Intent，depends_on 可以引用 v1 的 Intent ID（通过 `loom intent trace` 追溯历史）
-
-### Intent ID 延续
-
-v2 的 Intent ID **重新编号**（INT-001, INT-002...），不延续 v1。原因：
-- v2 的 Intent 语义可能和 v1 不同，延续 ID 会造成混淆
-- 追溯通过 Git history 和 `loom version diff` 完成，不靠 ID 延续
-
-### 版本对比
-
-- `loom version diff <v1> <v2>` 对比文件存在性和大小差异
-- 内容差异用 Git diff（`.loom/` 纳入版本控制）
-
-### 不做的
-
-- CLI 不判断 Minor/Major（决策由 Agent + 用户对话完成）
-- CLI 不自动复制旧版本内容到新版本（强制重新思考）
-- CLI 不强制旧版本只读（规范声明 + Git 保护，不靠代码强制）
-- CLI 不迁移验证记录（v2 的 Intent 是新 ID，v1 验证记录通过 Git history 追溯）
-
----
-
-## 给 Philosophy Weaver 的指令
-
-当 Philosophy Weaver 开始织造哲学时，这份文件是它的**硬约束输入**。
-
-Weaver 必须：
-1. 读取这份文件，理解每条底线
-2. 在织造哲学时，将底线转译为哲学语言——不是照抄，而是融入哲学叙事
-3. 确保织造出的哲学文档不与任何底线冲突
-4. 在哲学文档中显式声明"已内化 BASELINE 中的所有底线"
-5. 如果项目有领域特定的"不可妥协"（如安全合规、隐私保护、模型版本管理），产出 `PROJECT_BASELINE.md` 声明项目特定底线
-
-如果 Weaver 无法将某条底线融入哲学（例如哲学流派与底线矛盾），必须停止并报告——这意味着该哲学流派不适合这个项目。
+# 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、必要设计、自动验证。
+- 高风险系统：完整边界、决策记录、多层验证与回滚方案。
+
+当两条规则冲突时，优先保护真实用户结果、系统完整性和可恢复性；不要为了“流程正确”牺牲交付本身。