Site audit orchestration — high-level pointers (local fallback)

rotom answers “how healthy is this whole site?” by fanning out every other tool and combining the results. The detailed, current orchestration standards — sample-size guidance per site size, how to triage a REVIEW lane before a client handover, and the pre-launch checklist items rotom’s automated lanes don’t cover — live 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.

• Sampling is a tradeoff, not a shortcut — --sample bounds the QA lane (Playwright is heavy); raise it for a pre-launch or pre-handover sweep where every page matters, not just a spot check.
• --full for a genuine pre-launch gate — site-wide lanes (redirects, schema, SEO) default to a 25-URL sample; a launch or migration sign-off should run the unsampled set.
• A FAIL lane blocks a handover — treat any FAIL lane as a stop-ship item until it’s REVIEW or PASS; a “mostly healthy” site audit is not a passed audit.
• Stack routing decides what runs — WordPress/Divi lanes only fire when xatu detects them; don’t assume a lane ran just because the site “looks like” WordPress.
• A missing sibling skill degrades gracefully — rotom reports what it couldn’t run rather than failing the whole audit; install the missing skill and re-run before trusting the gap is closed.
• Composed lanes carry their own limits — read the linked sub-report for context (e.g. timburr sees rendered Divi output, not the Builder DB) before acting on a lane’s verdict alone.
• Discovery quality caps everything downstream — a site with no sitemap/robots only gets the single URL you gave it audited; fix discovery before trusting a “clean” site-wide verdict.

Full playbook → the team wiki’s site-audit orchestration & pre-launch/handover standards.