@haaaiawd/loom 0.7.0 → 0.9.0

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.9.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"
+    "url": "git+https://github.com/Haaaiawd/loom.git"
   },
-  "homepage": "https://github.com/haaaiawd/loom#readme",
+  "homepage": "https://github.com/Haaaiawd/loom#readme",
   "author": "haaaiawd"
 }