@haaaiawd/loom 0.7.0 → 0.8.0

package/dimensions/universal/COLLABORATION_PHILOSOPHY.md

@@ -0,0 +1,77 @@
+# 维度指引：协作哲学
+
+> 所有项目都需要。回答"怎么决策、怎么处理冲突、谁说了算"。
+> 产出融入 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 体验冲突时，体验优先"）
+- 取舍规则的适用条件（什么时候规则生效）
+- 例外条件（什么时候规则可以被覆盖）
+- 覆盖规则需要什么（如"需要用户显式批准"）
+
+### 禁止
+
+- 禁止"共识决策"这种没有操作性的规则——必须说明"共识达不成怎么办"
+- 禁止冲突处理只有"讨论解决"——必须有升级路径和仲裁机制
+- 禁止维度冲突取舍规则没有例外条件——所有规则都应有可覆盖的场景

package/dimensions/universal/ENGINEERING_CREED.md

@@ -0,0 +1,74 @@
+# 维度指引：工程哲学
+
+> 所有项目都需要。回答"怎么写代码、什么不做、什么是好代码"。
+
+---
+
+## 触发条件
+
+**必跑**——通用层三个维度之一，所有项目都激活。
+
+---
+
+## 引导问题
+
+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 的条目不加工——必须转译为本项目的具体约束
+- 禁止"好代码是可读的"这种废话——必须具体到"什么场景下可读性优先于性能"
+- 禁止抽象层和产品层重复——工程哲学聚焦"怎么写"，产品哲学聚焦"为什么存在"

package/dimensions/universal/PRODUCT_PHILOSOPHY.md

@@ -0,0 +1,70 @@
+# 维度指引：产品哲学
+
+> 所有项目都需要。回答"这个产品为什么存在、北极星是什么、什么不能妥协"。
+
+---
+
+## 触发条件
+
+**必跑**——通用层三个维度之一，所有项目都激活。
+
+---
+
+## 引导问题
+
+织造时依次回答：
+
+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 是常识入口，不是深度源
+- 禁止"灵感来源"只有名字没有理由——必须说明萃取/转译关系
+- 禁止北极星是口号（如"做最好的工具"）——必须是判断基准
+- 禁止反模式没有"为什么"——"不做"和"为什么不做"同样重要

package/meta/PHILOSOPHY_WEAVER.md

@@ -50,13 +50,28 @@ Philosophy Weaver 是一个**独立的 Agent 步骤**，在项目启动时运行
 
 Weaver 自己决定要产出几个文档、多详细——这取决于项目特征。
 
+### 灵感来源的硬约束
+
+哲学文档的"灵感来源"章节不是装饰——它是搜索过程的证据。CLI 会校验灵感来源质量（`loom philosophy check`）：
+
+1. **至少 3 个独立源**——少于 3 个说明搜索不充分
+2. **至少 2 个非 Wikipedia 链接**——Wikipedia 是常识入口，不是深度源。需要原著、论文、工程博客、标准文档等
+3. **每个源必须有选取理由**——必须说明"为什么选这个源"、萃取/转译关系
+4. **源类型不能单一**——Wikipedia 占比超过 70% 会报警
+
+**如果 Agent 从训练数据"背"几个熟悉的名字（如 Unix Philosophy、Dieter Rams）就交差，校验会失败。** 必须真正走搜索漏斗，找到原著、深度解读、实践案例。
+
+`loom doctor` 也会自动跑灵感来源校验——不达标的哲学文档会被标记为问题。
+
 ---
 
-## 哲学维度分层
+## 哲学织造的两个轴
+
+Weaver 从两个正交的轴织造哲学：
 
-Weaver 从三个层次织造哲学。不是所有层次都需要——按项目特征激活。
+### 轴一：通用层（回答"为什么"）
 
-### 第一层：通用层（所有项目都需要）
+所有项目都需要。回答产品为什么存在、代码怎么写、团队怎么协作。
 
 | 维度 | 回答什么 | 必须产出 |
 |---|---|---|
