القائمة
处理 reviewer 反馈：Red→Green 修复 + 技术论证（禁止表演性同意）。 Use when: 收到 review 结果、reviewer 提了 P1/P2、需要处理反馈。 Not for: 发 review 请求（用 request-review）、自检（用 quality-gate）。 Output: 逐项修复确认 + reviewer 放行。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
约定图发现方法论：进一个 repo 先识别 repo-specific conventions，再定义 domain/extractor 接 Convention Graph 引擎。Use when: 进入陌生 repo、要画约定图、要找“改 X 影响谁”的约定层关联、 F242/Convention Graph Layer 工作。Not for: 普通符号跳转/LSP、文档索引检索、记忆图谱、直接使用 codegraph/GitNexus。Output: domain 定义 + extractor 计划 + gap/freshness/provenance 报告。 GOTCHA: 沉淀的是“怎么画图”的方法，不是把 cat-cafe 的 extractor 硬搬到所有 repo。
跨 thread 协同：发现平行 session → 通知（3+2 件套）→ 争用协调 → 确认。 Use when: 平行 session 之间需要协同、收到跨线程消息、通知改动影响、共享文件争用。 Not for: 跨猫工作交接（用 cross-cat-handoff）、需要新建 thread 时（用 propose_thread / thread-orchestration）。 GOTCHA: 收到跨线程 ACTION 不等于接活；先做 thread/feat ownership gate，不属于当前 thread 就 cross-post 退回。 Boundary with F128: 发现跨 scope 问题 → 先 list_threads 查有没有已有 thread → 有 = 本 skill（cross_post）→ 没有 = propose_thread。 Output: cross-post 通知 + 争用协调完成。
Feature 立项、讨论、完成的全生命周期管理。 Use when: 开个新功能、new feature、F0xx、立项、feature 完成、验收通过、讨论新功能需求。 Not for: 代码实现、review、merge（那些有专门的 skill）。 Output: Feature 聚合文件 + BACKLOG 索引 + 真相源同步。
明星开源项目拆解：从宣传/PPT/README 进入源码，验证真实架构、明星特性、算法含量、营销水分、可学习点和不 follow 的 tradeoff。 Use when: operator要求拆解热门 GitHub 项目、竞品 agent/runtime、外部 skill/tool 框架，或问“它到底有什么真本事/我们能学什么”。 Not for: 普通资料搜索（用 deep-research）、社区 issue/PR 运营（用 opensource-ops）、只需要架构头脑风暴（用 collaborative-thinking）。 Output: feature-discussions/YYYY-MM-DD-{project}-deep-dive/ 下的代码证据报告 + 对比结论 + 候选 lesson/skill。 GOTCHA: 不许只看 README 下判断；每个明星特性必须追到代码路径、状态突变点、反馈闭环和算法输入输出。
开发完成后的自检门禁：愿景对照 + spec 合规 + 验证。 Use when: 开发完了准备提 review、声称完成了、准备交付。 Not for: 收到 review 反馈（用 receive-review）、merge（用 merge-gate）。 Output: Spec 合规报告（含愿景覆盖度）。
接球前真相核验三问：claim → resolver → verdict (sourceTier T0/T1/T2 + actionFamily)， 防止把传球者当无审视真相源（F167 Phase O 第一性原理）。 Use when: 即将调 hold_ball / register_pr_tracking / register_issue_tracking / merge / takeover / 改 owner / 任何 irreversible action / 基于 "operator signoff" 或 "你是 owner" 类 claim 行动之前。 Not for: 纯阅读 cross_post（无 actionFamily 后续）；本 thread 日常 @mention 无副作用； implementation continuation（自检通过的下一步）。 Output: claim grounding verdict (verified/mismatch/insufficient) + 接球决策 (proceed / block / push back to source thread)。
| name | receive-review |
| description | 处理 reviewer 反馈：Red→Green 修复 + 技术论证（禁止表演性同意）。 Use when: 收到 review 结果、reviewer 提了 P1/P2、需要处理反馈。 Not for: 发 review 请求（用 request-review）、自检（用 quality-gate）。 Output: 逐项修复确认 + reviewer 放行。 |
| triggers | ["review 结果","review 意见","reviewer 说","fix these","github-review-feedback"] |
SOP 位置: 本 skill 是
sop-definitions/development.yamlstagereview的反馈处理执行细节。 上一步:request-review| 下一步:merge-gate
处理 reviewer 反馈的完整流程。核心原则：技术正确性 > 社交舒适，验证后再实现，禁止表演性同意。
| 来源 | 说明 |
|---|---|
| operator/猫猫转述 | 手动告知 review 结果 |
github-review-feedback connector 通知 | F140 自动投递：review decisions（approved/changes_requested）+ inline/conversation comments |
| 云端 Codex review | 通过 ReviewRouter 投递的 email review 结果 |
收到 github-review-feedback 通知时，按下面的核心知识处理——不区分来源，只区分反馈类型。
当 github-review-feedback connector 唤醒你时：
CHANGES_REQUESTED → 直接进入下方 Red→Green 流程APPROVED → 不需要 receive-review，检查是否可以走 merge-gateCOMMENTED → 判断是否需要代码修改，需要则进入 Red→Green 流程详见 refs/pr-signals.md Phase B 自动响应行为。
| 类型 | 特征 | 处理 |
|---|---|---|
| 代码级 | bug / edge case / 性能 / 命名 | Red→Green 修复流程 |
| 愿景级 | "这不是operator要的" / "缺了多项目管理" / "UI 不可用" | STOP → 回读原始需求 → 升级operator |
愿景级反馈不能用代码 patch 修补设计问题。 先对照operator experience验证 reviewer 说得对吗；如确实偏离，升级operator确认偏差范围，再重新设计。
❌ "You're absolutely right!" ❌ "Great point!"
❌ "Excellent feedback!" ❌ "Thanks for catching that!"
❌ "让我现在就改"（验证之前）
行动说明一切——直接修复，代码本身证明你听到了反馈。
当以下情况时必须 push back，用技术论证，不是防御性反应：
如果你 push back 了但你错了：陈述事实然后继续，不要长篇道歉。
Review 代码时，自动执行 node scripts/check-fallback-layers.mjs 检测 fallback 模式增长。
同一文件新增 ≥3 层 fallback → 触发坐标系自检（三问）：
review 报告中必须包含 fallback 层数分析结果。
Review 有零分歧 = 走过场（反顺从规则）。真正的 review 需要技术争论。
WHEN 收到 review 反馈:
1. READ — 完整读完，不要边读边反应。**R2+ 时额外动作**：回看上轮 finding 列表，标注每个 finding 的 failure-mode 类型，用于 AUDIT 步骤的同型判别
2. CLASSIFY — 区分愿景级 vs 代码级；按 P1/P2/P3 分优先级
3. CLARIFY — 有不清晰的问题先全部问清，再动手
4. VERIFY — reviewer 说的问题真的存在吗？（见下方三道门）
5. AUDIT — failure-mode sweep（见下方 §16e 判别）
6. FIX — 通过验证的问题 + audit 发现的同类问题 Red→Green 修复
7. CONFIRM — 修完回给 reviewer 确认，不能自判"改对了"
对每条 review 意见，改代码之前必须过三道门：
特别注意：remote reviewer（Codex cloud）没有运行环境，判断基于静态分析和理论推理。你有本地环境 → 你的实测证据 > 他的理论推理。
修复顺序：P1（blocking）→ P2（必须修）→ P3（讨论后当场修或放下，不记 BACKLOG）
澄清原则：有任何问题不清晰，先 STOP，全部问清再动手。部分理解 = 错误实现。
VERIFY 完所有 findings 之后、动手修之前，做一次 failure-mode 判别：
判别问：这些通过验证的 P1/P2 里，有没有 ≥2 个属于同一类 failure mode？（边界遗漏、null 不安全、错误处理不一致、状态转换缺路径、类型假设不安全……）
R2+ 额外检查：如果本轮的 finding 和上轮是同型——不管数量多少，强制 audit。同型第二次出现 = author 上轮没泛化，这次必须补上。
≥3 轮升级规则（F229 PR-A1 20 轮教训）🔴：同一状态对象的 finding 连续 ≥3 轮出现（哪怕每轮都"修好了"）= 不是你修得不对，是 plan/spec 层欠状态机的边——代码层 audit 扫不出"spec 没定义 restore boundary"这种上游缺失。停手，@ plan/spec 作者按 writing-plans「Stateful Object Gate」补状态转移表 + 不变量，补完再继续修。别一个人打到 R20（PR #2202：实现猫每轮诚实修好当轮 finding，但缺这个升级出口，20 轮才合入）。
为什么在 FIX 之前：先 audit 再修 = 一次修完所有同类；先修再 audit = 改了一个又发现三个，反复 rebase。
对每个 P1/P2 问题：
Step 0: 创建修复任务（F160 Phase C — 在动手修之前）
调用 cat_cafe_create_task 为每个 P1/P2 创建独立跟踪任务：
[P{N}] {问题摘要}（如 [P2] TaskComposer HTTP 错误时丢失输入）cat_cafe_update_task 状态改为 doneGotcha: 不要为 P3 创建任务——P3 当场修或放下，不记 BACKLOG 也不记毛线球。
1. 理解问题
2. 写失败测试（Red）
3. 运行测试，确认红灯
4. 修复代码
5. 运行测试，确认绿灯（Green）
6. 运行完整测试套件，确认无 regression
例外：如果无法稳定自动化复现，提供最小手工复现步骤 + 说明原因，但不能跳过验证结论。
修复完成 ≠ 可以合入。必须回到原 feedback source 确认。
| Feedback source | 修复后动作 |
|---|---|
| 本地猫 reviewer | @reviewer 发送修复确认请求；等 reviewer 明确放行当前 SHA |
| cloud / GitHub review | 在 GitHub 回复或标注修复证据，push 新 SHA 后只重新触发 cloud review，等 PR tracking / review feedback；不要 @ 本地旧 reviewer |
| CI / PR check | 修复后 rerun/check gate；若只是外部 check gate，不需要本地 reviewer 续签 |
| operator / 愿景级 feedback | 回读原始需求；需要价值取舍时带 Decision Packet 给operator |
❌ 错误：cloud P2 修复 → @ 本地旧 reviewer 续签 → 等 cloud → 再 @ 本地 reviewer
✅ 正确：cloud P2 修复 → re-trigger cloud review → 等 PR truth source；local peer 只在非 cloud 行为 delta / scope 扩大时介入
确认信格式（简要，详细版见 refs/ 如有需要）：
## 修复确认请求
| # | 问题 | 状态 | Red→Green |
|---|------|------|-----------|
| P1-1 | {描述} | ✅ | {test file}: FAIL → PASS |
| P2-1 | {描述} | ✅ | {test file}: FAIL → PASS |
测试结果：pnpm test → {X} passed, 0 failed
Commit: {sha} — {message}
请确认修复，确认后执行合入。
修复完成后（F160 Phase C）：
cat_cafe_update_task 状态改为 doneremote review 修了 P1/P2 → 必须 re-trigger remote review，不能自判通过直接合入，也不能把 cloud gate 投射成本地旧 reviewer。
教训（F121 狼人杀）：reviewer 只看代码没打开浏览器，author 连续 9 轮瞎猜修都没被发现。
涉及 UX/前端/交互的改动，reviewer 必须实际打开浏览器操作验证，不能只看代码和测试输出。
验证清单：
1. 打开浏览器（Playwright/Chrome MCP）访问对应页面
2. 按 AC 或 bug 复现步骤实际操作
3. 截图/录屏作为验证证据
4. 如果和设计稿（.pen）有出入，标注差异
没有浏览器验证的前端 review = 走过场。
Reviewer 在 review 过程中发现 author 触发以下任一条件，可直接发起 TAKEOVER（详见 shared-rules §18）：
触发后：在 thread 显式宣布 TAKEOVER → 原 author 停止试错 → 你或另一只猫接手修复。接管猫不得自审，需由另一只猫 review。
| 错误 | 正确做法 |
|---|---|
| 边读边改，没读完 | 读完整反馈，分类后再动手 |
| 有不清晰的问题但先改清晰的 | 全部澄清后再统一动手 |
| 没写 Red 测试直接改代码 | 先写失败测试，确认红灯，再修 |
| 修完自判"对了"直接合入 | 必须回给 reviewer 确认 |
| 全盘接受，零 push back | 有技术理由必须说出来 |
| 愿景级问题用代码 patch | STOP，升级operator，不要硬修 |
| 云端 P1 修完不 re-trigger | 必须重新触发remote review |
| 前端改动只看代码不开浏览器 | 涉及 UX 必须打开浏览器实操验证 |
| 只修 reviewer 指的那一个点（补锅匠） | 先判 failure mode 是否同类，是则 audit 本 PR diff 全扫再修 |
| 同型 finding 打到 R5+ 还在逐轮修 | 第 3 轮就停，升级 plan/spec 作者补状态机（≥3 轮升级规则）——代码层修不掉 spec 层的洞 |
| Skill | 关注点 | 时机 |
|---|---|---|
quality-gate | 自己检查自己（spec + 证据） | 提 review 之前 |
request-review | 发出 review 请求 | 自检通过之后 |
| receive-review（本 skill） | 处理 reviewer 的反馈 | 收到 review 之后 |
merge-gate | 合入前门禁 + PR + remote review | reviewer 放行之后 |
Reviewer 在 review 期间创建的沙盒：
request-review 约定的路径 /tmp/cat-cafe-review/{review-target-id}/{reviewer-handle}为什么不让 reviewer 自己清理：reviewer session 在放行后结束，下次唤醒时 context 已换， 根本不记得自己在 /tmp 留了什么。merge-gate 是唯一确定性终态。
Reviewer 放行（"LGTM"/"通过"/"可以合入"）→ 直接加载 merge-gate skill（SOP stage merge）。不要停下来问operator（§17）。