opencode-gbuild 0.5.0 → 0.6.1

package/skills/run/SKILL.md

@@ -1,100 +1,146 @@
 ---
-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/db/graph.json` (the feature slug is `$ARGUMENTS`).
+Run the graph in `.gbuild/$ARGUMENTS/db` (the feature slug is `$ARGUMENTS`; `DB` below).
 
 **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.
 
-## Step 0: Load and query
+## Store rules
 
-Load `.gbuild/<feature>/db/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`; checkpoints live in the sibling `.gbuild/<feature>/nodes/`).
-**Confirm it's well-formed first:**
+- `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.
+- 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"]'`).
+- `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.
 
-```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/validate_format.py .gbuild/<feature>/db/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:
+## Step 0: Check and recover
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<feature>/db/graph.json --status
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/validate.cypher
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/attention.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.
+- `validate` printing anything → stop and report the rows; do not run a graph `plan` didn't finish
+  correctly.
+- `attention` rows with reason `in_progress` are left over from an interrupted run (this skill is the
+  only writer and records every node before finishing). Check `git log` for commits their agents already
+  made, then reset them all in one call so they re-dispatch, and mention it in the report:
 
-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.
+  ```
+  cypherlite DB --mode jsonl --param 'slugs=["<slug>", ...]' --param 'status="pending"' \
+    < ${CLAUDE_PLUGIN_ROOT}/cypher/set-status.cypher
+  ```
 
 ## 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
-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.
+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. 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 the results and record them from the main context (step 3.4).
 
 **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 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 3: One wave
+
+1. **CLAIM.**
+
+   ```
+   cypherlite 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 5.
+
+2. **IMPLEMENT.** 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 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
+     `{"started_at": "...", "completed_at": "...", "outputs": {...}}`;
+   - **not** run `cypherlite` or touch `.gbuild/`.
+
+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. Never let
+   the implementing agent review its own work.
+
+4. **RECORD** the whole wave in one call — one result per node, `verdict` from the reviewer's
+   `VERDICT:` line, `failed_criteria` from its `[fail]` lines:
+
+   ```
+   cypherlite 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
+   ```
+
+   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.
+
+5. **FAILURES.** For each row with `completed: false` (a failed review, 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, then record just those nodes. Bounded: 2 attempts.
+   - `fallback` → dispatch the named alternate approach the same way.
+   - `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 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, so true concurrent dispatch is safe by
+construction — only the store calls are 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>"`. Then claim again (step 3). Keep going until a claim
+returns no rows.
 
 ## 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.
+```
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/progress.cypher
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/attention.cypher
+```
+
+Every `progress` row with `open: []` → the graph is done. Otherwise `attention` names what's stuck
+(`failed` nodes with their last failed criteria, and what they block).
 
-Close with the next step:
+Report: which nodes ran this invocation, which passed review outright vs. needed a repair pass, 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) →
-  `next: /gbuild:status <feature>`.
+- **Graph fully done** → 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** (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: nodes an interrupted
+wave left `in_progress` are reset, 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

@@ -2,7 +2,16 @@
 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`.
+Report status for `$ARGUMENTS`. This skill only reads the store; `DB` below is `.gbuild/<feature>/db`.
+
+## 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 — never parallel tool calls on the same store.
+- 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`.
 
 ## Mode
 
@@ -13,73 +22,66 @@ Report status for `$ARGUMENTS`.
 
 ## Single feature
 
-### 1. Load
+This is the human-facing report, so it's the one place that reads every node.
 
-`.gbuild/<feature>/db/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; the
-`nodes/` dir is a sibling of the `db/` graph folder). This is a small, bounded read — status doesn't
-scale with graph size the way loading full node prose would.
-
-### 2. Compute
+### 1. Load
 
 ```
-python3 ${CLAUDE_PLUGIN_ROOT}/scripts/graph.py .gbuild/<feature>/db/graph.json --status
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/status.cypher
+cypherlite DB --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/validate.cypher
 ```
 
-Gives `frontier` / `blocked` / `in_flight` / `completed` / `cancelled` / `failed` / `waves` (all as slug
-lists) directly — don't re-derive these by hand.
+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.
 
-### 3. Render the graph
+### 2. Render the graph
 
-Draw the DAG with a marker per node status:
+Draw the DAG with a marker per node state:
 
 ```
-✓ completed   ◐ in_progress   ○ pending (frontier)   ● pending (blocked)   ✗ failed
+✓ completed   ◐ in_progress   ○ frontier   ● blocked   ✗ failed   – cancelled
 ```
 
-Annotate blocked nodes with what they're waiting on: `● d-join-and-sum ← b-consume-doubled, c-consume-squared`.
+Annotate blocked nodes with what they're waiting on (`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.
+Group by `wave` so fan-out is visible in the layout, not just in the dependency list.
 
-### 4. Review verdicts
+### 3. 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.
+For every `completed` node, one line: passed outright (`review_attempts: 1`), or passed after N repair
+attempts. For `failed` nodes, `last_failed_criteria` verbatim — this is what a human needs to make the
+`escalate`/`stop` call.
 
-### 5. Concurrency evidence
+### 4. 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).
+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).
 
