mindfn · mindfn · May 26, 2026 · Apr 30, 2026 · Jun 2, 2026 · Jun 1, 2026
diff --git a/.dir-exceptions.json b/.dir-exceptions.json
@@ -41,6 +41,13 @@
       "reason": "API utils 31 files；按 cli/process/media/paths/network/parsing/skills 子域拆分（详见 F23 § Phase 2）。SECOND-ROUND unblock（首轮 4136847b10 砚砚 2026-05-18 续期到 2026-06-01）。Follow-up split plan 记在 F23 § Phase 2 follow-up。",
       "expiresAt": "2026-06-30",
       "ticket": "F23-followup"
+    },
+    {
+      "path": "packages/api/src/infrastructure/harness-eval",
+      "owner": "opus",
+      "reason": "F192 socio-technical harness eval 当前 29 .ts（Phase F capability-wakeup 一批 eval-capability-wakeup-* 加入超 error=25）；登记基线红灯，后续按 capability-wakeup / a2a / domain / hub 子域拆分。详见 F192 feat doc Known Debt + GitHub issue。",
+      "expiresAt": "2026-06-15",
+      "ticket": "F192"
     }
   ]
 }
diff --git a/AGENTS.md b/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

diff --git a/GEMINI.md b/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)
diff --git a/cat-cafe-skills/quality-gate/SKILL.md b/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）

diff --git a/cat-cafe-skills/receive-review/SKILL.md b/cat-cafe-skills/receive-review/SKILL.md
@@ -44,15 +44,31 @@ triggers:
 
 ## 核心知识
 
-### 两类反馈，处理方式不同
+### 三类反馈，处理方式不同
 
 | 类型 | 特征 | 处理 |
 |------|------|------|
 | **代码级** | bug / edge case / 性能 / 命名 | Red→Green 修复流程 |
+| **数据流级** | "真相源读错了" / "状态不一致" / "全局改了项目没级联" / "UI 和 API 对不上" | STOP → 重建真相源模型 → 再修（见下方） |
 | **愿景级** | "这不是铲屎官要的" / "缺了多项目管理" / "UI 不可用" | STOP → 回读原始需求 → 升级铲屎官 |
 
 > **愿景级反馈不能用代码 patch 修补设计问题。** 先对照铲屎官原话验证 reviewer 说得对吗；如确实偏离，升级铲屎官确认偏差范围，再重新设计。
 
+### 数据流级反馈处理（反补锅匠门禁）🔴
+
+当 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 判别）

diff --git a/cat-cafe-skills/refs/review-request-template.md b/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（给 CVO，如有）
 {需要 CVO 判断的价值取舍——必须附 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 + 实际端口**
diff --git a/cat-cafe-skills/request-review/SKILL.md b/cat-cafe-skills/request-review/SKILL.md
@@ -81,9 +81,13 @@ BEFORE 发 review 请求:
 关键字段提醒：
 - **Original Requirements**: 必填，≤5 行铲屎官原话 + 来源文档路径，并明确请 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**（需要 CVO 判断的，附 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 一致？

diff --git a/cat-cafe-skills/writing-plans/SKILL.md b/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:**

diff --git a/desktop/package.json b/desktop/package.json
@@ -118,6 +118,10 @@
       {
         "from": "../assets/system-prompts",
         "to": "assets/system-prompts"
+      },
+      {
+        "from": "../plugins",
+        "to": "plugins"
       }
     ],
     "asar": false,

diff --git a/docs/ROADMAP.md b/docs/ROADMAP.md
@@ -7,7 +7,7 @@ created: 2026-02-26
 
 # Cat Cafe Feature Roadmap
 
-> 维护者：三猫 | 最后更新：2026-05-26（feature truth hygiene：F088/F101 active，F179 done）
+> 维护者：三猫 | 最后更新：2026-06-03（F220 GitHub Plugin Schedule Resource 立项）
 >
 > **规则**：只放活跃 Feature（idea/spec/in-progress/review），done 后移除。
 > 详细信息见 `docs/features/Fxxx-*.md`。
@@ -66,3 +66,4 @@ created: 2026-02-26
 | F208 | Capability Profile Routing — 能力画像档案 + 认知路由 | spec | Ragdoll | internal | [F208](features/F208-capability-profile-routing.md) |
 | F210 | Gemini CLI to Antigravity CLI Migration | in-progress | Maine Coon/Maine Coon | internal | [F210](features/F210-antigravity-cli-migration.md) |
 | F217 | Merge Gate Integrity — 检查覆盖 + 强制力 + 元守护（根治 6 类 gate 失效）| spec | Ragdoll Opus 4.8 | internal | [F217](features/F217-merge-gate-integrity.md) |
+| F220 | GitHub Plugin Schedule Resource — 定时任务插件化重构 | in-progress | Ragdoll | community [#844](https://github.com/zts212653/clowder-ai/issues/844) | [F220](features/F220-github-plugin-schedule-resource.md) |