opencode-gbuild 0.4.0

package/skills/pr/SKILL.md

@@ -0,0 +1,100 @@
+---
+description: Pushes the current gbuild feature branch to the appropriate remote, opens a pull request with a concise description that classifies the change (new feature, fix, optimization, etc.) and notes any user-facing impact, then monitors CI checks in the background and auto-triggers a graph reopen + run if any fail. Use after /gbuild:review reports nothing blocking, to publish the finished feature branch.
+---
+
+Publish a finished feature branch: push it to the right remote, open a well-formed pull request, then watch the PR's CI checks and drive a graph reopen automatically when a check goes red — looping until the checks are green or a round cap is hit.
+
+## CRITICAL: main-context requirement
+
+This skill MUST run in the **main conversation context**. It MUST NOT be invoked as a forked subagent (e.g. via the Agent/Task tool). The auto-fix step runs `/gbuild:run`, which dispatches one Agent per node — and forked agents cannot nest, so a nested fork will fail. If you are already running inside a forked agent, stop immediately and report that `/gbuild:pr` must be run from the top-level conversation.
+
+## Step 0: Parse arguments
+
+`$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).
+- **max_rounds**: the value of `--max-rounds N` (also accept `--max-rounds=N`). Default `3` when absent.
+
+## Step 1: Preconditions
+
+Verify the environment before touching the remote. Stop with a clear, actionable message if any check fails:
+
+1. **Git repo.** This skill is git + GitHub specific. If the repo is not git, stop and explain that `/gbuild:pr` only supports git + GitHub (`gh`).
+2. **GitHub CLI.** Confirm `gh` is installed and authenticated (`gh auth status`). If not, stop and tell the user to install/authenticate `gh`.
+3. **Base branch.** Determine the upstream default branch: `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`. Call it `<base>`.
+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.
+
+## Step 2: Determine the remote & push
+
+Choose the push remote from the project's actual remotes:
+
+1. List remotes (`git remote -v`).
+2. **Exactly one remote** → use it.
+3. **Multiple remotes** → look for a push-target hint in `AGENTS.md` or `CLAUDE.md` (e.g. an explicit statement that the project pushes to a fork). If a clear hint exists, use it. Otherwise, use `AskUserQuestion` to let the user pick which remote to push to (e.g. `origin` vs a fork remote).
+
+Push the current branch and set upstream: `git push -u <remote> <branch>`.
+
+## Step 3: Open the pull request
+
+Build a **short, well-formed** description, then open the PR.
+
+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`).
+
+Derive a concise, conventional-commit-style title from the feature/branch and the changes (e.g. `feat(auth): add OAuth login`).
+
+Write the body to this template. Keep it tight — bullets, not essays. Classify what kind of change this is (new feature, fix, optimization, replacement, refactor, or other) and lead with that. Most changes are not user-facing — only include the **User-facing impact** and **Example usage** sections when something a user actually interacts with (API, CLI, config, UI, output) changed; omit them entirely otherwise. When you include them, the **Example usage** section goes right after **User-facing impact** and shows concrete sample input and the resulting output. Omit any section that has nothing:
+
+```
+## Summary
+<1–2 sentences: what changed & why, and the kind of change — new feature / fix / optimization / replacement / refactor / other>
+
+## Changes
+- <bullet per notable change — what it does, not a play-by-play>
+
+## User-facing impact
+<Only when the change is user-facing: what users will now see or do differently (inputs and/or outputs). Drop this whole section for internal-only changes.>
+
+## Example usage
+<Only when the change is user-facing, immediately after User-facing impact: concrete before/after — sample input and the resulting output. Use fenced code blocks. Drop this whole section for internal-only changes.>
+
+---
+This description was auto generated
+```
+
+The trailing `This description was auto generated` line is **mandatory** — it always ends the body, after every other section, and is never dropped or reworded.
+
+Create the PR: `gh pr create --base <base> --title "<title>" --body "<body>"`. Let `gh` resolve the head branch (it handles fork `owner:branch` head refs automatically). Capture the PR URL and number (`<pr>`).
+
+## Step 4: Monitor checks in the background → auto-fix loop
+
+Watch the PR's CI checks and react when they fail. Run for at most `max_rounds` rounds:
+
+1. **Launch the watch in the background.** Run `gh pr checks <pr> --watch --fail-fast` via the Bash tool with `run_in_background: true`. It exits `0` when all checks pass and non-zero when a check fails; the harness re-invokes this skill when the command exits, so continue from the result.
+2. **Checks green (exit 0):** report success and go to Step 5.
+3. **Checks red (non-zero exit):**
+   - Collect the failure detail: `gh pr checks <pr>` for the failed-check list, and `gh run view <run-id> --log-failed` for the failing logs.
+   - **If `<slug>` is unresolved** (the branch wasn't produced by gbuild, so there's no graph to reopen): do not auto-fix. Print which checks failed with their logs and suggest the user fix manually, then go to Step 5 with an `unresolved` status.
+   - **Otherwise, fix automatically** — via the graph, not by patching around it. gbuild has no separate fix skill; a red check is a new requirement:
+     1. Read `${CLAUDE_PLUGIN_ROOT}/skills/plan/SKILL.md` and execute its **Reopen** path inline: `--add "<requirement>"` where the requirement is the failing check stated as a concrete outcome (e.g. `CI check "lint" passes — <the actual error>`). Re-read that file and follow it verbatim rather than paraphrasing it here, so this phase auto-syncs when `plan` changes. One requirement per distinct failing check.
+     2. Run it unattended. `plan`'s Reopen asks nothing, but if executing it would prompt the user (an ambiguous decomposition), resolve it yourself from the failing logs and note the choice in the final report — `/gbuild:pr` runs without a human present.
+     3. If Reopen concludes the requirement needs no new nodes, stop the loop and go to Step 5 with an `unresolved` status — the failure isn't something the graph can act on, so surface the logs to the user.
+     4. Read `${CLAUDE_PLUGIN_ROOT}/skills/run/SKILL.md` and execute it inline against `<slug>` to run the newly-unblocked frontier. Suppress its trailing `next: /gbuild:status…` line — this skill owns the transition.
+   - After the run completes, push the new commits (`git push`) and **re-launch the watch** (next round).
+
+4. **Round cap reached while still red:** stop, print the still-failing checks and their logs, and tell the user to inspect manually. Go to Step 5 with an `unresolved` status.
+
+## Step 5: Final output
+
+Report the outcome:
+
+```
+PR: <url>  (checks: green | fixed after <rounds> round(s) | unresolved after <max_rounds> round(s))
+next: /gbuild:status <slug>
+```