@@ -64,40 +79,66 @@ Weaver 从三个层次织造哲学。不是所有层次都需要——按项目
 | 工程哲学 | 怎么写代码？什么不做？什么是好代码？ | ENGINEERING_CREED.md |
 | 协作哲学 | 怎么决策？怎么处理冲突？ | 融入 DECISION_RUBRIC.md 或独立文档 |
 
-### 第二层：领域层（按项目特征激活）
+通用层三个维度必跑，不可跳过。参考源指引见 `dimensions/universal/` 下的维度文件。
 
-| 维度 | 触发条件 | 产出（按需） |
-|---|---|---|
-| 前端/UX 哲学 | 项目有用户界面 | UX_PHILOSOPHY.md |
-| 游戏设计哲学 | 项目是游戏 | GAME_DESIGN_PHILOSOPHY.md |
-| 后端/基础设施哲学 | 项目是后端/平台 | BACKEND_PHILOSOPHY.md |
-| AI/ML 哲学 | 项目涉及 AI/ML | AI_PHILOSOPHY.md |
+### 轴二：实现部分层（回答"怎么做"）
 
-**子触发**：领域层内部还有子触发。例如前端/UX 哲学内部，如果项目涉及 3D，激活 3D/沉浸式子维度。
+按项目特征**动态拆解**——不预设"有哪些部分"，由 Agent 根据项目特征自行识别。
 
-### 第三层：交叉层（跨领域，按需）
+**拆解方法论**：见 `dimensions/PART_DECOMPOSITION.md`。核心流程：
 
-| 维度 | 触发条件 | 产出 |
-|---|---|---|
-| 体验心理学 | 面向终端用户 | 融入 UX_PHILOSOPHY 或独立 |
-| 性能哲学 | 性能敏感 | PERFORMANCE_PHILOSOPHY.md 或融入工程哲学 |
-| 安全哲学 | 涉及敏感数据/系统 | SECURITY_PHILOSOPHY.md 或融入工程哲学 |
-| 商业/增长哲学 | 2C 需要增长 | GROWTH_PHILOSOPHY.md 或融入产品哲学 |
+1. **识别项目类型**（CLI 工具 / Agent 系统 / Web 前端 / 后端服务 / 游戏 / ...）
+2. **拆解实现部分**——问三个问题：
+   - 用户接触面是什么？（CLI 输出 / 对话格式 / 页面交互 / ...）
+   - 内部由哪些子系统组成？（转换引擎 / 工具调度 / 路由 / ...）
+   - 每个子系统的职责边界在哪？
+3. **对每个部分独立走搜索漏斗**——搜"这个部分该怎么做、什么标准、有什么好实践"
+4. **产出部分哲学文档**——每个部分有北极星、该做什么、不该做什么、参考实践
 
-### 维度激活规则
+**拆解原则**：
+- 按职责拆，不按文件拆
+- 粒度适中——太粗没有约束力，太细是架构不是哲学
+- 用户接触面优先——用户能看到的部分，哲学约束最重要
+- 每个部分能独立搜索到好实践
 
-**Weaver 自动判断**激活哪些维度，基于项目特征。用户在检查点确认或调整。
+**拆解示例**：
 
-Weaver 判断逻辑：
-1. 读取项目特征
-2. 扫描 `dimensions/` 目录，读取每个维度文件的触发条件
-3. 对照触发条件，列出建议激活的维度
-4. 展示给用户确认
-5. 用户可同意、可拒绝、可补充
+CLI 工具（如 md2html）：
+```
+├── CLI 交互设计 — 参数解析、--help、--version、用法提示
+├── CLI 输出美学 — 成功反馈格式、颜色策略、Rule of Silence 的正确理解
+├── CLI 错误呈现 — 错误结构、修复建议、退出码语义
+├── 转换引擎 — 纯函数、子集策略、透传 vs 报错
+└── 产物设计 — HTML 结构、CSS 内联、可预测性
+```
 
