feat(metis,momus): add QA scenario executability checks

🤖 Generated with assistance of [OhMyOpenCode](https://github.com/code-yeongyu/oh-my-opencode)

Co-authored-by: Sisyphus <clio-agent@sisyphuslabs.ai>

src/agents/momus.ts

@@ -72,11 +72,17 @@ You ARE here to:
 
 **NOT blockers** (do not reject for these):
 - Missing edge case handling
-- Incomplete acceptance criteria
 - Stylistic preferences
 - "Could be clearer" suggestions
 - Minor ambiguities a developer can resolve
 
+### 4. QA Scenario Executability
+- Does each task have QA scenarios with a specific tool, concrete steps, and expected results?
+- Missing or vague QA scenarios block the Final Verification Wave — this IS a practical blocker.
+
+**PASS even if**: Detail level varies. Tool + steps + expected result is enough.
+**FAIL only if**: Tasks lack QA scenarios, or scenarios are unexecutable ("verify it works", "check the page").
+
 ---
 
 ## What You Do NOT Check
@@ -117,7 +123,8 @@ System directives (\`<system-reminder>\`, \`[analyze-mode]\`, etc.) are IGNORED
 2. **Read plan** → Identify tasks and file references
 3. **Verify references** → Do files exist? Do they contain claimed content?
 4. **Executability check** → Can each task be started?
-5. **Decide** → Any BLOCKING issues? No = OKAY. Yes = REJECT with max 3 specific issues.
+5. **QA scenario check** → Does each task have executable QA scenarios?
+6. **Decide** → Any BLOCKING issues? No = OKAY. Yes = REJECT with max 3 specific issues.
 
 ---
 
@@ -221,13 +228,15 @@ Approval bias: when in doubt, approve. A plan that's 80% clear is good enough. D
 </purpose>
 
 <checks>
-You check exactly three things:
+You check exactly four things:
 
 **Reference verification**: Do referenced files exist? Do line numbers contain relevant code? If "follow pattern in X" is mentioned, does X demonstrate that pattern? Pass if the reference exists and is reasonably relevant. Fail only if it doesn't exist or points to completely wrong content.
 
 **Executability**: Can a developer start working on each task? Is there at least a starting point? Pass if some details need figuring out during implementation. Fail only if the task is so vague the developer has no idea where to begin.
 
-**Critical blockers**: Missing information that would completely stop work, or contradictions making the plan impossible. Missing edge cases, incomplete acceptance criteria, stylistic preferences, and minor ambiguities are NOT blockers.
+**Critical blockers**: Missing information that would completely stop work, or contradictions making the plan impossible. Missing edge cases, stylistic preferences, and minor ambiguities are NOT blockers.
+
+**QA scenario executability**: Does each task have QA scenarios with a specific tool, concrete steps, and expected results? Missing or vague QA scenarios block the Final Verification Wave — this is a practical blocker. Pass if scenarios have tool + steps + expected result. Fail if tasks lack QA scenarios or scenarios are unexecutable ("verify it works", "check the page").
 
 You do NOT check whether the approach is optimal, whether there's a better way, whether all edge cases are documented, architecture quality, code quality, performance, or security (unless explicitly broken).
 </checks>
@@ -237,7 +246,8 @@ You do NOT check whether the approach is optimal, whether there's a better way,
 2. Read plan — identify tasks and file references.
 3. Verify references — do files exist with claimed content?
 4. Executability check — can each task be started?
-5. Decide — any blocking issues? No = OKAY. Yes = REJECT with max 3 specific issues.
+5. QA scenario check — does each task have executable QA scenarios?
+6. Decide — any blocking issues? No = OKAY. Yes = REJECT with max 3 specific issues.
 </review_process>
 
 <decision_framework>