opencode-gbuild 0.8.0 → 0.9.0

package/skills/run/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: Executes a gbuild graph — dispatches every ready-and-independent node in the current wave concurrently, each file-touching node in its own git worktree, reviews each node's output with gbuild-reviewer before merging its branch and recording it complete, and resumes only the remaining frontier on re-invocation. Use after /gbuild:plan has charted the graph.
+description: Executes a gbuild graph as dataflow — each node starts the moment its own dependencies complete and runs its own implement → review → land → record pipeline in background subagents (each file-touching node in its own git worktree), handing agents only slugs and paths, recording a node complete only after gbuild-reviewer passes it, and resuming only the remaining frontier on re-invocation. Use after /gbuild:plan has charted the graph.
 ---
 
 Run the graph for the feature `$ARGUMENTS` (the slug; step 0 resolves `DB`, the store — the feature
@@ -7,21 +7,26 @@ branch lives in its own worktree, so this skill never changes the branch of the
 
 **CRITICAL: this skill must run in the main context, not inside a forked agent.** It dispatches its own
 subagents per node; a subagent cannot itself fan out further subagents reliably. It is also the store's
-**only writer**: subagents never run `cypherlite` — they get what they need in their prompt and report
-back in their final message, and this skill records it.
+**only writer**: agents read their brief from the store themselves and leave their result in the inbox;
+this skill passes them slugs and paths, reads their one-line replies, and records.
 
 ## Store rules
 
 - `cypherlite --version` first. If it's missing, stop: gbuild needs it
   (`curl -sSfL https://neo4j-labs.github.io/cypherlite/install.sh | bash`).
-- One `cypherlite` command at a time against `DB` — never parallel tool calls on it, never from a subagent.
+- You are the only writer: `dispatch`, `set-status` and `record` run only here, one `cypherlite` command
+  at a time against `DB` — never parallel tool calls on it. Subagents may run `cypherlite` only with
+  `--read-only` (a read opens beside the writer); their agent files say what they read.
 - Always `--mode jsonl`: one JSON object per row, no output = no rows. Every `--param` value is JSON,
-  single-quoted for the shell (`--param 'slugs=["a","b"]'`).
-- Pure reads (validate, attention, progress below) open the store `--read-only`; the writes (dispatch,
-  set-status, record) stay writable — the CLI checkpoints a writable store on exit itself.
-- `storage locked` → another process holds the store: wait a few seconds, retry up to 3 times, then stop.
-  Exit code 1 = failure; read stderr. Anything beyond the scripts below: `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
-- Never re-read what you already hold. The claimed wave's definitions stay valid for its retries.
+  single-quoted for the shell (`--param 'slugs=["a","b"]'`); write a `'` inside it as `\u0027`.
+- Pure reads (validate, attention, progress below) open the store `--read-only`; the writes
+  (dispatch, set-status, record) stay writable — the CLI checkpoints a writable store on exit itself.
+- `storage locked` (exit 5) → another writer holds the store: wait a few seconds, retry up to 3 times,
+  then stop. Exit code 1 = failure; read stderr. Anything beyond the scripts below:
+  `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
+- Hold only what routes: dispatch rows, one reply line per agent, record rows. Never open a result file,
+  a review file or a diff, and never type acceptance text or output values — the store and the inbox
+  carry them.
 
 ## Step 0: Establish VCS facts, then check and recover
 
@@ -40,6 +45,8 @@ Default to `git`. Resolve these facts first, absolute paths, and reuse them thro
   4. Else → stop: there is no feature branch for `$ARGUMENTS` — chart it with `/gbuild:plan` first.
 - `DB` = `WT/db` — the feature's store, beside the worktree: machine-local, never committed (a gbuild ≤ 0.7.1
   store needs the move in `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`).
+- `INBOX` = `WT/inbox` — beside `DB`, outside every worktree: each implementer writes `<slug>.json`
+  there and each reviewer `<slug>.review.json`; only `record.cypher` reads them, on your behalf.
 
 Then check and recover:
 
@@ -61,30 +68,40 @@ cypherlite query --read-only --database DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/
     < ${CLAUDE_PLUGIN_ROOT}/cypher/set-status.cypher
   ```
 
-- Sweep the worktree root `WT` for leaks from an interruption that struck mid-cleanup: any worktree
-  under `WT` — **except `FT` itself (`WT/tree`)** — whose slug is *not* among the slugs just reset does
-  not belong to live work — remove it
-  (`git worktree remove --force`) and delete its branch (`git branch -D`). An unmerged branch is
-  unaccepted work, which must never land — that is what the isolation is for.
+- Sweep the worktree root `WT` for leaks from an interruption that struck mid-cleanup: any registered
+  worktree under `WT` (`git worktree list --porcelain` — `db/` and `inbox/` are not worktrees) — **except
+  `FT` itself (`WT/tree`)** — whose slug is *not* among the slugs just reset does not belong to live
+  work — remove it (`git worktree remove --force`) and delete its branch (`git branch -D`). An unmerged
+  branch is unaccepted work, which must never land — that is what the isolation is for.
+- Create the inbox empty. This discards the files of the nodes just reset — an interrupted attempt is
+  never recorded; they re-dispatch from scratch on top of their surviving worktrees:
+
+  ```
+  mkdir -p WT/inbox
+  find WT/inbox -type f -delete
+  ```
 
 ## Step 1: Pick a backend
 
 **Workflow tool**, if this session has opted into multi-agent orchestration (ultracode, or the user
-asked for a workflow explicitly) — translate each claimed wave into a `pipeline()`/`parallel()` script:
-each node is an `agent()` implement call, immediately followed by a `gbuild-reviewer` `agent()` review
-call scoped to that node's outputs + `acceptance`, using `schema` for the pass/fail verdict. Every
-file-touching (`code`/`test`/`chore`) node gets `isolation: 'worktree'`.
-Controlled-cycle clusters become a bounded `while` loop per `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md`'s
-round cap. Route `model_tier: strong` nodes via `opts.model` where the harness supports an override. The
-script never touches the store: collect the results, land each accepted node's branch from the main
-context (step 2.4), then record (step 2.5).
-
-**Fallback** (default — no opt-in required, and always what step 2 below assumes): fire one `Agent`
-tool call per claimed node, **all in a single message** — this is what makes the fan-out real rather
-than claimed. Do not dispatch them one at a time across separate messages; that's exactly the serial
-behavior this plugin replaces.
-
-## Step 2: One wave
+asked for a workflow explicitly) — one `pipeline()` per claimed node: its implement `agent()`, then its
+`gbuild-reviewer` `agent()`, prompted exactly as in step 2.2 and read as in step 2.3, so a review starts
+the moment its implementer finishes and no node waits on another. Nodes use the worktrees step 2.2
+creates (no `isolation` option: the prompt names the worktree). Controlled-cycle clusters become a
+bounded `while` loop per `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md`'s round cap. Route
+`model_tier: strong` nodes via `opts.model` where the harness supports an override. The script never
+touches the store: as each pipeline returns, land and record that node from the main context (steps
+2.4–2.6), then claim again (step 3) and start pipelines for the new rows.
+
+**Fallback** (default — no opt-in required, and always what step 2 below assumes): one background
+subagent call per agent. When several nodes become ready at once, dispatch them all in a single
+message — never one per message, which is exactly the serial behavior this plugin replaces.
+
+## Step 2: One node's pipeline
+
+Every claimed node runs this pipeline on its own — implement → review → land → record — and different
+nodes are at different steps at the same time. Handle each completion the moment it arrives; never hold
+a node back for another.
 
 1. **CLAIM.**
 
