code-yangzz 1.0.0

package/skills/meta-theory/references/rhythm-orchestration.md

@@ -0,0 +1,257 @@
+# 节奏编排 — 完整参考
+
+> 来源：meta.md 第七、八部分（第648-896行），老金直播口播提炼
+
+## 核心命题
+
+**成熟系统不只是会拆、会组、会治理，还得会出牌。**
+
+编排不只是流程编排（谁先谁后），还包括节奏编排（什么时候给什么、什么时候不给）。
+
+---
+
+## 注意力成本模型
+
+### 第一定律：出牌有成本
+
+> **告诉用户某件事，是有成本的。**
+
+| 场景 | 成本 |
+|------|------|
+| 给用户一条建议 | 占用用户注意力带宽 |
+| 给系统加一个待办 | 与其他待办竞争优先级 |
+| 给Agent多塞一个目标 | 稀释当前任务的聚焦度 |
+| 给用户多推一个任务 | 增加用户的认知负荷 |
+
+每多说一件事，它就和前面那些事形成竞争。用户/组织/系统的注意力、带宽、吞吐都是有限的。
+
+### 第二定律：时机决定价值
+
+> **成熟系统不是知道的都说，而是知道什么时候说最值钱。**
+
+同一条信息在不同时机推送，价值天差地别：
+- 用户正在专注执行时推安全警告 → 高价值（可以防止事故）
+- 用户正在消化上一轮结果时推新任务 → 低价值（信息过载）
+- 用户刚完成一轮工作时推进化建议 → 中等价值（有余力吸收）
+
+### 第三定律：沉默也是设计
+
+> **什么都不做，不一定是系统失效。什么都不做，可能恰恰是最优动作。**
+
+---
+
+## 事件牌组机制
+
+### 设计哲学
+
+来自开放世界任务设计的启发：**表面给玩家自由，底层保留一套隐藏的节奏骨架。**
+
+用户感觉自由，最优交付顺序是设计过的。系统通过不同触点，把当前最该出现的内容送到用户面前。
+
+### 牌的数据结构
+
+每张牌包含以下属性：
+
+```yaml
+card:
+  id: string           # 唯一标识（如 "guide-01"）
+  type: enum           # 澄清/范围收缩/方案/执行/校验/修复/回滚/风险/建议/留白
+  priority: 1-10       # 默认优先级（10最高）
+  cost: low|mid|high   # 注意力成本等级
+  precondition: string # 出牌前提（如 "需求已明确"）
+  skip_condition: string # 跳过条件（如 "用户已知该信息"）
+  interrupt_trigger: string # 被插队的触发条件
+  delivery_shell: string   # 交付壳类型（详见意图放大）
+  max_iterations: number   # 迭代牌专用：最大循环次数（默认3）
+```
+
+### 十种牌的完整定义（对齐 `docs/meta.md` 原始设计）
+
+| 牌 | 原始设计名称 | 触发条件 | 动作 | 注意力成本 | 设计哲学 |
+|----|-----------|---------|------|-----------|---------|
+| **澄清牌** | 澄清 | 需求模糊 | 追问≤2轮，明确要改什么 | low | 信息不足时先收集再行动 |
+| **范围收缩牌** | 范围收缩 | 仓库太大/文件太多/同名冲突 | 先把边界缩小到可处理范围 | low | 环境复杂度变高时继续冲会误改 |
+| **方案牌** | 方案 | 需求清晰但有多条路径 | 把路线摆出来，好处/代价/该选哪条 | mid | 复杂问题不能一口吞，先给路线再动手 |
+| **执行牌** | 执行 | 规划完成，风险可控 | 分配到具体元，真正动代码 | high | 有计划才执行 |
+| **校验牌** | 校验 | 执行完成 | 编译/类型/依赖/需求对齐 | mid | 第一次做出来不等于做对 |
+| **修复牌** | 修复 | 校验不通过 | 重新修正，不要装作已完成 | mid | 修到过为止，设上限防死循环 |
+| **回滚牌** | 回滚 | 风险超预期或影响范围扩大 | 退回到上一个稳定状态 | high | 不要硬顶，能退回来才是成熟系统 |
+| **风险牌** | 风险 | 牵扯公共组件/鉴权/全局逻辑/多人协作 | 把风险抬到台面上，必要时插队 | high | 关键状态落后于预期，安全/权限/全局影响优先 |
+| **建议牌** | 建议 | 系统发现用户卡住但不需要太重打断 | 给一个更低成本的下一步推进动作 | low | 非紧急，但值得给一个方向 |
+| **留白牌** | 留白 | 连续完成/需消化/≥3连续高成本牌 | 暂停推送，给简短状态总结 | zero | 空白也是被设计的体验，什么都不做可能是最优动作 |
+
+### 发牌规则
+
+5条核心规则，按优先级排序：
+
+1. **默认按 priority 出牌**（理想顺序）
+2. **每出一张评估下一张的 skip_condition** — 满足则跳过
+3. **连续 ≥3 张 high 成本牌后，强制插入留白牌** — 防过载
+4. **interrupt_trigger 满足时，被触发的牌跳到队首** — 紧急优先
+5. **迭代牌最多循环 max_iterations 次，超出上报 Warden** — 防死循环
+
+### 发牌决策流程
+
+```
+[当前牌出完]
+  ↓
+检查下一张牌的 skip_condition
+  ├─ 满足 → 跳过，继续检查下一张
+  └─ 不满足 → 检查 interrupt_trigger 队列
+       ├─ 有插队牌 → 插队牌提到队首
+       └─ 无插队 → 检查留白条件
+            ├─ 连续 ≥3 high → 强制留白
+            └─ 不需要留白 → 正常出牌
+```
+
+---
+
+## 七大启发（从开放世界任务设计到AI系统）
+
+### 启发1：表面自由，底层有理想顺序
+
+编排元不只决定"谁先谁后"，还要决定：什么时候给什么、什么时候不给、什么内容先给、什么内容晚给、什么状态下要插队、什么状态下该跳过。
+
+**应用**：编排元从单纯任务调度升级为节奏控制器。
+
+### 启发2：发牌接口
+
+NPC、悬赏板、露营点不是内容本体，它们是内容投递接口。
+
+**应用**：AI系统中的聊天框、通知、日报、面板、Agent回复都是发牌员。不是所有元都负责生成内容，有些元的职责是交付内容。
+
+发牌接口选择：
+
+| 交付通道 | 适用场景 | 注意力占用 |
+|---------|---------|-----------|
+| 直接对话回复 | 用户正在交互、需要即时反馈 | high |
+| 写入文件 | 产出较大、需要持久化、用户稍后查看 | low |
+| spawn子代理 | 需要专业元独立完成的工作 | mid |
+| 等待用户操作 | 需要用户确认/输入/决策 | zero（等待中） |
+| 通知/摘要 | 后台完成的工作、状态更新 | low |
+
+### 启发3：留白机制
+
+留白不负责推进，它负责：降噪、降打扰、防过载、给用户留出消化空间、让探索感有机会发生。
+
+**触发条件**：
+- 连续 ≥3 轮高密度推送
+- 用户未响应上一轮输出
+- 当前信息密度已超过可消化阈值
+
+**留白时的行为**：
+- 不推送新任务
+- 给简短状态总结（"当前进度：X/Y 完成"）
+- 等待用户主动发起下一步
+
+### 启发4：出牌成本意识
+
+每条推送都和已有推送竞争注意力。
+
+**实践规则**：
+- 推送前自问：这条信息现在说，比 5 分钟后说更值钱吗？
+- 如果答案是否，不推
+- 如果答案不确定，降级为写入文件（低成本通道）
+
+### 启发5：跳过机制
+
+跳过不是偷懒，是注意力管理。
+
+**跳过条件设计**：
+- 用户已知同类信息 → 跳过
+- 当前上下文已包含该信息 → 跳过
+- 注意力预算不足（连续高密度后）→ 跳过或降级
+
+### 启发6：紧急治理机制
+
+某些元可以越过默认节奏直接顶上来。
+
+**触发信号**：
+
+| 信号源 | 信号 | 插队牌类型 |
+|--------|------|-----------|
+| Sentinel | 安全漏洞/权限问题 | 安全插队 — 最高优先级 |
+| Prism | pass_rate < 0.5 的严重质量漂移 | 质量插队 |
+| 用户 | 明确说"紧急"/"马上" | 用户插队 |
+| 系统 | 资源不足/超时/错误 | 系统插队 |
+
+**Sentinel → Conductor 信号通道**：
+- Sentinel 检测到安全问题 → 发送 `{type: "interrupt", source: "sentinel", severity: "critical", detail: "..."}`
+- Conductor 收到后暂停当前牌组，创建安全插队牌并提到队首
+
+**Prism → Conductor 信号通道**：
+- Prism 检测到质量漂移 → 发送 `{type: "interrupt", source: "prism", severity: "high", detail: "..."}`
+- Conductor 收到后评估：severity=critical 立即插队，severity=high 下一张牌前插入
+
+### 启发7：同一意图多种交付壳
+
+底层核不变，外层壳按场景换。
+
+**应用**：与意图放大直接对接。每张牌出牌时，除了决定"出什么"，还要决定"用什么壳交付"。
+
+---
+
+## 节奏编排与其他主线的关系
+
+```
+元(拆)
+  ↓ 提供：独立的可调度单位
+组织镜像(组)
+  ↓ 提供：层级结构和协作关系
+节奏编排(发) ← 本层
+  ↓ 提供：有节奏的出牌策略
+意图放大(成)
+  ↓ 消费：节奏控制下的结构化产出
+```
+
+### 与 Conductor 的关系
+
+Conductor 是节奏编排的**执行者**，本文档是节奏编排的**方法论**。
+
+Conductor 的具体实现（牌组数据结构、发牌函数、留白/插队逻辑）详见 `.claude/agents/meta-conductor.md`。
+
+### 与 Warden 的关系
+
+Warden 是留白和插队的**决策升级点**：
+- 迭代牌超过 max_iterations → 上报 Warden 决策
+- 多个插队牌冲突 → Warden 裁定优先级
+
+### 与 Sentinel/Prism 的关系
+
+Sentinel 和 Prism 是插队信号的**发送者**：
+- 安全问题 → Sentinel 发送插队信号
+- 质量漂移 → Prism 发送插队信号
+- Conductor 接收并处理这些信号
+
+---
+
+## 场景模拟
+
+### 场景1：正常流程
+
+```
+澄清牌(low) → 范围收缩牌(low) → 方案牌(mid) → 执行牌(high) → 校验牌(mid)
+→ 修复牌(mid) → [进化检测] → 完成
+```
+
+### 场景2：过载留白
+
+```
+执行牌(high) → 校验牌(high) → 修复牌-1(high)
+→ [连续3张high] → 强制留白牌 → "当前进度：修订第2轮，1/3项已通过"
+→ 用户确认继续 → 修复牌-2(mid)
+```
+
+### 场景3：紧急插队
+
+```
+执行牌(high) → [Sentinel安全警报] → 暂停当前牌组
+→ 风险牌(最高) → 安全修复 → 恢复原牌组 → 校验牌(mid)
+```
+
+### 场景4：回滚
+
+```
+执行牌(high) → [影响范围超预期] → 回滚牌(high)
+→ 回退到上一稳定状态 → 重新评估范围 → 范围收缩牌(low) → 重新执行
+```

