opencode-gbuild 0.4.0 → 0.6.0

package/skills/plan/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: Decomposes a feature into a real dependency graph in .gbuild/<feature>/graph.json — nodes with typed contracts, mandatory concrete acceptance criteria, and edges that pass the cut test. Use when starting new gbuild work, before /gbuild:run.
+description: Decomposes a feature into a real dependency graph in the gbuild CypherLite store (.gbuild/<feature>/db) — nodes with typed field contracts, mandatory concrete acceptance criteria, and edges that pass the cut test. Use when starting new gbuild work, before /gbuild:run.
 ---
 
 Plan the work described in `$ARGUMENTS` as a graph.
@@ -11,9 +11,11 @@ skill: `/gbuild:run <slug>` once — it iterates waves until the graph completes
 `/gbuild:review <slug>`; if it finds issues, reopen with `/gbuild:plan <slug> --add "<fix>"` and
 `/gbuild:run` again; if clean, `/gbuild:pr <slug>`.
 
-Read `${CLAUDE_PLUGIN_ROOT}/reference/graph-format.md` before doing anything — it's the normative schema. `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md`,
-`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`, and `${CLAUDE_PLUGIN_ROOT}/reference/cost-model.md` inform the choices below.
-`${CLAUDE_PLUGIN_ROOT}/reference/checklist.md` is the self-check at the end.
+Read `${CLAUDE_PLUGIN_ROOT}/reference/graph-format.md` (the normative graph model) and
+`${CLAUDE_PLUGIN_ROOT}/reference/cypher.md` (how to talk to the store) before doing anything, and run
+its version check. `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md`,
+`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`, and `${CLAUDE_PLUGIN_ROOT}/reference/cost-model.md`
+inform the choices below. `${CLAUDE_PLUGIN_ROOT}/reference/checklist.md` is the self-check at the end.
 
 ## Mode
 
@@ -22,7 +24,7 @@ Read `${CLAUDE_PLUGIN_ROOT}/reference/graph-format.md` before doing anything —
 | a description, link, or file path             | **Chart** — new feature |
 | an existing feature slug with `--add "<req>"` | **Reopen**              |
 
-A bare slug with no `.gbuild/<slug>/` is a description, not a slug — chart it.
+A bare slug with no `.gbuild/<slug>/db/` is a description, not a slug — chart it.
 
 ## Chart
 
@@ -30,7 +32,7 @@ A bare slug with no `.gbuild/<slug>/` is a description, not a slug — chart it.
 
 Derive the feature slug from `$ARGUMENTS`: kebab-case, ≤4 words, names the outcome not the mechanism
 (`oauth-device-flow`, not `add-some-auth-stuff`). It's the `.gbuild/<slug>/` directory name and the
-`feature` field in `graph.json` — immutable once charted.
+`Feature` node's `feature` property — immutable once charted.
 
 Then get onto a branch for it, so `run`'s commits land somewhere isolated:
 
@@ -44,9 +46,9 @@ Report the branch. Everything below happens on it.
 
 ### 2. Analyse the codebase
 
-Read the project manifest(s), directory structure, `README.md`, and any existing `.gbuild/*/graph.json`
-for related in-flight work. Resolve file paths or URLs in `$ARGUMENTS`; if a reference fails to load,
-say so and ask.
+Read the project manifest(s), directory structure, `README.md`, and — for related in-flight work — the
+`Feature` of every existing store (`feature.cypher` against each `.gbuild/*/db`, one at a time). Resolve
+file paths or URLs in `$ARGUMENTS`; if a reference fails to load, say so and ask.
 
 ### 3. Validate and explore
 
@@ -77,8 +79,8 @@ the survey when there's only one real way — don't perform thoroughness for its
 a `research`-typed GbuildNode in the first wave — `plan` charts it, `run` executes it. `plan` does
 not run prototypes inline (the "Plan, don't do" rule below). The one exception: a check so cheap it
 finishes in a single tool call (grep, read a file, check an installed version) — do that inline and
-note the result. A prototype worth charting names the specific question it answers in its
-`contract.output`, and its `acceptance` is the answer to that question.
+note the result. A prototype worth charting names the specific question it answers in its `OUTPUT`
+field, and its `acceptance` is the answer to that question.
 
 ### 4. Name the destination
 
@@ -87,108 +89,102 @@ done. Do not proceed until it's that sharp; everything past it goes in `out_of_s
 
 ### 5. Decompose into nodes, not steps
 
