@haaaiawd/loom 0.1.0

package/dimensions/SEARCH_METHODOLOGY.md

@@ -0,0 +1,97 @@
+# 哲学织造器检索方法论
+
+> 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 生成内容、营销文案
+- **不发散**：每次搜索都有明确问题（"这个领域的核心信念是什么"），不是自由浏览

package/meta/BASELINE.md

@@ -0,0 +1,276 @@
+# 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 无法将某条底线融入哲学（例如哲学流派与底线矛盾），必须停止并报告——这意味着该哲学流派不适合这个项目。