request-review

name	request-review
description	向跨家族 peer-reviewer 发送 review 请求（含五件套）。 Use when: 自检通过后准备请其他猫 review。 Not for: 收到 review 结果（用 receive-review）、自检（用 quality-gate）。 Output: Review 请求信（存档到 review-notes/）。
triggers	["请 review","帮我看看","request review"]

SOP 位置: 本 skill 是 sop-definitions/development.yaml stage review 的执行细节。 SOP definition: sop-definitions/development.yaml stage review。 上一步: quality-gate | 下一步: receive-review

Request Review

把改动送到 reviewer 眼前，让 reviewer 花时间在重点上——不是基础检查上。

核心知识

前置条件（三项都要满足才能发请求）

条件	检查方式	未满足时
quality-gate 通过	有本轮 gate report	BLOCKED — 先跑 quality-gate
测试全绿	附测试命令输出	BLOCKED — 修到绿灯再发
原始需求可引用	Discussion/Interview 文档路径 + ≤5 行摘录	BLOCKED — reviewer 有权拒绝审查
Architecture ownership 已声明	附 Architecture cell / Map delta / Why	BLOCKED — 回 Design Gate / plan 补齐
前端改动已浏览器实测	Playwright/Chrome 截图证据	BLOCKED — 涉及前端必须真实打开浏览器验证
根目录工件闸门通过	无根目录媒体/设计工件（工作树 + 已提交差异）	BLOCKED — 先归档/清理再发

教训（F041）：review 信只附了 spec，没附原始 Discussion。结果 multiple remote review rounds 全在抓 edge case，没有一轮说"UI 不可用"。Reviewer 没有上下文，无法做愿景验证。

Reviewer 匹配规则

从 cat-config.json 动态匹配，三猫都不能 review 自己的代码：

优先级（从高到低）：
1. 跨 family（author family ↔ reviewer family）
2. peer-reviewer 角色标记
3. 当前可用（无正在进行的 review 任务）

工具落点自检（Codex apply_patch 陷阱）

在 worktree 分支上用 apply_patch 改代码时，改动可能落到主 worktree（cat-cafe/）而非当前 worktree。发请求前必须确认：

git status  # 只在目标 worktree 有变更，主 worktree 干净

流程

BEFORE 发 review 请求:

1. 确认 quality-gate 已通过（拿到本轮 gate report）
2. 确认测试全绿（附这次真实运行的输出）
3. 找到原始 Discussion 文档路径 + 摘录 ≤5 行operator experience
4. 抄入 Architecture ownership 三字段（F191）：
   - `Architecture cell: ...`
   - `Map delta: none | update required | new cell required`
   - `Why: ...`
5. 检查 worktree 工具落点（git status 干净）
5.5 检查根目录工件闸门（两条都要为空）：
   - `git status --short | rg '^.. [^/]+\.(png|jpe?g|webp|gif|webm|mp4|mov|wav|pdf|pen)$'`
   - `git diff --name-only origin/main...HEAD | rg '^[^/]+\.(png|jpe?g|webp|gif|webm|mp4|mov|wav|pdf|pen)$'`
6. 匹配 reviewer（跨 family 优先）
7. 用模板写 review 请求 → 存档 mailbox
8. 发给 reviewer

Review 请求

使用 refs/review-request-template.md 模板（单一真相源，不在此重复）。

关键字段提醒：

• Original Requirements: 必填，≤5 行operator experience + 来源文档路径，并明确请 reviewer 对照判断
• Architecture Ownership: 必填，列 Architecture cell / Map delta / Why，并请 reviewer 检查 diff 是否与 Map delta 一致
• Open Questions: 分为两类——技术 OQ（给 reviewer 的，如实现正确性）和 价值 OQ（需要 operator 判断的，附 Decision Packet——格式见 refs/decision-matrix.md）。不混在一起
• 自检证据: 附 quality-gate report 摘要 + 测试命令输出 + 根目录工件闸门输出

F191 reviewer 视角：