-List the real pieces of work. For each pair, apply the **cut test** (`${CLAUDE_PLUGIN_ROOT}/reference/graph-format.md`):
-does one actually read the other's output? If no, they're independent — same wave, not a chain. This is
-the step hone-ai v1 skipped, and the whole reason gbuild exists: state the true dependency structure,
-don't default to the order you thought of things in.
-
-Classify each cluster's shape per `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md` (chain / diamond / router / controlled cycle).
-A controlled cycle needs its round cap and dedup rule decided now, not left to `run` to invent.
-
-The graph is a **CypherLite GraphData file** (see `${CLAUDE_PLUGIN_ROOT}/reference/graph-format.md` — normative). You
-write three kinds of nodes and three kinds of relationships:
-
-- **`Feature` node** (id 1) — one per graph, properties `feature` (the slug), `destination`, `context`,
-  `out_of_scope` (array). No `acceptance` property here.
-- **`Acceptance` nodes** — one per feature-level bullet, properties `id` (`a-1`, `a-2`, …) and `text`.
-  Each linked `Feature -[:HAS_ACCEPTANCE]-> Acceptance`.
-- **`GbuildNode`s** — one per unit of work. Integer `id` (sequential after the Feature and Acceptance
-  nodes), `labels` `["GbuildNode", <PascalCase type>]`, properties `slug` / `title` / `type` (lowercase
-  enum) / `contract` (`{input,output}`) / `acceptance` (node-level local criteria) / `verify` / `failure_policy`
-  / `model_tier`. No `satisfies` property — use a `SATISFIES` edge instead.
-- **`DEPENDS_ON` relationships** — one per dependency that passed the cut test. Direction
-  dependent→dependency (`start_node` depends on `end_node`). Both endpoints are GbuildNodes.
-- **`SATISFIES` relationships** — `GbuildNode -[:SATISFIES]-> Acceptance` for each global criterion a
-  node covers.
-- **`HAS_ACCEPTANCE` relationships** — `Feature -[:HAS_ACCEPTANCE]-> Acceptance`, one per bullet.
-
-For each GbuildNode, write:
-
-- `id` — integer, sequential, unique, never reused. Authoring convenience; `slug` is the stable identity.
-- `slug` — filename-safe, kebab-case, immutable once created. This is what skills and checkpoint files
-  key on; it's how nodes are referred to in anything the user reads.
-- `type` — `research | decision | code | test | verify | chore`. Set both the lowercase `type` property
-  and the matching PascalCase label (`Code`, `Research`, …).
-- `contract.input` / `contract.output` — structured shapes, not prose. A downstream node's `input`
-  should be able to reference an upstream node's `output` field directly.
-- `acceptance` — **mandatory, non-empty, concrete.** No vague adjectives ("looks correct", "works
-  well"). A criterion a fresh context with no other information couldn't check is not concrete enough.
-  Rewrite it until it names a file, a shape, a value, or a command's result.
-- `verify` — only set when this node needs something *beyond* the standard `gbuild-reviewer` pass
-  (adversarial check, fact-check, human approval). Usually `null`.
-- `failure_policy` — pick per `${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`, don't default everything to `retry`.
-- `model_tier` — `strong` only where judgement, not throughput, is the bottleneck
-  (`${CLAUDE_PLUGIN_ROOT}/reference/cost-model.md`).
-
-Wire each dependency as a `DEPENDS_ON` relationship (not a `dependencies` array on the node), and each
-criterion a node covers as a `SATISFIES` relationship (not a `satisfies` array). Set `next_node_id` and
-`next_rel_id` to `max(id)+1` for each kind. `${CLAUDE_PLUGIN_ROOT}/templates/graph.json` is a complete worked example.
+List the real pieces of work. For each pair, apply the **cut test** (`graph-format.md`): does one
+actually read the other's output? If no, they're independent — same wave, not a chain. This is the step
+hone-ai v1 skipped, and the whole reason gbuild exists: state the true dependency structure, don't
+default to the order you thought of things in.
+
+Classify each cluster's shape per `${CLAUDE_PLUGIN_ROOT}/reference/shapes.md` (chain / diamond / router /
+controlled cycle). A controlled cycle needs its round cap and dedup rule decided now, not left to `run`
+to invent.
+
+For each GbuildNode decide (full model in `graph-format.md`):
+
+- `slug` — kebab-case, immutable; what skills and the store key on. `title` — what the user reads.
+- `type` — `research | decision | code | test | verify | chore`, plus the matching PascalCase label.
+- **`OUTPUT` fields** — every node declares at least one, each with a precise `shape`
+  (`<integer>`, `<list of changed file paths>`, `<commit sha>`). Values will be scalars or lists of
+  scalars; for anything nested, the shape says it is a JSON-encoded string.
+- **`INPUT` fields** — one per value the node reads. If it comes from another node, wire it
+  `FROM` that node's `OUTPUT` field and add the `DEPENDS_ON`. If it comes from the codebase or the
+  environment, leave it without `FROM` and say where in its `shape`. The cut test is now concrete:
+  a `DEPENDS_ON` exists exactly when the node reads one of the other's outputs.
+- `acceptance` — **mandatory, non-empty, concrete.** No vague adjectives. A criterion a fresh context
+  with no other information couldn't check is not concrete enough — rewrite it until it names a file, a
+  shape, a value, or a command's result.
+- `verify` — only when the node needs something *beyond* the standard `gbuild-reviewer` pass. Usually
+  omitted.
+- `failure_policy` — per `${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`, don't default everything
+  to `retry`. `model_tier` — `strong` only where judgement, not throughput, is the bottleneck.
+- `status: 'pending'` — every new node starts pending.
 
 ### 6. Write the global acceptance bar
 
