Page QA ship/block policy — high-level pointers (local fallback)

audino tells you the worst verdict across the tools it ran. The detailed, current ship/block policy — how to weigh a combined axew/rapidash/viewvee result, when a REVIEW blocks a release versus just gets logged, and where manual judgement overrides an automated PASS — lives in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• A PASS is “no automated findings,” not a certification — the rules table’s manual-review policies are where human judgement still belongs before calling a page done.
• The overall verdict is the worst of the graded tools — a page that renders fast but fails accessibility is not a pass because performance looked good.
• A BLOCKED tool is not a PASS — bot protection or an interstitial means nothing was assessed; treat it as “unknown,” not “clean.”
• Edit rules/qa-standards.json to match your policy — the shipped rule set is a starter (WCAG AA
  • Core Web Vitals + no-broken-links + core metadata); every audino report inherits a change there.
• --seo is opt-in — decide per engagement whether the search lane (on-page signals, structured data, links) is part of the ship gate or a separate pass.
• A tool that didn’t run is not evidence of quality — a missing card means “not assessed,” and should be treated with the same caution as a failing one.

Full playbook → the team wiki’s page-QA standards & ship/block policy.