@@ -92,103 +109,122 @@ behavior this plugin replaces.
    cypherlite query --database DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/dispatch.cypher
    ```
 
-   It moves the whole frontier to `in_progress` and prints one row per claimed node with everything its
-   agent needs: `slug`, `title`, `type`, `acceptance`, `failure_policy`, `model_tier`, `verify`,
-   `inputs` (an input with a `value` came from an upstream node; one without is external — its `shape`
-   says where to find it), and `outputs`. **No rows** → nothing is ready: go to step 4.
+   It moves every pending node whose dependencies are all completed or cancelled to `in_progress` and
+   prints one routing row per claimed node: `slug`, `type`, `model_tier`, `failure_policy`. That is all
+   you need — agents read the rest themselves. **No rows** → nothing newly ready (step 3).
 
-2. **IMPLEMENT.** First, give every claimed `code`/`test`/`chore` node its own worktree — one shell
-   loop over the wave's slugs, idempotent so an interrupted or re-dispatched node keeps its earlier
-   work (`research`/`decision` nodes touch no files and get no worktree):
+2. **IMPLEMENT.** A `code`/`test`/`chore` node first gets its own worktree (`research`/`decision`/`verify`
+   nodes edit no files and get none) — idempotent, so a reset or re-dispatched node keeps its earlier work:
 
    ```