-The feature-level bar is one `Acceptance` node per bullet, each linked `Feature -[:HAS_ACCEPTANCE]-> Acceptance`,
-with ids `a-1`, `a-2`, …. Every bullet must end up covered by at least one node's `SATISFIES` edge —
-that's checked in step 7 and enforced by the validator.
+The feature-level bar is one `Acceptance` node per bullet (`id` `a-1`, `a-2`, …), each linked
+`(:Feature)-[:HAS_ACCEPTANCE]->(:Acceptance)`. Every bullet must end up covered by at least one node's
+`SATISFIES` edge — the validator enforces it.
 
 ### 7. Self-check against the checklist
 
-Walk every item in `${CLAUDE_PLUGIN_ROOT}/reference/checklist.md` against the graph you just wrote. Fix the graph, don't
-annotate around a failing item.
+Walk every item in `${CLAUDE_PLUGIN_ROOT}/reference/checklist.md` against the graph you designed. Fix the
+design, don't annotate around a failing item.
 
-### 8. Write and validate
+### 8. Create the store and write the graph
 
-Write `.gbuild/<slug>/graph.json` (a CypherLite GraphData file). **Run the format validator first:**
+Create the store exactly as `reference/cypher.md` § Creating a store shows (`mkdir`, `schema.cypher` with
+`--snapshot-format json`, the `db/.gitignore`).
+
+Then write the whole graph as **one** Cypher script, piped through a quoted heredoc.
+`${CLAUDE_PLUGIN_ROOT}/templates/example.cypher` is a complete worked example — follow its structure:
+`.begin`, a single statement of `CREATE` clauses (so variables like `a1` or `a_value` stay in scope for
+the edges), `.commit`, `.checkpoint`.
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate_format.py .gbuild/<slug>/graph.json
+cypherlite .gbuild/<slug>/db <<'CYPHER'
+.begin
+CREATE (f:Feature {feature: '<slug>', destination: '...', context: '...', out_of_scope: ['...']})
+CREATE (a1:Acceptance {id: 'a-1', text: '...'})
+CREATE (f)-[:HAS_ACCEPTANCE]->(a1)
+CREATE (n:GbuildNode:Code {slug: '...', title: '...', type: 'code', acceptance: ['...'],
+                           failure_policy: 'repair', model_tier: 'cheap', status: 'pending'})
+CREATE (n)-[:OUTPUT]->(n_out:Field {name: '...', shape: '<...>'})
+...
+CREATE (m)-[:DEPENDS_ON]->(n)
+CREATE (m)-[:INPUT]->(:Field {name: '...', shape: '<...>'})-[:FROM]->(n_out)
+CREATE (m)-[:SATISFIES]->(a1);
+.commit
+.checkpoint
+CYPHER
 ```
 
-If it prints `invalid: ...`, fix the file and re-run — never hand off or commit a file that fails
-validation. The validator is the format gate; it checks the GraphData envelope, node shapes, the three
-relationship types, id/counter invariants, acyclicity, and coverage. **Run it after every change** —
-initial write, reopen, any hand-edit, any fix-up — before doing anything else with the file.
+A constraint violation (`ConstraintValidationFailed`: a missing property, a wrong type, a duplicate
+slug) fails the transaction and writes nothing — fix the script and run it again.
 
-Then confirm run-readiness:
+### 9. Validate
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<slug>/graph.json --status
+cypherlite .gbuild/<slug>/db -json < ${CLAUDE_PLUGIN_ROOT}/cypher/validate.cypher
 ```
 
