Broken-Window Check

Across shift-notes-driven sessions (see shift-notes), agents will sometimes mark a feature complete after unit tests pass — even when the feature is end-to-end broken. The next session opens the repo, sees a green git log, and builds on top of a broken foundation. By the time anyone notices, three features are stacked on the crack.

The check: before picking new work, exercise the most recently "completed" feature end-to-end. If it fails, treat it as your only job this session.

The sequence — run in order, no skipping

1. Read the last "done" entry in the shift notes / feature list (whichever the project uses).
2. Drive the feature end-to-end using the actual runtime path — browser automation, HTTP request, CLI invocation. Not the unit test.
3. Compare observed behavior to the spec — the steps field on the feature, or the acceptance criteria in the spec.
4. If it works — proceed to normal work selection. Note the check in the shift notes ("verified feature N still green").
5. If it fails —
   • git revert the commit that claimed completion (do not force-push).
   • Set that feature's status back to not-done in the feature list.
   • Note in shift notes: "reverted feature N, cause: ".
   • Fix it. That is your entire session.

Do not pick new work on top of a broken previous feature. Ever.