QA Gate

Validate the assembled feature against the promises in its spec by exercising the public interfaces a real user reaches. The Daemon runs this skill from the unique authored terminal qa Task named by _tasks.md frontmatter; it is part of the Task Graph, not a per-run request. That node depends on every non-QA leaf and therefore becomes runnable only after the graph it closes settles. This skill owns the complete gate: plan, execution, evidence, findings, report, and final verdict. Use the agent's tools and connected servers directly; do not load another QA skill or create a separate living QA tree.

Non-negotiables

1. Real user seat. Enter through the same frontend, API, CLI, data workflow, or documented operational path as the intended actor. Internal helpers and code inspection can diagnose a failure, but cannot prove a user story passes.
2. Proof beyond optimistic state. A pass requires the expected observable, an independent confirmation through a fresh load or another public read path, persistence across refresh/restart when relevant, and captured evidence.
3. Resumable evidence. Create the dated report with every row pending before the first check. Update it after each row so an interrupted run resumes from disk instead of repeating completed work.
4. One honest verdict. Every planned row ends as pass, fail, blocked, or skipped; the report closes with zero pending rows.
5. Typed blocked causes. Record a row that is unreachable for a proved environmental cause as blocked (environment: <cause>) and count it in rows_blocked_environment; record a row stopped by a finding as blocked (finding: <id> — waits on <named failure>) and count it in rows_blocked_finding; record a row that is unreachable for the reason in a matching, pre-run Spec declaration as blocked (declared: <criterion>) and count it in rows_blocked_declared. Keep the three causes separate: never fold one into another to make the report or verdict look cleaner.