-The graph is now queryable with Cypher **if the `cypherlite` binary is on PATH** (`command -v
-cypherlite`) — in that case you can mention it to the user:
+`[]` means valid. Every row is a violation (`check`, `detail`): fix it with Cypher — a `.begin` …
+`.commit` … `.checkpoint` script of `MATCH … SET/CREATE/DELETE` — and re-run until it prints `[]`. Never
+hand off or commit a graph that fails validation, and never edit `graph.json` directly.
+
+Then confirm run-readiness:
 
 ```
-cypherlite .gbuild/<slug>/graph.json "MATCH (n:GbuildNode) RETURN n.slug, n.type"
+cypherlite .gbuild/<slug>/db -json < ${CLAUDE_PLUGIN_ROOT}/cypher/status.cypher
 ```
 
-If the binary is absent, skip this without comment. CypherLite is an optional consumer, never a
-requirement — `validate_format.py` already cross-checks with it when present and passes without it,
-and the user should never be asked to install it.
-
-### 9. Fire research nodes
-
-For each `research`-typed node in the initial wave, dispatch a subagent **in parallel** (one message,
-multiple `Agent` calls). Give each the node's `contract.input`, `acceptance`, and enough context to
-work independently. Each writes its `output` to `.gbuild/<slug>/nodes/<id>.json` directly (`status:
-completed`) — these still get a `gbuild-reviewer` pass before `run` will treat them as satisfying
-anyone's dependency, same as every other node type.
+The `wave` column is the decomposition; rows with `state: frontier` are what `run` dispatches first.
 
 ### 10. Commit and stop
 
-Commit `.gbuild/<slug>/` unless the repo ignores it (`git check-ignore -q .gbuild/`; if true, don't
-stage anything under it). Message: `<slug>: chart graph`.
+Commit `.gbuild/<slug>/` unless the repo ignores it (`git check-ignore -q .gbuild/`; if true, don't stage
+anything under it). The store's own `.gitignore` limits that to `db/graph.json` and `db/.gitignore`.
+Message: `<slug>: chart graph`.
 
-Report the branch, the wave decomposition, and the frontier. Close with `next: /gbuild:run <slug>`.
+Report the branch, the waves, and the frontier. Close with `next: /gbuild:run <slug>`.
 
 ## Reopen
 