-   mkdir -p WT
    git worktree list --porcelain | grep -q "^worktree .*/<slug>$" \
      || git worktree add WT/<slug> -b gbuild/<feature>/<slug> BRANCH 2>/dev/null \
      || git worktree add WT/<slug> gbuild/<feature>/<slug>
    ```
 
-   (skip if the worktree already exists; else fork a fresh branch off `BRANCH` — just a ref here, the
-   cwd doesn't matter; if the branch already
-   exists from an earlier attempt, attach to it instead — nothing is redone). Then, in one message,
-   spawn one `Agent` per claimed node with its row. Tell it to:
-   - actually do the work — for `code`/`test`/`chore` nodes make the change **in its worktree**
-     (`WT/<slug>`), never the main working tree: every edit, every check, and every git command runs
-     there, and it commits on the node branch, message `<feature>/<slug>: <what changed>`. A worktree
-     is a fresh checkout — if the project needs installed dependencies to build or test
-     (`node_modules`, `.venv`, …), install or symlink them in the worktree first;
-   - before finishing, run the checks relevant to its change — anything the node's `acceptance` names,
-     and for `code`/`test` nodes the tests covering the files it touched — and leave them green. The
-     per-node review will not re-run these; the full suite runs in the end-of-feature audit;
-   - produce a value for every output field: a scalar or a list of scalars, JSON-encoding anything
-     nested into a string;
-   - record its own UTC start and finish (`date -u +%Y-%m-%dT%H:%M:%SZ`) and end its final message with
-     `{"started_at": "...", "completed_at": "...", "outputs": {...}}`;
-   - **not** run `cypherlite` or touch the store.
-
-3. **REVIEW.** Once IMPLEMENT returns, spawn a `gbuild-reviewer` per node, again all in one message
-   (`agents/gbuild-reviewer.md` — this plugin's own copy, gbuild does not depend on hone-ai being
-   installed). Give it the node's row, the agent's reported outputs, and where the diff is — for a
-   worktree'd node that is its branch, `git diff BRANCH...gbuild/<feature>/<slug>`, plus the worktree
-   path so it can run just the checks `acceptance` names there (the worktree still exists at this
-   point). Never let the implementing agent review its own work.
-
-4. **LAND.** For each `pass` verdict on a `code`/`test`/`chore` node, merge its branch into the
-   feature branch — in the feature worktree `FT`, never the user's checkout — and clean up:
+   (reuse an existing worktree; else fork a fresh branch off `BRANCH`, or attach the branch an earlier
+   attempt left — nothing is redone). Then dispatch the implementer — `Agent` tool, `subagent_type`
+   `gbuild-implementer` / `gbuild-reviewer` (`gbuild:`-prefixed when namespaced), description
+   `implement <slug>` / `review <slug>`, `run_in_background: true` — with this one prompt for both agents:
 
    ```