• PR 是否新建了并行 Store / Queue / Router / Adapter / Dispatcher / Binding？
• Map delta: none 是否与 diff 一致？
• 若修改了 docs/architecture/ownership/cells/*.md，是否真是 owner/boundary/extension point/canonical anchor 变化？

Reviewer 怎么把 verdict 落到 PR 上（GPT 系 offline / 跨家族不可用降级到Ragdoll互 review 时尤其要看）：

• ❌ 不要 gh pr review --approve —— 所有猫猫共享一个 GitHub 账号 zts212653，author 和 reviewer 是同一 GH login，GraphQL 会直接报 Review Can not approve your own pull request。白费 token，已多次踩雷
• ✅ 正路 gh pr comment {N} --repo … --body-file <verdict.md> —— logical-approve 落 issue comment（生成 #issuecomment-* 锚点，PR 时间线可追溯），评论正文写明：verdict（APPROVE/REQUEST-CHANGES/COMMENT）、覆盖的 HEAD SHA、独立验证证据（不要只信 author 转述）、签名
• 这条不是降级方案，是同 GH 账号下的标准路径。完整说明 + 教训锚点（cat-cafe#941）见 refs/opensource-ops-inbound-pr.md §self-approve / COMMENTED review 段——inbound PR 和内部 PR 一视同仁
• 案例：cat-cafe#2357 / #2359（2026-06-17，GPT 系 offline 降级到 47 review 46 author）— 47 撞了两次 --approve 失败才记起这条规则，已沉淀到 feedback_intake_review_on_github

存档：review-notes/YYYY-MM-DD-{topic}-review-request.md

Review 沙盒约定（review-target-id）

Review 请求必须包含 review-target-id，reviewer 据此创建标准路径的沙盒，merge-gate 回收时依赖此 ID。

review-target-id 推导规则：

• 分支名含 fNNN → 取 feature ID（如 f113）
• 无 Feature ID → 取 branch slug（如 fix-redis-keyprefix）

在 review 请求信中附上：

Review-Target-ID: {id}
Branch: {branch-name}

Reviewer 创建沙盒的标准路径：

/tmp/cat-cafe-review/{review-target-id}/{reviewer-handle}

例：/tmp/cat-cafe-review/f113/codex

Reviewer 启动命令（统一入口）：

pnpm review:start

说明：

• 该入口默认在 review 沙盒内运行，自动分配隔离端口（起点 3201/3202）
• review 请求信里必须记录实际启动端口（web/api）

沙盒必须是 detached HEAD / read-only。要改代码 = TAKEOVER，开正式 worktree。

Block 场景

❌ 没有 quality-gate 报告

⚠️ BLOCKED — 缺少 quality-gate 自检报告

请先运行 quality-gate skill，确认：
- 原始需求逐项对照
- 测试/lint/build 全绿
- 有本轮输出证据

再发 review 请求。

❌ 没有原始需求摘录

⚠️ BLOCKED — 缺少原始需求文档

请附上：
- operator Discussion/Interview 文档路径
- ≤5 行operator experience摘录

Reviewer 不只审代码质量，还要判断"这是operator要的吗？"
没有原始需求 = Reviewer 无法做愿景验证 = 有权拒绝审查。

❌ 测试未通过

⚠️ BLOCKED — 测试未全绿

请先修复，再发请求：
  pnpm test                              # 必须 0 failures
  pnpm --filter @cat-cafe/api test:redis # Redis 改动额外跑

Reviewer 不应该是第一个发现测试失败的人。

Reviewer 视角：Failure-Mode Sweep Report（§16e）

R2+ 且同型 finding 再次出现时，reviewer 应期待 author 在 PR comment 提交 Failure-Mode Sweep Report（pattern name / scanned N / fixed / N/A 列表）。没有 Sweep Report = author 没做 failure-mode audit → reviewer 有权要求补做后再继续 review，不浪费 round 逐点抓同型。

和其他 skill 的区别

Skill	关注点	时机
quality-gate	自检（spec 对照 + 证据）	review 之前
request-review（本 skill）	把改动送到 reviewer 面前	自检通过之后
receive-review	处理 reviewer 的反馈	收到 review 之后
merge-gate	合入前的门禁 + PR + remote review	reviewer 放行之后

下一步

Review 请求发出后 → 等 reviewer 回复 → 直接加载 receive-review skill 处理反馈（SOP stage review）。SOP 链条自动推进，不要停下来问operator（§17）。