package/skills/meta-theory/references/ten-step-governance.md

@@ -0,0 +1,285 @@
+# 十步治理 — 完整参考
+
+> 来源：meta.md 第五部分（第498-554行），老金直播口播提炼
+> **前三步是"会动"，后七步是"成熟"。**
+
+## 核心命题
+
+治理的本质是：**让系统不仅会做事，还会判断、会纠偏、会验证、会进化。**
+
+第一次产出只能说明它"会动"。会动不等于可靠，可靠不等于可复用，可复用不等于可演化。
+
+> **AI 系统的水平，不取决于它第一次能写多好，而取决于它有没有自我校正链路。**
+
+---
+
+## 十步全景
+
+```
+方向(1) → 规划(2) → 执行(3) → 评审(4) → 元评审(5) → 修订(6) → 验证(7) → 汇总(8) → 反馈(9) → 进化(10)
+├────── 会动 ──────┤├──────────────────── 成熟 ─────────────────────────────────────────┤
+```
+
+---
+
+## 每步详解
+
+### 步骤1：方向
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Warden + 用户 |
+| **输入** | 用户需求（可能模糊） |
+| **核心动作** | 需求清晰度检测 → 意图核提取 → 复杂度评估 |
+| **输出** | 明确的意图核 + 复杂度等级（简单/中等/复杂） |
+| **质量门控** | 意图核必须可验证：能用一句话描述"做完了是什么样"？不能 → 追问 |
+
+**追问规则**：
+- 最多追问 2 轮（引导牌）
+- 2 轮后仍模糊 → 基于已有信息做最保守假设，标记假设点
+- 不假设用户意图，但也不无限追问
+
+### 步骤2：规划
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Conductor |
+| **输入** | 意图核 + 复杂度等级 |
+| **核心动作** | 任务拆解 → 元分配 → 依赖分析 → 牌组编排 |
+| **输出** | 任务拆解方案 + 牌组配置 + 并行/串行标记 |
+| **质量门控** | 每个子任务必须能映射到一个具体元。无法映射 → 触发元创建 |
+
+**复杂度路由在此步决定**：
+- 简单（<2文件）→ 跳过规划，直接执行
+- 中等（2-5文件）→ 轻量规划
+- 复杂（>5文件）→ 完整规划 + 依赖图
+
+### 步骤3：执行
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | 执行元（按任务分配） |
+| **输入** | 任务拆解方案 + 具体子任务 |
+| **核心动作** | 搜索已有资源 → 能力匹配 → 分配执行 → 产出 |
+| **输出** | 具体产出物（代码/文档/配置/设计） |
+| **质量门控** | 文件所有权声明（一个文件同时只有一个元在写） |
+
+**执行原则**：
+- 文件不重叠 → 安全并行
+- 文件有重叠 → 串行，后者等前者完成
+- 找不到匹配元 → 触发类型B创建流水线
+
+### 步骤4：评审
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Prism |
+| **输入** | 步骤3的产出物 |
+| **核心动作** | AI-Slop扫描 → 断言化评估 → 声明验证 → 思考深度量化 → 质量评级 |
+| **输出** | 【Prism分析报告】含断言PASS/FAIL列表 + 质量等级(S/A/B/C/D) |
+| **质量门控** | A/S → 通过。B → 修订。C/D → 重做 |
+
+**评审不是打分**，是法医式取证：
+- 每个论断必须有具体证据（文件路径、行号、数据）
+- 隐含声明必须被提取并验证
+- 无证据的判定 = FAIL
+
+### 步骤5：元评审 ⭐
+
+> **这一步是整个治理流程中最独特的——谁来评审评审者？**
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Warden（审 Prism 的审查标准，不是审具体结论） |
+| **输入** | Prism 的审查报告 + 审查标准 |
+| **核心动作** | 断言覆盖性检查 → 断言强度检查 → 标准一致性检查 |
+| **输出** | 元评审判定：通过 / 要求补充 / 标准漂移警告 |
+| **质量门控** | 见下方元评审协议 |
+
+#### 元评审协议
+
+Warden 审查的是 Prism 的审查标准本身，不是重复审查产出：
+
+| 检查维度 | 方法 | 不通过处理 |
+|---------|------|-----------|
+| **断言覆盖性** | Prism 断言是否覆盖所有关键维度？ | 要求补充缺失维度的断言 |
+| **断言强度** | 有没有弱断言制造虚假信心？ | 要求收紧条件（如"有 Core Truths"→"有 ≥3 条且通过可替换性测试"） |
+| **标准一致性** | 和上次同类审查标准一致吗？ | 记录差异，判断是"进化"还是"漂移" |
+
+**触发规则**：
+
+```
+IF Prism pass_rate > 0.9 AND 产出明显有问题
+  THEN 强制触发元评审（Prism 的标准可能太宽松）
+
+IF Prism pass_rate < 0.3 AND 产出看起来合理
+  THEN 强制触发元评审（Prism 的标准可能太严格）
+
+IF 标准和上次同类审查差异 > 30%
+  THEN 标准漂移警告 → Warden 裁��
+```
+
+> **通过弱断言的 PASS 比 FAIL 更危险——它制造虚假信心。**
+
+### 步骤6：修订
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | 原执行元（谁做的谁改） |
+| **输入** | Prism 评审报告 + Warden 元评审意见 |
+| **核心动作** | 按评审意见修复 → 重新提交 |
+| **输出** | 修订后的产出物 |
+| **质量门控** | 最多 3 轮修订（AutoFix 循环）。3 轮后仍 B 级 → 上报 Warden 决策。<br>**注**：AutoFix 是自动修复循环——Review 发现问题后自动派发修复任务给执行元，不需要用户介入。只有3轮自动修复全部失败后才上报 Warden 决策。 |
+
+**修订分级**：
+- B级问题 → 补充具体案例、数据引用
+- C级问题 → 重写套话段落，用实际数据替换
+- D级问题 → 回到执行步骤，从头重做
+
+### 步骤7：验证
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Prism（独立于修订者） |
+| **输入** | 修订后的产出物 |
+| **核心动作** | 用同一套断言重新评估 → 确认修订确实解决了问题 |
+| **输出** | 验证结果：通过 / 需要继续修订 |
+| **质量门控** | 验证必须基于 fresh evidence，不是"我记得改过了" |
+
+> **验证不是自我感动。改了不等于改好了。必须重新跑断言。**
+
+### 步骤8：汇总
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | Warden |
+| **输入** | 所有步骤的过程数据 + 最终产出 |
+| **核心动作** | 综合各元报告 → 提取学习 → 生成CEO报告 |
+| **输出** | CEO报告（按交付壳适配）+ 学习记录 |
+| **质量门控** | CEO报告必须通过意图放大审查（壳适配检查） |
+
+**汇总不是复制粘贴**，是综合判断：
+- 多个元的报告可能矛盾 → Warden 做权衡决策
+- 提取本轮的关键学习 → 为步骤10进化做准备
+
+### 步骤9：反馈
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | 用户/CEO |
+| **输入** | 汇总报告 + 最终产出 |
+| **核心动作** | 用户确认满意度 → 补充修改意见 → 签收 |
+| **输出** | 用户确认 / 修改要求 |
+| **质量门控** | 必须获得明确确认。模糊确认（"还行吧"）→ 追问具体不满意的点 |
+
+### 步骤10：进化
+
+| 属性 | 内容 |
+|------|------|
+| **执行者** | 全员（每个元各自进化 + Conductor 统筹） |
+| **输入** | 全流程过程数据 + 用户反馈 |
+| **核心动作** | 5维度进化检测 → 进化放大操作 |
+| **输出** | 进化建议清单 + 已执行的进化操作 |
+| **质量门控** | 至少 1 个维度有具体进化操作（不能全是"维持现状"） |
+
+详细的5维度展开和放大操作见 `references/intent-amplification.md`。
+
+---
+
+## 复杂度路由
+
+不是所有任务都要走完10步。按复杂度路由：
+
+### 简单（<2文件改动）
+
+```
+方向(1) → 执行(3) → 评审(4) → 验证(7) → 反馈(9)
+跳过：规划(2)、元评审(5)、修订(6)、汇总(8)、进化(10)
+```
+
+**理由**：2文件以内的改动，评审覆盖即可，不需要元评审和完整进化。
+
+### 中等（2-5文件改动）
+
+```
+方向(1) → 规划(2) → 执行(3) → 评审(4) → 元评审(5) → 修订(6) → 验证(7) → 反馈(9)
+跳过：汇总(8)、进化(10)
+```
+
+**理由**：需要规划和元评审保证质量，但规模不足以需要完整进化分析。
+
+### 复杂（>5文件/多模块）
+
+```
+方向(1) → 规划(2) → 执行(3) → 评审(4) → 元评审(5) → 修订(6) → 验证(7) → 汇总(8) → 反馈(9) → 进化(10)
+全部10步
+```
+
+**理由**：大规模变更需要完整治理，包括元评审防止审查盲区、汇总综合判断、进化提取学习。
+
+### 路由决策矩阵
+
+| 信号 | 升级条件 |
+|------|---------|
+| 文件数从 <2 增加到 >2 | 简单 → 中等 |
+| 出现跨模块依赖 | 中等 → 复杂 |
+| Sentinel 报安全问题 | 任何 → 复杂（全步骤） |
+| Prism 评审发现系统性问题 | 中等 → 复杂 |
+| 用户明确要求完整流程 | 任何 → 复杂 |
+
+---
+
+## 步骤间的信号流
+
+```
+方向(1) ──意��核+复杂度──→ 规划(2)
+规划(2) ──牌组+分配──→ 执行(3)
+执行(3) ──产出物──→ 评审(4)
+评审(4) ──审查报告──→ 元评审(5)
+         ──评审意见──→ 修订(6)
+元评审(5) ──标准判定──→ 修订(6)（如有标准问题）
+修订(6) ──修订产出──→ 验证(7)
+验证(7) ──通过──→ 汇总(8)
+         ──未通过──→ 修订(6)（回环，最多3轮AutoFix）
+汇总(8) ──CEO报告──→ 反馈(9)
+反馈(9) ──用户确认──→ 进化(10)
+         ──修改要求──→ 修订(6)（回环）
+进化(10) ──进化操作──→ [下一轮的系统更强]
+```
+
+---
+
+## 元评审的深入设计
+
+元评审是十步治理中最容易被跳过、但最不该被跳过的步骤。
+
+### 为什么需要元评审
+
+**问题**：Prism 负责评审产出质量。但谁来评审 Prism 的评审质量？
+
+**风险**：
+- Prism 用了太宽松的断言 → 低质量产出通过了（虚假信心）
+- Prism 用了太严格的断言 → 合理产出被打回了（浪费资源）
+- Prism 的标准随时间漂移 → 同类产出今天过、明天不过（不一致）
+
+### 元评审不做什么
+
+- 不重复审查产出物本身（那是 Prism 的工作）
+- 不质疑 Prism 的具体结论（除非标准有问题）
+- 不替代 Prism 的角色
+
+### 元评审只做什么
+
+- 审查 Prism 的断言是否覆盖关键维度
+- 审查 Prism 的断言强度是否足够（弱断言检测）
+- 审查 Prism 的标准是否与历史一致（漂移检测）
+
+### Prism 的配合义务
+
+Prism 在被元评审时需要：
+- 公开完整的断言列表和评分标准
+- 说明每个断言的设计理由
+- 标记与上次同类审查的标准差异
+- 接受 Warden 的标准调整建议
+
+详见 `.claude/agents/meta-prism.md` 的"被审查协议"。