Inspector core workflows

Three recipes: check a page before shipping, wire the CI gate, and layer in browser smoke checks.

Overview

Inspector detects and reports — it doesn't rewrite anything for you. These are the three workflows that cover most real usage.

•
Workflow 1 — check a single page before you consider it done
Run Protect against the page while you're still editing. Read the rule-by-rule report, fix what needs fixing, and re-run before moving on.
•
Workflow 2 — make sure a bad release can't ship
Wire Protect (and any Playwright smoke checks you have) into the CI gate so a release attempt runs the checks automatically and a failure blocks the deploy rather than relying on someone remembering to look.
•
Workflow 3 — cover a flow a rule check can't see
For flows that matter most — checkout, a signup form, a key click-through — layer in Playwright journeys so a broken render or interaction gets caught even when the metadata looks fine.

Fast, deterministic Protect checks for SEO, schema, accessibility, and recipe rules.
A CI gate that turns those checks into an enforced blocker, not just an advisory report.
Browser-level journeys (building) for what static rule checks structurally can't catch.

Inspector reports; it never rewrites your content or code to fix what it finds — that decision stays yours.
The CI gate only enforces what you've wired into it; an empty gate blocks nothing.
Playwright smoke & journeys and the Inspector MCP server are both still building — check their tier badges before depending on full coverage.