SOP definition: sop-definitions/development.yaml stage review。

Request Review

把当前 diff、最高风险面和真实验证证据送到一只非作者猫眼前。默认只选一个合适的独立验证源；local peer、cloud、愿景守护各按自己的风险触发，不能因为“进入 review”就自动叠加。

先选验证源

安全、数据或契约高风险需要不同视角时可以叠加；叠加理由必须指向不同风险面。相同目的的重复 reviewer 不增加门禁强度，只增加等待。

选择边界：只有新增了需要第二只猫判断的实质内容，或风险面明确要求独立验证时才进入本 skill；“有 diff”“SHA 变了”“开了 PR”都不是独立触发器。机械登记、已审内容转录、低风险 direct-main docs 与可证明 continuity 可以 skip/reuse。一旦选择 review，同一个体不能 review 自己，证据须覆盖最终实质内容（exact SHA 或 continuityProof）。

稀缺判断席位（dossier-driven）

当队友 dossier / L0 把 reviewer 标为周额度稀缺的高杠杆判断猫（当前为 Fable）时，不能沿用普通迭代 reviewer 的默认回路。请求必须写明 engagementMode=one_shot_calibration|final_seal、本轮唯一判断问题、停止条件和修后去向：

• one_shot_calibration：用于重要 plan、架构/failure-mode 校准。reviewer 一次性交付判断和 findings 后退出；作者负责修复与测试，仍需独立验证时转日常 reviewer。
• final_seal：用于其他猫已经完成多轮审查、分歧和证据已整理后的最终封版讨论。只有 scope 已稳定、预期不再进入实现陪练时才选。
• 普通修复不复入原稀缺 reviewer。P1/P2 的严重度不自动等于需要同一只高杠杆猫再次判断；只有修复引入新的架构/决策问题、原 finding 无法机械验收，或 operator 明确要求时才可复入。

稀缺指的是可用判断席位，不是单 token 价格。省下来的额度应留给“判断错的代价高、验证器弱”的节点；routine fix、exact-HEAD 续签、礼貌确认都不占这个席位。

发请求前

前端证据边界

前端验证劳动属于 author：自己启动/复用正确的 preview，走一遍关键交互，并记录 URL、操作和结果。截图、录屏、DOM assertion、Playwright 输出都可以作为证据载体；缺截图本身不是 operator 补劳动的许可证。

• 禁止把“请operator打开页面 / 截图给我”当 review 前置条件。
• 视觉差异需要看画面时，author 自己采截图；浏览器能力暂不可用就如实 BLOCKED 或换可用验证面，不能把劳动转嫁给 operator。
• 未合入改动验证当前 worktree，不能拿 runtime 3003/3004 冒充。

Review packet 深度

结构化轻审

低风险、单一语义面的 diff 直接在当前 thread 或 PR 发，不新增 mailbox 文档：

Review target: <branch@HEAD>
Scope: <changed files / one-line intent>
Risk: <最高风险面，或 none + 理由>
Evidence: <真实命令 / preview 结果>
Engagement: <iterative|one_shot_calibration|final_seal> + <stop condition / repair return>
Ask: checked=<请 reviewer 指认最高风险面> verdict=approve|block

完整 packet

跨组件、状态对象、架构或高风险 change 使用 ../.cat-cafe-shared-refs/review-request-template.md。只有需要跨 session 持久交接时才存 review-notes/YYYY-MM-DD-{topic}-review-request.md；PR/thread 已足够追溯时不另造归档。

完整 packet 额外包含：

• Original Requirements：≤5 行原话 + 真相源路径；
• Architecture Ownership：cell / map delta / why；
• 技术 OQ 与价值 OQ 分开；价值 OQ 才附 Decision Packet；
• 验证命令、输出与 frontend preview 证据；
• Review-Target-ID（需要 review sandbox 时用于 /tmp/cat-cafe-review/{id}/{reviewer}）。

工具落点与工件检查

git status --short
git diff --name-only origin/main...HEAD
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)$'

两条工件命令应无输出。用 apply_patch 时尤其要确认改动只落在目标 worktree，主 worktree 仍干净。

Review sandbox（按需）

只有 reviewer 需要启动未合入应用时才创建 detached / read-only sandbox：

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

统一入口 pnpm review:start，请求中记录实际 web/api 端口。只审 diff 或治理文字时不启动 sandbox；要改代码则 TAKEOVER，另开正式 worktree。

Verdict return route

Review Entry Mode Classifier（先于 task / PR tracking）

exact-HEAD external PR review 在写 task 或 PR tracking instructions 时就必须定型，不能等 verdict 出来再补出口：

• reviewMode=formal（默认）：任务必须授权写回同一 GitHub subject。formal task/tracker 出现 no-comment、 “不要评论 GitHub”或“不落 GitHub”即互相矛盾，fail closed；退回改写，不能私下做完。
• reviewMode=advisory_read_only（必须显式）：允许只读私下审计，但输出只能是 advisory findings；不得产出 APPROVE / REQUEST_CHANGES 完成态，也不得进入 review-complete。
• local_cat handoff：继续走 author cat route，不因 review target 是 PR 而强制 GitHub comment。

