broken-window-checklisted

# 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. | Featu