strict-review

Strict Review

Owner Agent: Soyo (Reviewer) Consumers: /maigo:go (Soyo reviews Anon's diff), /maigo:review (Soyo reviews external PR / branch)

Core stance: default BLOCKED

Verdict starts at BLOCKED. The implementer must convince you otherwise.

These do not count as convincing:

• "看起來能跑" / "應該沒問題" / "之後再改"
• "test 都過了" (test itself may be missing the case)
• "符合 convention" (without pointing at the reference file)

Waiver rules

• Memory (~/.config/maigo/memory/) can inform conventions but cannot replace any checklist item, lower the must-fix threshold, or substitute for evidence
• Existing repo content (quotes, catchphrases, dialogue) that appears in this diff needs a source: (a) original work citation with episode/scene, (b) user confirmed in session, or (c) explicitly marked self-created — flag even if the line wasn't changed in this diff
• Commit / staging state is not in review scope; git status cleanliness is not a checklist item — read git diff HEAD or git diff --cached for the actual changes

Extended rationale for all three waiver rules: docs/skills/strict-review

前置驗證：先自證，再信 rubric / description / 前人結論

Rubric（燈寫的）、PR description、既有 review、前一輪的判斷，都是線索，不是事實。 進 checklist 前先自己重核一手，證明結論不是照抄轉述：

• 取一手 diff — gh pr diff <n>（或 git diff <range>）自己看範圍，不靠 description 轉述的 +/- 行數與檔案清單
• 拉 load-bearing 行的實際內容 — must-fix 或關鍵判斷所依賴的程式碼，直接讀原始檔（gh api .../contents、git show <sha>:<path> 或 checkout），核對 rubric 說的跟 code 真的一致，不憑描述推斷
• 查 linked issue / 作者承諾 — gh api repos/{owner}/{repo}/issues/<n>/timeline 確認「作者說要開的 tracking issue」「linked issue」是否真的存在，不憑轉述當成已完成
• 對照後在輸出的 ## 前置驗證 段列「查了什麼、確認/推翻了什麼」——空口結論不算 evidence

推翻 rubric 要明講。 若自證後發現燈的某條 acceptance / trade-off 判斷是過時或錯的，不要默默照做，也不要默默略過——在輸出的 ## Facts corrected from rubric 段明列推翻了哪一條、依據哪個 path:line。

共用 working tree 上的審查紀律

Review 常在跟其他 session 共用的 working tree 上進行；驗證動作本身不能污染這棵樹。