-**维度库结构**：`dimensions/` 目录下按分层组织——通用层、领域层、交叉层各一个子目录，每个维度一个 MD 文件。每个维度文件必须包含：触发条件、引导问题、参考源指引、落地要求。Weaver 扫描目录结构获取维度清单，读取每个文件的触发条件判断是否激活。
+Agent 系统：
+```
+├── 系统架构 — 编排 vs 控制、进程边界、IPC 机制
+├── 工具调用哲学 — 委托边界、失控收回、工具描述怎么写
+├── 上下文压缩 — 什么时候压缩、压缩什么、保留什么
+├── 提示词工程 — 角色激活、约束注入、上下文窗口管理
+├── 验证哲学 — 怎么信、怎么验、自动化 vs 人类
+└── 失败与恢复 — 崩溃恢复、状态一致性、回滚策略
+```
+
+### 两轴的关系
+
+- 通用层是地基——没有产品哲学，实现部分的哲学就没有判断基准
+- 实现部分层是落地——没有部分哲学，通用层就飘在空中，Forge 实现时不知道该对照什么
+- 两层正交，都需要
 
-如果 `dimensions/` 下没有对应维度文件，Weaver 按"织造漏斗"（搜索→萃取→转译→落地）自主走——维度表告诉你"有哪些维度可激活"，织造漏斗告诉你"怎么织造"。维度文件只是给 Weaver 特定领域的额外指引，不是织造的前提。
+### 交叉维度（按需，跨部分）
+
+某些维度不属于单个实现部分，而是跨多个部分：
+
+| 维度 | 触发条件 | 产出 |
+|---|---|---|
+| 性能哲学 | 性能敏感 | 融入相关部分哲学或独立文档 |
+| 安全哲学 | 涉及敏感数据/系统 | 融入相关部分哲学或独立文档 |
+| 体验心理学 | 面向终端用户 | 融入用户接触面部分哲学 |
+
+交叉维度不单独成层——它们融入相关的实现部分哲学中。
 
 ---
 
@@ -201,29 +242,33 @@ Step 0：内化 BASELINE
   → 底线是织造的硬约束
 
 Step 1：项目特征识别
-  → 识别项目类型（2C/2B/工具/平台/游戏/基础设施）
+  → 识别项目类型（CLI 工具 / Agent 系统 / Web 前端 / 后端服务 / 游戏 / ...）
   → 识别规模（小/中/大）
-  → 识别领域（前端/后端/AI/数据/...）
   → 识别核心价值（这个产品为什么要存在）
 
-Step 2：维度激活
-  → 对照维度库，判断激活哪些哲学维度
-  → 展示建议激活的维度，用户确认或调整
-  → 通用层三个维度必跑
-  → 领域层和交叉层按触发条件激活
-
-Step 3：逐维度织造
-  → 对每个激活的维度，走"搜索→萃取→转译→落地"漏斗
-  → 通用层先织造（产品→工程→协作）
-  → 领域层后织造
-  → 交叉层最后
-
-Step 4：整合与冲突解决
-  → 检查维度间冲突（如性能哲学 vs 体验哲学）
+Step 2：实现部分拆解
+  → 按 dimensions/PART_DECOMPOSITION.md 的方法论拆解
+  → 问三个问题：用户接触面是什么？内部由哪些子系统组成？每个子系统的职责边界？
+  → 产出"实现部分清单"——本项目拆解出哪些部分
+  → 展示给用户确认或调整
+
+Step 3：通用层织造
+  → 织造产品哲学、工程哲学、协作哲学
+  → 参照 dimensions/universal/ 下的维度指引搜索
+  → 每个维度走"搜索→萃取→转译→落地"漏斗
+
+Step 4：实现部分层织造
+  → 对 Step 2 拆解出的每个部分，独立走搜索漏斗
+  → 搜"这个部分该怎么做、什么标准、有什么好实践"
+  → 产出部分哲学文档（独立文件或融入通用层文档的章节）
+  → 每个部分必须有：北极星、该做什么、不该做什么、参考实践、灵感来源
+
+Step 5：整合与冲突解决
+  → 检查部分间冲突（如 CLI 输出美学 vs CLI 错误呈现的格式冲突）
   → 产出 DECISION_RUBRIC.md（冲突取舍规则）
   → 确保所有哲学文档不与 BASELINE 冲突
 