-   git -C FT merge --no-ff gbuild/<feature>/<slug> \
-     && git worktree remove --force WT/<slug> \
-     && git branch -d gbuild/<feature>/<slug>
+   gbuild node `<slug>`. Store: <DB>. Worktree: <worktree>. Feature branch: <BRANCH>. Agent file: ${CLAUDE_PLUGIN_ROOT}/agents/gbuild-<implementer|reviewer>.md.
    ```
 
-   A merge conflict means two supposedly independent nodes touched the same lines: `git -C FT merge
-   --abort`
-   and treat the node as review-failed, the conflict as its failed criterion — step 5's policy decides
-   (a retry/repair re-dispatch tells the agent to rebase its branch onto `BRANCH` and resolve it).
-   Worktrees and branches are deleted only here, after acceptance — a failed node's stays for its next
-   attempt (step 5).
+   `<DB>`, `<BRANCH>` are `DB`, `BRANCH`; `<implementer|reviewer>` names the agent; `<worktree>` is
+   `WT/<slug>` for `code`/`test`/`chore` and `FT` (read-only) otherwise — every path absolute. The
+   implementer gets a model per its `model_tier` where the harness offers one
+   (`${CLAUDE_PLUGIN_ROOT}/reference/cost-model.md`).
+   Append nothing — no acceptance, inputs, outputs, notes, failed criteria or agent-file text. Retries,
+   repairs and fallbacks use the same prompt: the agent's brief carries the failed criteria.
+
+3. **REVIEW.** The implementer replies with one line; read nothing else:
+   - `done <slug>` and `test -s INBOX/<slug>.json` → dispatch its reviewer right away with the same
+     prompt naming `gbuild-reviewer.md` — a fresh agent, never the implementer.
+   - `done <slug>` but no file → no review; record a fail: `["implementer reported done but <slug>.json is missing"]`.
+   - `failed <slug>: <reason>` → no review; record a fail: `["implementer failed: <reason>"]`.
+
+   The reviewer replies `VERDICT: pass`, or `VERDICT: fail` plus one `[fail] <criterion> — <reason>`
+   line per failed check. It is a pass only with a line exactly `VERDICT: pass` and no `[fail]` lines;
+   `failed_criteria` is the text after `[fail] ` on each line, verbatim and in order. No `VERDICT` line
+   → re-dispatch that reviewer once in the foreground (no background flag); still none →
+   `["reviewer returned no verdict"]`. A `[fail] CONTRADICTS <upstream-slug>` line also hands that
+   upstream node to its own `failure_policy` (step 2.6). The verdict comes only from this reply — never
+   from `INBOX/<slug>.review.json`.
+
+4. **LAND.** A `pass` on a `code`/`test`/`chore` node merges its branch into the feature worktree `FT`,
+   never the user's checkout — one merge at a time, never two in parallel:
 
-5. **RECORD** the whole wave in one call — one result per node, `verdict` from the reviewer's
-   `VERDICT:` line, `failed_criteria` from its `[fail]` lines:
+   ```
+   git -C FT merge --no-ff gbuild/<feature>/<slug>
+   ```
+
+   A conflict means two supposedly independent nodes touched the same lines: list them
+   (`git -C FT diff --name-only --diff-filter=U`), `git -C FT merge --abort`, and record a fail instead:
+   `["merge conflict with BRANCH in <path>[, <path>] — rebase gbuild/<feature>/<slug> onto BRANCH and resolve"]`.
+
+5. **RECORD** — one call per node, as soon as its verdict is settled:
 
    ```
