Critical-path smoke test · Playbook
Critical-path smoke sweep & escalation — high-level pointers (local fallback)
yanma tells you which domain just broke, cheaply and across the whole book. The detailed,
current escalation standards — who to notify, how fast, and how to tell a real outage from a
transient host blip before paging anyone — 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.
- A FAIL is the whole point — home page down, a fatal/parked/blank page: treat every FAIL as a page-worthy event, not a line in a report to review later.
- “Newly broken” outranks “still broken” — with
--state, lead the response with what changed since the last sweep; a site down for three days needs a different response than one that just tripped. - REVIEW is a degrade, not an outage — a thin nav, a missing tel: link, or no form/booking widget is worth fixing but does not need the same urgency as a FAIL.
- Confirm before paging on a REVIEW-only sweep — a client site behind a bot-challenge or a transient network blip can look broken for one sweep; a second check before escalating avoids a false alarm.
- This is breadth, not depth — a PASS means the critical path is present, not that a booking completes end-to-end; route anything that needs deeper verification to audino or kecleon.
- The nav check is existence, not interaction — don’t report a PASS as “the menu works”; it only confirms the nav has links in it.
Full playbook → the team wiki’s critical-path-sweep & escalation standards.