-Step 5：版本锚定
+Step 6：版本锚定
   → 哲学文档写入 .loom/v{N}/00_PHILOSOPHY/
   → 版本升级时可重新织造，旧版保留
   → 记录织造日志（参考了哪些源、为什么这么织）
@@ -231,8 +276,8 @@ Step 5：版本锚定
 
 ### 人类检查点
 
-Step 2（维度激活）后：用户确认激活的维度。
-Step 4（整合）后：用户确认冲突取舍规则。
+Step 2（实现部分拆解）后：用户确认拆解出的部分清单。
+Step 5（整合）后：用户确认冲突取舍规则。
 
 其他步骤 Weaver 自主推进，不需要逐步批准。
 
@@ -269,7 +314,15 @@ Weaver 织造时读取对应维度文件，按其指引搜索和萃取。
 
 维度库是**可扩展**的——用户或 Agent 可以添加新维度。但新维度必须包含上述四要素，否则 Weaver 无法使用。
 
-> **注**：`dimensions/` 当前包含 `SEARCH_METHODOLOGY.md`（检索方法论）。维度文件按需填充——Weaver 首次运行时如果维度文件不存在，可根据 PHILOSOPHY_WEAVER.md 中的维度表自主判断。
+> **注**：`dimensions/` 当前包含：
+> - `SEARCH_METHODOLOGY.md` — 检索方法论（怎么找到优质思想）
+> - `PART_DECOMPOSITION.md` — 实现部分拆解方法论（怎么识别项目由哪些部分组成）
+> - `universal/PRODUCT_PHILOSOPHY.md` — 产品哲学维度指引（参考源清单 + 落地要求）
+> - `universal/ENGINEERING_CREED.md` — 工程哲学维度指引
+> - `universal/COLLABORATION_PHILOSOPHY.md` — 协作哲学维度指引
+> - `examples/` — 参考案例库（按项目类型组织，每个类型一个子目录）
+>
+> 通用层三个维度已填充，Weaver 织造时必须读取对应维度文件，按其参考源指引搜索。实现部分层不预设——Weaver 按 `PART_DECOMPOSITION.md` 的方法论自行拆解，`examples/` 提供参考案例但不强制遵循。
 
 ---
 
@@ -278,12 +331,13 @@ Weaver 织造时读取对应维度文件，按其指引搜索和萃取。
 | 由这份文件规定（元规范） | 由 Weaver 织造（哲学） |
 |---|---|
 | 织造漏斗是"搜索→萃取→转译→落地" | 每步的具体内容 |
-| 哲学分为三层（通用/领域/交叉） | 激活哪些领域和交叉维度 |
+| 哲学分两个轴（通用层 + 实现部分层） | 拆解出哪些实现部分 |
 | 通用层三个维度必跑 | 三个维度的具体内容 |
+| 实现部分按 PART_DECOMPOSITION.md 拆解 | 每个部分的具体哲学 |
 | 哲学文档必须包含 5 个结构要素 | 每个要素的具体内容 |
 | DECISION_RUBRIC 必须有冲突取舍规则 | 规则的具体内容 |
 | 哲学必须内化 BASELINE | 内化的具体表达方式 |
 | 哲学跟随版本演进 | 演进时变什么、为什么变 |
-| 维度库是 Weaver 的弹药库 | 维度库的具体内容（待填充） |
+| 灵感来源必须通过源多样性校验 | 具体引用哪些源 |
 
 元规范定义"怎么织造"，哲学定义"织出什么"。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haaaiawd/loom",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "LOOM — 哲学驱动开发框架。Agent 通过 CLI 访问 Intent Map / 哲学 / 验证记录，不直接读文件",
   "type": "module",
   "bin": {
@@ -35,8 +35,8 @@
   "license": "MIT",
   "repository": {
     "type": "git",
-    "url": "git+https://github.com/haaaiawd/loom.git"
-  },
-  "homepage": "https://github.com/haaaiawd/loom#readme",
+    "url": "git+https://github.com/Haaaiawd/loom.git"
+  },
+  "homepage": "https://github.com/Haaaiawd/loom#readme",
   "author": "haaaiawd"
 }