@pmelab/gtd 15.8.0 → 15.10.0

package/README.md

@@ -335,9 +335,11 @@ noted in steps 2, 3, and 4 below.
      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.
+   The reference driver answers this judgment itself (`gtd judge run`, auto
+   selection); if that fails it shows you the message and stops, same as any
+   other question. **The `llm` provider's `p` is self-reported by the model, not
+   a measured probability, so a confidently wrong haiku verdict can skip a
+   question you would have asked.**
 
 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, then reviewed
@@ -349,8 +351,13 @@ noted in steps 2, 3, and 4 below.
    `GTD_JUDGE_ANSWERS` env var, inline JSON — answers one from a file, piped
    between `gtd judge --json` and `gtd judge answer`;
    `gtd judge run --provider jev` asks TypeSafe's Jev instead, with the key in
-   `TYPESAFE_API_KEY` and `JEV_BASE_URL` optionally overriding the endpoint, and
-   exits 1 with nothing on stdout when it cannot answer every question):
+   `TYPESAFE_API_KEY` and `JEV_BASE_URL` optionally overriding the endpoint;
+   `gtd judge run --provider llm` asks the `claude` CLI on `PATH` (Claude Code
+   users only; model `haiku`, `--model <name>` overrides) and reuses its login.
+   With no `--provider`, `gtd judge run` picks jev when `TYPESAFE_API_KEY` is
+   set and non-empty and no `--model` is given, else llm — never falling back
+   across them; `--model` with `--provider fixed`/`jev` is refused. jev and llm
+   exit 1 with nothing on stdout when they cannot answer every question):
    - 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
@@ -358,9 +365,12 @@ noted in steps 2, 3, and 4 below.
    - After a review turn raises concerns: would each one actually violate the
      spec if left unaddressed, or is it a nit?
 
-   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.
+   The reference driver answers these itself (`gtd judge run`, auto selection:
+   jev when `TYPESAFE_API_KEY` is set, else `llm` via `claude`, default model
+   haiku, `--model <name>` overrides); if that fails it shows you the message
+   and stops. **The `llm` provider's `p` is self-reported by the model, not a
+   measured probability, so a confidently wrong verdict can clear the 0.9/0.7
+   floors and skip a gate unattended.**
 
    Once the last package is built, the whole change goes through a qualitative
    review lap before you see anything: one configured skill per turn, each
@@ -383,12 +393,19 @@ noted in steps 2, 3, and 4 below.
 
 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. 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.
+   the process; feedback is judged note by note, each as `edit`, `question`,
+   `nit` or `praise`. An `edit` sends the process back to step 2 for a fresh
+   plan — it never patches over a design you rejected. A `question` is answered
+   inline under your note and the process stops at the review again — no new
+   plan. A `nit` is fixed in one batch, the suite must go green (a red one gets
+   fix turns first), then a fresh review of the change stops at the review
+   again. `praise` is dropped; a round of only praise signs off. When a round
+   mixes them, questions are answered and nits fixed first, then the edits are
+   planned — risk: the planning lap may redo nit fixes it touches. A hand-edit
+   to code always plans a lap. Only a confident non-`edit` verdict skips the
+   replan — a note whose evidence was cut, or that got no verdict, counts as
+   `edit`. 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