opencode-gbuild 0.5.0 → 0.6.1

package/reference/shapes.md

@@ -1,8 +1,8 @@
 # Graph shapes
 
 `plan` classifies each cluster of nodes it creates into one of these. `run` uses the classification to
-decide how to schedule it. This is a lens for judgement, not a field stored on the node — the shape
-falls out of `dependencies`.
+decide how to schedule it. This is a lens for judgement, not a property stored on the node — the shape
+falls out of the `DEPENDS_ON` edges.
 
 ## Chain
 
@@ -24,10 +24,11 @@ though nothing requires it; the whole point of a real dependency graph is that `
 ## Router
 
 One node whose output selects which of several downstream nodes actually runs — not all of them, not
-none, exactly the branch the output implies. Model this as a `decision`-type node whose `contract.output`
-names the chosen branch, with the downstream nodes each depending on it; `run`'s job is to only dispatch
-the node(s) the router's output actually selected, and mark the un-selected siblings `cancelled` (which,
-per the derived-queries rule, still satisfies anything waiting on "the router resolved").
+none, exactly the branch the output implies. Model this as a `decision`-type node with an `OUTPUT`
+field naming the chosen branch, and each downstream node depending on it with an `INPUT` field `FROM`
+that output; `run`'s job is to only dispatch the node(s) the router's output actually selected, and mark
+the un-selected siblings `cancelled` (which, per the status lifecycle, still satisfies anything waiting
+on "the router resolved").
 
 ## Controlled cycle
 
@@ -40,9 +41,9 @@ in a graph must have, at plan time:
 - an explicit **exit node** reached either by the verify passing or by hitting the cap and escalating
 
 `run` implements this as a bounded loop (see `skills/run/SKILL.md`), never as extra graph edges that
-loop back on themselves — `scripts/graph.py` rejects literal cycles in `dependencies` (that's how it
-catches a malformed graph). A controlled cycle is a *behavior* `run` executes around a small
-sub-cluster, not a topology `graph.py` has to tolerate.
+loop back on themselves — `validate.cypher` rejects literal `DEPENDS_ON` cycles (that's how it catches a
+malformed graph). A controlled cycle is a *behavior* `run` executes around a small sub-cluster, not a
+topology the graph has to tolerate.
 
 ## Choosing a shape
 

package/skills/plan/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: Decomposes a feature into a real dependency graph in .gbuild/<feature>/db/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/*/db/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,111 +89,103 @@ 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>/db/graph.json` (a CypherLite GraphData file). It lives alone in the `db/` folder so
-CypherLite can open that folder as a JSON-store database; checkpoints stay in the sibling
-`.gbuild/<slug>/nodes/` directory. **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>/db/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>/db/graph.json --status
+cypherlite .gbuild/<slug>/db --mode jsonl < ${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. Point CypherLite at the `db/` folder
-(not the `.json` file), and keep it read-only:
+No output 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 nothing. Never
+hand off or commit a graph that fails validation, and never edit `graph.json` directly.
+
+Then confirm run-readiness:
 
 ```
-cypherlite .gbuild/<slug>/db "MATCH (n:GbuildNode) RETURN n.slug, n.type"
+cypherlite .gbuild/<slug>/db --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/progress.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.
+One row per wave: each row's `open` slugs are the decomposition, and the `frontier` counts are what
+`run` claims first. Nodes you expected to run together should share a wave.
 
 ### 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
 
@@ -199,22 +193,41 @@ 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 narrowly: `progress.cypher` for its shape and what's done, and `node.cypher`
+   only for the nodes 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 nothing, then `progress.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/*/db/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, every graph read below goes through `cypherlite`: run `cypherlite --version` first (missing → stop; gbuild needs it), one command at a time, always `--mode jsonl` (no output = no rows), and on `storage locked` wait and retry up to 3 times. Anything else: `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
 - **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>/db/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 --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/progress.cypher`. If any row's `open` is non-empty, warn that the graph isn't finished (name the open nodes) and ask whether to open the PR anyway. If any row has `failed` > 0, get their names from `attention.cypher` and name them — 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>/db/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 --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/feature.cypher` — the `destination` and the acceptance bar (with the nodes covering each criterion).
 
 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,38 @@ 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/*/db/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>/db/graph.json` then
-`python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<slug>/db/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.
+Store rules: run `cypherlite --version` first (missing → stop; gbuild needs it). One `cypherlite`
+command at a time, always `--mode jsonl` (no output = no rows); on `storage locked` wait and retry up to
+3 times. Anything else: `${CLAUDE_PLUGIN_ROOT}/reference/cypher.md`.
+
+Check the graph is finished — one row per wave, cheap:
+
+```
+cypherlite .gbuild/<slug>/db --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/progress.cypher
+```
+
+If any row's `open` is non-empty, say the graph isn't finished (name the open nodes) 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 --mode jsonl < ${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>/db/graph.json` path.
+- The resolved slug and the `feature.cypher` result verbatim (destination and the acceptance bar with
+  the nodes covering each criterion) — the auditor never opens the store itself, and reads the code from
+  the branch diff.
 - 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.