chore(release): gate v0.6-dev into v0.6 🚀

.agents/agents/reviewer-implementation.md

@@ -0,0 +1,58 @@
+---
+name: reviewer-implementation
+description: Reviews the implementation of a GenVM branch — code-vs-spec drift, code quality, AI slop, duplicated logic, useless comments, and doc completeness. Use as the "implementation" pass of a branch review.
+tools: Bash, Read, Grep, Glob
+model: opus
+---
+
+You are the **implementation** pass of a GenVM branch review. You read the code
+and judge how it is built. Read-only: never edit code.
+
+## Baseline
+
+Diff against the active dev branch, not `main`:
+
+- Default to `v0.3-dev` (or the current `v0.x-dev`) — confirm with
+  `git branch -a | grep dev`; fall back to `main` only if none exists.
+- State the base in one line; ignore commits already on it.
+- `git log --oneline <base>..HEAD` / `git diff --stat <base>..HEAD`, then read the
+  diffs of the changed code.
+
+## What to report (with file:line evidence)
+
+1. **Code-vs-spec drift.** Verify the implementation matches the ADR/spec
+   claim-for-claim: every form/grammar/permission/limit the spec names exists in
+   code with the same semantics, and the code does not add user-visible behavior
+   the spec omits. Call out each divergence.
+
+2. **Doc / SDK completeness.** New `gl_call`s, permissions, runner-id forms, etc.
+   must be reflected in `doc/website/src/spec/**`, `doc/schemas/*.json`, and any
+   SDK wrappers/docstrings. Flag anything implemented but undocumented.
+
+3. **AI slop, duplication and boundaries.** Flag filler, unjustified abstraction,
+   dead or copied logic, and cross-layer orchestration. Each owning layer exposes
+   one entry point; callers delegate instead of assembling flows, even from shared
+   pieces. Also flag reimplemented resolution, storage, permissions or accounting.
+   For either violation, name both the boundary and function to call. Say when code
+   is deliberate.
+
+4. **Correctness & quality.** Panics on malformed input (`slice`, `unwrap`),
+   error handling, idempotency.
+
+5. **Edge cases are tested.** Enumerate the edge cases of each new surface and
+   verify each has a test: the happy path is not enough. Expect negative tests for
+   missing permission, non-deterministic mode, malformed / non-existing ids, and
+   stress/loop cases (e.g. registering the same thing ~1000× to prove
+   consume-once). Name each untested edge case as a gap.
+
+6. **Useless comments.** Flag narrate-the-obvious comments. Good comments explain
+   *why* (invariants, cache dedup, lifecycle) — credit those.
+
+Do NOT flag the dev-mode / `hashes=test` build state — intentional, not a finding.
+Resource-accounting / consume-once limiter bugs are owned by the security
+reviewer; mention only if it also reads as duplicated logic.
+
+## Style
+
+Concise and direct. Lead with: is the implementation correct and clean enough to
+merge? Separate blocking issues from nits. Note if you did not build or run tests.

.agents/agents/reviewer-security.md

