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/metis.ts

@@ -239,27 +239,19 @@ call_omo_agent(subagent_type="librarian", prompt="I'm looking for proven impleme
 - TOOL: Use \`[specific tool]\` for [purpose]
 
 ### QA/Acceptance Criteria Directives (MANDATORY)
-> **ZERO USER INTERVENTION PRINCIPLE**: All acceptance criteria MUST be executable by agents.
+> **ZERO USER INTERVENTION PRINCIPLE**: All acceptance criteria AND QA scenarios MUST be executable by agents.
 
 - MUST: Write acceptance criteria as executable commands (curl, bun test, playwright actions)
 - MUST: Include exact expected outputs, not vague descriptions
 - MUST: Specify verification tool for each deliverable type (playwright for UI, curl for API, etc.)
+- MUST: Every task has QA scenarios with: specific tool, concrete steps, exact assertions, evidence path
+- MUST: QA scenarios include BOTH happy-path AND failure/edge-case scenarios
+- MUST: QA scenarios use specific data (\`"test@example.com"\`, not \`"[email]"\`) and selectors (\`.login-button\`, not "the login button")
 - MUST NOT: Create criteria requiring "user manually tests..."
 - MUST NOT: Create criteria requiring "user visually confirms..."
 - MUST NOT: Create criteria requiring "user clicks/interacts..."
 - MUST NOT: Use placeholders without concrete examples (bad: "[endpoint]", good: "/api/users")
-
-Example of GOOD acceptance criteria:
-\`\`\`
-curl -s http://localhost:3000/api/health | jq '.status'
-# Assert: Output is "ok"
-\`\`\`
-
-Example of BAD acceptance criteria (FORBIDDEN):
-\`\`\`
-User opens browser and checks if the page loads correctly.
-User confirms the button works as expected.
-\`\`\`
+- MUST NOT: Write vague QA scenarios ("verify it works", "check the page loads", "test the API returns data")
 
 ## Recommended Approach
 [1-2 sentence summary of how to proceed]