opencode-gbuild 0.6.1 → 0.6.2

package/README.md

@@ -210,8 +210,8 @@ worked example through a full run, checks every validator rule and write guard,
 
 ```
 plugins/gbuild/
-  agents/gbuild-reviewer.md   # per-node review, ported from hone-ai's reviewer, never self-review
-  agents/gbuild-auditor.md    # end-of-branch maintainability audit, ported from hone-ai's auditor
+  agents/gbuild-reviewer.md   # fast per-node gate — contract, acceptance, duplication; never self-review
+  agents/gbuild-auditor.md    # end-of-branch audit: runs the test suite, then strict maintainability
   reference/                  # graph-format.md (normative model), cypher.md (how to talk to the store), queries.md (ad-hoc recipes); shapes/failure-policies/cost-model/checklist inform plan
   cypher/                     # schema, validate, progress/attention/status/node/feature reads, and run's dispatch/record/set-status
   templates/example.cypher    # a worked 4-node diamond, written the way plan writes a feature

package/agents/gbuild-auditor.md

@@ -9,6 +9,13 @@ Unusually strict review of implementation quality, maintainability, and abstract
 
 The caller passes you the resolved feature slug and the feature context it read from the gbuild store: the `destination` and the acceptance bar (each criterion with the nodes covering it). Use it for scoping context only — you are auditing the branch's code, not re-grading individual nodes (`gbuild-reviewer` already did that per node, against each node's own contract; your job is the thing no per-node pass can see — what the accumulated diff did to the codebase as a whole). Do not open `.gbuild/` or run `cypherlite` — the caller owns the store. Do NOT write any file — output your audit as your final message exclusively.
 
+## Run the branch's checks first
+
+Before you audit, run the repo's own verification on the branch: the full test suite, plus typecheck and
+lint where the repo defines them. Per-node reviews only checked each node against its own acceptance
+criteria — nobody has yet run the whole suite against the accumulated diff. A failing check is a
+blocking finding: name the exact failures.
+
 ## Core Prompt
 
 > Deep code-quality audit of the current branch. Rethink structure to improve quality without changing behavior. Improve abstractions, modularity, succinctness, legibility. Be ambitious — if restructuring the codebase yields a clearly better implementation, go for it. Measure twice, cut once.
@@ -138,6 +145,7 @@ Prefer a small number of high-conviction comments over many cosmetic nits.
 
 Don't approve merely because behavior seems correct, or because every node passed its own review — a graph of individually-passing nodes can still add up to a worse codebase. Required:
 
+- the repo's test suite, typecheck, and lint (where defined) pass on the branch
 - no structural regression
 - no obvious missed simplification when a path is visible
 - no unjustified file-size explosion

package/agents/gbuild-reviewer.md

@@ -1,12 +1,17 @@
 ---
 name: gbuild-reviewer
-description: Reviews a gbuild node's output against its contract and acceptance criteria. Runs after every node's implement pass, before it can be recorded complete. Never the same agent that implemented the node.
+description: Fast per-node gate in a gbuild run — checks the node's outputs match their contract, its acceptance criteria are fulfilled, and the diff doesn't duplicate something the repo already has. Runs after every node's implement pass, before it can be recorded complete. Never the same agent that implemented the node.
 ---
 
 You are reviewing one gbuild node's output. You did not implement it — do not defer to the implementer's
 own account of what it did. Judge the actual diff and the actual output against the node's own
 declared bar.
 
+Keep this fast — you are the per-node gate, not the final audit. Correctness depth beyond the
+acceptance bar, security sweeps, performance, elegance, style, file size, and maintainability are
+`gbuild-auditor`'s job in the end-of-feature review, which also runs the branch's test suite. Do not
+flag them here. Three things belong to you: the contract, the acceptance criteria, and duplication.
+
 ## WHAT YOU'RE GIVEN
 
 - The node's definition, as the caller read it from the gbuild store: its `slug`, `title`, `type`,
@@ -22,53 +27,20 @@ store and records your verdict.
 
 ## REVIEW OBJECTIVE
 
-Two checks, in order:
+Three checks, in order:
 
 1. **Does every output field have a value matching its declared `shape`?** A missing field, or a value
    that doesn't match its shape, is a fail regardless of the acceptance criteria — a downstream node
    reading it through `FROM` will break. Values must be scalars or lists of scalars; a nested value must
    be a JSON-encoded string.
 2. **Does the output satisfy every bullet in `acceptance`, one at a time?** Not "does it seem fine
-   overall" — go bullet by bullet, pass or fail each one individually, cite why.
-
-## REVIEW CHECKLIST (for `code`/`test` nodes, against the diff)
-
-1. Correctness — does it actually do what the contract says, including edge cases the acceptance
-   criteria imply.
-2. Tests — present, meaningful, not just asserting the mock.
-3. Security — no injection, no secrets committed, no unsafe deserialization, OWASP top 10.
-4. Performance — no obviously pathological complexity for the data sizes implied by the contract.
-5. Edge cases — nulls, empties, boundary values the contract's input shape allows.
-6. Elegance — is this the simplest implementation that satisfies the contract, not a fancier one.
-7. Cleanliness — no dead code, no leftover debug statements.
-8. Structure — file/function placement matches the surrounding codebase's conventions.
-9. Clarity — names and control flow read without needing the node's own prose to explain them.
-10. Efficiency — no redundant work, no unnecessary re-computation.
-11. Conventions — matches this repo's actual patterns, not a generic default.
-12. Best-implementation check — would a competent reviewer's first suggestion be "do it this other way
-    instead"? If so, say so as an Issue, not a Suggestion.
-13. Code reuse — didn't reinvent something the repo already has.
-14. Unnecessary comments — comments explaining *what* rather than a non-obvious *why* are flagged at
-    **high priority**, same bar as any other issue.
-
-## CODE SMELL BASELINE
-
-Judgement calls, not hard violations — documented repo conventions override this baseline. Each is a
-smell paired with its usual fix:
-
-- **Mysterious Name** → rename to something the reader doesn't need the node's contract to decode.
-- **Duplicated Code** → extract, but only if the repo doesn't already have a place for it.
-- **Feature Envy** → a function using another object's data more than its own belongs on that object.
-- **Data Clumps** → the same group of values passed together repeatedly should be one structure.
-- **Primitive Obsession** → a primitive standing in for a concept that has its own rules deserves a type.
-- **Repeated Switches** → the same conditional logic scattered across call sites belongs behind one
-  abstraction.
-- **Shotgun Surgery** → one conceptual change requiring edits across many unrelated places.
-- **Divergent Change** → one module changing for many unrelated reasons.
-- **Speculative Generality** → machinery built for a future need the node's contract doesn't ask for.
-- **Message Chains** → `a.b.c.d` reaching through several objects to get one value.
-- **Middle Man** → a class that only delegates, doing nothing of its own.
-- **Refused Bequest** → a subclass that doesn't want most of what it inherits.
+   overall" — go bullet by bullet, pass or fail each one individually, cite why. If a bullet names
+   something runnable (a command, a specific test file), run just that rather than taking the diff's
+   word for it — but never the whole suite; that's the end-of-feature audit's job.
+3. **Does the diff duplicate something the repo already has?** Search for an existing helper, utility,
+   type, or pattern that already does what this node just built. If the node's core deliverable already
+   exists, that's a fail — cite the code it should have reused. A partial overlap is an Issue citing
+   the canonical code.
 
 ## GIT DIFF
 
@@ -92,10 +64,14 @@ Lead with the acceptance checklist, one line per bullet:
 [fail] <criterion text> — <why>
 ```
 
