run-dogfood
Run Dogfood
Execute an existing guide from write-dogfood against the product app in a real browser. Fix what fails and build what blocks until every case passes. The deliverable is the run file — every case ID accounted for with quoted screen evidence and, when the case touches server-owned state, a server-side probe that actually ran — plus one report at the end. A chat summary is not the deliverable.
The Iron Law
NO CASE IS TICKED ON THE SCREEN ALONE
A HUMAN TICK IS RECORDED, NEVER A VERDICT
THE RUN ENDS ONLY WHEN EVERY CASE IS PASS OR PARKED — NO REPORT BEFORE THAT
Parked means one of two things only: a case still failing after 3 fix attempts (Gate 3), or a case blocked on something only a person can supply (the list is in unblock.md). Any other fail is a fix to dispatch. Any other blocked is a precondition to build. Both are work, not a report. Waiting on a fix subagent is not a stop: end the turn with no verdict table and no question, and resume when the subagent returns.
If the case's Expect (or backend) touches state the server owns, the run block carries both saw (quoted UI) and server (probe + result) before verdict: pass; pure presentation records server: none — presentational. (Rationalizations below name every excuse for skipping this; Red Flags name the Chrome-ticking trap.)
Probe ladder (strongest first): the UI's own request/response → read-back through the app's API → store peek (DB/file/cache) → reload/restart for durability. A red console error or 5xx fails the case even when the screen looks right — never invent a probe result you did not run.