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: <one line>".
   • Fix it. That is your entire session.

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

What "end-to-end" means

The check must exercise the path the user actually takes. Anything less is theater.

Feature shape	Valid check	Invalid check
Web UI button	Puppeteer/Playwright click → observe DOM	expect(handler).toHaveBeenCalled()
HTTP endpoint	curl the route → check status + body	Unit test on the handler function
CLI flag	Invoke the binary with the flag → observe output	Import the parser, assert on the AST
Background job	Trigger it → wait → assert side effect	Assert the job function returns

Red flags, the check is not doing its job