@@ -196,22 +192,40 @@ Report the branch, the wave decomposition, and the frontier. Close with `next: /
 
 0. Check out the feature's existing branch if you're not on it. Never chart a reopen onto a different
    branch than the one the graph was charted on.
-1. Add a new `Acceptance` node (next `a-` id) + a `Feature -[:HAS_ACCEPTANCE]-> Acceptance` edge for the
-   requirement.
-2. Decompose whatever new GbuildNodes it needs, wire `DEPENDS_ON` edges against the *existing* graph (a
-   new node may depend on an already-completed one — that's fine, its dependency is satisfied) and
-   `SATISFIES` edges to the new (or existing) `Acceptance` nodes it covers. Assign the next available
-   integer ids, bump `next_node_id`/`next_rel_id`. Re-run the checklist against the delta.
-3. **Re-run `validate_format.py`** (counters, coverage, acyclicity all re-checked on the mutated graph),
-   then `graph.py --status`. Commit (`<slug>: reopen graph — <what was added>`), report the new frontier.
+1. Read the current graph (`status.cypher`, and `node.cypher` for any node the requirement touches).
+2. Design the delta: a new `Acceptance` node (next `a-` id) linked from the `Feature`, and whatever new
+   GbuildNodes it needs, with their `Field`s. A new node may depend on an already-completed one — wire
+   its `INPUT` `FROM` that node's `OUTPUT` like any other; its value is already recorded. Re-run the
+   checklist against the delta.
+3. Write it as one script that `MATCH`es what it connects to and `CREATE`s the rest:
+
+   ```
+   cypherlite .gbuild/<slug>/db <<'CYPHER'
+   .begin
+   MATCH (f:Feature), (up:GbuildNode {slug: '<existing-slug>'})-[:OUTPUT]->(up_out:Field {name: '<field>'})
+   CREATE (f)-[:HAS_ACCEPTANCE]->(a:Acceptance {id: 'a-3', text: '...'})
+   CREATE (n:GbuildNode:Code {slug: '...', ..., status: 'pending'})
+   CREATE (n)-[:DEPENDS_ON]->(up)
+   CREATE (n)-[:INPUT]->(:Field {name: '...', shape: '<...>'})-[:FROM]->(up_out)
+   CREATE (n)-[:OUTPUT]->(:Field {name: '...', shape: '<...>'})
+   CREATE (n)-[:SATISFIES]->(a);
+   .commit
+   .checkpoint
+   CYPHER
+   ```
+
+4. **Re-run `validate.cypher`** until it prints `[]`, then `status.cypher`. Commit
+   (`<slug>: reopen graph — <what was added>`), report the new frontier.
 
 If the requirement needs no new nodes (an existing node's contract already covers it), say so and stop
 — don't manufacture graph churn.
 
 ## Rules
 
-- **Plan, don't do.** Nodes here get *defined*, not executed — even `research` nodes just write
-  findings to their own checkpoint, they don't touch anything `run` is responsible for.
+- **Plan, don't do.** Nodes here get *defined*, not executed — even `research` nodes. They land in the
+  first wave and `run` dispatches them.
+- **The store is only touched through `cypherlite`**, from this skill, one command at a time
+  (`reference/cypher.md`).
 - **Acceptance criteria are the bar, not a formality.** A node with vague acceptance is a node
   `gbuild-reviewer` can't actually check — that's a planning failure, not something to fix later.
-- **Refer to nodes by title in anything the user reads.** IDs are for the graph, not the conversation.
+- **Refer to nodes by title in anything the user reads.** Slugs are for the graph, not the conversation.

package/skills/pr/SKILL.md

@@ -12,7 +12,9 @@ This skill MUST run in the **main conversation context**. It MUST NOT be invoked
 
 `$ARGUMENTS` is free-form text: an optional feature slug and an optional `--max-rounds N` flag.
 
-- **slug**: the first token that isn't a flag. If absent, infer it — the current branch commonly ends in the slug (`plan` checks out `<prefix>/<slug>`), otherwise fall back to the most recently modified `.gbuild/*/graph.json`. If neither resolves, leave `<slug>` unresolved (the auto-fix step degrades gracefully — see Step 4).
+- **slug**: the first token that isn't a flag. If absent, infer it — the current branch commonly ends in the slug (`plan` checks out `<prefix>/<slug>`), otherwise fall back to the store whose `.gbuild/*/db/graph.json` was most recently modified. If neither resolves, leave `<slug>` unresolved (the auto-fix step degrades gracefully — see Step 4).
+
+When `<slug>` resolved, read `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md` and run its version check — every graph read below goes through `cypherlite`, one command at a time.
 - **max_rounds**: the value of `--max-rounds N` (also accept `--max-rounds=N`). Default `3` when absent.
 
 ## Step 1: Preconditions
@@ -25,7 +27,7 @@ Verify the environment before touching the remote. Stop with a clear, actionable
 4. **Not on base.** Get the current branch (`git branch --show-current`). If it equals `<base>`, stop — there is nothing to open a PR for.
 5. **Clean tree.** Check for uncommitted changes (`git status --porcelain`). `/gbuild:run` commits each node's work as it goes, so the tree should be clean. If there are uncommitted changes, warn the user and ask whether to proceed (they may want to commit first).
 6. **Commits ahead of base.** Confirm the branch has commits the base lacks (`git log <base>..HEAD --oneline`). If empty, stop — nothing to push.
-7. **Graph finished.** When `<slug>` resolved, run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<slug>/graph.json --status`. If the frontier is non-empty or nodes are still `in_progress`, warn that the graph isn't finished and ask whether to open the PR anyway. If any node is `failed`, name it — a PR built on an escalated node is usually premature.
+7. **Graph finished.** When `<slug>` resolved, run `cypherlite .gbuild/<slug>/db -json < ${CLAUDE_PLUGIN_ROOT}/cypher/status.cypher`. If any row has `state: frontier` or `in_progress`, warn that the graph isn't finished and ask whether to open the PR anyway. If any node is `failed`, name it — a PR built on an escalated node is usually premature.
 
 ## Step 2: Determine the remote & push
 
@@ -45,7 +47,7 @@ Gather context from:
 
 - Commit subjects: `git log <base>..HEAD --oneline`.
 - File overview: `git diff <base>...HEAD --stat`.
-- When present: the `Feature` node's `destination` property and the `Acceptance` nodes (linked `Feature -[:HAS_ACCEPTANCE]-> Acceptance`) from `.gbuild/<slug>/graph.json` (a CypherLite GraphData file), and the per-node `output` values in `.gbuild/<slug>/nodes/*.json` (keyed by GbuildNode `slug`).
+- When `<slug>` resolved: `cypherlite .gbuild/<slug>/db -json < ${CLAUDE_PLUGIN_ROOT}/cypher/feature.cypher` — the `destination`, the acceptance bar (with the nodes covering each criterion), and every node's recorded output values.
 
 Derive a concise, conventional-commit-style title from the feature/branch and the changes (e.g. `feat(auth): add OAuth login`).
 

