@pmelab/gtd 28.1.0 → 29.0.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gtd",
-  "version": "28.1.0",
+  "version": "29.0.0",
   "description": "Drive the gtd loop inside Claude Code: agent turns run as subagents, gtd decides every beat",
   "author": {
     "name": "Philipp Melab"

package/README.md

@@ -336,16 +336,18 @@ questions one at a time, answers your own questions about the plan or the diff,
 records what you decide in the steering file the way the step asks, and moves
 the process on only when you say so; a review you leave untouched signs off.
 While a step runs you can keep asking; requests for changes wait for the next
-rest. When the process finishes, Claude offers to squash it into one commit and
-open its pull request (or run `/gtd ship`). A process can change hands at any
-gate: ask Claude to hand it off (or run `/gtd throw @dev`) and it opens a draft
-pull request assigned to them, and `/gtd catch <pr>` picks it up exactly where
-it waits, so whoever wrote the requirements can hand the architecture to someone
-else. Ship, hand-off and throw answer at once and run in the background, with
-progress on the status line; they report by waking Claude, a toast, a transcript
-line and a push notification, and a failed push or `gh` call reports as a
-failure. While a ship or hand-off runs or is queued, `/gtd catch`, the doors,
-`/gtd <requirements>` and bare `/gtd` wait for its report. See
+rest. When the process finishes, Claude offers to squash it and open its pull
+request(s) (or run `/gtd ship`; `GTD_SHIP_MODE` picks one stacked pull request
+per slice or one commit per slice, see the [driver doc](docs/driver.md)). A
+process can change hands at any gate: ask Claude to hand it off (or run
+`/gtd throw @dev`) and it opens a draft pull request assigned to them, and
+`/gtd catch <pr>` picks it up exactly where it waits, so whoever wrote the
+requirements can hand the architecture to someone else. Ship, hand-off and throw
+answer at once and run in the background, with progress on the status line; they
+report by waking Claude, a toast, a transcript line and a push notification, and
+a failed push or `gh` call reports as a failure. While a ship or hand-off runs
+or is queued, `/gtd catch`, the doors, `/gtd <requirements>` and bare `/gtd`
+wait for its report. See
 [Inside Claude Code](https://github.com/pmelab/gtd/blob/main/docs/driver.md#inside-claude-code-the-gtd-mod).
 
 ### Then let an agent build your own
@@ -568,8 +570,16 @@ home directory — fails every command until you delete it. See
 architecture and package files, the agent first implements the requirements
 directly. A judge checks whether it changed anything outside the expected set
 (tests, steering files; see `seamAllow`). Incidental changes land; a needed seam
-change goes to you for approval and is refactored first; a wrong approach is
-retried twice, then rests for you to steer or overrule it. Details in
+change is refactored first, in its own slice with its own quality lap
+(`refactorQualityReviews`) and review, before the feature is implemented and
+reviewed; a wrong approach is retried twice, then rests for you to steer or
+overrule it. `gtd slices` lists the `refactor` and `feature` slices. Feedback at
+the feature review re-runs design and the implementation, never the naive pass;
+feedback at the refactor review re-runs the refactor, never design; a
+refactor-review change the refactor cannot build is refused, and the only way
+out is `gtd abandon`. A process from 27.5.0 or later whose judge ruled
+`refactor-first` must `gtd abandon` too. Each slice's quality lap reviews only
+that slice. Details in
 [the naive-pass path](docs/configuration.md#the-naive-pass-path).
 
 **Risk tier (flag `GTD_FLAG_RISK_TIER=1`, off by default, needs
@@ -623,9 +633,9 @@ When a process finishes, the landing that closes it also keeps the whole run
 behind a ref, `refs/gtd/history/<entry>`, so a squash or a deleted branch
 doesn't lose it. `/gtd ship` pushes this process's own ref to origin alongside
 the branch (never the others) and writes a `Gtd-History: <ref>` trailer on the
-squash commit. The push is forced, so it replaces origin's copy of that one ref.
-If that push fails, the ship fails and nothing is squashed. Recover the full
-trail with `gtd history fetch | sh`, then `gtd history show <ref>`.
+commit of every slice. The push is forced, so it replaces origin's copy of that
+one ref. If that push fails, the ship fails and nothing is squashed. Recover the
+full trail with `gtd history fetch | sh`, then `gtd history show <ref>`.
 
 ```sh
 gtd history list                 # one line per kept process
@@ -654,8 +664,9 @@ are not process history: `gtd history` does not list them, and the
 `refs/gtd/history/*` refspecs above neither push nor fetch them.
 
 A workflow can rest at an approval gate (`human(name, { approve: true })`; the
-`seamGate` helper does this after a `refactor-first` diff-shape judgment). Only
-a clean `gtd land` approves it, and the commit records who in a
+`seamGate` helper does this for a `refactor-first` diff-shape judgment; the
+shipped flow does not use it). Only a clean `gtd land` approves it, and the
+commit records who in a
 `Gtd-Approved: {"step":"<step>#<n>","name":"<name>","email":"<email>"}` trailer;
 a landing with any edit is refused (as is a script run after the tree changed —
 revert and land again), and `gtd abandon` is the only other way out. `approve`

package/claude/hooks/assist.ts

@@ -119,7 +119,7 @@ function trouble(w: Wake) {
 function finished(w: Wake) {
   return [
     `gtd finished the process on branch ${w.branch}.`,
-    `Tell the person in two or three lines what was built (read the branch's commits), then ask whether to combine it into one commit and open its pull request. On yes, call ${TOOL.ship}.`,
+    `Tell the person in two or three lines what was built (read the branch's commits), then ask whether to squash it and open its pull request(s). On yes, call ${TOOL.ship}.`,
   ]
 }
 

package/claude/hooks/register.tsx

@@ -593,7 +593,7 @@ async function shipNow($: $, isDry: boolean, isInTurn: boolean) {
     isInTurn,
     async () => {
       $.ui.status(isDry ? "previewing the pull request…" : "opening the pull request…")
-      return ship(shipIo($), isDry)
+      return ship(shipIo($), isDry, await $.env.get("GTD_SHIP_MODE"))
     },
     async (shipped) => {
       // a failed ship leaves the run as it was; a dry run changes nothing