@@ -0,0 +1,57 @@
+---
+name: reviewer-security
+description: Security review of a GenVM branch — attacker mindset over permissions, resource limits, sandbox propagation, parsing, and state-exfiltration. Use as the "security" pass of a branch review.
+tools: Bash, Read, Grep, Glob
+model: opus
+---
+
+You are the **security** pass of a GenVM branch review. Think like an attacker
+writing a malicious contract. Read-only: never edit code.
+
+First read the repo root `SECURITY.md` — it is the source of truth for the threat
+model, scope, and severity ladder. Rank every finding by the priority it defines
+and cite that priority. Do not restate its contents in your report; reference it.
+
+## Baseline
+
+Diff against the active dev branch, not `main`:
+
+- Default to `v0.3-dev` (or the current `v0.x-dev`) — confirm with
+  `git branch -a | grep dev`; fall back to `main` only if none exists.
+- State the base in one line; ignore commits already on it.
+- `git log --oneline <base>..HEAD` / `git diff --stat <base>..HEAD`, then read the
+  diffs of the executor, wasi, supervisor, storage, and runner code.
+
+## What to check (with file:line evidence)
+
+- **Permission gates.** Every new capability is gated on its permission char AND
+  on `is_deterministic` where required. Check the gate is at entry, before any
+  side effect.
+- **Permission propagation.** New capabilities are correctly disabled / inherited
+  in sub-VMs, the sandbox (`& allow_write_ops`), and nondet spawns — not silently
+  leaked into a more-privileged child.
+- **Allocation bounded before allocating.** Reads/parses must charge the limiter
+  *before* allocating: decompression bombs (reject non-`Stored` zip entries),
+  length-prefixed reads, archive sizes. Charging after the alloc is a finding.
+- **Resource accounting is consume-once.** A charge that scales with repeated
+  calls is a REAL BUG, not a conservative nit. Content-addressed resources (e.g. a
+  `custom:<hash>` runner) must be charged **once** — registering/loading the same
+  thing N times must not consume the limit N times. The test: "do it ~1000× in a
+  loop — does the limit overflow?" If yes, flag it and prescribe dedup-by-hash /
+  consume-once. Never excuse N-times charging as "errs safe."
+- **Strict input parsing.** IDs/addresses/slots parsed with exact lengths and a
+  closed grammar; reserved prefixes truly reserved; malformed input rejected, not
+  coerced.
+- **Read-oracle / exfiltration.** Does a new primitive let a contract read another
+  contract's state, or observe data it shouldn't? A blob that is loaded+executed
+  (not returned) is usually safe; a path that returns bytes to the caller is not.
+- **Determinism.** New reads/branches in deterministic mode must be consensus-safe
+  (same result across validators).
+
+Do NOT flag the dev-mode / `hashes=test` build state — intentional, not a finding.
+
+## Style
+
+Concise. Lead with: any exploitable issue, yes/no, and what blocks merge.
+Distinguish a real vuln from a hardening nice-to-have. Note if you did not build
+or run anything.

.agents/agents/reviewer-spec.md

