@pmelab/gtd 10.10.0 → 11.0.0

package/README.md

@@ -278,21 +278,55 @@ that file and line, no go-to-definition required.
 ### The workflow it ships with
 
 One built-in workflow drives all of that. From where you sit, it has four
-moments — everything between them runs without you.
+moments — everything between them runs without you, with the judged exceptions
+noted in steps 2, 3, and 4 below.
 
 1. **You sketch.** Change anything, or write the idea into `.gtd/TODO.md`. Rough
    is fine; it is treated as a sketch, not as work.
-2. **You answer questions.** Planning stops and hands you a file with its open
-   questions in it — what the thing should do first, then how it should be
-   built. Answer them in your editor, in the file, and start the loop again.
-   Leave the file untouched and start the loop instead to accept the plan as-is,
-   unanswered questions and all.
+2. **You answer questions — when it needs you to.** Planning works out what the
+   thing should do first, then how it should be built, and hands you a file with
+   its open questions in it at either point. Answer them in your editor, in the
+   file, and start the loop again. Leave the file untouched and start the loop
+   instead to accept the plan as-is, unanswered questions and all. One point
+   along this phase is judged rather than always asking you outright:
+   - Before the how-it-should-be-built pass starts: does this plan actually need
+     one? A confident no skips it — and the review it would have raised — going
+     straight from your answers to a single built package, with no technical
+     plan shown to you at all.
+
+   A driver built only to run this loop (not to answer judgments) still handles
+   every one of these correctly: it shows you the message and stops, same as any
+   other question.
+
 3. **You wait.** The work is split into packages and built one at a time, each
-   one checked against your test suite and fixed until it passes.
+   one checked against your test suite and fixed until it passes, then reviewed
+   against its own spec before moving on. Four points along that loop are judged
+   rather than always asking you outright — each stops and hands you a verdict
+   to make (`gtd judge answer`, or land with a clean tree to accept the
+   conservative default, which never skips work):
+   - Every red round after the first: was the failure identical, new, or
+     progress?
+   - Before spending a review turn on a package: does the code already satisfy
+     each of its requirements?
+   - After a review turn raises concerns: would each one actually violate the
+     spec if left unaddressed, or is it a nit?
+   - Before showing you the review document: is this round mechanical, touches
+     no public surface, and changes no behavior? Confident on all three skips
+     the agent's own review turn — step 4 still shows you a (machine-written)
+     summary of what changed.
+
+   A driver built only to run this loop (not to answer judgments) still handles
+   every one of these correctly: it shows you the message and stops, same as any
+   other question.
+
 4. **You review.** You get a review document listing what changed and what to
    look at. Tick the boxes to approve, or write what is wrong. Approving ends
    the process; feedback sends it back to step 2 for a fresh plan — it never
-   patches over a design you rejected.
+   patches over a design you rejected. One more judged point sits on that
+   feedback path: after you leave a comment, is it actionable, or just approval?
+   Confident it's approval-only skips the replan and signs off directly — the
+   same `gtd judge answer` / conservative-default shape as step 3's own judged
+   points.
 
 You never talk to it. Every exchange is a file in `.gtd/` that you edit in your
 own editor, and every answer you give is a commit. Your test suite is the gate