Mark per-milestone review as an M1 experiment

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-17 01:09:08 -07:00
parent bafe3f9fff
commit 19104a9629
2 changed files with 9 additions and 4 deletions
@@ -270,9 +270,14 @@ Builds are deployed to straylight afterwards.
   the plan. For the security-critical parts of M3 the tests are too.
 5. Laguna keeps `docs/implementer-log.md`: one row per task with the date, how many gate runs it
   took, whether the first run passed, any deviation from the task, and anything it stopped on.
-6. Review is once per milestone, by the design model: the branch is checked against the plan, and
-   the gate is run on the development machine. Findings go back as follow-up tasks for Laguna.
-   Trivial or blocking findings may be fixed directly, and the log says so.
+6. Review is once per milestone, by the design model. This is an experiment for M1: after the M1
+   review the owner decides whether to keep it or go back to reviewing each task. The review
+   checks the branch against the plan and runs the gate on the development machine. Findings go
+   back as follow-up tasks for Laguna. Trivial or blocking findings may be fixed directly, and the
+   log says so.
+7. Because nobody checks the work between tasks in M1, each task's "done when" list ends with
+   `make gate` passing, and a task that cannot reach that state stops and reports instead of
+   moving on.

 ## 10. Not covered here