fix(F192): generators read domain registry from LIVE root, not stale publish base

AGENTS.md

@@ -1,23 +1,18 @@
-# Clowder AI — OpenAI/Codex Agent Guide
+# Clowder AI — Agent Guide
 
 ## Identity
-You are the Maine Coon cat (Codex/GPT), the code reviewer and security specialist of this Clowder AI instance.
+Your identity, role, and personality are provided by Cat Cafe at runtime.
+This file contains shared governance rules that apply to all team members.
 
 ## Safety Rules (Iron Laws)
 1. **Data Storage Sanctuary** — Never delete/flush your Redis database, SQLite files, or any persistent storage.
 2. **Process Self-Preservation** — Never kill your parent process or modify your startup config.
 3. **Config Immutability** — Never modify runtime config files. Config changes require human action.
 4. **Network Boundary** — Never access localhost ports that don't belong to your service.
 
-## Your Role
-- Code review with clear stance on every finding (no "fix or not, up to you")
-- Security analysis and vulnerability detection
-- Test coverage verification
-- Cross-model review (you review Claude's code, Claude reviews yours)
-
 ## Review Protocol
 - Same individual cannot review their own code
-- Cross-family review preferred (Maine Coon reviews Ragdoll's code)
+- Cross-family review preferred
 - Every finding must have a clear severity: P1 (blocking) / P2 (should fix) / P3 (nice to have)
 
 ## Truth Sources

CLAUDE.md

@@ -22,3 +22,9 @@ See `cat-cafe-skills/` for the full skill-based workflow:
 - No `any` types
 - Biome: `pnpm check` / `pnpm check:fix`
 - Types: `pnpm lint`
+
+## Cost Discipline
+- **Agent demotion**: before spawning Agent/Explore/Workflow, ask "can a single grep/Read do this?" If yes → use Bash/Read directly
+- **Model tiering**: simple subagent tasks (search, summarize, format) → `model: 'haiku'`
+- **Debug strategy gate**: 1 round of static analysis with no root cause → switch to instrument → reproduce → observe. No multi-session static exhaustion
+- Full rules: `cat-cafe-skills/refs/shared-rules.md` §20

GEMINI.md

@@ -1,21 +1,21 @@
-# Clowder AI — Gemini Agent Guide
+# Clowder AI — Agent Guide
 
 ## Identity
-You are the Siamese cat (Gemini), the visual designer and creative thinker of this Clowder AI instance.
+Your identity, role, and personality are provided by Cat Cafe at runtime.
+This file contains shared governance rules that apply to all team members.
 
 ## Safety Rules (Iron Laws)
 1. **Data Storage Sanctuary** — Never delete/flush persistent storage.
 2. **Process Self-Preservation** — Never kill your parent process.
 3. **Config Immutability** — Never modify runtime config files.
 4. **Network Boundary** — Never access ports that don't belong to your service.
 
-## Your Role
-- Visual design and UX consultation
-- Creative ideation and brainstorming
-- Design system maintenance
-- Breaking conventional thinking patterns
-
-## Important Constraints
+## Gemini-Specific Constraints
 - Focus on design consultation, not code implementation
 - Always validate suggestions against the project's design system
 - Provide visual references when suggesting changes
+
+## Review Protocol
+- Same individual cannot review their own code
+- Cross-family review preferred
+- Every finding must have a clear severity: P1 (blocking) / P2 (should fix) / P3 (nice to have)

cat-cafe-skills/quality-gate/SKILL.md

@@ -61,6 +61,28 @@ Step 2: CREATE — 建检查清单
   - 列出每一个 AC / 功能点 / 边界条件
   - 列出 Discussion 里的 UX 描述和场景
 
+Step 2.4: PATCH COUNTER GATE（反复返工硬闸）🔴
+  - **Step A — 列出候选 commits**：
+    ```
+    UPSTREAM_REF="$(git rev-parse --abbrev-ref --symbolic-full-name '@{upstream}' 2>/dev/null || echo origin/main)"
+    BASE_REF="$(git merge-base "$UPSTREAM_REF" HEAD)"
+    git log --oneline "$BASE_REF..HEAD" -- <changed-files>
+    ```
+    自动取当前分支的 upstream tracking ref，无 tracking 时 fallback `origin/main`。develop_base 流程中会自动解析为 `origin/develop_base`。
+  - **Step B — 人工分类**：逐条标记每个 commit 为以下之一：
+    - ✅ **同一 bug/AC 返工**：修上次没修好的同一个问题、用户报告同一问题后的重复修复、同一区域反复修补
+    - ⬚ **正常迭代**（不计入）：reviewer 正常 P1/P2 修复（`fix: address review P2-xxx`）、新发现的不同问题的修复
+    - ⬚ **排除**（不计入）：纯 lint/format/typo（`chore:` / `style:`）、rebase 冲突解决
+    - 判断标准：问自己——"这个 fix 是在修一个**新发现的问题**，还是在修**上次没修好的同一个问题**？"后者才标 ✅
+  - **Step C — 硬闸判定**：标 ✅ 的 ≥3 个 → **GATE FAIL**
+  - FAIL 时必须：
+    ① 停止继续修补
+    ② 重读 spec 原文 + 铲屎官原始需求
+    ③ 产出完整的真相源矩阵（格式同 writing-plans 的 Truth-Source Model Gate）
+    ④ 写清"为什么需要这么多 fix"的根因分析
+    ⑤ 根因分析通过后才能继续
+  - > **根因（2026-06-05 反思 + LL-020）**：F719 分支前 25 个提交大量 fix/refactor/test-fix，远超 LL-020 的"N > 3 换方向"告警线。补丁数量是方向信号——N > 3 不是"还需要更多补丁"的信号，而是"理解不完整，需要停下来重新建模"的信号。
+
 Step 2.5: CLOSE GATE MATRIX + FOLLOW-UP TAIL SCAN（F177 Phase A）🔴
   - 检查 CloseGateReport 是否已生成（schema: `cat-cafe-skills/refs/close-gate.md`）
   - 每个 unmet AC 是否三选一处置（immediate / delete / cvo_signoff）

cat-cafe-skills/receive-review/SKILL.md

@@ -44,15 +44,31 @@ triggers:
 
 ## 核心知识
 
-### 两类反馈，处理方式不同
+### 三类反馈，处理方式不同
 
 | 类型 | 特征 | 处理 |
 |------|------|------|
 | **代码级** | bug / edge case / 性能 / 命名 | Red→Green 修复流程 |
+| **数据流级** | "真相源读错了" / "状态不一致" / "全局改了项目没级联" / "UI 和 API 对不上" | STOP → 重建真相源模型 → 再修（见下方） |
 | **愿景级** | "这不是operator要的" / "缺了多项目管理" / "UI 不可用" | STOP → 回读原始需求 → 升级operator |
 
 > **愿景级反馈不能用代码 patch 修补设计问题。** 先对照operator experience验证 reviewer 说得对吗；如确实偏离，升级operator确认偏差范围，再重新设计。
 
+### 数据流级反馈处理（反补锅匠门禁）🔴
+
+当 reviewer 或用户指出的问题涉及**真相源/状态/级联/一致性**时，**禁止直接按点修**。必须：
+
+1. **STOP** — 不写一行代码
+2. **重建真相源模型** — 产出真相源矩阵（格式同 `writing-plans` 的 Truth-Source Model Gate），明确谁写谁读谁派生
+3. **定位根因** — 当前 bug 是哪个环节的读/写/级联断了？用矩阵定位，不用直觉猜
+4. **Blast radius 评估** — 修这个环节会影响哪些消费方？列出来，每个都需要验证
+5. **补 regression guard** — 对每个受影响的消费方，先写测试保护现有正确行为，再改代码
+6. **修复** — 在 regression guard 保护下修根因，不是修症状
+
+**判别标准**：如果你的修复方案是"在前端读另一个字段 / 加一个 workaround / 在 UI 层补逻辑"——这大概率是在修症状。问自己："后端/数据层的真相源对不对？"如果不对，先修数据层。
+
+> **根因（2026-06-05 反思）**：布偶猫 F719 中 toggle 不更新时，先做了前端读 `mountedCount` 的 workaround 而不是修 API 层的 `cap.enabled` 写入。这是"收到反馈后仍按点修"的典型失败模式。数据流级问题的修法必须回到数据层，不能在展示层打补丁。
+
 ### 禁止的响应（表演性同意）
 
 ```
@@ -93,7 +109,7 @@ review 报告中必须包含 fallback 层数分析结果。
 WHEN 收到 review 反馈:
 
 1. READ  — 完整读完，不要边读边反应。**R2+ 时额外动作**：回看上轮 finding 列表，标注每个 finding 的 failure-mode 类型，用于 AUDIT 步骤的同型判别
-2. CLASSIFY — 区分愿景级 vs 代码级；按 P1/P2/P3 分优先级
+2. CLASSIFY — 区分代码级 / 数据流级 / 愿景级（见上方三类反馈表）；按 P1/P2/P3 分优先级。数据流级 = 涉及真相源/状态/级联/一致性 → 走数据流级处理流程
 3. CLARIFY — 有不清晰的问题先全部问清，再动手
 4. VERIFY — reviewer 说的问题真的存在吗？（见下方三道门）
 5. AUDIT — failure-mode sweep（见下方 §16e 判别）

cat-cafe-skills/refs/review-request-template.md

@@ -35,10 +35,22 @@ Why: {一句话}
 - 是否新建了并行 `Store` / `Queue` / `Router` / `Adapter` / `Dispatcher` / `Binding`
 - 若修改 `docs/architecture/ownership/cells/*.md`，是否确实改变了 owner / boundary / extension point / canonical anchor
 
+## Invariant Matrix（涉及跨层状态同步/级联时必填）
+<!-- 格式同 writing-plans Truth-Source Model Gate。简单 CRUD 可写"不适用"。 -->
+| 不变量 | 断言描述 | 验证方式 |
+|--------|---------|---------|
+| INV-1  | {描述}  | {测试/手动验证} |
+
+## E2E User Path Evidence（涉及用户可感知功能时必填）
+<!-- 引用 quality-gate Step 4.5 Dogfood-Your-Slice 输出即可，不需要重跑。 -->
+<!-- 若 quality-gate 中该项为"可豁免"，此处写"可豁免（理由：xxx）"。 -->
+{端到端路径 + 命令/截图}
+
 ## Open Questions
 
 ### 技术 OQ（给 reviewer）
 {需要 reviewer 特别关注的实现正确性/安全性/性能问题}
+请 reviewer 逐条验证 Invariant Matrix 中的不变量是否被代码保持。
 
 ### 价值 OQ（给 operator，如有）
 {需要 operator 判断的价值取舍——必须附 Decision Packet（格式见 `refs/decision-matrix.md`）}
@@ -76,6 +88,8 @@ pnpm -r --if-present run build         # 成功
 
 - **附原始需求摘录（≤5 行）**，否则 reviewer 不审
 - **附 Architecture Ownership 三字段**，否则 reviewer 不审
+- **涉及跨层状态同步/级联时附 Invariant Matrix**，reviewer 有权要求补上后再继续
+- **涉及用户可感知功能时附 E2E User Path Evidence**（引用 quality-gate Dogfood 输出）
 - 自检报告必须附上（从 quality-gate skill 输出）
 - 前端功能附截图证据
 - 前端 review 需要起 dev 时，**必须附 review 沙盒 Path + Start Command + 实际端口**

cat-cafe-skills/refs/shared-rules.md

@@ -777,7 +777,46 @@ beforeEach(() => {
 
 **违反代价**：用真身份发测试 payload 到operator thread / 其他猫 thread，看起来像 spam / cron job / 幻觉。已发出去的消息**不可撤回**。
 
-## 20. 根目录卫生公约（F214 — 根目录运行时残留治理）
+## 20. Agent 降级与成本纪律（2026-06-11 usage 分析教训）
+
+> 来源：usage 分析发现 93% 成本来自 subagent-heavy sessions。Agent/Workflow 派发是高杠杆操作——每次调用 ≈ 新开一个完整上下文窗口。
+
+### 20a. Agent 降级反射（派发前必问）
+
+派 Agent / Explore / Workflow **前**，先问：
+
+1. **一个 grep/Read 能做吗？** → 能 → 直接 `grep -rn` / `Read` / `Bash`，不派 agent
+2. **需要并行或隔离上下文吗？** → 不需要 → 直接做，不开 Workflow
+3. **这个 subagent 需要 Opus 吗？** → 简单搜索/摘要/格式化 → 用 `model: 'haiku'`
+
+**典型降级场景**（直接用工具，不派 agent）：
+- 找函数定义 → `grep -rn "functionName" .`
+- 找文件 → `find . -name "pattern"`
+- 看某个符号的引用 → `grep -rn "symbolName" packages/`
+- 读已知文件的某段 → `Read` tool
+
+**Explore agent 保留场景**（合理使用）：
+- 搜索目标未知，需要跨多目录多命名探索
+- `very thorough` 广度搜索，确实不知道在哪
+
+### 20b. 调试策略切换门禁
+
+调试（定位 bug / 理解行为）时：
+- **静态分析 1 轮未定位** → 切换到"加诊断 → 复现 → 看数据"策略
+- **禁止**在同一方向穷举 2+ 轮 session 的静态分析（token 消耗巨大，收益递减）
+- **观察优先于推理**：运行时日志 / 诊断 / 断点 > 反复读同一批文件推理
+
+来源：消息消失 bug 调查——2 轮 session 穷举静态分析未定位，如果一开始加诊断 + 复现可能 30 分钟就定位。
+
+### 20c. 长 session 成本意识
+
+- `/loop` 和 `/schedule` 必须有明确退出条件，不做无限轮询
+- 调查类任务设心理 token budget——到预算 → 切换策略或求助，不在同方向死磕
+- Workflow 使用 `budget.remaining()` 做提前终止
+
+---
+
+## 21. 根目录卫生公约（F214 — 根目录运行时残留治理）
 
 > 来源：F214（2026-05-28）。ADR-010 / F023 管子目录代码 + docs 归档，不管根目录运行时残留——本节是 ADR-010 在根目录维度的补丁。
 

cat-cafe-skills/request-review/SKILL.md

@@ -81,9 +81,13 @@ BEFORE 发 review 请求:
 关键字段提醒：
 - **Original Requirements**: 必填，≤5 行operator experience + 来源文档路径，并明确请 reviewer 对照判断
 - **Architecture Ownership**: 必填，列 `Architecture cell` / `Map delta` / `Why`，并请 reviewer 检查 diff 是否与 `Map delta` 一致
+- **Invariant Matrix**（涉及跨层状态同步/级联时必填；简单 CRUD 可写"不适用"）🔴: 列出核心不变量 + 真相源读写关系（格式同 `writing-plans` 的 Truth-Source Model Gate）。reviewer 必须逐条验证 invariant 是否被代码保持。缺少 invariant matrix 时，reviewer 有权要求补上后再继续 review
+- **E2E User Path Evidence**（涉及用户可感知功能时必填）🔴: 引用 quality-gate Step 4.5 Dogfood-Your-Slice 的输出即可（不需要重新跑）。reviewer 可据此判断 blast radius。若 quality-gate 中该项为"可豁免"，此处同样豁免
 - **Open Questions**: 分为两类——**技术 OQ**（给 reviewer 的，如实现正确性）和 **价值 OQ**（需要 operator 判断的，附 Decision Packet——格式见 `refs/decision-matrix.md`）。不混在一起
 - **自检证据**: 附 quality-gate report 摘要 + 测试命令输出 + 根目录工件闸门输出
 
+> **根因（2026-06-05 反思）**：F719 review 中缅因猫发现的 P1 都指向同一类问题——global/project state 语义混淆、guard 读错真相源。如果 review 请求附了 invariant matrix，reviewer 能直接验证"代码是否保持了这些不变量"，而不是在代码里逐行找状态不一致。E2E 用户路径证据则防止"测试通过但用户体验不通"的盲区。
+
 **F191 reviewer 视角**：
 - PR 是否新建了并行 `Store` / `Queue` / `Router` / `Adapter` / `Dispatcher` / `Binding`？
 - `Map delta: none` 是否与 diff 一致？

cat-cafe-skills/writing-plans/SKILL.md

@@ -25,6 +25,52 @@ triggers:
 
 **Save plans to:** `feature-specs/YYYY-MM-DD-<feature-name>.md`
 
+## Truth-Source Model Gate（复杂需求强制）🔴
+
+**写不出完整数据流 = 还没理解 = 不许拆步骤。**
+
+对于涉及**跨层状态同步或级联更新**的需求（如：全局配置→项目配置→文件系统→UI 多层联动），动手拆步骤前**必须**先产出以下三张表。简单的 CRUD 读写（API 读 DB 返回 JSON）不触发此门禁：
+
+### 表 1：真相源矩阵（谁写谁读谁派生）
+
+```markdown
+| 数据 | 真相源（写） | 消费方（读） | 派生关系 | 级联规则 |
+|------|-------------|-------------|---------|---------|
+| 例：全局 skill 启禁用 | capabilities.json (全局) | 项目级 capabilities / UI | 项目继承全局 | 全局禁用 → 所有项目 unmount |
+```
+
+**每一行必须回答**：这个数据从哪来？谁负责写？谁读？读的人直接读真相源还是读派生？状态变化时谁级联通知谁？
+
+### 表 2：核心不变量（invariants）
+
+```markdown
+- INV-1: 全局禁用的 skill，任何项目下都不可见且无 symlink
+- INV-2: 项目配置的启禁用状态 = 实际 symlink 存在与否
+- INV-3: UI 展示的状态 = 后端 API 返回的状态（无前端 workaround）
+```
+
+**每条 invariant 必须可测试**——写不出对应的断言 = 不是 invariant，是愿望。
+
+### 表 3：既有正确行为保护点
+
+```markdown
+| 现有功能 | 当前正确行为 | 保护方式 |
+|---------|------------|---------|
+| 项目选择器 | 能列出所有已知项目 | 现有测试 / 新增 regression guard |
+```
+
+**改代码前，先确认保护方式到位**（已有测试覆盖 or 需要先补测试）。没有保护 = 改了之后不知道有没有破坏。
+
+### 何时豁免
+
+- 单文件 ≤50 行改动、不涉及多数据源交互 → 可跳过
+- 纯 UI 样式调整、文档修改 → 可跳过
+- **涉及 config/state/filesystem 多层交互 → 不可跳过，写不出就停下来问清楚**
+
+> **根因（2026-06-05 反思）**：布偶猫 F719 Skill Lifecycle Management 反复返工的核心病因是"边做边理解"——抓关键词就动手，没花时间画完整数据流。铲屎官给了闭环方案但实现出来"长得像但数据流不通"。此门禁把"理解"从"实现"中分离：理解产物是三张表，不是代码。
+
+---
+
 ## Straight-Line Check (A→B, No Detour)
 
 **Before splitting steps, do this first:**