-### 6. Next action
+### 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`/`escalate`d nodes, an empty frontier with incomplete
-nodes remaining).
+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).
 
-### 7. Invariant checks
+### 6. Invariant checks
 
-Numbered, only reporting violations (silence on an item means it passed, not that it was skipped):
+`validate.cypher` is the invariant check — it covers non-empty acceptance, acceptance coverage,
+acyclicity, completed nodes without a passing review or missing an output value, orphan chores, and the
+`FROM` cut test. Report every row it returned, numbered. If it returned nothing, say so in one line —
+don't let silence be ambiguous between "checked, clear" and "not checked."
 
-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.
+## All-features mode
 
-If all five are clear, say so in one line — don't let silence be ambiguous between "checked, clear" and
-"not checked."
+Don't read every node of every feature. For each `.gbuild/<slug>/db` found, one store at a time:
 
-## All-features mode
+```
+cypherlite .gbuild/<slug>/db --mode jsonl < ${CLAUDE_PLUGIN_ROOT}/cypher/progress.cypher
+```
 
-For each `.gbuild/<slug>/db/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.
+Print one line per feature: slug, node counts by state summed over its waves, and whether it's done
+(every `open` empty), has ready work (`frontier` > 0), or is stuck. Point at `/gbuild:status <slug>` for
+detail.

package/templates/example.cypher

@@ -0,0 +1,57 @@
+// A worked 4-node diamond: A produces a value, B and C each consume it
+// independently, D joins both. This is exactly the script plan writes for a
+// new feature — one atomic statement, piped into the store:
+//   cypherlite .gbuild/<slug>/db < plan.cypher
+// Variables (f, a1, a, a_value, ...) are only scoped to this one statement, so
+// the whole graph is created in a single CREATE chain.
+.begin
+CREATE (f:Feature {
+  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 tests. Not a real feature.",
+  out_of_scope: ['Anything beyond demonstrating fan-out and join scheduling.']
+})
+CREATE (a1:Acceptance {id: 'a-1', text: 'run dispatches B and C concurrently, not one after the other'})
+CREATE (a2:Acceptance {id: 'a-2', text: 'D does not start until both B and C are recorded completed'})
+CREATE (f)-[:HAS_ACCEPTANCE]->(a1), (f)-[:HAS_ACCEPTANCE]->(a2)
+
+CREATE (a:GbuildNode:Chore {
+  slug: 'a-produce-shared-value', title: 'Produce the shared value B and C both need', type: 'chore',
+  acceptance: ['output.value is a single integer'],
+  failure_policy: 'retry', model_tier: 'cheap', status: 'pending'
+})
+CREATE (a)-[:OUTPUT]->(a_value:Field {name: 'value', shape: '<integer>'})
+
+CREATE (b:GbuildNode:Code {
+  slug: 'b-consume-doubled', title: 'Consume the shared value, produce its double', type: 'code',
+  acceptance: ['output.doubled equals input.value multiplied by 2'],
+  failure_policy: 'repair', model_tier: 'cheap', status: 'pending'
+})
+CREATE (b)-[:DEPENDS_ON]->(a)
+CREATE (b)-[:INPUT]->(:Field {name: 'value', shape: '<integer>'})-[:FROM]->(a_value)
+CREATE (b)-[:OUTPUT]->(b_doubled:Field {name: 'doubled', shape: '<integer>'})
+CREATE (b)-[:SATISFIES]->(a1)
+
+CREATE (c:GbuildNode:Code {
+  slug: 'c-consume-squared', title: 'Consume the shared value, produce its square', type: 'code',
+  acceptance: ['output.squared equals input.value raised to the power of 2'],
+  failure_policy: 'repair', model_tier: 'cheap', status: 'pending'
+})
+CREATE (c)-[:DEPENDS_ON]->(a)
+CREATE (c)-[:INPUT]->(:Field {name: 'value', shape: '<integer>'})-[:FROM]->(a_value)
+CREATE (c)-[:OUTPUT]->(c_squared:Field {name: 'squared', shape: '<integer>'})
+CREATE (c)-[:SATISFIES]->(a1)
+
+CREATE (d:GbuildNode:Code {
+  slug: 'd-join-and-sum', title: 'Join B and C, produce their sum', type: 'code',
+  acceptance: ['output.sum equals input.doubled plus input.squared',
+               'only runs after both b-consume-doubled and c-consume-squared are recorded completed'],
+  failure_policy: 'repair', model_tier: 'cheap', status: 'pending'
+})
+CREATE (d)-[:DEPENDS_ON]->(b), (d)-[:DEPENDS_ON]->(c)
+CREATE (d)-[:INPUT]->(:Field {name: 'doubled', shape: '<integer>'})-[:FROM]->(b_doubled)
+CREATE (d)-[:INPUT]->(:Field {name: 'squared', shape: '<integer>'})-[:FROM]->(c_squared)
+CREATE (d)-[:OUTPUT]->(:Field {name: 'sum', shape: '<integer>'})
+CREATE (d)-[:SATISFIES]->(a2);
+.commit
+.checkpoint