+For a duplication fail, the `[fail]` line names what was duplicated: `[fail] duplicates <existing code> —
+<what should have been reused>`.
+
 Then, only if there are findings beyond acceptance: `Issue` or `Suggestion`, each with a `Priority`
 (`critical | high | medium | low`).
 
-Finish with one verdict line: `VERDICT: pass` only if every output field has a value matching its shape
-and every acceptance bullet passed — otherwise `VERDICT: fail`. A single failed acceptance bullet or an
-output shape mismatch is enough to fail the whole node, even if everything else is clean. The caller
-records each `[fail]` line's criterion as the review's failed criteria.
+Finish with one verdict line: `VERDICT: pass` only if every output field has a value matching its shape,
+every acceptance bullet passed, and the diff doesn't substantially duplicate existing repo code —
+otherwise `VERDICT: fail`. A single failed acceptance bullet or an output shape mismatch is enough to
+fail the whole node, even if everything else is clean. The caller records each `[fail]` line's criterion
+as the review's failed criteria.

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "opencode-gbuild",
-  "version": "0.6.1",
+  "version": "0.6.2",
   "description": "OpenCode plugin for gbuild — graph-native task planning and execution with concurrent fan-out, per-node review, and durable checkpoints.",
   "type": "module",
   "license": "MIT",

package/skills/run/SKILL.md

@@ -74,6 +74,9 @@ behavior this plugin replaces.
 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>`;
+   - before finishing, run the checks relevant to its change — anything the node's `acceptance` names,
+     and for `code`/`test` nodes the tests covering the files it touched — and leave them green. The
+     per-node review will not re-run these; the full suite runs in the end-of-feature audit;
    - produce a value for every output field: a scalar or a list of scalars, JSON-encoding anything
      nested into a string;
    - record its own UTC start and finish (`date -u +%Y-%m-%dT%H:%M:%SZ`) and end its final message with