diff --git a/tasks/lessons.md b/tasks/lessons.md
index f20bb50..518c4bf 100644
--- a/tasks/lessons.md
+++ b/tasks/lessons.md
@@ -6,6 +6,13 @@ Recurring mistakes and the rule we adopted so the same issue doesn't bite twice.
 
 ## Sprint 5 (closed 2026-05-28)
 
+### Process — The "git status pre-sprint-close" discipline is still broken, 3 sprints in a row (team-lead)
+**Context** : Sprint 3, sprint 4, AND sprint 5 all shipped initial PRs without the corresponding SPEC.md update (the new section drafted in §0 of the plan sat as `M SPEC.md` in the worktree but was never committed before push). Each time I caught it at the START of the NEXT sprint via `git fetch + git status` revealing the orphan change. Sprint 5 I caught it mid-PR (slightly earlier) but the underlying habit is still broken.
+**Lesson** : the team-lead wrap-up checklist needs a hard step BEFORE the `git push` command: run `git status` AND eyeball every line. If anything shows `M` or `??` that's not the wrap-up commit's own files, decide explicitly. The mental model "I committed everything" is wrong because the §0 SPEC edit is done EARLY in the sprint and forgotten by the time wrap-up commits land. Fix candidates :
+- Stage SPEC.md as part of the FIRST sprint commit (the plan commit), not as a separate later commit.
+- OR add a `make sprint-close-check` target that runs `git status --short | grep -v "^[?][?] tasks/pr-body"` and fails if non-empty.
+- OR add a pre-push hook in the project that warns on `M SPEC.md`.
+
 ### Process — Spec-reviewer 2-pass BEFORE backend dispatch eliminated mid-implementation addenda (team-lead)
 **Context** : Sprint 3 and 4 both required urgent addenda to the backend-builder mid-implementation because the spec-reviewer's 2nd pass arrived after the backend-builder had already started. Sprint 5 explicitly waited for spec-reviewer Pass 2 APPROVED before dispatching backend — and the backend ran straight through with 0 addenda churn. The 2-pass model finally clicked.
 **Lesson** : ALWAYS wait for the spec-reviewer's verdict on the post-edit pass before dispatching the first builder. If Pass 1 returns NEEDS-CHANGES, apply the fixes, request Pass 2, wait for APPROVED, THEN dispatch. The "let's send to builders in parallel to save time" instinct costs more than it saves.