package/skills/review/SKILL.md

@@ -11,20 +11,28 @@ missed abstractions that only exist *between* nodes, which no per-node review ca
 ## Arguments
 
 `$ARGUMENTS` is optional. If present, treat it as the feature slug. If absent, infer it — the current
-branch commonly ends in the slug (`plan` checks out `<prefix>/<slug>`), otherwise fall back to the most
-recently modified `.gbuild/*/graph.json`. Do NOT write any file — this skill outputs to chat exclusively.
+branch commonly ends in the slug (`plan` checks out `<prefix>/<slug>`), otherwise fall back to the store
+whose `.gbuild/*/db/graph.json` was most recently modified. Do NOT write any file — this skill outputs to
+chat exclusively.
 
-Run `python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate_format.py .gbuild/<slug>/graph.json` then
-`python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<slug>/graph.json --status` first. If the frontier is
-non-empty or nodes are still `in_progress`, say the graph isn't finished and ask whether to audit anyway
-— auditing a half-built branch produces findings that the remaining nodes were going to address.
+Read `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md` and run its version check. Then, one after the other,
+run `validate.cypher` and `status.cypher` against `.gbuild/<slug>/db`. If the frontier is non-empty or
+nodes are still `in_progress`, say the graph isn't finished and ask whether to audit anyway — auditing a
+half-built branch produces findings that the remaining nodes were going to address.
 
 ## Run the audit
 
+Fetch the feature context:
+
+```
+cypherlite .gbuild/<slug>/db -json < ${CLAUDE_PLUGIN_ROOT}/cypher/feature.cypher
+```
+
 Launch the `gbuild-auditor` subagent (agents/gbuild-auditor.md — this plugin's own copy, gbuild does not
 depend on hone-ai being installed). Pass it:
 
-- The resolved slug and its `.gbuild/<slug>/graph.json` path.
+- The resolved slug and the `feature.cypher` result verbatim (destination, acceptance bar with the nodes
+  covering each criterion, every node's recorded outputs) — the auditor never opens the store itself.
 - Tell it to audit the current branch.
 
 The sub-agent runs the full audit in its own fresh context and returns the audit as its final message.

package/skills/run/SKILL.md

@@ -1,99 +1,140 @@
 ---
-description: Executes a gbuild graph — dispatches every ready-and-independent node in the current wave concurrently, reviews each node's output with gbuild-reviewer before checkpointing it complete, and resumes only the remaining frontier on re-invocation. Use after /gbuild:plan has written graph.json.
+description: Executes a gbuild graph — dispatches every ready-and-independent node in the current wave concurrently, reviews each node's output with gbuild-reviewer before recording it complete, and resumes only the remaining frontier on re-invocation. Use after /gbuild:plan has charted the graph.
 ---
 
-Run `.gbuild/$ARGUMENTS/graph.json` (the feature slug is `$ARGUMENTS`).
+Run the graph in `.gbuild/$ARGUMENTS/db` (the feature slug is `$ARGUMENTS`).
 
 **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.
+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. Read `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`
+first and run its version check; `DB` below is `.gbuild/<feature>/db`.
 
 ## Step 0: Load and query
 
-Load `.gbuild/<feature>/graph.json` (a CypherLite GraphData file — nodes keyed by integer `id`, with a
-`slug` property; dependencies are `DEPENDS_ON` relationships, feature-level acceptance is `Acceptance`
-nodes linked by `HAS_ACCEPTANCE`/`SATISFIES`). **Confirm it's well-formed first:**
+**Confirm the graph is well-formed:**
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate_format.py .gbuild/<feature>/graph.json
+cypherlite DB -json < ${CLAUDE_PLUGIN_ROOT}/cypher/validate.cypher
 ```
 
-If it prints `invalid: ...`, stop and report — do not attempt to run a graph `plan` didn't finish
-correctly. Then take the frontier:
+Anything but `[]` → stop and report the rows; do not run a graph `plan` didn't finish correctly. Then:
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<feature>/graph.json --status
+cypherlite DB -json < ${CLAUDE_PLUGIN_ROOT}/cypher/status.cypher
 ```
 
-Take the `frontier` list (node **slugs**) from the status report. This is the set of nodes ready
-right now — not a judgement call, the query already excludes anything blocked, in-flight, or done.
-
-If `frontier` is empty and `completed` + `cancelled` covers every node, the graph is done — report that
-and stop. If `frontier` is empty but nodes remain incomplete, there's a stuck cluster (likely an
-`escalate`d or `stop`ped node) — report what's blocking per the last checkpoint and stop.
+- **Rows with `state: in_progress`** at this point are left over from an interrupted run (this skill is
+  the only writer, and it records every node before finishing). Check `git log` for commits the node's
+  agent already made, reset each to `pending` with `set-status.cypher` (`--param 'status="pending"'`) so
+  it re-dispatches, and mention it in the report.
+- The rows with `state: frontier` are the set ready right now — not a judgement call; the query already
+  excludes anything blocked, in flight, or done.
+- If there is no frontier and every row is `completed` or `cancelled`, the graph is done — report that
+  and stop. If there is no frontier but nodes remain incomplete, there's a stuck cluster (likely an
+  `escalate`d or `stop`ped node, now `failed`) — report what's blocking and stop.
 
 ## Step 1: Establish VCS facts
 