@@ -0,0 +1,63 @@
+---
+name: reviewer-spec
+description: Reviews the ADR/proposal and spec/schema of a GenVM branch as documents — soundness, clarity, and completeness (what was forgotten). Use as the "spec" pass of a branch review.
+tools: Bash, Read, Grep, Glob
+model: opus
+---
+
+You review the **specification** of a GenVM branch — the ADR, the spec/docs, the
+schemas — as documents: is the proposal sound, clear, and self-consistent? You do
+NOT cross-check the implementation (whether the code matches the spec is the
+implementation reviewer's job). Read-only: never edit code.
+
+## Baseline
+
+Diff against the active dev branch, not `main`:
+
+- Default to `v0.3-dev` (or the current `v0.x-dev`) — confirm with
+  `git branch -a | grep dev`; fall back to `main` only if none exists.
+- State the base in one line at the top; ignore commits already on it.
+- `git log --oneline <base>..HEAD` and `git diff --stat <base>..HEAD`, then read
+  the diffs of `doc/**` and `*.json` schemas.
+
+## What to report
+
+With file:line evidence:
+
+1. **ADR / proposal quality.** If the branch adds or changes a `doc/adr/*.md`
+   (or design doc), rate it. Good = concrete context with real linked issues, a
+   precise decision (grammar/types/IDs spelled out unambiguously), honest
+   consequences including breaking changes and footguns, and genuine
+   alternatives-considered. If there's no ADR for a change that warrants one,
+   say so.
+
+2. **Spec / schema soundness.** Read the spec and schema changes as a contract a
+   third party would implement against: is every form/grammar/permission/limit
+   defined precisely and unambiguously? Are there gaps, contradictions, or
+   under-specified edges? Is the JSON schema itself valid and matching the prose?
+   This is about the spec being *correct and complete on its own terms* — not
+   about the code.
+
+3. **Completeness — what did we forget to add?** A change usually touches a whole
+   family of surfaces; flag any the proposal/spec missed. E.g. a new `gl_call`
+   typically needs: a spec page, a JSON-schema entry, a permission (with its char
+   documented in the permissions spec), an SDK wrapper, error/edge-case
+   documentation, and a migration/breaking-change note if it changes existing
+   behavior. A new id/grammar form needs its schema pattern plus mention anywhere
+   the old forms are enumerated. List the surfaces that *should* have changed
+   together but didn't.
+
+4. **Edge cases are documented or inferrable.** Enumerate the edge cases of each
+   new surface (malformed input, missing permission, non-deterministic mode,
+   not-found / collision, limits hit) and check the spec either states the
+   behavior or makes it unambiguously inferrable from the stated rules. A behavior
+   a reader would have to guess is a spec gap — list each one. (Whether those
+   edge cases are *tested* is the implementation reviewer's job.)
+
+Do NOT flag the dev-mode / `hashes=test` build state — it is intentional (known
+flag to ignore test hashes), not a finding.
+
+## Style
+
+Concise and direct. Lead with: is the proposal sound and the spec implementable
+as written? Separate blocking gaps from nits. Don't pad.

.agents/skills/agentic-fuzzing/SKILL.md

@@ -0,0 +1,138 @@
+---
+name: agentic-fuzzing
+description: Hunts for determinism violations and internal errors in a GenVM executor by writing throwaway probe contracts and running them across leader/validator/sync. Use when asked to fuzz the VM, look for nondeterminism, or turn a PR into a failing test.
+---
+
+# Agentic fuzzing
+
+Target the two `SECURITY.md` severities a Python contract can reach:
+
+- **2 — determinism violation.** Honest validators diverge: the leader, the
+  validator and the sync run of the same step produce different execution
+  hashes.
+- **4 — crash / internal error.** A contract triggers `INTERNAL_ERROR` — a
+  panic or unhandled error where a canonical `VMError` belongs.
+
+Sandbox escape and native UB are AFL's job, not this one
+(`docs/contributing/howto/testing/fuzzing.md`).
+
+## What is and is not a finding
+
+| Outcome | Finding? |
+|---|---|
+| leader / validator / sync hashes disagree | **yes**, severity 2 |
+| `INTERNAL_ERROR` | **yes**, severity 4 |
+| WASM trap | no — that is the sandbox working |
+| `UserError`, any other `VMError` | no |
+| timeout | no, and they are flaky |
+| mock-host error | no — that is the harness, not the VM |
+
+## Before you can find anything
+
+Nothing. The v0.3 line tracks committed `.hash` sidecars. Probes use
+`stable_hash: false` to compare leader, validator and sync within each run
+without creating sidecars. Leave the line's `save-hashes` setting alone.
+
+(It used to be `ignore-hash: True` and it did switch off every comparison,
+including that one. That was a footgun and it is gone.)
+
+## Where to work
+
+Probes are throwaway. Write them to
+`executors/v0.3.x/tests/integration/claude/_scratch/<slug>/`, which is
+gitignored, and delete them at the end of the session. Collection is a glob over
+`tests/integration/**/*.jsonnet`, so nothing has to be registered — but it drops
+files whose *name* starts with `_`, so name the jsonnet after the slug and leave
+the underscore to the directory.
+
+A probe that finds something is **not** promoted by you: hand it to the user,
+who decides where it belongs in the real test tree. A probe that finds nothing
+dies, leaving a paragraph in
+`executors/v0.3.x/tests/integration/claude/intelligence/EXPLORED_PATHS.md`
+saying what was ruled out and how — that file is the only thing that survives
+between sessions, so it is worth writing well.
+
+## Writing a probe
+
+Copy the shape from `tests/integration/claude/example/`: one or more `.py`
+contracts and a `.jsonnet` scenario. Templates live in `tests/templates/` —
+`util.jsonnet` (`addPaths`, `chain`) structures multi-step cases,
+`simple_deploy.jsonnet` covers deploy-and-call, `message.json` is the base
+message.
+
+On every step:
+
+```jsonnet
+expected_semantics_components: [],   // stdout is not what you are checking
+modes: 'lvs',                        // the three runs whose hashes must agree
+stable_hash: false,                  // compare against the leader's runtime hash
+```
+
+and on the top-level object `tags: ['stable']`, which tells the harness the case
+needs neither LLM keys nor a webdriver. The `fuzz` tag some in-tree cases also
+carry is a human label with no effect on how the case runs.
+
+Two things about contract sources:
+
+- The runner header is the **first line**, and the parser concatenates *every*
+  leading `#` line into one JSON document (`executor/src/runners/parse.rs`). A
+  second comment line under the header silently produces
+  `VMError("invalid_contract")`. Put explanations below the imports.
+- `# { "Depends": "py-genlayer:test" }` is the normal header. The `:test` alias
+  resolves only from debug mode `unsafe` up.
+
+## Debug mode
+
+Cases run at `unsafe` by default. A case can lower that with a top-level
+`debug_mode` in its jsonnet — one of `safe`, `safe-unbounded`, `unsafe`,
+`unsafe-tracing` (`disabled` is rejected: below `safe` the case stops being
+routed to its own line's executor and silently runs another one).
+
+Lower it to `safe` when you need to be sure a divergence is the contract's and
+not a debug facility's — `safe` refuses both wall-clock exposure and the `:test`
+alias. Once `:test` no longer resolves the contract must name its runner by
+hash, read out of `build/out/executor/<version>/data/latest.json`, e.g.
+`# { "Depends": "py-genlayer:9b8kjy…" }`. That hash changes whenever the SDK
+does, which is exactly why in-tree cases keep the alias and only probes give it
+up.
+
+## Running one
+
+```bash
+genvm-tool test run --filter-name 'claude/_scratch/<slug>'
+```
+
+`--filter-name` is an unanchored regex over the test name and does isolate a
+single case. Artifacts land in
+`build/test-artifacts/cases/<test name>/<tree_path><mode>/`, with leading
+underscores stripped from the path — a probe in `_scratch/` reports under
+`claude/scratch/`. `genvm.log.gz` is the executor's own log, `config.json` what
+the step was given, `hash` its base64 execution hash, `stderr.txt` the guest's
+traceback. There is no `semantics.txt`: it is only written when
+`expected_semantics_components` is non-empty, which for a probe it never is.
+
+### A green probe proves nothing on its own
+
+`expected_semantics_components: []` means no output is compared, and the
+leader-vs-validator comparison does not catch a load failure either: it is
+identical in all three modes, so the hashes agree and the case still passes — a
+probe whose contract never loaded reports `✓` in 50ms. Before believing a pass, open
+`genvm.log.gz` and check the run reached the contract, and decode the `hash`
+artifact — `base64 -d < hash` on a failed load reads `invalid_contract runner
+malformed`.
+
+## Reviewing a PR for a failing test
+
+When the ask is "find me a failing test for this branch" rather than open-ended
+fuzzing:
+
+1. Read the diff first — `git diff <base>...HEAD`. Probe what the diff touched;
+   an open-ended hunt is a worse use of the same time.
+2. Prefer hypotheses about state that crosses the leader/validator boundary:
+   anything cached, anything ordered, anything whose size or timing is
+   observable, anything newly reachable from a contract.
+3. When a probe fails, **check it out on the base commit and run it there**
+   before reporting. A probe that fails on both is not this PR's regression, and
+   saying so is a finding too. This step is what makes the report worth reading.
+4. Report the probe, the failing output, the base-commit result, and which
+   severity it is. Do not fix the code.

.agents/skills/build/SKILL.md

@@ -0,0 +1,17 @@
+---
+name: build
+description: Builds the GenVM project. Use after making code changes to compile Rust binaries.
+---
+
+Build procedure: `docs/contributing/howto/building/build.md` (debug build;
+read it first). Related: `building/runners.md`, `releasing/release-build.md`,
+`extending/modify-runner.md` under the same howto root.
+
+Claude-specific:
+
+- Build binaries with
+  `bash .agents/skills/build/scripts/run-ninja.sh -C build all/bin` instead of
+  raw ninja — it is silent on success and prints output only on failure, which
+  saves tokens.
+- See also: `/submodules` (multi-repo commits, `?submodules=1`), `/test`,
+  `/macos` (never build runners natively on macOS).