package/skills/review/SKILL.md

@@ -0,0 +1,41 @@
+---
+description: Performs a strict end-of-feature maintainability audit of the current gbuild branch — abstraction quality, file size, spaghetti growth, cross-node duplication, missed code-judo simplifications. Runs the audit in the gbuild-auditor sub-agent and relays its result to chat. Use after /gbuild:run finishes a graph, before /gbuild:pr.
+---
+
+Run the strict end-of-feature maintainability audit in a dedicated sub-agent, then relay its result.
+
+This is not a second pass at what `gbuild-reviewer` already did. That agent grades one node against one
+contract; this one grades what the whole accumulated diff did to the codebase — the duplication and
+missed abstractions that only exist *between* nodes, which no per-node review can see.
+
+## 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.
+
+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.
+
+## Run the audit
+
+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.
+- 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.
+That message is a tool result — it is NOT shown to the user. So once it returns:
+
+**Relay the sub-agent's entire output to chat verbatim, preserving its closing line exactly.** Do not
+summarize, reorder, or rewrite it. The closing line is a contract:
+
+- `Run /gbuild:plan <slug> --add "the above blocking issues"` — `plan`'s Reopen path resolves
+  `the above blocking issues` as a back-reference to the relayed audit.
+- `Nothing blocking.` followed by `next: /gbuild:pr <slug>` — that exact `Nothing blocking.` text is
+  what any caller looping review→fix parses to end the loop.
+
+Both must appear verbatim in the chat output for the rest of the chain to work.

package/skills/run/SKILL.md