-Default to `git`. `git check-ignore -q .gbuild/` tells you whether to stage anything under it at all.
+Default to `git`. `git check-ignore -q .gbuild/` tells you whether to commit the store at all.
 
 ## Step 2: Pick a backend
 
 **Workflow tool**, if this session has opted into multi-agent orchestration (ultracode, or the user
-asked for a workflow explicitly) — translate `frontier` into a `pipeline()`/`parallel()` script: each
+asked for a workflow explicitly) — translate the frontier 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 `contract.output` + `acceptance`, using `schema` for the pass/fail verdict. Code
-nodes touching files that could conflict with a concurrent sibling get `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.
+scoped to that node's outputs + `acceptance`, using `schema` for the pass/fail verdict. Code nodes
+touching files that could conflict with a concurrent sibling get `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 every implement and review result, then record them from the
+main context exactly as step 3.4 describes.
 
 **Fallback** (default — no opt-in required, and always what step 3 below assumes): fire one `Agent`
-tool call per node in the current `frontier`, **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 3: Per-node dispatch (fallback backend)
-
-For every node in the current wave's `frontier`, in one message, spawn one `Agent` call per node:
-
-1. **IMPLEMENT.** Give the agent the node's `slug`, `title`, `type`, `contract.input` (resolved: for
-   each `DEPENDS_ON` target, read the actual `output` values from its checkpoint
-   `.gbuild/<feature>/nodes/<dep-slug>.json`), and `acceptance`. Tell it to produce `contract.output`'s
-   declared shape and, for `code`/`test`/`chore` nodes, to actually make the change in the working tree
-   (not describe it) and commit it — message `<feature>/<slug>: <what changed>`.
-2. **REVIEW.** Once IMPLEMENT returns, spawn a `gbuild-reviewer` agent (agents/gbuild-reviewer.md — this
-   plugin's own copy, gbuild does not depend on hone-ai being installed) against the actual diff and
-   output. Never let the implementing agent review its own work.
-3. **PASS or FAIL:**
-   - **Pass** (`VERDICT: pass`): write `.gbuild/<feature>/nodes/<slug>.json` with `status: completed`,
-     the `output`, the review verdict, and timestamps.
-   - **Fail**: apply the node's `failure_policy` (`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`) — `retry`/`repair`
-     re-dispatch (bounded, 2 attempts) with the reviewer's per-criterion failures fed back in;
-     `fallback` dispatches the named alternate approach; `skip` checkpoints `cancelled`; `escalate`
-     checkpoints `failed` and stops that node's downstream only; `stop` halts the entire run.
-
-Each node's checkpoint write is independent — nodes in the same wave never touch each other's files, so
-true concurrent dispatch is safe by construction.
+tool call per frontier 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 3: One wave (fallback backend)
+
+1. **MARK.** Move the whole frontier to `in_progress` in one call and check that `dispatched` lists every
+   slug you passed:
+
+   ```
+   cypherlite DB -json --param 'slugs=["<slug>", ...]' < ${CLAUDE_PLUGIN_ROOT}/cypher/dispatch.cypher
+   ```
+
+   Then fetch each node's definition — `node.cypher` with `--param 'slug="<slug>"'`, one call per node,
+   one after the other. Its `inputs` are already resolved: each input read from another node carries
+   the upstream `value`.
+
+2. **IMPLEMENT.** In one message, spawn one `Agent` per node. Give each the node's `slug`, `title`,
+   `type`, `inputs` (name, shape, value — or for an input with no `from`, where to find it),
+   `outputs` (name, shape), and `acceptance`. Tell it to:
+   - actually do the work — for `code`/`test`/`chore` nodes make the change in the working tree (not
+     describe it) and commit it, message `<feature>/<slug>: <what changed>`;
+   - 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
+     a JSON object `{"started_at": "...", "completed_at": "...", "outputs": {...}}`;
+   - **not** run `cypherlite` or touch `.gbuild/`.
+
+3. **REVIEW.** Once IMPLEMENT returns, spawn a `gbuild-reviewer` agent 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 definition from `node.cypher`, the implementing agent's reported
+   outputs, and where the diff is. Never let the implementing agent review its own work.
+
+4. **RECORD** — sequentially, one `cypherlite` call at a time, after the agents returned. For each node:
+
+   ```
+   cypherlite DB -json --param 'slug="<slug>"' --param 'verdict="pass"' --param 'failed_criteria=[]' \
+     < ${CLAUDE_PLUGIN_ROOT}/cypher/record-review.cypher
+   ```
+
+   (`verdict="fail"` and the reviewer's failed criteria as `failed_criteria` on a fail.)
+
+   - **Pass** (`VERDICT: pass`): record it complete with the agent's outputs and times.
+
+     ```
+     cypherlite DB -json --param 'slug="<slug>"' --param 'outputs={...}' \
+       --param 'started_at="<iso>"' --param 'completed_at="<iso>"' < ${CLAUDE_PLUGIN_ROOT}/cypher/complete.cypher
+     ```
+
+     Check `completed: true`. If it is `false`, `missing_outputs` names the output fields the agent didn't
+     produce — treat that as a failed review with those as the failed criteria. An `InvalidPropertyType`
+     error means an output value was a map: JSON-encode it into a string and record again.
+   - **Fail**: apply the node's `failure_policy` (`${CLAUDE_PLUGIN_ROOT}/reference/failure-policies.md`).
+     `retry`/`repair` re-dispatch implement → review (bounded: 2 attempts — `review_attempts` in
+     `status.cypher` counts them) with the reviewer's failed criteria fed back in; the node stays
+     `in_progress`. `fallback` dispatches the named alternate approach. `skip` sets it `cancelled`,
+     `escalate` sets it `failed` (its dependents stay blocked; siblings elsewhere keep going), both with
+     `set-status.cypher`. `stop` sets it `failed` and halts the entire run.
+
+Nodes in the same wave never read each other's outputs, so true concurrent dispatch is safe by
+construction — only the recording is serialized.
 
 ## Step 4: Next wave
 
-Re-run `graph.py --status`. If the wave that just finished unblocked new frontier nodes, repeat step 3
-for them. Keep going until `frontier` is empty (done, or stuck — see step 0's exit conditions).
+If `.gbuild/` isn't ignored, commit the store: `git add .gbuild/<feature>/db` and
+`git commit -m "<feature>: record wave <n>"`. Re-run `status.cypher`. If the wave that just finished
+unblocked new frontier nodes, repeat step 3 for them. Keep going until there is no frontier (done, or
+stuck — see step 0's exit conditions).
 
 ## Step 5: Report and stop
 
 Report: which nodes ran this invocation, which passed review outright vs. needed a repair pass, what's
-newly in the frontier or still blocked, and any `failed`/`escalate`d nodes needing a decision.
+newly on the frontier or still blocked, and any `failed` nodes needing a decision.
 
 Close with the next step:
 
 - **Graph fully done** (every node `completed` or `cancelled`) → say so plainly, then
   `next: /gbuild:review <feature>` — the per-node reviews graded each node against its own contract;
   nothing has yet looked at what the accumulated diff did to the codebase.
-- **Work remains** (frontier non-empty, or nodes `failed`/`escalate`d awaiting a decision) →
+- **Work remains** (frontier non-empty, or nodes `failed` awaiting a decision) →
   `next: /gbuild:status <feature>`.
 
 ## Resuming
 
-Re-invoking `/gbuild:run <feature>` after an interruption re-runs step 0 fresh: anything with a
-`completed` or `cancelled` checkpoint is excluded from `frontier` automatically, so only the genuinely
-remaining work re-dispatches. Nothing needs to be told what already finished — the checkpoint files are
-the memory.
+Re-invoking `/gbuild:run <feature>` after an interruption re-runs step 0 fresh: completed and cancelled
+nodes are excluded from the frontier automatically, and nodes an interrupted wave left `in_progress` are
+reset and re-dispatched. Nothing needs to be told what already finished — the store is the memory.