@pmelab/gtd 6.6.0 → 6.8.0

package/dist/gtd.bundle.mjs

@@ -189107,27 +189107,46 @@ const isReviewBaseState = (def, state) => def.states[state]?.reviewBase === true
 const reviewEntryStateOf = (def) => {
 	for (const [name, state] of Object.entries(def.states)) if (state.reviewEntry === true) return name;
 };
-/**
-* `gtd(<actor>): <state>` — the subject a step commit carries. Per decision
-* 2, `<actor>` is WHO AUTHORED THE STEP (the invoker), and `<state>` is the
-* state being ENTERED; `resolveState` reads back only the state name.
-*/
-const stateSubject = (actor, state) => `gtd(${actor}): ${state}`;
+/** The ` → ` that separates a transition subject's source state from its target. */
+const TRANSITION_SEP = " → ";
+/**
+* `gtd(<actor>): <from> → <to>` — the subject a step commit carries. Per
+* decision 2, `<actor>` is WHO AUTHORED THE STEP (the invoker); `<to>` is the
+* state being ENTERED and `<from>` the state the authored changes were made
+* in, so the subject reads as what this commit DID, not just where the machine
+* is headed. `from` is optional: when it is omitted or equals `to` (a
+* self-loop, or a manual entry like `gtd review` that has no meaningful
+* source), the subject collapses to the bare `gtd(<actor>): <to>` form.
+* `resolveState` reads back only `<to>` — the ` → ` prefix is human context.
+*/
+const stateSubject = (actor, to, from) => from === void 0 || from === to ? `gtd(${actor}): ${to}` : `gtd(${actor}): ${from}${TRANSITION_SEP}${to}`;
 const SUBJECT_RE = /^gtd\(([^()]+)\): (.+)$/;
 /**
-* Parse a raw commit subject as `gtd(<actor>): <state>`. Returns `undefined`
-* for anything else (non-gtd, malformed, or missing either half) — never
-* throws. Trims surrounding whitespace before matching.
+* Parse a raw commit subject as `gtd(<actor>): <from> → <to>` (or the bare
+* `gtd(<actor>): <to>` form). Returns `undefined` for anything else (non-gtd,
+* malformed, or missing either half) — never throws. Trims surrounding
+* whitespace before matching. `state` is always the ENTERED state (`<to>`, the
+* segment after the last ` → `); the pre-arrow segment, when present, is
+* surfaced as `from` for display but is never consulted by `resolveState`.
 */
 const parseStateSubject = (subject) => {
 	const match = SUBJECT_RE.exec(subject.trim());
 	if (match === null) return void 0;
 	const actor = match[1];
-	const state = match[2];
-	if (actor === void 0 || actor === "" || state === void 0 || state === "") return void 0;
+	const rest = match[2];
+	if (actor === void 0 || actor === "" || rest === void 0 || rest === "") return void 0;
+	const sepIndex = rest.lastIndexOf(TRANSITION_SEP);
+	if (sepIndex === -1) return {
+		actor,
+		state: rest
+	};
+	const from = rest.slice(0, sepIndex);
+	const state = rest.slice(sepIndex + 3);
+	if (from === "" || state === "") return void 0;
 	return {
 		actor,
-		state
+		state,
+		from
 	};
 };
 /**
@@ -189288,9 +189307,9 @@ const applyRetry = (def, target, trace, visited = /* @__PURE__ */ new Set()) =>
 * steps are the default, silent case. A match's target is retry-redirected
 * (`applyRetry`) before being classified: a commit-state target yields a
 * `"squash"` decision carrying its `commit` template verbatim; anything