-   cypherlite query --database DB --mode jsonl --param 'results=[
-     {"slug": "<slug>", "verdict": "pass", "failed_criteria": [], "outputs": {...},
-      "started_at": "<iso>", "completed_at": "<iso>"},
-     {"slug": "<slug>", "verdict": "fail", "failed_criteria": ["<criterion>"]}
-   ]' < ${CLAUDE_PLUGIN_ROOT}/cypher/record.cypher
+   cypherlite query --database DB --mode jsonl \
+     --param 'verdict={"slug":"<slug>","verdict":"pass","failed_criteria":[]}' \
+     --fetch-params result=INBOX/<slug>.json --fetch-params review=INBOX/<slug>.review.json \
+     < ${CLAUDE_PLUGIN_ROOT}/cypher/record.cypher
    ```
 
-   Each returned row says whether that node `completed`. A slug missing from the output was not
-   recorded (it wasn't `in_progress`) — find out why before moving on. `InvalidPropertyType` means an
-   output value was a map; the whole batch was rejected — JSON-encode it and send the batch again.
-
-6. **FAILURES.** For each row with `completed: false` (a failed review, an aborted merge, or a pass
-   `record` downgraded because `missing_outputs` is non-empty), apply the node's `failure_policy`
-   (`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`), using its `attempt` as the count:
-   - `retry` / `repair` → re-dispatch implement → review with the failed criteria fed back in, reusing
-     the row you already hold **and the node's existing worktree and branch** — the next attempt builds
-     on them, it does not start over. Then record just those nodes. Bounded: 2 attempts.
-   - `fallback` → dispatch the named alternate approach the same way, but remove the failed attempt's
-     worktree and branch first (`git worktree remove --force`, `git branch -D`) — the alternate
-     approach starts from a fresh branch off `BRANCH`.
+   `verdict` is all you type: `pass`, or `fail` with `failed_criteria` — the reviewer's `[fail]` lines
+   or one of the fixed lines in steps 2.3–2.4, never your own words. Bind `result` from its file only on
+   a pass (`--param 'result={}'` on every fail), and `review` from its file whenever `test -s` finds it
+   (else `--param 'review={}'`) — all three are always bound. record.cypher takes the outputs, times,
+   notes and symbols from the file itself.
+
+   No row, or another slug → it wasn't recorded (the node wasn't `in_progress`) — find out why. Exit 1
+   or 6 → re-run once with `--param 'review={}'`; still failing → re-run with `--param 'result={}'
+   --param 'review={}'` and verdict `fail`,
+   `["result file rejected by record.cypher: <error.kind>: <error.message, first 120 chars>"]`, which
+   can't fail. Then `rm -f INBOX/<slug>.*` and:
+   - `completed: true` → for a worktree'd node `git worktree remove --force WT/<slug>` and
+     `git branch -d gbuild/<feature>/<slug>` — only now, so a pass downgraded after its merge repairs in
+     place. Non-empty `unselected` (a router's unchosen branches) → cancel them with
+     `set-status.cypher`. Then claim again (step 3).
+   - `completed: false` (a failed review, a merge conflict, a failed implementer, or a pass downgraded
+     because `missing_outputs` is non-empty) → step 2.6.
+
+6. **FAILURES.** Apply the node's `failure_policy` (`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`),
+   using its `attempt` as the count:
+   - `retry` / `repair` → back to step 2.2 with the same prompt, reusing the node's existing worktree
+     and branch — the next attempt builds on them, it does not start over. Bounded: 2 attempts.
+   - `fallback` → remove the failed attempt's worktree and branch first (`git worktree remove --force`,
+     `git branch -D`), then step 2.2 — a fresh branch off `BRANCH`; the brief names the alternate
+     approach.
    - `skip` → `cancelled`; `escalate` (or an exhausted retry/repair) → `failed`, its dependents stay
-     blocked while siblings elsewhere keep going; `stop` → `failed` and halt the entire run. One
-     `set-status.cypher` call per status, with every slug that gets it. A node reaching a terminal
-     status gets cleaned up: `git worktree remove --force WT/<slug>` and
+     blocked while everything else keeps going; `stop` → `failed` and halt the run. Set it with
+     `set-status.cypher`, then clean up a worktree'd node: `git worktree remove --force WT/<slug>` and
      `git branch -D gbuild/<feature>/<slug>` — its work was never accepted, so it never lands.
-   - A completed router (`decision` choosing a branch) → cancel the unselected branches with
-     `set-status.cypher` before the next claim.
 
-Nodes in the same wave never read each other's outputs, and every file-touching node works in its own
-worktree, so true concurrent dispatch is safe by construction — the store calls and the merges in `FT`
-are the only serialized points, and since `FT` belongs to this feature alone, other features (or the
-user) changing branches in their own checkouts cannot race them.
+   Then claim again (step 3) — except after `stop`: claim nothing more, finish the pipelines in flight,
+   then step 4.
+
+## Step 3: Claim again
+
+After every `record.cypher` and `set-status.cypher` call, run dispatch.cypher (step 2.1) again and start
+step 2.2 for every row it returns. That is the dataflow: a node starts the moment its own dependencies
+complete, while unrelated slower nodes are still running. Between claims, wait for completion
+notifications and handle each as it arrives.
+
+A node is claimed only once everything it depends on has completed, so nodes in flight together never
+read each other's outputs, and every file-touching node works in its own worktree — concurrency is safe
+by construction. Your store calls and the merges into `FT` are the only serialized points; `FT` belongs
+to this feature alone, so no other checkout can race them.
 
-## Step 3: Next wave
+**Lost notifications.** Claude Code can drop a completion notification when 3 or more background agents
+run at once. When an agent stays silent well past ones started after it, or you wake with nothing new to
+handle, check instead of waiting: an implementer whose `INBOX/<slug>.json` exists counts as
+`done <slug>` (it writes `.tmp` then renames, so presence means complete); otherwise, and for a
+reviewer, fetch the reply by task id (`TaskOutput`) where the harness offers it. A reviewer whose reply
+still can't be had is re-dispatched once in the foreground (step 2.3). Never take a verdict from a file.
 
-Claim again (step 2). Keep going until a claim returns no rows.
+Stop when a claim returns no rows and no agent is in flight: step 4.
 
 ## Step 4: Report and stop
 
@@ -211,6 +247,7 @@ Report: which nodes ran this invocation, which passed review outright vs. needed
 ## Resuming
 
 Re-invoking `/gbuild:run <feature>` after an interruption re-runs step 0 fresh: the feature worktree is
-resolved or re-attached, nodes an interrupted wave left `in_progress` are reset (their worktrees and any
-commits on their branches survive — the re-dispatch reuses them), and the next claim picks up exactly
-the remaining frontier. Nothing needs to be told what already finished — the store is the memory.
+resolved or re-attached, nodes an interrupted run left `in_progress` are reset (their worktrees and any
+commits on their branches survive — the re-dispatch reuses them; their inbox files are discarded), and
+the next claim picks up exactly the remaining frontier. Nothing needs to be told what already finished —
+the store is the memory.

package/skills/status/SKILL.md

@@ -14,9 +14,9 @@ the feature is gone (or was never charted here); say so.
   (`curl -sSfL https://neo4j-labs.github.io/cypherlite/install.sh | bash`).
 - One `cypherlite` command at a time — never parallel tool calls on the same store.
 - Always `--read-only`: status never writes, and a missing store fails fast instead of being created.