先按 author/custody/handoff source 判 external / local_cat / unknown，再判 mode。不要把缺少 GitHub 写入授权 静默解释为 advisory；没有显式 advisory_read_only 就按 formal 冲突处理。PR tracking 路径同样适用，旧 instructions 中的 no-comment 禁令必须在新 HEAD 复审前清除。

正式结论前按 author/custody/handoff source 分类，repo 名和 GitHub login 不参与分类：

• 外部作者或 external PR / Issue custody：verdict 必须写回同一 GitHub subject，并绑定精确 PR HEAD / Issue body digest；没有 review/comment URL 就还没完成。

• 本地猫通过 @ / handoff 交来的 review：默认走 author cat route。direct review carrier 是直接承载本轮 review 请求、并被 lease 记录为 predecessorThreadId 的 thread；它压过任务祖先 thread、旧 sourceThreadId 与继承 coordination。开始真实 review 链时，同 thread 用 post_message(coordination.phase=active)，跨 thread 用 cross_post_message(coordination.phase=active)；final verdict 用同一 carrier 的 coordination.phase=terminal 回 direct review carrier。结构化 action 失败后的普通消息降级必须留在该 carrier，并显式带 coordination={phase:"active", subjectRef:"<same subjectRef>"}；不得裸继承旧链。包内带 final HEAD / content digest 与独立验证证据，不强制 GitHub comment。

  invocation-bound local review lease 的 final post 必须在同一次调用里同时带显式 clientMessageId 与 typed localReviewVerdict（approved | changes_requested | commented）。coordination.phase=terminal 只确定返还路由， 不能代替 verdict 事实；漏字段会在持久化前返回 400 local_review_verdict_required。公开正文格式不参与授权。

两条完成证据不能互相代偿。本地 review 只有在 merge-gate、repository rule 或 operator 明确要求时才额外写 GitHub；额外 artifact 不取代回作者猫的 custody。

terminal verdict 是这条 direct review coordination 的最后一次必达投递。作者确认 exact target、no open items 后直接进入 merge-gate 或 clean-stop；不再为了“出口必须有 @”回传 courtesy ACK。即使作者补发礼貌 ACK，terminal fence 也只持久化、不再唤醒 reviewer。

已完成 review lease 只有出现需要判断力的新信息才可重开。新 exact HEAD 复审必须携带 reviewReentry：behavioral_delta、stale_or_blocking 或 explicit_matrix_route 三选一，并附 durable evidenceRef；初审省略该字段。cloud finding 不是把本地旧 reviewer 拉回来的理由，纯 ACK / 状态复述 / 无新信息也不是。

需要额外 GitHub artifact 时，家里共享 GitHub login 不能用 gh pr review --approve 自我账号审批，应使用 gh pr comment {N} --body-file <verdict.md> 留逻辑 verdict，并包含：

• APPROVE / REQUEST_CHANGES / COMMENT；
• 覆盖的 final HEAD SHA；
• 独立验证证据；
• reviewer 自己的身份签名。

共享 login 不改变“author catId ≠ reviewer catId”的铁律，也不能把平台 self-review 当成跨个体 review。

Feedback 循环

• 普通 iterative review 的 P1/P2 修复后，只让提出该 finding 的活跃 review source覆盖新 HEAD。
• 稀缺席位的 one_shot_calibration / final_seal findings 交回 author；普通修复不复入原稀缺 reviewer，仍需独立确认时选日常 reviewer 覆盖真实 delta 或 final HEAD。
• cloud finding 修复回 cloud；local finding 修复回 local。不要把二者叠成常驻双门。
• R2+ 同型 finding 再出现时，author 给出 Failure-Mode Sweep（pattern / scanned / fixed / N/A），避免 reviewer 逐点补锅。

正反灰例

• 正例：skill/SOP 语义改动 → 一只跨族 local peer，targeted checks，跳 cloud。
• 正例：auth callback 变更 → cloud + full gate；若还需要家里状态语义，再有理由叠 local。
• 反例：local 已审纯文案，又因“流程到了”触发 cloud。
• 反例：author 没 preview，要求 operator 截图后才肯发 review。
• 灰例：前端 copy-only 改动仍应由 author preview；截图可选，DOM/页面证据足够时不阻塞。

Common Mistakes

和其他 skill 的区别

• quality-gate：author 自证；本 skill 是选中 local peer 后的独立验证。
• receive-review：处理已经收到的 finding。
• merge-gate：消费选定 review source 与验证证据，决定合入。

下一步

收到 local verdict 后进入 receive-review；放行且证据覆盖 final HEAD 后进入风险匹配的 merge-gate。