@@ -0,0 +1,99 @@
+---
+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.
+---
+
+Run `.gbuild/$ARGUMENTS/graph.json` (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.
+
+## 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:**
+
+```
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate_format.py .gbuild/<feature>/graph.json
+```
+
+If it prints `invalid: ...`, stop and report — do not attempt to run a graph `plan` didn't finish
+correctly. Then take the frontier:
+
+```
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<feature>/graph.json --status
+```
+
+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.
+
+## Step 1: Establish VCS facts
+
+Default to `git`. `git check-ignore -q .gbuild/` tells you whether to stage anything under it 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
+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.
+
+**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.
+
+## 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).
+
+## 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.
+
+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) →
+  `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.

package/skills/status/SKILL.md

@@ -0,0 +1,84 @@
+---
+description: Reports a gbuild feature's graph — frontier, blocked, in-flight, completed, each node's review verdict, and the cluster shapes with evidence of what actually ran concurrently. Use to check progress or diagnose a stuck run.
+---
+
+Report status for `$ARGUMENTS`.
+
+## Mode
+
+| arguments         | mode                                  |
+| ------------------ | -------------------------------------- |
+| empty              | every feature under `.gbuild/`         |
+| a feature slug     | that feature only                      |
+
+## Single feature
+
+### 1. Load
+
+`.gbuild/<feature>/graph.json` (a CypherLite GraphData file — GbuildNodes have a `slug` property and are
+linked by `DEPENDS_ON` relationships; feature-level acceptance is `Acceptance` nodes linked by
+`HAS_ACCEPTANCE`/`SATISFIES`) and every `.gbuild/<feature>/nodes/*.json` checkpoint (keyed by slug). This
+is a small, bounded read — status doesn't scale with graph size the way loading full node prose would.
+
+### 2. Compute
+
+```
+python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<feature>/graph.json --status
+```
+
+Gives `frontier` / `blocked` / `in_flight` / `completed` / `cancelled` / `failed` / `waves` (all as slug
+lists) directly — don't re-derive these by hand.
+
+### 3. Render the graph
+
+Draw the DAG with a marker per node status:
+
+```
+✓ completed   ◐ in_progress   ○ pending (frontier)   ● pending (blocked)   ✗ failed
+```
+
+Annotate blocked nodes with what they're waiting on: `● d-join-and-sum ← b-consume-doubled, c-consume-squared`.
+
+Group by wave (from `--waves`) so fan-out is visible in the layout, not just in the dependency list.
+
+### 4. Review verdicts
+
+For every `completed` node, one line: pass outright, or passed after N repair attempts, from its
+checkpoint's `review` field. For `failed` nodes, the last review's failed acceptance bullets verbatim —
+this is what a human needs to make the `escalate`/`stop` call.
+
+### 5. Concurrency evidence
+
+For each wave with more than one node, compare `started_at` timestamps across that wave's checkpoints.
+Report whether they actually overlapped (real concurrent dispatch) or ran sequentially 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).
+
+### 6. Next action
+
+One priority-ordered list: what `/gbuild:run <feature>` would do next (the current frontier), and
+anything needing a human decision first (`failed`/`escalate`d nodes, an empty frontier with incomplete
+nodes remaining).
+
+### 7. Invariant checks
+
+Numbered, only reporting violations (silence on an item means it passed, not that it was skipped):
+
+1. Every GbuildNode has non-empty `acceptance` (should already be caught by `validate_format.py`'s own
+   validation — report if a node manages to lack it anyway, since that means the file was hand-edited or
+   written by something other than `plan`).
+2. Every `Acceptance` node is `SATISFIES`-covered by at least one GbuildNode (enforced by
+   `validate_format.py` — report if one slips through anyway).
+3. `DEPENDS_ON` is acyclic (validated by `validate_format.py`/`graph.py` already; report if it somehow
+   wasn't checked).
+4. No `completed` node's checkpoint is missing a `review` field with `verdict: pass` — a node marked
+   complete without a passing review means `run` skipped the review step.
+5. Every `chore`-type GbuildNode is the target of at least one `DEPENDS_ON` edge.
+
+If all five are clear, say so in one line — don't let silence be ambiguous between "checked, clear" and
+"not checked."
+
+## All-features mode
+
+For each `.gbuild/<slug>/graph.json` found, one line: slug, node counts by status, and whether the
+frontier is empty (done or stuck) or has ready work. Point at `/gbuild:status <slug>` for detail.

package/templates/graph.json

@@ -0,0 +1,110 @@
+{
+  "nodes": [
+    {
+      "id": 1,
+      "labels": ["Feature"],
+      "properties": {
+        "feature": "example-diamond",
+        "destination": "A tiny worked example: A produces a shared value, B and C each consume it independently, D joins both.",
+        "context": "Ships with the plugin as the toy graph used in gbuild's own verification steps. Not a real feature.",
+        "out_of_scope": ["Anything beyond demonstrating fan-out and join scheduling."]
+      }
+    },
+    {
+      "id": 2,
+      "labels": ["Acceptance"],
+      "properties": { "id": "a-1", "text": "run dispatches B and C concurrently, not one after the other" }
+    },
+    {
+      "id": 3,
+      "labels": ["Acceptance"],
+      "properties": { "id": "a-2", "text": "D does not start until both B and C are checkpointed complete" }
+    },
+    {
+      "id": 4,
+      "labels": ["GbuildNode", "Chore"],
+      "properties": {
+        "slug": "a-produce-shared-value",
+        "title": "Produce the shared value B and C both need",
+        "type": "chore",
+        "contract": { "input": {}, "output": { "value": "<integer>" } },
+        "acceptance": ["writes a JSON object with a single integer field 'value' to its checkpoint output"],
+        "verify": null,
+        "failure_policy": "retry",
+        "model_tier": "cheap"
+      }
+    },
+    {
+      "id": 5,
+      "labels": ["GbuildNode", "Code"],
+      "properties": {
+        "slug": "b-consume-doubled",
+        "title": "Consume the shared value, produce its double",
+        "type": "code",
+        "contract": {
+          "input": { "value": "<integer, from a-produce-shared-value.output.value>" },
+          "output": { "doubled": "<integer>" }
+        },
+        "acceptance": ["output.doubled equals a's output.value multiplied by 2"],
+        "verify": null,
+        "failure_policy": "repair",
+        "model_tier": "cheap"
+      }
+    },
+    {
+      "id": 6,
+      "labels": ["GbuildNode", "Code"],
+      "properties": {
+        "slug": "c-consume-squared",
+        "title": "Consume the shared value, produce its square",
+        "type": "code",
+        "contract": {
+          "input": { "value": "<integer, from a-produce-shared-value.output.value>" },
+          "output": { "squared": "<integer>" }
+        },
+        "acceptance": ["output.squared equals a's output.value raised to the power of 2"],
+        "verify": null,
+        "failure_policy": "repair",
+        "model_tier": "cheap"
+      }
+    },
+    {
+      "id": 7,
+      "labels": ["GbuildNode", "Code"],
+      "properties": {
+        "slug": "d-join-and-sum",
+        "title": "Join B and C, produce their sum",
+        "type": "code",
+        "contract": {
+          "input": {
+            "doubled": "<integer, from b-consume-doubled.output.doubled>",
+            "squared": "<integer, from c-consume-squared.output.squared>"
+          },
+          "output": { "sum": "<integer>" }
+        },
+        "acceptance": [
+          "output.sum equals b's output.doubled plus c's output.squared",
+          "only runs after both b-consume-doubled and c-consume-squared are checkpointed completed"
+        ],
+        "verify": null,
+        "failure_policy": "repair",
+        "model_tier": "cheap"
+      }
+    }
+  ],
+  "relationships": [
+    { "id": 1, "type": "HAS_ACCEPTANCE", "start_node": 1, "end_node": 2, "properties": {} },
+    { "id": 2, "type": "HAS_ACCEPTANCE", "start_node": 1, "end_node": 3, "properties": {} },
+    { "id": 3, "type": "SATISFIES", "start_node": 5, "end_node": 2, "properties": {} },
+    { "id": 4, "type": "SATISFIES", "start_node": 6, "end_node": 2, "properties": {} },
+    { "id": 5, "type": "SATISFIES", "start_node": 7, "end_node": 3, "properties": {} },
+    { "id": 6, "type": "DEPENDS_ON", "start_node": 5, "end_node": 4, "properties": {} },
+    { "id": 7, "type": "DEPENDS_ON", "start_node": 6, "end_node": 4, "properties": {} },
+    { "id": 8, "type": "DEPENDS_ON", "start_node": 7, "end_node": 5, "properties": {} },
+    { "id": 9, "type": "DEPENDS_ON", "start_node": 7, "end_node": 6, "properties": {} }
+  ],
+  "indexes": [],
+  "constraints": [],
+  "next_node_id": 8,
+  "next_rel_id": 10
+}