+  It takes no lock, so it reads beside a running `/gbuild:run`.
 - Always `--mode jsonl`: one JSON object per row, no output = no rows.
-- `storage locked` → another process (likely a running `/gbuild:run`) holds the store: wait a few
-  seconds, retry up to 3 times, then say so. Anything else: `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
+- Any error: `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
 
 ## Mode
 
@@ -38,7 +38,7 @@ cypherlite query --read-only --database DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/
 
 One call after the other. `status.cypher` gives one row per node with its derived `state`
 (`frontier` / `blocked` / `in_progress` / `completed` / `cancelled` / `failed`), `wave`, `waiting_on`,
-review summary and timestamps — don't re-derive any of these by hand.
+review summary, timestamps and `last_dependency_at` — don't re-derive any of these by hand.
 
 ### 2. Render the graph
 
@@ -61,16 +61,24 @@ attempts. For `failed` nodes, `last_failed_criteria` verbatim — this is what a
 
 ### 4. Concurrency evidence
 
-For each wave with more than one completed node, compare the implementing agents' `started_at` /
-`completed_at` intervals. Report whether they actually overlapped (real concurrent dispatch) or ran
-back-to-back despite being in the same wave (a sign the fallback backend was invoked one node at a time —
-a bug in how `run` was driven, not a graph problem).
+`run` schedules as dataflow: a node is claimed the moment its last dependency completes, not when its
+wave does. Nodes sharing a `wave` need not overlap — a short chain can finish before a slow node beside
+it — so don't judge by overlap; check dispatch timing instead, from the `status.cypher` rows of step 1.
+
+For each node with both `started_at` and `last_dependency_at` (the latest `completed_at` among its
+completed dependencies), report the gap from `last_dependency_at` to `started_at`. A few minutes is
+the dependency's review, merge and record — dataflow working. A much longer gap, e.g. a start that
+waited for an unrelated slower node to complete, means the node sat ready while something else held it
+back (`run` driven wave by wave, or a lost completion notification) — a bug in how `run` was driven,
+not a graph problem. A node with repair attempts (`review_attempts` > 1) started late by design: its
+times are the passing attempt's. Nodes with no dependencies should have started together at the
+beginning of the run.
 
 ### 5. Next action
 
 One priority-ordered list: what `/gbuild:run <feature>` would do next (the current frontier), and
 anything needing a human decision first (`failed` nodes, an empty frontier with incomplete nodes
-remaining, `in_progress` nodes when no run is active — an interrupted wave `run` will reset).
+remaining, `in_progress` nodes when no run is active — interrupted work `run` will reset).
 
 ### 6. Invariant checks