-* else yields a `"commit"` decision naming the `gtd(<invoker>): <to>` subject
-* to write — `<invoker>` is who authored this step, per decision 2, not `to`'s
-* own declared actor (see `StepCommit`'s doc comment). Throws only on a
+* else yields a `"commit"` decision naming the `gtd(<invoker>): <from> → <to>`
+* subject to write — `<invoker>` is who authored this step, per decision 2, not
+* `to`'s own declared actor (see `StepCommit`'s doc comment). Throws only on a
 * structurally invalid call (an undefined
 * `state`, or a commit-state `state` — stepping AT a commit state is a
 * caller error: a commit state ends the process, `resolveState` never rests
@@ -189331,7 +189350,7 @@ const step = (def, state, invoker, payload) => {
 	if (targetDef.actor === void 0) throw new Error(`step: "${finalTarget}" is not a commit state but declares no actor`);
 	return {
 		kind: "commit",
-		subject: stateSubject(invoker, finalTarget),
+		subject: stateSubject(invoker, finalTarget, state),
 		actor: invoker,
 		from: state,
 		to: finalTarget
@@ -190070,7 +190089,7 @@ var Cwd = class Cwd extends Tag("Cwd")() {
 * schema.ts` (run via `jiti`, a plain TS-via-Babel loader with no bundler-
 * style pluggable per-extension loaders) can import JUST the schema without
 * risking a transitive pull into the bundled workflow templates
-* (`./workflows/templates.js`, which imports `simple.yaml`/`advanced.yaml` as
+* (`./workflows/templates.js`, which imports `unified.yaml` as
 * raw text via tsdown's/vitest's `.yaml`-as-text loader — something `jiti` has
 * no equivalent for and doesn't need here): the schema shape never depends on
 * any workflow's content.
@@ -190374,7 +190393,7 @@ const compileRcVars = (raw) => {
 * there is nothing to fall back to — the user must scaffold one with
 * `gtd init`. Exported so the CLI layer and tests can assert on it verbatim.
 */
-const NO_WORKFLOW_MESSAGE = "gtd: no workflow configured — run `gtd init <simple|advanced>` to create .gtdrc.json";
+const NO_WORKFLOW_MESSAGE = "gtd: no workflow configured — run `gtd init` to create .gtdrc.json";
 /**
 * Compile the decoded config's `workflow:` key plus its top-level
 * `vars:`/`modes:` keys into `ConfigOperations`. `root` is used as the
@@ -191366,11 +191385,8 @@ var WorktreeReader = class WorktreeReader extends Tag("WorktreeReader")() {
 	}));
 };
 //#endregion
-//#region src/workflows/advanced.yaml
-var advanced_default = "# The \"advanced\" gtd workflow template — written verbatim into `.gtdrc.json`\n# (nested under a `workflow:` key) by `gtd init advanced`. See\n# docs/examples/advanced-workflow.md for the full state-by-state walkthrough\n# and STATES.md §10 for how it relates to the \"simple\" template.\n#\n# This is the fuller machine: two-phase human-in-the-loop planning\n# (grilling ⇄ grilling-answer for the product plan, architecting ⇄\n# architecting-answer for the technical plan), task decomposition\n# (decompose → .gtd/tasks/), a deterministic per-task builder queue (picking →\n# building → checking/fixing), agent-prepared review (reviewing → await-review),\n# and a squash finale (squashing → done, a `commit:` state that collapses the\n# whole cycle into one commit whose message the agent authored in\n# .gtd/COMMIT_MSG.md).\n#\n# Every content string below is INLINE (no `./`-relative file references): the\n# bundled templates ship inside a single-file build (`dist/gtd.bundle.mjs`), so\n# their content must already be resolved at BUILD time rather than read from\n# disk at RUNTIME. `advanced.yaml` is imported as raw text (tsdown's `.yaml`\n# text loader / the vitest rawMd transform), so this module never touches the\n# filesystem.\n#\n# `gtd init advanced` DERIVES the scaffolded `.gtdrc.json` from this inline\n# source (src/workflows/templates.ts `renderInitScaffold`): each agent state's\n# `prompt:` below is written out as an editable `gtd-prompts/<state>.md` file\n# and the config value is rewritten to a `./gtd-prompts/<state>.md` reference\n# `compileWorkflowConfig` inlines back at load time. Human `message:`/check\n# `script:` bodies and the `done` `commit:` template stay inline in the config.\n# This YAML stays fully inline regardless — the split happens only at scaffold\n# time, on real disk.\n\nvars:\n  testCommand: npm test\n  todoFile: .gtd/TODO.md\n  architectureFile: .gtd/ARCHITECTURE.md\n  reviewFile: .gtd/REVIEW.md\n  feedbackFile: .gtd/FEEDBACK.md\n  # The two model tiers every agent state draws from (see the model comment at\n  # `grilling` below). Both are opaque harness hints — repoint them here (or\n  # via a top-level `.gtdrc` `vars:` key / a `GTD_VAR_plannerModel` env var) to\n  # change every state on that tier at once.\n  plannerModel: smart\n  coderModel: base\n\nstates:\n  idle:\n    actor: human\n    initial: true\n    message: |\n      No active gtd cycle.\n\n      To start one: write `.gtd/TODO.md` with a short sketch of what you want\n      built — a few sentences is enough — then run `gtd step human`.\n    on:\n      \"* **\": grilling\n\n  grilling:\n    actor: agent\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    # `model` is an opaque harness hint — gtd never interprets this string, it\n    # only passes it through to `gtd next --json`/`gtd status --json` so the\n    # driving loop can map it onto whatever models its agent harness provides.\n    # Every agent state draws its tier from a `vars` model entry (see `vars:`\n    # above) so the tiers repoint in one place: `plannerModel` (default\n    # \"smart\") names the heavier tier for the one-shot planning/architecting/\n    # reviewing turns, `coderModel` (default \"base\") the tier for the\n    # decompose/build/fix/squash turns.\n    model: <%= it.vars.plannerModel %>\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state (plans, task specs, review records) — never create, edit, or\n      delete anything under `.gtd/` except `<%= it.vars.todoFile %>`, which\n      this prompt tells you to write.\n\n      `<%= it.vars.todoFile %>` holds the plan under development. Read it,\n      then develop it into a concrete, product-level plan in this one turn —\n      explore the codebase before asking anything, so every open question is\n      one the codebase genuinely cannot answer.\n\n      Scope: product and user-facing decisions only. Leave implementation\n      details (file/module structure, data models, tech-stack choices) for\n      the next phase (`.gtd/ARCHITECTURE.md`).\n\n      For every remaining open question, add it under a `## Open Questions`\n      heading near the top, one `### <question>` sub-heading each, its body\n      your suggested answer in plain prose (always suggest one — the human\n      accepts it by leaving it untouched, or overrides it by editing it). Omit\n      the section entirely once there are none.\n\n      If `.gtd/TODO.md` already carries a `## Open Questions` section from a\n      previous lap, the human has now responded to that whole batch: fold every\n      one of those questions into the plan — the human's edit where they gave\n      one, your own suggestion where they left it untouched (an untouched\n      suggestion IS acceptance) — and MOVE each resolved `### <question>` block\n      down into a `## Answered Questions` section at the bottom. Raise any\n      genuinely new questions under `## Open Questions` at the top.\n\n      Leave `.gtd/TODO.md` uncommitted and finish your turn — do not commit,\n      and do not run `gtd step agent` yourself; the harness does that.\n    on:\n      \"* **\": grilling-answer\n\n  grilling-answer:\n    actor: human\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.todoFile %>` holds the plan under development, with any\n      open questions under `## Open Questions` — each carrying a suggested\n      answer.\n\n      To answer a question, edit its body in place, then run\n      `gtd step human`; leave a suggestion untouched to accept it as-is. On the\n      next lap the agent folds every answered question into the plan and moves\n      it down to `## Answered Questions`.\n\n      To accept all suggested answers as-is and move on to technical\n      architecting, run `gtd step human` with no edits.\n    on:\n      \"C\": architecting\n      \"* **\": grilling\n\n  architecting:\n    actor: agent\n    file: <%= it.vars.architectureFile %>\n    mode: qa\n    model: <%= it.vars.plannerModel %>\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.architectureFile %>` and `<%= it.vars.todoFile %>`, which\n      this prompt tells you to write and delete respectively.\n\n      Read `<%= it.vars.todoFile %>` (the converged product plan) and\n      develop `<%= it.vars.architectureFile %>` from it in this one turn:\n      file/module structure, data models, library/tech-stack choices,\n      error-handling strategy — the *how*, building on the *what* already\n      settled. Do not re-open product-level decisions from\n      `<%= it.vars.todoFile %>`; treat them as settled.\n\n      For every remaining open question, add it under a `## Open Questions`\n      heading the same way as the grilling phase (one `### <question>`\n      sub-heading, its body your suggested answer in plain prose). Omit the\n      section once there are none. On a return lap, fold the whole answered\n      batch into the plan and move each resolved `### <question>` block down\n      into a `## Answered Questions` section at the bottom, exactly as grilling\n      does.\n\n      Once `<%= it.vars.architectureFile %>` is written, delete\n      `<%= it.vars.todoFile %>` — its content has been folded in and it must\n      not linger.\n\n      Leave everything uncommitted and finish your turn.\n    on:\n      \"* **\": architecting-answer\n\n  architecting-answer:\n    actor: human\n    file: <%= it.vars.architectureFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.architectureFile %>` holds the technical plan under\n      development, with any open questions under `## Open Questions`.\n\n      To answer a question, edit its body in place, then run `gtd step human`;\n      leave a suggestion untouched to accept it as-is.\n\n      To accept all suggested answers as-is and move on to decomposing the\n      work, run `gtd step human` with no edits.\n    on:\n      \"C\": decompose\n      \"* **\": architecting\n\n  decompose:\n    actor: agent\n    model: <%= it.vars.coderModel %>\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except the\n      task-spec files this prompt tells you to write (under `.gtd/tasks/`),\n      and `.gtd/ARCHITECTURE.md`, which it tells you to delete.\n\n      Read `.gtd/ARCHITECTURE.md` (the converged technical plan) and\n      decompose it into an ordered set of self-contained task files under\n      `.gtd/tasks/` (e.g. `.gtd/tasks/01-short-name.md`,\n      `.gtd/tasks/02-short-name.md`, ...). Order them so the test suite can\n      pass again after each one lands; each file is self-contained\n      (description, acceptance criteria as `- [ ]` checkboxes, relevant\n      paths) since a building turn receives only that one file as context.\n\n      No task file may reference any other `.gtd/` file, or a requirement to\n      preserve/update workflow state — `.gtd/` is machine-managed and gets\n      cleaned up as the cycle proceeds.\n\n      Once the task files are written, delete `.gtd/ARCHITECTURE.md`. Leave\n      everything uncommitted and finish your turn.\n    on:\n      \"* .gtd/tasks/**\": picking\n\n  picking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn (the queue arbiter) — the loop driver executes this\n      # verbatim, then steps the check actor. Mechanics only: take the\n      # first task file (by name) under .gtd/tasks/ into .gtd/NEXT.md, or\n      # remove .gtd/NEXT.md when the queue is empty. What NEXT.md's\n      # presence/absence MEANS (another task to build vs. the queue closing\n      # out to review) is decided by this state's own `on` rules at capture\n      # time — never here.\n      set +e\n      next=$(ls .gtd/tasks/*.md 2>/dev/null | head -n 1)\n      if [ -n \"$next\" ]; then\n        printf '%s' \"$next\" > .gtd/NEXT.md\n      else\n        rm -f .gtd/NEXT.md\n      fi\n    on:\n      \"D .gtd/NEXT.md\": reviewing\n      \"* .gtd/NEXT.md\": building\n      \"C\": reviewing\n\n  building:\n    actor: agent\n    model: <%= it.vars.coderModel %>\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create or edit anything under `.gtd/` except deleting the\n      one task file this prompt tells you to delete; never touch\n      `.gtd/NEXT.md` yourself — the `picking` state owns it.\n\n      The task file to implement is: <%~ it.read(\".gtd/NEXT.md\") %>\n\n      Read that file and implement EXACTLY the one task it describes — no\n      more, no less; leave every other task file under `.gtd/tasks/`\n      untouched. Use TDD discipline: one test, then the implementation that\n      passes it, then the next — never write all the tests first.\n\n      Delete the task file once its work is complete and verified. Leave\n      everything else uncommitted and finish your turn.\n    on:\n      \"* **\": checking\n\n  checking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — the loop driver executes this verbatim, then steps\n      # the check actor. Mechanics only: run the test suite and record a\n      # red run's output as .gtd/FEEDBACK.md. What that output MEANS (another\n      # fix round vs escalation) is decided by the workflow's own `on`/`retry`\n      # rules at capture time — never here.\n      #\n      # `it.vars.testCommand` defaults to \"npm test\" (this workflow's own\n      # `vars:` above) — override it with a top-level `.gtdrc`\n      # `vars: { testCommand: ... }` key, or a `GTD_VAR_testCommand`\n      # environment variable (highest precedence).\n      set +e\n      mkdir -p .gtd\n      <%~ it.vars.testCommand %> > .gtd/.check-output 2>&1\n      code=$?\n      if [ \"$code\" -ne 0 ]; then\n        if [ -s .gtd/.check-output ]; then\n          mv .gtd/.check-output .gtd/FEEDBACK.md\n        else\n          rm -f .gtd/.check-output\n          printf 'npm test failed with exit code %s and produced no output.' \"$code\" > .gtd/FEEDBACK.md\n        fi\n      else\n        rm -f .gtd/.check-output\n      fi\n    on:\n      \"A .gtd/FEEDBACK.md\": fixing\n      \"M .gtd/FEEDBACK.md\": fixing\n      \"C\": picking\n\n  fixing:\n    actor: agent\n    file: <%= it.vars.feedbackFile %>\n    model: <%= it.vars.coderModel %>\n    retry:\n      max: 3\n      otherwise: escalate\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.feedbackFile %>`, which this prompt tells you to address.\n\n      Read `<%= it.vars.feedbackFile %>` (the failing test output) and fix\n      the code so the suite passes. Keep the change focused — do not\n      refactor unrelated code. If the feedback is wrong, empty or delete\n      `<%= it.vars.feedbackFile %>` instead of \"fixing\" a non-issue; the\n      machine picks the dispute up either way.\n\n      Leave everything uncommitted and finish your turn — do not commit.\n    on:\n      \"* **\": checking\n\n  escalate:\n    actor: human\n    file: <%= it.vars.feedbackFile %>\n    message: |\n      The agent could not get the check to pass after repeated attempts.\n      `<%= it.vars.feedbackFile %>` holds the last failing output.\n\n      Investigate and fix it yourself (editing code and/or\n      `<%= it.vars.feedbackFile %>`), then run `gtd step human` to try the\n      check again.\n    on:\n      \"* **\": checking\n\n  reviewing:\n    actor: agent\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    model: <%= it.vars.plannerModel %>\n    # A direct entry point: `gtd review <commitish>` starts a fresh review\n    # process here over `<commitish>..HEAD` (e.g. a colleague's PR branch).\n    reviewEntry: true\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.reviewFile %>`, which this prompt tells you to write.\n\n      Write `<%= it.vars.reviewFile %>` to help a human review the cycle's\n      full diff (inlined below): group hunks semantically (same\n      feature/refactor/fix, even across files), and for each group write a\n      short heading, an explanation of what changed and why, and\n      `- [ ] ./path/to/file.ts#42` style file pointers (checkboxes are for\n      the human to tick, not you).\n\n      Leave `<%= it.vars.reviewFile %>` uncommitted and finish your turn.\n      <% if (it.processDiff.trim()) { %>\n\n      ## Full cycle diff\n\n      ```diff\n      <%~ it.processDiff %>\n      ```\n      <% } %>\n    on:\n      \"* .gtd/REVIEW.md\": await-review\n\n  await-review:\n    actor: human\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    # While the cycle rests here for human review, gtd opens a \"review checkout\n    # window\": HEAD and the index are temporarily rewound to this cycle's start\n    # (the process boundary — no `reviewBase` state is declared, so the base\n    # defaults to it) with the working tree untouched, so the whole cycle diff\n    # surfaces as ordinary uncommitted changes in the editor's git integration.\n    # The window closes automatically on the next invocation, once the cycle\n    # rests anywhere else (see src/ReviewWindow.ts, STATES.md §11).\n    reviewWindow: true\n    message: |\n      `<%= it.vars.reviewFile %>` holds the review record for the completed\n      cycle.\n\n      To approve: delete `<%= it.vars.reviewFile %>` and run\n      `gtd step human`.\n\n      To request changes: edit `<%= it.vars.reviewFile %>` (or the code)\n      with what's wrong — including just ticking its checkboxes — then run\n      `gtd step human`; this sends the cycle back through grilling with your\n      feedback as the new input.\n    on:\n      \"D .gtd/REVIEW.md\": squashing\n      \"* **\": grilling\n\n  squashing:\n    actor: agent\n    model: <%= it.vars.coderModel %>\n    prompt: |\n      You are an autonomous coding agent. The cycle is approved and done.\n      `.gtd/` holds this workflow's own state — never create, edit, or delete\n      anything under `.gtd/` except `.gtd/COMMIT_MSG.md`, which this prompt\n      tells you to write.\n\n      Write `.gtd/COMMIT_MSG.md` with ONE conventional-commits message for\n      the entire cycle (subject line `type(scope): subject`, imperative mood,\n      <= 72 characters; a body explaining the why, trade-offs, and key\n      decisions). Plain text, no markdown wrapper.\n\n      Leave `.gtd/COMMIT_MSG.md` uncommitted and finish your turn — entering\n      this file squashes the whole cycle into one commit using its content as\n      the message.\n      <% if (it.processDiff.trim()) { %>\n\n      ## Full cycle diff\n\n      ```diff\n      <%~ it.processDiff %>\n      ```\n      <% } %>\n    on:\n      \"A .gtd/COMMIT_MSG.md\": done\n      \"M .gtd/COMMIT_MSG.md\": done\n\n  done:\n    commit: |\n      <%~ it.read(\".gtd/COMMIT_MSG.md\") %>\n\n      Token cost: <%= it.processCost %>\n      <% it.processCostByModel.forEach(function(m){ %>\n      - <%= m.model %>: <%= m.cost %>\n      <% }) %>\n";
-//#endregion
-//#region src/workflows/simple.yaml
-var simple_default = "# The \"simple\" gtd workflow template — written verbatim into `.gtdrc.json`\n# (nested under a `workflow:` key) by `gtd init simple`. gtd ships no default\n# workflow: a repo picks one of the bundled templates with `gtd init`, and a\n# state command run with no workflow configured fails (see src/Config.ts).\n# See STATES.md §10 for the walkthrough and docs/examples/advanced-workflow.md\n# for the fuller `advanced` template.\n#\n# Compiled through the exact same `compileWorkflowConfig` a user's `.gtdrc`\n# `workflow:` key goes through — no privileged code path\n# (src/workflows/templates.ts does the compiling).\n#\n# Every content string below is INLINE (no `./`-relative file references):\n# the bundled templates ship inside a single-file build\n# (`dist/gtd.bundle.mjs`), so their content must already be resolved at BUILD\n# time rather than read from disk at RUNTIME. `simple.yaml` itself is imported\n# as raw text (tsdown/vitest both treat `.yaml` as text — see\n# tsdown.config.ts / tests/vitest.rawMd.ts), so this file never needs a\n# sibling prompts/ directory to exist on disk once installed.\n#\n# `gtd init simple` DERIVES the scaffolded `.gtdrc.json` from this inline\n# source (src/workflows/templates.ts `renderInitScaffold`): each agent state's\n# `prompt:` below is written out as an editable `gtd-prompts/<state>.md` file\n# and the config value is rewritten to a `./gtd-prompts/<state>.md` reference\n# `compileWorkflowConfig` inlines back at load time. Human `message:`/check\n# `script:` bodies stay inline in the config. This YAML stays fully inline\n# regardless — the split happens only at scaffold time, on real disk.\n#\n# States, in cycle order — 10 states, no squash:\n#   idle (initial, human, message)\n#     -> grilling (agent, prompt): reads .gtd/TODO.md's sketch (or a prior\n#     lap's feedback), explores the codebase, and develops it into a concrete\n#     implementation plan, stating any open question it can't settle itself\n#     under a `## Open Questions` heading rather than guessing silently. Its\n#     `file:`/`mode:` (TODO.md/`qa`) makes the plan's format checkable — it\n#     self-validates before finishing (see \"Steering-file validation\" below).\n#   grilling -> grilling-answer (human, message): answer a question by\n#     editing its body in place, or leave a suggestion untouched to accept it;\n#     a clean step accepts every remaining suggestion -> building; any edit\n#     loops back to grilling (which folds the whole answered batch into the\n#     plan and moves it down to `## Answered Questions`).\n#   grilling-answer -> building (agent, prompt): implements the plan in\n#     .gtd/TODO.md directly (no task decomposition, no per-task queue) and\n#     deletes .gtd/TODO.md once the work is complete and verified.\n#   building -> checking (check, script): runs the test command inline;\n#     A/M .gtd/FEEDBACK.md -> fixing (capped, redirects to escalate); D\n#     .gtd/FEEDBACK.md (a green run that just cleaned up prior feedback) or C\n#     (green, nothing to clean) -> reviewing.\n#   fixing (agent, prompt) <-> checking\n#   escalate (human, message): manual intervention, then back to checking\n#   checking (green) -> reviewing (agent, prompt): writes .gtd/REVIEW.md in\n#     the checkbox review format, grouping the cycle's full diff into\n#     reviewable chunks; its `file:`/`mode:` (REVIEW.md/`review`) makes that\n#     format checkable, so it self-validates before finishing. `reviewing`\n#     ALSO declares `reviewEntry: true` — a second way in: `gtd review\n#     <commitish>` (a clean tree resting at idle) writes an empty\n#     `gtd(human): reviewing` entry commit carrying <commitish>'s hash as a\n#     `Gtd-Review-Base:` trailer, starting a brand new process that reviews\n#     <commitish>..HEAD (e.g. a colleague's PR branch) through this exact same\n#     reviewing/await-review/feedback-lap machinery.\n#   reviewing -> await-review (human, message): tick a pointer's `- [\n#     ]` to `- [x]` to approve that item; deleting .gtd/REVIEW.md outright is\n#     the power-user approve-everything shortcut; anything else pending\n#     (code edits with REVIEW.md untouched) is feedback straight to grilling.\n#   await-review -> review-deciding (check, script), entered by any `M\n#     .gtd/REVIEW.md` step: if no unticked `- [ ]` pointer remains, the cycle\n#     is approved (rm .gtd/REVIEW.md -> idle); otherwise the still-unticked\n#     pointers (with their notes) are extracted into a fresh .gtd/TODO.md and\n#     .gtd/REVIEW.md is removed (-> grilling, feedback lap).\n#\n# The cycle ends at human approval, resting back at idle — there is no\n# squash state. The cycle's commits stay in history; whether/how to squash\n# them (amend, interactive rebase, a PR's squash-merge) is entirely the\n# human's business once they're done reviewing — gtd makes no assumption.\n# That squash-flavored finale (a `squashing` prompt state + a `done` commit\n# state) still exists as an ENGINE capability (see STATES.md §8) and is kept\n# as part of the fuller machine at docs/examples/advanced-workflow.md.\n#\n# A `gtd(<actor>): idle` commit — entering the workflow's own initial state —\n# is therefore a PROCESS BOUNDARY (see `computeProcessRun` in src/Edge.ts):\n# the next cycle's `retry` counts, `startCommit`, and diffs never reach back\n# across an approved cycle's own idle-entering commit.\n#\n# HYGIENE INVARIANT (asserted in e2e — see default-workflow.feature): an\n# approved cycle leaves `.gtd/` empty. FEEDBACK.md is cleaned up by a green\n# `checking` run; REVIEW.md by the review-deciding approval branch; TODO.md by\n# `building`.\n#\n# Steering-file validation. `grilling` and `reviewing` each declare a\n# `file:`/`mode:` pair (TODO.md as `qa`, REVIEW.md as `review`), so their\n# output has a checkable format. src/OpenQuestions.ts and src/ReviewDoc.ts are\n# those two formats' EXECUTABLE SPECS (their unit tests are the format spec\n# tests), and `gtd validate` FORMATS the resolved state's rendered `file:` in\n# place then runs the SAME parser over it, exiting non-zero with findings when\n# it violates the format. There is no in-machine validation state and no bash\n# port to keep in sync — the producing agent self-validates before finishing\n# (plain `gtd next` appends the \"run `gtd validate` and fix all violations\"\n# instruction; under `--json` the driving loop runs it after the turn and\n# re-prompts on findings — see skills/loop/SKILL.md), AND `gtd step` runs the\n# same format-and-validate gate on capture, refusing a turn whose steering file\n# is invalid. So the check runs after a human edits too — at the human gates\n# `grilling-answer` (TODO.md) and `await-review` (REVIEW.md) — and a human gate\n# is only ever handed a tidy, well-formed file. The same parsers back the LSP's\n# live diagnostics (src/Lsp.ts).\n#\n# Every agent state draws its `model` from a `vars` tier entry (see `vars:`\n# below and the comment at `grilling`) rather than a hardcoded string, so both\n# tiers repoint in one place: `plannerModel` (default \"smart\") for the heavier\n# one-shot planning/reviewing turns (`grilling`, `reviewing`), `coderModel`\n# (default \"base\") for the coding turns (`building`, `fixing`). Both are opaque\n# hints the driving loop maps onto its harness.\n#\n# The four agent states each declare a `memory:` scope label (`plan`,\n# `build`, `fix`, `review` — see the comment at `grilling` below) — another\n# opaque hint a memory-aware driver reads to decide when an agent turn keeps\n# the previous turn's memory and when it starts fresh: a loop that re-enters\n# one state (grilling around its answer loop, fixing around checking) keeps\n# the same label and retains memory across its laps; crossing to the next\n# phase's differently-labelled state clears it. gtd never interprets the\n# label (see STATES.md §1 and skills/loop/SKILL.md's driver contract).\n#\n# `vars.testCommand` is this workflow's own declared default for `checking`'s\n# script (see it.vars in PatternTemplates.ts) — override it per-repo with a\n# top-level `.gtdrc` `vars: { testCommand: ... }` key, or per-invocation with\n# a `GTD_VAR_testCommand` environment variable (highest precedence).\n#\n# `vars.todoFile`/`reviewFile`/`feedbackFile` are this workflow's ONE source\n# of truth for the three steering-file paths every prompt/script below reads\n# or writes — each appears in templates as `<%~ it.vars.todoFile %>` etc\n# (see docs/design/state-file-association.md §2). Every state that rests on\n# one of these files also declares a `file:`/`mode:` pair (see STATES.md's\n# property table) so `gtd status`/`gtd next --json` and the LSP (`gtd lsp`)\n# know which file a human/editor should look at, and in what format\n# (`qa` for TODO.md's open-questions format, `review` for REVIEW.md's\n# checkbox format) — `fixing`/`escalate` declare `file:` alone (FEEDBACK.md\n# is plain text, no LSP format). KNOWN LIMITATION: `on` pattern keys below are\n# NOT Eta templates — they keep the LITERAL `.gtd/...` paths matching these\n# vars' DEFAULT values. Repointing `todoFile`/`reviewFile`/`feedbackFile` via\n# `.gtdrc`'s top-level `vars:` or a `GTD_VAR_` override changes what `file:`\n# renders to (and what a template reads/writes) WITHOUT changing what the\n# `on` patterns match against — desyncing the machine. See\n# docs/configuration.md's `file:`/`mode:` section for the full caveat.\n#\n# A fuller machine — two-phase Q&A planning, an architecture phase, task\n# decomposition, a deterministic per-task builder loop, agent-prepared\n# review, and the squash finale (`squashing` + `done`) — is preserved as a\n# copy-paste `.gtdrc` example at docs/examples/advanced-workflow.md.\n\nvars:\n  testCommand: npm test\n  todoFile: .gtd/TODO.md\n  reviewFile: .gtd/REVIEW.md\n  feedbackFile: .gtd/FEEDBACK.md\n  # The two model tiers every agent state draws from (see the model comment at\n  # `grilling` below). Both are opaque harness hints — repoint them here (or\n  # via a top-level `.gtdrc` `vars:` key / a `GTD_VAR_plannerModel` env var) to\n  # change every state on that tier at once.\n  plannerModel: smart\n  coderModel: base\n\nstates:\n  idle:\n    actor: human\n    initial: true\n    # Every human-gate `message:` below closes with the SAME rendered block —\n    # a \"What each change does next\" list built from `it.edges`, the resting\n    # state's own `on` edges (see PatternTemplates.TemplateContext.edges). Each\n    # edge's human-readable route lives in its `describe:` (the single source\n    # of truth), so the list can never drift from the routing it documents.\n    # The block skips edges without a `describe`, and each `<%~ ... \"\\n\" %>`\n    # keeps the bullet's own newline (Eta's autoTrim strips the template's own\n    # line breaks around `<% %>` tags, not text inside an interpolation).\n    message: |\n      No active gtd cycle.\n\n      To start one, write `.gtd/TODO.md` with a short sketch of what you want\n      built — a few sentences is enough.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"* **\":\n        to: grilling\n        describe: >-\n          Save your sketch to `.gtd/TODO.md` (any working-tree change) to start\n          the cycle — the agent reads it, explores the codebase, and develops it\n          into a concrete implementation plan (**grilling**).\n\n  grilling:\n    actor: agent\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    # `model` is an opaque harness hint — gtd never interprets this string, it\n    # only passes it through to `gtd next --json`/`gtd status --json` so the\n    # driving loop can map it onto whatever models its agent harness provides.\n    # Every agent state draws its tier from a `vars` model entry (see `vars:`\n    # above) so the tiers repoint in one place: `plannerModel` (default\n    # \"smart\") names the heavier tier for the one-shot planning/reviewing\n    # turns, `coderModel` (default \"base\") the tier for the coding turns.\n    model: <%= it.vars.plannerModel %>\n    # `memory` is an opaque memory-scope label — gtd never interprets it, it\n    # only passes it through to `gtd next --json`/`gtd status --json` so a\n    # memory-aware driving loop can decide when an agent turn continues from\n    # the previous turn's memory and when it starts fresh: consecutive agent\n    # turns that emit the SAME label share memory, a change (or the first\n    # turn) is where the driver starts fresh. `grilling` re-enters itself\n    # around the grilling-answer loop, so labelling every lap\n    # `plan` keeps the planner's accumulated exploration across the loop; the\n    # next phase (`building`) carries a different label, clearing it.\n    memory: plan\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.todoFile %>`, which this prompt tells you to develop.\n\n      `<%= it.vars.todoFile %>` holds a short sketch of what to build (or\n      feedback from a prior review lap). Read it, explore the codebase, and\n      develop it into a concrete implementation plan.\n\n      For every question you cannot settle yourself, add it under a\n      `## Open Questions` heading near the top, one `### <question>`\n      sub-heading each, its body your suggested answer in plain prose (always\n      suggest one — the human accepts it by leaving it untouched, or overrides\n      it by editing it). Omit the section entirely once there are no open\n      questions.\n\n      If `<%= it.vars.todoFile %>` already carries a `## Open Questions`\n      section from a previous lap, the human has now responded to that whole\n      batch: fold every one of those questions into the plan — using the\n      human's edit where they gave one, your own suggested answer where they\n      left it untouched (an untouched suggestion IS acceptance) — and MOVE each\n      resolved `### <question>` block down into a `## Answered Questions`\n      section at the very bottom, keeping it as a record. Raise any genuinely\n      new questions this lap under `## Open Questions` at the top.\n\n      Leave `<%= it.vars.todoFile %>` uncommitted and finish your turn — do\n      not commit, and do not run `gtd step agent` yourself; the harness does\n      that.\n    on:\n      \"* **\": grilling-answer\n\n  grilling-answer:\n    actor: human\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.todoFile %>` holds the plan under development, with any\n      open questions under `## Open Questions` — each carrying a suggested\n      answer. Answer a question by editing its body in place; leave a\n      suggestion untouched to accept it as-is. On the next lap the agent folds\n      every answered question into the plan and moves it down to\n      `## Answered Questions`.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"C\":\n        to: building\n        describe: >-\n          Change nothing to accept every suggested answer as-is and move on to\n          implementation (**building**).\n      \"* **\":\n        to: grilling\n        describe: >-\n          Edit the plan — answer a question, add detail, or raise a new one — to\n          send it back for another round of grilling (**grilling**).\n\n  building:\n    actor: agent\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    model: <%= it.vars.coderModel %>\n    # A distinct memory scope from `plan`: implementation starts fresh, with\n    # the plan already settled in `.gtd/TODO.md` (which this prompt reads\n    # below) rather than carried in the planner's working memory.\n    memory: build\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create or edit anything under `.gtd/` except deleting\n      `<%= it.vars.todoFile %>`, which this prompt tells you to delete once\n      its work is complete.\n\n      The plan to implement is: <%~ it.read(it.vars.todoFile) %>\n\n      Read that plan and implement it in full. Use TDD discipline: one test,\n      then the implementation that passes it, then the next — never write\n      all the tests first.\n\n      Delete `<%= it.vars.todoFile %>` once the work it describes is complete\n      and verified. Leave everything else uncommitted and finish your turn.\n    on:\n      \"* **\": checking\n\n  checking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — the loop driver executes this verbatim, then\n      # steps the check actor. Mechanics only: run the test suite and record a\n      # red run's output as .gtd/FEEDBACK.md. What that output MEANS (another\n      # fix round vs escalation) is decided by the workflow's own `on`/`retry`\n      # rules at capture time — never here.\n      #\n      # `it.vars.testCommand` defaults to \"npm test\" (this workflow's own\n      # `vars:` above) — override it with a top-level `.gtdrc`\n      # `vars: { testCommand: ... }` key, or a `GTD_VAR_testCommand`\n      # environment variable (highest precedence).\n      #\n      # A green run also removes any `<%= it.vars.feedbackFile %>` left over\n      # from an earlier red run — there is no squash to discard it for us\n      # anymore, so the script cleans it up itself before moving on to\n      # review.\n      set +e\n      mkdir -p .gtd\n      <%~ it.vars.testCommand %> > .gtd/.check-output 2>&1\n      code=$?\n      if [ \"$code\" -ne 0 ]; then\n        if [ -s .gtd/.check-output ]; then\n          mv .gtd/.check-output <%~ it.vars.feedbackFile %>\n        else\n          rm -f .gtd/.check-output\n          printf 'npm test failed with exit code %s and produced no output.' \"$code\" > <%~ it.vars.feedbackFile %>\n        fi\n      else\n        rm -f .gtd/.check-output\n        rm -f <%~ it.vars.feedbackFile %>\n      fi\n    on:\n      \"A .gtd/FEEDBACK.md\": fixing\n      \"M .gtd/FEEDBACK.md\": fixing\n      \"D .gtd/FEEDBACK.md\": reviewing\n      \"C\": reviewing\n\n  fixing:\n    actor: agent\n    file: <%= it.vars.feedbackFile %>\n    model: <%= it.vars.coderModel %>\n    # Its own memory scope: the fix loop re-enters `fixing` around `checking`\n    # (up to the retry cap), so labelling every attempt `fix` lets the agent\n    # remember what it already tried across the loop; a green check moves on\n    # to the differently-labelled `reviewing`, clearing it.\n    memory: fix\n    retry:\n      max: 3\n      otherwise: escalate\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.feedbackFile %>`, which this prompt tells you to address.\n\n      Read `<%= it.vars.feedbackFile %>` (the failing test output) and fix\n      the code so the suite passes. Keep the change focused — do not\n      refactor unrelated code. If the feedback is wrong, empty or delete\n      `<%= it.vars.feedbackFile %>` instead of \"fixing\" a non-issue; the\n      machine picks the dispute up either way.\n\n      Leave everything uncommitted and finish your turn — do not commit.\n    on:\n      \"* **\": checking\n\n  escalate:\n    actor: human\n    file: <%= it.vars.feedbackFile %>\n    message: |\n      The agent could not get the check to pass after repeated attempts.\n      `<%= it.vars.feedbackFile %>` holds the last failing output.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"* **\":\n        to: checking\n        describe: >-\n          Fix the failure yourself — edit the code and/or `.gtd/FEEDBACK.md` —\n          to re-run the check (**checking**).\n\n  reviewing:\n    actor: agent\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    model: <%= it.vars.plannerModel %>\n    # A distinct memory scope again: the reviewer looks at the cycle's full\n    # diff (inlined into its prompt) with a fresh perspective, not the\n    # builder's or fixer's working memory.\n    memory: review\n    # `gtd review <commitish>` (a plain non-gtd branch, e.g. a colleague's PR)\n    # enters here directly, recording the resolved base as a `Gtd-Review-Base:`\n    # trailer on its empty entry commit — everything below then reuses the\n    # existing reviewing/await-review/feedback-lap machinery unmodified over\n    # <commitish>..HEAD (see STATES.md §11).\n    reviewEntry: true\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.reviewFile %>`, which this prompt tells you to write.\n\n      Write `<%= it.vars.reviewFile %>` to help a human review the cycle's\n      full diff (inlined below) in this EXACT format:\n\n      - First non-blank line: `# Review: <%= it.currentCommit.slice(0, 7) %>`\n      - Somewhere in the document: `<!-- base: <%= it.startCommit %> -->`\n      - At least one `## <Chunk Title>` heading, grouping hunks semantically\n        (same feature/refactor/fix, even across files) — a short explanation\n        of what changed and why, then one\n        `- [ ] ./path/to/file.ts#42 — note` file pointer per hunk (checkboxes\n        are for the human to tick, not you; every path is `./`-relative, with\n        an optional `#line` and an optional ` — note`).\n\n      Leave `<%= it.vars.reviewFile %>` uncommitted and finish your turn.\n      <% if (it.processDiff.trim()) { %>\n\n      ## Full cycle diff\n\n      ```diff\n      <%~ it.processDiff %>\n      ```\n      <% } %>\n    on:\n      \"* **\": await-review\n\n  await-review:\n    actor: human\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    # While the cycle rests here for human review, gtd opens a \"review checkout\n    # window\": HEAD and the index are temporarily rewound to this cycle's start\n    # (the process boundary — no `reviewBase` state is declared, so the base\n    # defaults to it) with the working tree untouched, so the whole cycle diff\n    # surfaces as ordinary uncommitted changes in the editor's git integration.\n    # The window closes automatically on the next invocation, once the cycle\n    # rests anywhere else (see src/ReviewWindow.ts, STATES.md §11).\n    reviewWindow: true\n    message: |\n      `<%= it.vars.reviewFile %>` holds the review record for the completed\n      cycle — one `- [ ]` checkbox per reviewable item, grouped into chunks.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"D .gtd/REVIEW.md\":\n        to: idle\n        describe: >-\n          Delete `.gtd/REVIEW.md` outright to approve the whole cycle at once\n          and rest back at the start (**idle**).\n      \"M .gtd/REVIEW.md\":\n        to: review-deciding\n        describe: >-\n          Edit `.gtd/REVIEW.md` — tick a `- [ ]` box to `- [x]` to approve that\n          item, or add notes — to hand it to a deterministic check\n          (**review-deciding**) that closes the cycle out when every box is\n          ticked, or extracts the still-unticked items into a fresh\n          `.gtd/TODO.md` and loops back through **grilling** with that feedback.\n      \"* **\":\n        to: grilling\n        describe: >-\n          Change only code, leaving `.gtd/REVIEW.md` untouched, to send that as\n          feedback straight back to **grilling**.\n\n  review-deciding:\n    actor: check\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — the loop driver executes this verbatim, then\n      # steps the check actor. Mechanics only: if .gtd/REVIEW.md still has any\n      # unticked \"- [ ]\" pointer, extract those pointers (with their notes)\n      # into a fresh .gtd/TODO.md; either way, remove .gtd/REVIEW.md. What\n      # the resulting diff MEANS (feedback lap vs. full approval) is decided\n      # by this state's own `on` rules at capture time — never here. The\n      # A/M .gtd/TODO.md row is declared BEFORE the D .gtd/REVIEW.md row (see\n      # this workflow's `on` map below) so a feedback lap — which always also\n      # deletes .gtd/REVIEW.md — is captured as feedback, not mistaken for an\n      # approval.\n      set +e\n      mkdir -p .gtd\n      if grep -qE '^[[:space:]]*-[[:space:]]*\\[[[:space:]]*\\]' <%~ it.vars.reviewFile %> 2>/dev/null; then\n        {\n          echo \"Feedback from review — address these before continuing:\"\n          echo\n          grep -E '^[[:space:]]*-[[:space:]]*\\[[[:space:]]*\\]' <%~ it.vars.reviewFile %>\n        } > <%~ it.vars.todoFile %>\n      fi\n      rm -f <%~ it.vars.reviewFile %>\n    on:\n      \"A .gtd/TODO.md\": grilling\n      \"M .gtd/TODO.md\": grilling\n      \"D .gtd/REVIEW.md\": idle\n      \"C\": await-review\n";
+//#region src/workflows/unified.yaml
+var unified_default = "# The unified gtd workflow template — written verbatim into `.gtdrc.json`\n# (nested under a `workflow:` key) by `gtd init` (no argument). gtd ships no\n# default workflow: a repo picks this bundled template with `gtd init`, and a\n# state command run with no workflow configured fails (see src/Config.ts).\n# See STATES.md §10 for the full walkthrough.\n#\n# Compiled through the exact same `compileWorkflowConfig` a user's `.gtdrc`\n# `workflow:` key goes through — no privileged code path\n# (src/workflows/templates.ts does the compiling). Every content string below\n# is INLINE (no `./`-relative file references): the bundled template ships\n# inside a single-file build (`dist/gtd.bundle.mjs`), so its content must\n# already be resolved at BUILD time. `gtd init` DERIVES the scaffolded\n# `.gtdrc.json` from this inline source (`renderInitScaffold`): each agent\n# state's `prompt:` is written out as an editable `gtd-prompts/<state>.md`\n# file; human `message:`/check `script:`/the `done` `commit:` body stay inline.\n#\n# ── Three entry points, one shared tail ────────────────────────────────────\n#\n# The initial `idle` state FORKS on which steering file the human creates:\n#\n#   * .gtd/REQUIREMENTS.md -> the ADVANCED flow (product + technical Q&A,\n#     package decomposition, per-package parallel build + agentic spec-review).\n#   * anything else (e.g. .gtd/TODO.md) -> the SIMPLE flow (one grilling Q&A\n#     loop, a monolithic build, no decomposition, no agentic review).\n#\n# A third entry, `gtd review <commitish>`, jumps straight to `reviewing`\n# (reviewEntry) to review a foreign branch through the same shared tail.\n#\n# All three converge at `reviewing` -> `await-review`. From there:\n#   * full sign-off (tick every box, or delete REVIEW.md) -> squashing -> done\n#     (the ONLY path to the finale — the whole cycle collapses into one commit).\n#   * partial sign-off / notes -> review-deciding extracts the unticked items\n#     into REVIEW_FEEDBACK.md -> feedback-building implements them -> checking\n#     -> reviewing regenerates an INCREMENTAL REVIEW.md (review-deciding carries\n#     `reviewBase: true`, so each feedback round's review + checkout window\n#     covers only `last-review..HEAD`) -> await-review, looping until sign-off.\n#   * a code-only human edit (REVIEW.md untouched) -> checking -> reviewing.\n#\n# The shared health segment (`checking`/`fixing`/`escalate`) serves the simple\n# build, the feedback loop, and code-only edits — its green edge targets\n# `reviewing`. The advanced per-package loop keeps its OWN health triple\n# (`adv-checking`/`adv-fixing`/`adv-escalate`) because its green edge targets\n# the per-package `spec-review` gate instead.\n#\n# KNOWN LIMITATION: `on` pattern keys are NOT Eta templates — they keep the\n# LITERAL `.gtd/...` paths matching these vars' DEFAULT values. Repointing a\n# file var changes what templates read/write WITHOUT changing what the `on`\n# patterns match, desyncing the machine (see docs/configuration.md).\n\nvars:\n  testCommand: npm test\n  todoFile: .gtd/TODO.md\n  requirementsFile: .gtd/REQUIREMENTS.md\n  architectureFile: .gtd/ARCHITECTURE.md\n  packagesDir: .gtd/packages\n  nextFile: .gtd/NEXT.md\n  reviewFile: .gtd/REVIEW.md\n  reviewFeedbackFile: .gtd/REVIEW_FEEDBACK.md\n  feedbackFile: .gtd/FEEDBACK.md\n  specFeedbackFile: .gtd/SPEC_FEEDBACK.md\n  commitMsgFile: .gtd/COMMIT_MSG.md\n  # The two opaque model tiers every agent state draws from — repoint them here\n  # (or via a top-level `.gtdrc` `vars:` key / a `GTD_VAR_plannerModel` env var)\n  # to change every state on that tier at once. `plannerModel` (default \"smart\")\n  # is the heavier tier for the one-shot planning/architecting/review turns;\n  # `coderModel` (default \"base\") is the tier for the build/fix turns.\n  plannerModel: smart\n  coderModel: base\n\nstates:\n  # ── Shared entry ────────────────────────────────────────────────────────\n  idle:\n    actor: human\n    initial: true\n    # Every human-gate `message:` below closes with the same rendered \"What\n    # each change does next\" list, built from `it.edges` (the resting state's\n    # own `on` edges — each edge's `describe:` is the single source of truth).\n    message: |\n      No active gtd cycle.\n\n      To start one, create a steering file describing what you want built:\n\n      - `.gtd/TODO.md` — a short sketch — starts the SIMPLE flow (plan, build,\n        review).\n      - `.gtd/REQUIREMENTS.md` — the product requirements — starts the ADVANCED\n        flow (product + technical Q&A, package decomposition, parallel build,\n        per-package agentic review).\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"* .gtd/REQUIREMENTS.md\":\n        to: adv-grilling\n        describe: >-\n          Save the product requirements to `.gtd/REQUIREMENTS.md` to start the\n          ADVANCED flow — the agent develops them through product then technical\n          Q&A, decomposes the work into packages, and builds each in parallel\n          (**adv-grilling**).\n      \"* **\":\n        to: grilling\n        describe: >-\n          Save a short sketch to `.gtd/TODO.md` (or any other change) to start\n          the SIMPLE flow — the agent reads it, explores the codebase, and\n          develops it into a concrete implementation plan (**grilling**).\n\n  # ── Simple flow: one Q&A loop, monolithic build ───────────────────────────\n  grilling:\n    actor: agent\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    model: <%= it.vars.plannerModel %>\n    memory: plan\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.todoFile %>`, which this prompt tells you to develop.\n\n      `<%= it.vars.todoFile %>` holds a short sketch of what to build (or\n      feedback from a prior review lap). Read it, explore the codebase, and\n      develop it into a concrete implementation plan.\n\n      For every question you cannot settle yourself, add it under a\n      `## Open Questions` heading near the top, one `### <question>`\n      sub-heading each, its body your suggested answer in plain prose (always\n      suggest one — the human accepts it by leaving it untouched, or overrides\n      it by editing it). Omit the section entirely once there are none.\n\n      If `<%= it.vars.todoFile %>` already carries a `## Open Questions`\n      section from a previous lap, the human has now responded to that whole\n      batch: fold every one of those questions into the plan — the human's edit\n      where they gave one, your own suggestion where they left it untouched (an\n      untouched suggestion IS acceptance) — and MOVE each resolved\n      `### <question>` block down into a `## Answered Questions` section at the\n      bottom. Raise any genuinely new questions under `## Open Questions`.\n\n      Leave `<%= it.vars.todoFile %>` uncommitted and finish your turn — do\n      not commit, and do not run `gtd step agent` yourself; the harness does\n      that.\n    on:\n      \"* **\": grilling-answer\n\n  grilling-answer:\n    actor: human\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.todoFile %>` holds the plan under development, with any\n      open questions under `## Open Questions` — each carrying a suggested\n      answer. Answer a question by editing its body in place; leave a\n      suggestion untouched to accept it.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"C\":\n        to: building\n        describe: >-\n          Change nothing to accept every suggested answer as-is and move on to\n          implementation (**building**).\n      \"* **\":\n        to: grilling\n        describe: >-\n          Edit the plan — answer a question, add detail, or raise a new one — to\n          send it back for another round of grilling (**grilling**).\n\n  building:\n    actor: agent\n    file: <%= it.vars.todoFile %>\n    mode: qa\n    model: <%= it.vars.coderModel %>\n    memory: build\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create or edit anything under `.gtd/` except deleting\n      `<%= it.vars.todoFile %>`, which this prompt tells you to delete once its\n      work is complete.\n\n      The plan to implement is: <%~ it.read(it.vars.todoFile) %>\n\n      Read that plan and implement it in full. Use TDD discipline: one test,\n      then the implementation that passes it, then the next — never write all\n      the tests first.\n\n      Delete `<%= it.vars.todoFile %>` once the work it describes is complete\n      and verified. Leave everything else uncommitted and finish your turn.\n    on:\n      \"* **\": checking\n\n  # ── Advanced flow: product + technical Q&A ────────────────────────────────\n  adv-grilling:\n    actor: agent\n    file: <%= it.vars.requirementsFile %>\n    mode: qa\n    model: <%= it.vars.plannerModel %>\n    memory: plan\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.requirementsFile %>`, which this prompt tells you to develop.\n\n      `<%= it.vars.requirementsFile %>` holds the product requirements (or\n      feedback from a prior review lap). Read it, explore the codebase, and\n      develop it into a concrete, PRODUCT-level plan in this one turn.\n\n      Scope: product and user-facing decisions only. Leave implementation\n      details (file/module structure, data models, tech-stack choices) for the\n      next phase (`<%= it.vars.architectureFile %>`).\n\n      For every remaining open question, add it under a `## Open Questions`\n      heading near the top, one `### <question>` sub-heading each, its body your\n      suggested answer in plain prose (always suggest one). Omit the section\n      once there are none. On a return lap, fold the whole answered batch into\n      the plan and move each resolved `### <question>` block down into a\n      `## Answered Questions` section at the bottom.\n\n      Leave `<%= it.vars.requirementsFile %>` uncommitted and finish your turn.\n    on:\n      \"* **\": adv-grilling-answer\n\n  adv-grilling-answer:\n    actor: human\n    file: <%= it.vars.requirementsFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.requirementsFile %>` holds the product plan under\n      development, with any open questions under `## Open Questions` — each\n      carrying a suggested answer. Answer a question by editing its body in\n      place; leave a suggestion untouched to accept it.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"C\":\n        to: architecting\n        describe: >-\n          Change nothing to accept the product plan and move on to technical\n          architecting (**architecting**).\n      \"* **\":\n        to: adv-grilling\n        describe: >-\n          Edit the product plan — answer a question, add detail, or raise a new\n          one — to send it back for another round (**adv-grilling**).\n\n  architecting:\n    actor: agent\n    file: <%= it.vars.architectureFile %>\n    mode: qa\n    model: <%= it.vars.plannerModel %>\n    memory: plan\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.architectureFile %>` and `<%= it.vars.requirementsFile %>`,\n      which this prompt tells you to write and delete respectively.\n\n      Read `<%= it.vars.requirementsFile %>` (the converged product plan) and\n      develop `<%= it.vars.architectureFile %>` from it in this one turn:\n      file/module structure, data models, library/tech-stack choices,\n      error-handling strategy — the *how*, building on the *what* already\n      settled. Do not re-open product-level decisions; treat them as settled.\n\n      For every remaining open question, add it under a `## Open Questions`\n      heading exactly as the grilling phase does (one `### <question>` each, its\n      body your suggested answer). Omit the section once there are none. On a\n      return lap, fold the whole answered batch in and move each resolved block\n      down into a `## Answered Questions` section at the bottom.\n\n      Once `<%= it.vars.architectureFile %>` is written, delete\n      `<%= it.vars.requirementsFile %>` — its content has been folded in and it\n      must not linger. Leave everything uncommitted and finish your turn.\n    on:\n      \"* **\": architecting-answer\n\n  architecting-answer:\n    actor: human\n    file: <%= it.vars.architectureFile %>\n    mode: qa\n    message: |\n      `<%= it.vars.architectureFile %>` holds the technical plan under\n      development, with any open questions under `## Open Questions`. Answer a\n      question by editing its body in place; leave a suggestion untouched to\n      accept it.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"C\":\n        to: decompose\n        describe: >-\n          Change nothing to accept the technical plan and move on to decomposing\n          the work into packages (**decompose**).\n      \"* **\":\n        to: architecting\n        describe: >-\n          Edit the technical plan to send it back for another round\n          (**architecting**).\n\n  # ── Advanced flow: decomposition + per-package parallel build loop ─────────\n  decompose:\n    actor: agent\n    model: <%= it.vars.coderModel %>\n    memory: build\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except the\n      package files this prompt tells you to write (under\n      `<%= it.vars.packagesDir %>/`), and `<%= it.vars.architectureFile %>`,\n      which it tells you to delete.\n\n      Read `<%= it.vars.architectureFile %>` (the converged technical plan) and\n      decompose it into an ordered set of WORK PACKAGES, one file each under\n      `<%= it.vars.packagesDir %>/` (e.g. `<%= it.vars.packagesDir %>/01-name.md`,\n      `<%= it.vars.packagesDir %>/02-name.md`, ...). Order the packages so the\n      test suite can pass again after each one lands.\n\n      Each package file describes a set of INDEPENDENT tasks that can be\n      implemented concurrently without ordering constraints between them — a\n      single build turn will fan them out to parallel subagents. Give each task\n      a clear description, acceptance criteria as `- [ ]` checkboxes, and the\n      relevant paths. Also state the package's overall requirement so it can be\n      reviewed against its spec. Do NOT put ordering-dependent tasks in the same\n      package — split them across ordered packages instead.\n\n      No package file may reference any other `.gtd/` file. Once the package\n      files are written, delete `<%= it.vars.architectureFile %>`. Leave\n      everything uncommitted and finish your turn.\n    on:\n      \"* .gtd/packages/**\": picking\n\n  picking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn (the package queue arbiter) — the loop driver executes\n      # this verbatim, then steps the check actor. Mechanics only: take the\n      # first package file (by name) under the packages dir into NEXT.md, or\n      # remove NEXT.md when the queue is empty. What NEXT.md's presence/absence\n      # MEANS (another package to build vs. the queue closing out to review) is\n      # decided by this state's own `on` rules at capture time — never here.\n      set +e\n      next=$(ls <%~ it.vars.packagesDir %>/*.md 2>/dev/null | head -n 1)\n      if [ -n \"$next\" ]; then\n        printf '%s' \"$next\" > <%~ it.vars.nextFile %>\n      else\n        rm -f <%~ it.vars.nextFile %>\n      fi\n    on:\n      \"D .gtd/NEXT.md\": reviewing\n      \"* .gtd/NEXT.md\": adv-building\n      \"C\": reviewing\n\n  adv-building:\n    actor: agent\n    model: <%= it.vars.coderModel %>\n    memory: build\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/`; in\n      particular do NOT delete the package file (the `spec-review` gate reads it\n      after you) and never touch `<%= it.vars.nextFile %>` — the `picking` state\n      owns it.\n\n      The package to implement is: <%~ it.read(it.vars.nextFile) %>\n\n      That file describes a set of INDEPENDENT tasks. Implement ALL of them in\n      this one turn, fanning the independent tasks out to parallel subagents\n      where your harness supports it — each task is self-contained and can be\n      built concurrently. Implement EXACTLY the tasks this package describes — no\n      more, no less; leave every other package file untouched. Use TDD\n      discipline within each task.\n\n      Leave the package file in place and everything else uncommitted, then\n      finish your turn.\n    on:\n      \"* **\": adv-checking\n\n  adv-checking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — run the suite; a red run records .gtd/FEEDBACK.md, a\n      # green run cleans it up. The `on` rules decide what that means.\n      set +e\n      mkdir -p .gtd\n      <%~ it.vars.testCommand %> > .gtd/.check-output 2>&1\n      code=$?\n      if [ \"$code\" -ne 0 ]; then\n        if [ -s .gtd/.check-output ]; then\n          mv .gtd/.check-output <%~ it.vars.feedbackFile %>\n        else\n          rm -f .gtd/.check-output\n          printf 'the test command failed with exit code %s and produced no output.' \"$code\" > <%~ it.vars.feedbackFile %>\n        fi\n      else\n        rm -f .gtd/.check-output\n        rm -f <%~ it.vars.feedbackFile %>\n      fi\n    on:\n      \"A .gtd/FEEDBACK.md\": adv-fixing\n      \"M .gtd/FEEDBACK.md\": adv-fixing\n      \"D .gtd/FEEDBACK.md\": spec-review\n      \"C\": spec-review\n\n  adv-fixing:\n    actor: agent\n    file: <%= it.vars.feedbackFile %>\n    model: <%= it.vars.coderModel %>\n    memory: fix\n    retry:\n      max: 3\n      otherwise: adv-escalate\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.feedbackFile %>`, which this prompt tells you to address.\n\n      Read `<%= it.vars.feedbackFile %>` (the failing test output) and fix the\n      code so the suite passes. Keep the change focused — do not refactor\n      unrelated code. If the feedback is wrong, empty or delete\n      `<%= it.vars.feedbackFile %>` instead of \"fixing\" a non-issue.\n\n      Leave everything uncommitted and finish your turn — do not commit.\n    on:\n      \"* **\": adv-checking\n\n  adv-escalate:\n    actor: human\n    file: <%= it.vars.feedbackFile %>\n    message: |\n      The agent could not get the check to pass after repeated attempts.\n      `<%= it.vars.feedbackFile %>` holds the last failing output.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"* **\":\n        to: adv-checking\n        describe: >-\n          Fix the failure yourself — edit the code and/or\n          `.gtd/FEEDBACK.md` — to re-run the check (**adv-checking**).\n\n  spec-review:\n    actor: agent\n    model: <%= it.vars.plannerModel %>\n    memory: review\n    # Bounded per cycle: once entered `max` times, a transition into it is\n    # redirected to `closing` (force-close the package and move on — the\n    # unresolved concern is deferred to the shared human review at the tail,\n    # which sees the whole diff anyway). NOTE the cap is PROCESS-scoped, so it\n    # pools across packages — the same documented limitation the shared\n    # `fixing` cap has (see STATES.md / docs/configuration.md).\n    retry:\n      max: 3\n      otherwise: closing\n    prompt: |\n      You are an autonomous coding agent reviewing a freshly-built work package\n      against its own spec. `.gtd/` holds this workflow's own state — never\n      create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.specFeedbackFile %>`, which this prompt tells you to write\n      when — and only when — you find problems.\n\n      The package spec is: <%~ it.read(it.vars.nextFile) %>\n\n      Read that spec, then verify the package's implementation (the diff below)\n      against it: are all its tasks done, acceptance criteria met, and the code\n      sound and consistent with the codebase?\n\n      - If it fully satisfies the spec, write NOTHING and finish your turn — a\n        clean turn is your approval.\n      - If it does not, write `<%= it.vars.specFeedbackFile %>` listing the\n        concrete problems for a fix turn to address. Be specific.\n\n      Do not fix anything yourself and do not delete the package file — a later\n      step owns that. Finish your turn.\n      <% if (it.processDiff.trim()) { %>\n\n      ## Diff under review\n\n      ```diff\n      <%~ it.processDiff %>\n      ```\n      <% } %>\n    on:\n      \"A .gtd/SPEC_FEEDBACK.md\": spec-fix\n      \"M .gtd/SPEC_FEEDBACK.md\": spec-fix\n      \"D .gtd/SPEC_FEEDBACK.md\": closing\n      \"C\": closing\n\n  spec-fix:\n    actor: agent\n    file: <%= it.vars.specFeedbackFile %>\n    model: <%= it.vars.coderModel %>\n    memory: fix\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.specFeedbackFile %>`, which this prompt tells you to address\n      and then delete.\n\n      Read `<%= it.vars.specFeedbackFile %>` (the reviewer's concerns about the\n      current package) and the package spec (`<%= it.read(it.vars.nextFile) %>`),\n      then fix the code to resolve every concern. Keep the change focused.\n\n      Delete `<%= it.vars.specFeedbackFile %>` once every concern is addressed.\n      Leave everything else uncommitted and finish your turn.\n    on:\n      \"* **\": adv-checking\n\n  closing:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn (the package closer) — remove the just-reviewed package\n      # file (its path is in NEXT.md) plus any leftover spec feedback, so\n      # `picking` selects the NEXT package (or falls through to review when the\n      # queue is empty). Reached on approval (spec-review clean) and on the\n      # spec-review retry cap (force-close, deferring the concern to the tail).\n      set +e\n      pkg=$(cat <%~ it.vars.nextFile %> 2>/dev/null)\n      [ -n \"$pkg\" ] && rm -f \"$pkg\"\n      rm -f <%~ it.vars.specFeedbackFile %> <%~ it.vars.nextFile %>\n    on:\n      \"* **\": picking\n\n  # ── Shared health segment (simple build, feedback loop, code-only edits) ──\n  checking:\n    actor: check\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — run the suite; a red run records .gtd/FEEDBACK.md, a\n      # green run cleans it up. The `on` rules decide what that means.\n      set +e\n      mkdir -p .gtd\n      <%~ it.vars.testCommand %> > .gtd/.check-output 2>&1\n      code=$?\n      if [ \"$code\" -ne 0 ]; then\n        if [ -s .gtd/.check-output ]; then\n          mv .gtd/.check-output <%~ it.vars.feedbackFile %>\n        else\n          rm -f .gtd/.check-output\n          printf 'the test command failed with exit code %s and produced no output.' \"$code\" > <%~ it.vars.feedbackFile %>\n        fi\n      else\n        rm -f .gtd/.check-output\n        rm -f <%~ it.vars.feedbackFile %>\n      fi\n    on:\n      \"A .gtd/FEEDBACK.md\": fixing\n      \"M .gtd/FEEDBACK.md\": fixing\n      \"D .gtd/FEEDBACK.md\": reviewing\n      \"C\": reviewing\n\n  fixing:\n    actor: agent\n    file: <%= it.vars.feedbackFile %>\n    model: <%= it.vars.coderModel %>\n    memory: fix\n    retry:\n      max: 3\n      otherwise: escalate\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.feedbackFile %>`, which this prompt tells you to address.\n\n      Read `<%= it.vars.feedbackFile %>` (the failing test output) and fix the\n      code so the suite passes. Keep the change focused — do not refactor\n      unrelated code. If the feedback is wrong, empty or delete\n      `<%= it.vars.feedbackFile %>` instead of \"fixing\" a non-issue.\n\n      Leave everything uncommitted and finish your turn — do not commit.\n    on:\n      \"* **\": checking\n\n  escalate:\n    actor: human\n    file: <%= it.vars.feedbackFile %>\n    message: |\n      The agent could not get the check to pass after repeated attempts.\n      `<%= it.vars.feedbackFile %>` holds the last failing output.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"* **\":\n        to: checking\n        describe: >-\n          Fix the failure yourself — edit the code and/or `.gtd/FEEDBACK.md` —\n          to re-run the check (**checking**).\n\n  # ── Shared tail: agent review -> human review -> squash finale ────────────\n  reviewing:\n    actor: agent\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    model: <%= it.vars.plannerModel %>\n    memory: review\n    # `gtd review <commitish>` (a plain non-gtd branch, e.g. a colleague's PR)\n    # enters here directly, recording the resolved base as a `Gtd-Review-Base:`\n    # trailer on its empty entry commit — everything below then reuses the same\n    # reviewing/await-review/feedback machinery over <commitish>..HEAD.\n    reviewEntry: true\n    prompt: |\n      You are an autonomous coding agent. `.gtd/` holds this workflow's own\n      state — never create, edit, or delete anything under `.gtd/` except\n      `<%= it.vars.reviewFile %>`, which this prompt tells you to write.\n\n      Write `<%= it.vars.reviewFile %>` to help a human review the diff below in\n      this EXACT format:\n\n      - First non-blank line: `# Review: <%= it.currentCommit.slice(0, 7) %>`\n      - Somewhere in the document: `<!-- base: <%= it.startCommit %> -->`\n      - At least one `## <Chunk Title>` heading, grouping hunks semantically\n        (same feature/refactor/fix, even across files) — a short explanation of\n        what changed and why, then one `- [ ] ./path/to/file.ts#42 — note` file\n        pointer per hunk (checkboxes are for the human to tick, not you; every\n        path is `./`-relative, with an optional `#line` and an optional\n        ` — note`).\n\n      The diff below is `it.reviewDiff` — on a feedback round it covers ONLY the\n      changes made since the previous review, so you review just what changed,\n      not items already signed off. Leave `<%= it.vars.reviewFile %>`\n      uncommitted and finish your turn.\n      <% if (it.reviewDiff.trim()) { %>\n\n      ## Full diff under review\n\n      ```diff\n      <%~ it.reviewDiff %>\n      ```\n      <% } %>\n    on:\n      \"* **\": await-review\n\n  await-review:\n    actor: human\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    # While the cycle rests here, gtd opens a \"review checkout window\": raw HEAD\n    # is rewound to the review base (the most-recent `review-deciding` commit —\n    # so a feedback round shows only `last-review..HEAD` — or the process start\n    # on the first review) with the working tree untouched, surfacing the diff\n    # as ordinary uncommitted changes. It closes on the next invocation.\n    reviewWindow: true\n    message: |\n      `<%= it.vars.reviewFile %>` holds the review record for the cycle — one\n      `- [ ]` checkbox per reviewable item, grouped into chunks.\n\n      What each change does next (then run `gtd step human`):\n      <% it.edges.forEach(function (e) { if (e.describe) { %>\n      <%~ \"- \" + e.describe + \"\\n\" %>\n      <% } }) %>\n    on:\n      \"D .gtd/REVIEW.md\":\n        to: squashing\n        describe: >-\n          Delete `.gtd/REVIEW.md` outright to sign off on the whole cycle at\n          once and collapse it into one commit (**squashing**).\n      \"M .gtd/REVIEW.md\":\n        to: review-deciding\n        describe: >-\n          Edit `.gtd/REVIEW.md` — tick a `- [ ]` box to `- [x]` to sign off that\n          item, or add notes — to hand it to a deterministic check\n          (**review-deciding**) that squashes when every box is ticked, or sends\n          the still-unticked items back for another build+review round.\n      \"* **\":\n        to: checking\n        describe: >-\n          Change only code, leaving `.gtd/REVIEW.md` untouched, to re-run the\n          tests on your manual fix and re-review it (**checking**).\n\n  review-deciding:\n    actor: check\n    file: <%= it.vars.reviewFile %>\n    mode: review\n    # Anchors the INCREMENTAL review base: its most-recent in-process commit is\n    # the point the previous review round ended, so the next `reviewing` turn\n    # (and the review checkout window) covers only the changes since then. On\n    # the first review there is no such commit, so the base is the cycle start.\n    reviewBase: true\n    script: |\n      #!/usr/bin/env bash\n      # gtd check turn — if REVIEW.md still has any unticked \"- [ ]\" pointer,\n      # extract those pointers (with their notes) into REVIEW_FEEDBACK.md;\n      # either way, remove REVIEW.md. What the resulting diff MEANS (feedback\n      # round vs. full sign-off) is decided by this state's own `on` rules. The\n      # A/M REVIEW_FEEDBACK.md rows are declared BEFORE the D REVIEW.md row so a\n      # feedback round — which always also deletes REVIEW.md — is captured as\n      # feedback, not mistaken for a sign-off.\n      set +e\n      mkdir -p .gtd\n      if grep -qE '^[[:space:]]*-[[:space:]]*\\[[[:space:]]*\\]' <%~ it.vars.reviewFile %> 2>/dev/null; then\n        {\n          echo \"Feedback from review — address these before continuing:\"\n          echo\n          grep -E '^[[:space:]]*-[[:space:]]*\\[[[:space:]]*\\]' <%~ it.vars.reviewFile %>\n        } > <%~ it.vars.reviewFeedbackFile %>\n      fi\n      rm -f <%~ it.vars.reviewFile %>\n    on:\n      \"A .gtd/REVIEW_FEEDBACK.md\": feedback-building\n      \"M .gtd/REVIEW_FEEDBACK.md\": feedback-building\n      \"D .gtd/REVIEW.md\": squashing\n      \"C\": await-review\n\n  feedback-building:\n    actor: agent\n    file: <%= it.vars.reviewFeedbackFile %>\n    model: <%= it.vars.coderModel %>\n    memory: build\n    prompt: |\n      You are an autonomous coding agent addressing review feedback. `.gtd/`\n      holds this workflow's own state — never create, edit, or delete anything\n      under `.gtd/` except `<%= it.vars.reviewFeedbackFile %>`, which this\n      prompt tells you to address and then delete.\n\n      The review feedback to address is: <%~ it.read(it.vars.reviewFeedbackFile) %>\n\n      Implement exactly those changes — no Q&A, no re-planning. Use TDD\n      discipline. Delete `<%= it.vars.reviewFeedbackFile %>` once every item is\n      addressed. Leave everything else uncommitted and finish your turn.\n    on:\n      \"* **\": checking\n\n  squashing:\n    actor: agent\n    file: <%= it.vars.commitMsgFile %>\n    model: <%= it.vars.coderModel %>\n    memory: build\n    prompt: |\n      You are an autonomous coding agent. The cycle is approved and done.\n      `.gtd/` holds this workflow's own state — never create, edit, or delete\n      anything under `.gtd/` except `<%= it.vars.commitMsgFile %>`, which this\n      prompt tells you to write.\n\n      Write `<%= it.vars.commitMsgFile %>` with ONE conventional-commits message\n      for the entire cycle (subject line `type(scope): subject`, imperative\n      mood, <= 72 characters; a body explaining the why, trade-offs, and key\n      decisions). Plain text, no markdown wrapper.\n\n      Leave `<%= it.vars.commitMsgFile %>` uncommitted and finish your turn —\n      entering this file squashes the whole cycle into one commit using its\n      content as the message.\n      <% if (it.processDiff.trim()) { %>\n\n      ## Full cycle diff\n\n      ```diff\n      <%~ it.processDiff %>\n      ```\n      <% } %>\n    on:\n      \"A .gtd/COMMIT_MSG.md\": done\n      \"M .gtd/COMMIT_MSG.md\": done\n\n  done:\n    commit: |\n      <%~ it.read(it.vars.commitMsgFile) %>\n\n      Token cost: <%= it.processCost %>\n      <% it.processCostByModel.forEach(function(m){ %>\n      - <%= m.model %>: <%= m.cost %>\n      <% }) %>\n";
 //#endregion
 //#region src/workflows/templates.ts
 /**
@@ -191390,7 +191406,7 @@ const PROMPTS_DIR = "gtd-prompts";
 /**
 * The top-level `modes:` block `gtd init` SEEDS into the scaffolded
 * `.gtdrc.json` as a ready-to-edit suggestion: a `format:` command for each
-* built-in steering-file mode the bundled templates use (`qa` for the plan /
+* built-in steering-file mode the bundled template uses (`qa` for the plan /
 * open-questions files, `review` for REVIEW.md), so a fresh project's steering
 * files are auto-formatted with Prettier before gtd validates them. Only
 * `format:` is declared — gtd's built-in `qa`/`review` validators still do the
@@ -191401,40 +191417,36 @@ const PROMPTS_DIR = "gtd-prompts";
 *
 * Seeded only by `renderInitScaffold` (the real `gtd init` write path), NOT by
 * `renderInitConfig`: the latter is reused as a hermetic test fixture (the
-* `Given the "…" workflow` step) that must not depend on Prettier being
-* installed or spawn a subprocess at every steering-file gate.
+* `Given the workflow` step) that must not depend on Prettier being installed
+* or spawn a subprocess at every steering-file gate.
 */
 const MODES_SUGGESTION = {
 	qa: { format: "npx prettier --write <%= it.file %>" },
 	review: { format: "npx prettier --write <%= it.file %>" }
 };
 /**
-* The bundled workflow templates `gtd init <name>` can scaffold, keyed by the
-* name the user passes. Each value is the raw YAML text of the template file,
-* imported as a string (tsdown's `.yaml` text loader / the vitest `rawMd`
-* transform — see tsdown.config.ts / tests/vitest.rawMd.ts), so this module
-* never touches the filesystem: it works identically in the dev checkout,
-* under `vitest`, and inside the single-file `dist/gtd.bundle.mjs` build.
+* The single bundled workflow template `gtd init` scaffolds — the raw YAML text
+* of `unified.yaml`, imported as a string (tsdown's `.yaml` text loader / the
+* vitest `rawMd` transform — see tsdown.config.ts / tests/vitest.rawMd.ts), so
+* this module never touches the filesystem: it works identically in the dev
+* checkout, under `vitest`, and inside the single-file `dist/gtd.bundle.mjs`
+* build. gtd ships NO default workflow and no longer offers a choice of
+* templates — `gtd init` takes no argument.
 */
-const WORKFLOW_TEMPLATES = {
-	simple: simple_default,
-	advanced: advanced_default
-};
-/** The template names as a plain array, for usage messages and validation. */
-const WORKFLOW_TEMPLATE_NAMES = Object.keys(WORKFLOW_TEMPLATES);
-const isWorkflowTemplateName = (name) => Object.prototype.hasOwnProperty.call(WORKFLOW_TEMPLATES, name);
+const UNIFIED_WORKFLOW = unified_default;
 /**
-* Render everything `gtd init <name>` writes. Like `renderInitConfig`, but each
-* agent state's inline `prompt:` is EXTRACTED into a standalone
+* Render everything `gtd init` writes. Like `renderInitConfig`, but each agent
+* state's inline `prompt:` is EXTRACTED into a standalone
 * `gtd-prompts/<state>.md` file and the config value is rewritten to a
 * `./gtd-prompts/<state>.md` file reference — `compileWorkflowConfig` inlines
 * it back at load time (`resolveContent`), so the workflow behaves identically
 * to the fully-inline `renderInitConfig` form while the prompts stay editable
 * as ordinary Markdown. Only `prompt:` content is externalized: human
-* `message:` blocks and check `script:` bodies remain inline in the config
-* (they are workflow mechanics, not prompts). The bundled YAML template itself
-* stays fully inline (it ships inside the single-file bundle); this function is
-* the only place the split happens, at scaffold time.
+* `message:` blocks, check `script:` bodies, and the `done` `commit:` template
+* remain inline in the config (they are workflow mechanics, not prompts). The
+* bundled YAML template itself stays fully inline (it ships inside the
+* single-file bundle); this function is the only place the split happens, at
+* scaffold time.
 *
 * It also seeds a top-level `modes:` block (`MODES_SUGGESTION`) — a ready-to-
 * edit Prettier `format:` for the built-in `qa`/`review` steering-file modes —
@@ -191442,8 +191454,8 @@ const isWorkflowTemplateName = (name) => Object.prototype.hasOwnProperty.call(WO
 * here rather than in `renderInitConfig` so the latter stays a hermetic test
 * fixture (see `MODES_SUGGESTION`).
 */
-const renderInitScaffold = (name) => {
-	const workflow = (0, import_dist$1.parse)(WORKFLOW_TEMPLATES[name]);
+const renderInitScaffold = () => {
+	const workflow = (0, import_dist$1.parse)(UNIFIED_WORKFLOW);
 	const prompts = [];
 	for (const [stateName, state] of Object.entries(workflow.states ?? {})) if (typeof state.prompt === "string") {
 		const path = `${PROMPTS_DIR}/${stateName}.md`;
@@ -192155,11 +192167,24 @@ const toTemplateEdges = (edges) => (edges ?? []).map(([pattern, target, describe
 * breakdown including the squashing step) — `0`/absent for the pure emitters
 * (`gtd next`/`gtd status`), where no step is being performed.
 */
-const buildTemplateContext = (git, read, state, actor, run, vars, edges, currentCost = 0, currentModel) => gen(function* () {
+/** Join a committed diff and the pending working-tree diff, dropping empties. */
+const joinDiffs = (committed, pending) => [committed, pending].filter((d) => d.trim().length > 0).join("\n\n");
+/**
+* The committed half of `it.reviewDiff`: the diff from `reviewDiffBase` (the
+* previous review round's boundary) when it is a distinct base, else the
+* already-computed process-wide `committedDiff` (first review — reviewDiff
+* collapses to processDiff).
+*/
+const committedReviewDiffOf = (git, processDiffBase, reviewDiffBase, committedDiff) => reviewDiffBase !== void 0 && reviewDiffBase !== processDiffBase ? git.diffRef(reviewDiffBase).pipe(catchAll(() => succeed$3(""))) : succeed$3(committedDiff);
+const buildTemplateContext = (git, read, state, actor, run, vars, edges, currentCost = 0, currentModel, reviewDiffBase) => gen(function* () {
 	const hasCommits = yield* git.hasCommits();
 	const currentCommit = hasCommits ? yield* git.resolveRef("HEAD") : "";
 	const previousCommit = hasCommits ? yield* git.resolveRef("HEAD~1").pipe(catchAll(() => succeed$3(run.startParentHash))) : "";
-	const processDiff = [yield* git.diffRef(run.diffBase).pipe(catchAll(() => succeed$3(""))), yield* git.diffHead().pipe(catchAll(() => succeed$3("")))].filter((d) => d.trim().length > 0).join("\n\n");
+	const committedDiff = yield* git.diffRef(run.diffBase).pipe(catchAll(() => succeed$3("")));
+	const pendingDiff = yield* git.diffHead().pipe(catchAll(() => succeed$3("")));
+	const processDiff = joinDiffs(committedDiff, pendingDiff);
+	const committedReviewDiff = yield* committedReviewDiffOf(git, run.diffBase, reviewDiffBase, committedDiff);
+	const reviewDiff = joinDiffs(committedReviewDiff, pendingDiff);
 	const lastDiff = run.trace.length > 0 ? yield* git.commitDiff(currentCommit).pipe(catchAll(() => succeed$3(""))) : "";
 	const stepEntry = currentCost > 0 || currentModel !== void 0 ? [{
 		cost: currentCost,
@@ -192173,6 +192198,7 @@ const buildTemplateContext = (git, read, state, actor, run, vars, edges, current
 		state,
 		actor,
 		processDiff,
+		reviewDiff,
 		lastDiff,
 		processCost: totalCostOf(allCostEntries),
 		processCostByModel: costByModel(allCostEntries),
@@ -203862,6 +203888,7 @@ const buildFileModeMap = (def, vars, root) => {
 				state: name,
 				actor: "",
 				processDiff: "",
+				reviewDiff: "",
 				lastDiff: "",
 				processCost: 0,
 				processCostByModel: [],
@@ -204226,12 +204253,12 @@ const GTD_VERSION = createRequire(import.meta.url)("../package.json").version;
 const HELP_TEXT = `Usage: gtd [command] [options]
 
 Commands:
-  init <workflow>  Scaffold a .gtdrc.json for this repo with the chosen
-                   bundled workflow (one of: simple, advanced); its agent
-                   prompts are written as editable Markdown under gtd-prompts/
-                   and referenced from the config. Run once per repo; refuses
-                   if a gtd config already exists. Leaves the files uncommitted
-                   for you to review and commit
+  init             Scaffold a .gtdrc.json for this repo with the bundled
+                   unified workflow; its agent prompts are written as editable
+                   Markdown under gtd-prompts/ and referenced from the config.
+                   Takes no argument. Run once per repo; refuses if a gtd
+                   config already exists. Leaves the files uncommitted for you
+                   to review and commit
   step <actor>     Authenticate as <actor>, match the resolved rest's
                    declared patterns against the pending changes, and commit
                    (or squash) the one resulting transition. Pass
@@ -204273,6 +204300,17 @@ Options:
 const ENVELOPED = Symbol.for("gtd/enveloped");
 const markEnveloped = (error) => Object.assign(error, { [ENVELOPED]: true });
 const isEnveloped = (error) => typeof error === "object" && error !== null && error[ENVELOPED] === true;
+/**
+* The stderr line for a CLI error (see `main.ts`): a `gtd: ` prefix UNLESS the
+* message already carries one. Most gtd errors are authored with a
+* `gtd:`/`gtd <cmd>:` prefix of their own (e.g. `gtd init: …`,
+* `gtd: no workflow configured …`), so a blind prepend produced a doubled
+* `gtd: gtd: …`.
+*/
+const cliErrorLine = (error) => {
+	const message = error instanceof Error ? error.message : String(error);
+	return /^gtd[: ]/.test(message) ? message : `gtd: ${message}`;
+};
 /** Non-flag positional arguments past the subcommand name (argv[3..]). */
 const commandArgs = (argv) => argv.slice(3).filter((a) => a.length > 0 && !a.startsWith("--"));
 const COST_FLAG = "--cost=";
@@ -204345,13 +204383,12 @@ const runLspCommand = (argv, json) => gen(function* () {
 	yield* rejectExtraArgs("lsp", argv);
 	yield* startLspServer();
 });
-/** The `choose one of: ...` suffix shared by every `gtd init` usage error. */
-const initWorkflowChoices = () => `choose one of: ${WORKFLOW_TEMPLATE_NAMES.join(", ")}`;
 /**
-* `gtd init <workflow>`: scaffold a `.gtdrc.json` carrying one of the bundled
-* workflow templates inline (`simple`/`advanced`). Dispatched like `lsp` —
-* BEFORE the closeReviewWindow/dispatch/openReviewWindow block — because it is
-* the ONE command that must run with no workflow configured yet: it needs no
+* `gtd init`: scaffold a `.gtdrc.json` carrying the bundled unified workflow
+* template inline. Takes NO argument — gtd ships a single template and no
+* longer offers a choice. Dispatched like `lsp` — BEFORE the
+* closeReviewWindow/dispatch/openReviewWindow block — because it is the ONE
+* command that must run with no workflow configured yet: it needs no
 * `ConfigService` (which would throw the "no workflow" error pre-init) and no
 * review window. It still runs the repo-root guard (it writes `.gtdrc.json` at
 * the root) and refuses to clobber an existing config. It also writes each
@@ -204364,17 +204401,14 @@ const initWorkflowChoices = () => `choose one of: ${WORKFLOW_TEMPLATE_NAMES.join
 */
 const runInitCommand = (argv, json, write) => gen(function* () {
 	const args = commandArgs(argv);
-	if (args.length === 0) return yield* fail$2(/* @__PURE__ */ new Error(`gtd init: missing workflow — ${initWorkflowChoices()}`));
-	if (args.length > 1) return yield* fail$2(/* @__PURE__ */ new Error(`gtd init: too many arguments — expected one workflow, got: ${args.join(", ")}`));
-	const name = args[0];
-	if (!isWorkflowTemplateName(name)) return yield* fail$2(/* @__PURE__ */ new Error(`gtd init: unknown workflow '${name}' — ${initWorkflowChoices()}`));
+	if (args.length > 0) return yield* fail$2(/* @__PURE__ */ new Error(`gtd init: too many arguments — init takes no argument, got: ${args.join(", ")}`));
 	const git = yield* GitService;
 	const fs = yield* FileSystem;
 	yield* assertRunningFromRepoRoot(git, fs);
 	const { root } = yield* Cwd;
 	if (yield* configPresentAt(root)) return yield* fail$2(/* @__PURE__ */ new Error("gtd init: a gtd config already exists — remove it before re-initializing"));
 	const toError = (e) => e instanceof Error ? e : new Error(String(e));
-	const scaffold = renderInitScaffold(name);
+	const scaffold = renderInitScaffold();
 	yield* fs.writeFileString(join(root, ".gtdrc.json"), scaffold.config).pipe(mapError$1(toError));
 	for (const prompt of scaffold.prompts) {
 		const full = join(root, prompt.path);
@@ -204383,12 +204417,12 @@ const runInitCommand = (argv, json, write) => gen(function* () {
 	}
 	if (json) write(JSON.stringify({
 		written: ".gtdrc.json",
-		workflow: name,
+		workflow: "unified",
 		prompts: scaffold.prompts.map((p) => p.path)
 	}) + "\n");
 	else {
 		const promptCount = scaffold.prompts.length;
-		write(`Wrote .gtdrc.json with the "${name}" workflow, and its ${promptCount} agent prompt${promptCount === 1 ? "" : "s"} as editable Markdown under ${PROMPTS_DIR}/ (referenced from the config).\n\nReview and commit them before starting: an uncommitted .gtdrc.json (or prompt\nfile) counts as a pending change, so the initial state would capture it on the\nfirst step. Once committed, run \`gtd step human\` to begin.\n`);
+		write(`Wrote .gtdrc.json with the bundled unified workflow, and its ${promptCount} agent prompt${promptCount === 1 ? "" : "s"} as editable Markdown under ${PROMPTS_DIR}/ (referenced from the config).\n\nReview and commit them before starting: an uncommitted .gtdrc.json (or prompt\nfile) counts as a pending change, so the initial state would capture it on the\nfirst step. Once committed, run \`gtd step human\` to begin.\n`);
 	}
 });
 /**
@@ -204406,10 +204440,11 @@ const resolveRestContext = (git) => gen(function* () {
 	const rest = yield* resolveRest();
 	const run = yield* computeProcessRun(git, rest.def);
 	const vars = resolveVars(config.workflowVars, config.rcVars, envVars.all);
+	const reviewBase = yield* reviewBaseHash(git, rest.def, run);
 	return {
 		rest,
 		run,
-		context: yield* buildTemplateContext(git, worktree.read, rest.state, rest.actor, run, vars, rest.stateDef.on)
+		context: yield* buildTemplateContext(git, worktree.read, rest.state, rest.actor, run, vars, rest.stateDef.on, 0, void 0, reviewBase)
 	};
 });
 /** The user-facing message for a `step` refusal — out-of-turn names the awaited actor, no-match names every declared pattern. */
@@ -204798,7 +204833,7 @@ const dispatchKnownSubcommand = (sub, argv, json, write, cost, model) => {
 *
 * v3 command surface: `step <actor>` / `next` / `status` / `validate` /
 * `mermaid` (see `src/Edge.ts` and `docs/design/pattern-machine-plan.md` §3),
-* plus `lsp` and `init <workflow>` — both dispatched before the config-reading
+* plus `lsp` and `init` — both dispatched before the config-reading
 * path since they must work with no workflow configured yet. Bare `gtd` or an
 * unknown subcommand is a usage error. Shared setup (argv parsing, the
 * repo-root guard) lives here; each subcommand's own logic is a named
@@ -204838,7 +204873,7 @@ makeProgram().pipe(provide$1(GitService.Live), provide$1(ConfigService.Live), pr
 		state: "error",
 		prompt: error.message
 	}) + "\n");
-	process.stderr.write(`gtd: ${error.message ?? String(error)}\n`);
+	process.stderr.write(cliErrorLine(error) + "\n");
 	process.exit(1);
 })), runMain);
 //#endregion