skills: integrate varve + red-first oracle rule (plugin 0.20.0)

claude-tooling/plugins/pulseengine-claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "pulseengine-claude",
-  "version": "0.19.0",
+  "version": "0.20.0",
   "description": "PulseEngine methodology as installable Claude Code tooling \u2014 philosophy + toolchain + repo-taxonomy + model-operating-contract memory, memory-persistence hooks (situational awareness at session start, working-context checkpoints across sessions/compaction), plus sixteen procedural skills (clean-room verification, release execution with a V-model traceability gate, oracle-gating, the full feature loop, the standardized release-artifact pipeline, tool-friction reporting, session-learning capture, STPA/STPA-Sec hazard-analysis audit, backend-agnostic proof synthesis, full bidirectional traceability audit across the V, greenfield verification bootstrap, release planning with an issue-driven delivery loop, an incremental issue-hunt loop, a quiesce-gated post-release repo-hygiene sweep, and a gate-potency audit that proves standing CI checks can still fail).",
   "author": {
     "name": "PulseEngine",

claude-tooling/plugins/pulseengine-claude/memory/pulseengine-toolchain.md

@@ -41,6 +41,15 @@ Map of the PulseEngine tools. Each lives in `/Users/r/git/pulseengine/<name>` on
 
 **mcp** — Rust framework for building Model Context Protocol servers and clients (the MCP layer rivet/spar expose). Published to crates.io.
 
+**ordeal** — certificate-checked QF_BV SMT. Ships inside the varve layer; a decision procedure whose results carry a checkable certificate rather than being trusted on the solver's word.
+
+**varve** — toolchain **layer manager**, and the reason "which toolchain produced this artifact?" is answerable. Distributes the whole tool set as one signed, dated, digest-pinned OCI layer (`YYYY.MM.P`) on `ghcr.io/pulseengine/varve/layers`; per-project `varve.toml` pin discovered by walking up from cwd; offline verification against a trust root; anti-rollback counters; content-addressed core so layers coexist and switching is `cd`; PATH shims; `self-update` (old-verifies-new); `deposit` / `export-bazel` for CI. Sits **outside** the layer it installs — it must exist before any layer does. Native Rust CLI, so witness MC/DC and scry are N/A to varve itself (they target the Wasm the layers carry).
+
+Two properties of varve are load-bearing for the other skills, both verified by execution (2026-08-08, v0.13.0):
+
+- **No silent fallback.** Outside a pinned project a shim *refuses* — `error: no varve.toml found …`, exit 1 — rather than running whatever is on PATH. Inside one it dispatches and exits 0.
+- **Realms beat the ambient environment.** When the pin names a `realm`, a committed `varve-realms.toml` supplies the registry *and* the trust root, and a hostile `VARVE_TRUST_ROOT` cannot substitute a different root. Negative control: the same bogus root makes `varve verify` exit 1 with no realm, and is ignored with one. Prefer the realm path — it needs no environment variable and is the stronger of the two.
+
 ## How they compose
 
 The procedure for composing these tools end-to-end (spar → WIT → rivet → code → witness → sigil → smithy) lives in the **`pulseengine-feature-loop` skill** shipped with this plugin, not here. This memory is the directory; the skill is the recipe.

claude-tooling/plugins/pulseengine-claude/skills/clean-room-verification/SKILL.md

@@ -3,7 +3,7 @@ name: clean-room-verification
 description: This skill should be used whenever findings, audits, code-review results, claims, or analysis output need to be validated before reporting — including "verify this", "double-check this", "audit", "is this actually true", "before I report this", "before we merge this", or whenever an agent's summary needs independent confirmation. ALWAYS use this skill before delivering non-trivial inspection results, before claiming a property holds, and whenever agent-produced hashes, digests, versions, file paths, or flag names appear in a report.
 metadata:
   author: pulseengine.eu
-  version: "0.1.0"
+  version: "0.2.0"
 ---
 
 # Clean-room verification
@@ -44,11 +44,24 @@ This is the smithy ritual in PulseEngine vocabulary. The point is to catch hallu
 - **An agent's summary describes intent, not what landed.** Check the diff. Check the file. Check the symbol. Check the digest.
 - **"It passed CI" is a statement about the gate's coverage that day, not a timeless guarantee.** Re-verify on the current artifact, not on the historical green check.
 - **Evidence-backed "blocked" beats forced "done."** If verification surfaces a real blocker, report the blocker — that's the honest path the user explicitly prefers.
+- **In a solo-agent-authored repo, this stops being on-demand and becomes a release gate.** Automation
+  can close almost every gap in such a repo except one: **the authoring agent assigning itself
+  `verified` status.** No mutation score, coverage number or green board closes that — it is a
+  structural independence gap, and it is the finding that repeated audits keep returning. The
+  standing expectation: a release's scope gets a fresh-context reviewer who re-derives every claimed
+  verdict from evidence (runs the named tests, re-checks the oracles, attempts to refute), with
+  **reviewer identity, date and outcome recorded on the artifacts** — and the release gate refuses a
+  scope whose independent review is absent or dissenting. Canonical statement: varve's
+  `REQ-INDEP-001`, *"No requirement is verified on the author's word alone"* (approved, v0.14.0).
+  This is the strongest independence achievable without a second human; treat it as the default for
+  any repo where one agent both writes and blesses the work.
 
 ## Anti-patterns
 
 - Skipping verification because "the agent ran successfully." The agent's exit code is not evidence the claim is true.
 - Re-using the verifier's *own* prior context to verify its findings. The whole point is clean-room.
+- **Marking a requirement `verified` on the strength of having implemented it.** Authorship and
+  verification collapsing into one agent is the gap; a stronger mutation score does not fill it.
 - Burying the verifier's verdict in a footnote. Lead with what was independently confirmed; the rest is suspected.
 - Verifying with a soft oracle (asking an LLM to read the spec back). See [`oracle-gate-a-change`] — mechanical oracle preferred.
 

claude-tooling/plugins/pulseengine-claude/skills/gate-potency/SKILL.md

@@ -3,7 +3,7 @@ name: gate-potency
 description: This skill should be used to audit whether a repo's EXISTING required CI checks can still fail — the vacuous-gate class, where a check runs, reports green, and cannot go red. Use it when the user says "audit our gates", "can our CI actually fail", "is this check real", "why did that slip through a green board", when inheriting or taking over a repo, at the campaign self-verify interval, and before a release whose evidence rests on CI being green. Presence is not potency — a non-empty required-checks list proves a gate exists, never that it bites. The method is negative control (inject a violation, confirm red) plus six mechanical audits for the ways a gate goes inert. Composes with oracle-gate-a-change (which covers wiring an oracle you are authoring), release-execution (fire before tagging) and repo-hygiene (same cadence).
 metadata:
   author: pulseengine.eu
-  version: "0.1.0"
+  version: "0.2.0"
 ---
 
 # Gate potency — can this check still go red?
@@ -43,6 +43,24 @@ mutant, a broken trace link, a `sorry` without the exemption, a deleted assertio
 afterwards. Everything below is a cheap proxy; this is the actual evidence. Do it on a scratch
 branch and record the run URL — that link *is* the potency evidence.
 
+**Worked example — a supply-chain check, audited in minutes.** To establish that varve's digest
+verification actually bites rather than merely existing, append one byte to a tool inside the
+content-addressed core and re-run `varve verify`:
+
+```
+error: tool 'rivet' does not match its signed digest sha256:53af23a… — the binary was altered
+```
+
+Restore, and it is green again. That is potency evidence; *reading* the verification code is not.
+
+**Pair the negative control with a positive one.** A control that goes red proves something fired —
+not that the *mechanism you think* fired. Show it biting in one configuration and correctly inert in
+another. Same audit: pointing `VARVE_TRUST_ROOT` at a bogus key makes `varve verify` exit 1 when the
+pin names no realm, and is *ignored* (exit 0) when it names one — which is exactly the claim that a
+realm's trust root cannot be substituted by the ambient environment. Either result alone proves
+little; the pair isolates the mechanism. Without the red case the test may be vacuous; without the
+green case you have not shown the red came from the property rather than the environment.
+
 ### 2. Reads what it writes
 Assert the gate parses a path the tool actually produces. Compare the parsed path against the real
 output/artifact layout, not against the docs. Version bumps silently relocate results files.

claude-tooling/plugins/pulseengine-claude/skills/oracle-gate-a-change/SKILL.md

@@ -3,7 +3,7 @@ name: oracle-gate-a-change
 description: This skill should be used whenever proposing, designing, landing, or evaluating a consequential change on a PulseEngine project (rivet, spar, witness, sigil, meld, loom, synth, wohl) — including "propose a change", "add a feature", "fix a bug", "is this safe to land", "what verifies this", "what's the gate", "how do we know this is correct", "before merging this", or whenever a code change needs a mechanical check to back it. ALWAYS use this skill before claiming a property holds and before recommending a change be merged.
 metadata:
   author: pulseengine.eu
-  version: "0.3.0"
+  version: "0.4.0"
 ---
 
 # Oracle-gate a change
@@ -55,6 +55,34 @@ This is the one step where doing it wrong feels identical to doing it right: you
 
 Field cases this rule comes from: an oracle behind two headline size claims existed for two releases and was never CI-wired; the next release shipped its central differential oracle referenced by nothing, with a fully green PR board; a later audit found ~70 of ~150 repro scripts undeclared or unwired.
 
+### 2c. Confirm the oracle is RED — before implementing
+
+Writing the oracle and wiring it still leaves the question the whole method rests on unanswered:
+**does it fail when the property is false?** Run it *before* the implementing change and read the
+result. **An oracle that passes before the change is not an oracle** — it is measuring something
+other than the property, and it will ship as evidence.
+
+The two commonest causes, both of which look correct in review:
+
+- **The predicate is satisfied by the initial or default state.** Zero-initialised values, empty
+  collections, absent files, a fresh entry point. The assertion is true before the feature exists.
+  Fix by making it position- or state-specific, not merely existential.
+- **It is an upper bound where a presence check was needed.** Field case, in this plugin's own gate:
+  `claim-check`'s `count-max` fails only when `n > max`, so a pattern matching **0** times stays
+  green — the code's own comment now reads *"greens a 0-match, since 0 > max is false"*. A claim
+  binding a doc's version string to `count-max` therefore went green precisely when the version
+  drifted and the string vanished. The `count-min` predicate exists to catch that drift-to-absent
+  case; pick the polarity that matches what you are asserting.
+
+**A fixture chosen after the property is written is suspect.** If you picked the input *because* the
+test passed, you may have selected around the failing case. Ask what the property claims in general
+and whether your fixture is the easy instance.
+
+This applies to **gates as much as tests**. A CI check whose predicate can silently match nothing is
+the same failure with a longer blast radius, because a green check is read as evidence by everyone
+downstream. Step 2b proves the gate *runs*; this step proves it can *fail*. Both are required —
+see [`gate-potency`] for auditing checks that are already live.
+
 ### 3. Attach a kill-criterion to the claim
 
 Per PulseEngine methodology, every claim should carry a falsifiable kill-criterion: "this claim would be wrong if X is observed." This is required for the philosophy to compose — without kill-criteria the falsification stance is empty.
@@ -120,6 +148,9 @@ inert. Each of these has cost real time in this org:
   demonstrably able to fail there**.
 - **Asserting a gate is non-vacuous by *reading* it rather than by *mutating* it.** Vacuous gates
   look correct in review — that is exactly why they survive. Break the property and watch for red.
+- **Running the oracle for the first time *after* the implementation.** A green result then is
+  ambiguous — it cannot distinguish "the change works" from "this never measured anything." The
+  red observation is not a formality; it is the only evidence the oracle discriminates at all.
 - "Review looks good" as the gate. Review is input; oracle is the gate.
 - "Tests pass" without saying *which* test exercises the new property. If you can't name it, it doesn't exist.
 - Skipping the oracle write because "we already have lots of tests." The relevant question is whether *this property* is checked, not whether *anything* is.

claude-tooling/plugins/pulseengine-claude/skills/pulseengine-feature-loop/SKILL.md

@@ -3,7 +3,7 @@ name: pulseengine-feature-loop
 description: This skill should be used when doing a feature end-to-end on a PulseEngine project (rivet, spar, witness, sigil, meld, loom, synth, wohl, kiln) — including "implement a feature", "add a new requirement", "extend the architecture", "write a new pass", "ship a feature end-to-end", "do this properly with traceability", "model-driven implementation", or any feature work that should pass through the full AADL → WIT → typed traceability → oracle-gated code → MC/DC → attestation → verify loop. ALWAYS use this skill when the user authorizes feature work on a PulseEngine project and the work touches more than a single file.
 metadata:
   author: pulseengine.eu
-  version: "0.2.0"
+  version: "0.3.0"
 ---
 
 # PulseEngine feature loop
@@ -22,6 +22,57 @@ This is a long-running explorer (see [`pulseengine-operating-contract`]): self-v
 
 ## The compose loop (ordered steps, each producing a concrete artifact)
 
+### 0. Resolve the loop's tools through varve — pin before you build
+
+Every step below invokes a tool, and by default gets *whatever is on PATH*. That is the
+mixed-toolchain hazard: half the pipeline running on one tool version and half on another, producing
+an artifact no single toolchain ever built. Pinning a **varve** layer closes it by construction and
+makes the outputs traceable to an exact toolchain.
+
+Two committed files — the realm supplies the registry and the trust root, so **no environment
+variable is needed**:
+
+```toml
+# varve-realms.toml — the trust universe; travels with the code
+[realm.pulseengine]
+registry   = "oci://ghcr.io/pulseengine/varve/layers"
+trust-root = "4e771dc62a08be89e3450f8cd807da58ff70af4a4e124ebf2d2b71684cfd9973"
+```
+
+```toml
+# varve.toml — this project's pin
+manifest-version = 1
+
+[toolchain]
+realm   = "pulseengine"
+channel = "rolling"
+layer   = "2026.08.2"
+```
+
+```sh
+varve install          # fetch + verify + lay down the layer
+varve shim install     # shims on PATH; switching projects is `cd`
+varve which rivet      # which binary runs here — and which layer it came from
+```
+
+- **State the layer when you report results.** `varve which <tool>` prints the layer and manifest
+  digest; that identity is what makes "which toolchain produced this?" answerable later. A result
+  reported without it is not reproducible evidence.
+- **A refusal is the feature.** Outside a pinned project a shim exits 1 rather than falling back to
+  an ambient binary. Do not "fix" that by bypassing varve — fix the pin.
+- **Prefer the realm over `VARVE_TRUST_ROOT`.** The realm is authoritative and cannot be overridden
+  by the ambient environment; the env var can. See the roster entry in
+  [`pulseengine-toolchain`] for the negative control establishing this.
+- If a repo has no pin yet, say so plainly rather than implying the loop ran pinned. Adding
+  `varve.toml` is a reviewable change like any other — and per **varve**'s design, the *only* way a
+  project ever changes layers.
+
+**Artifact:** a committed pin, and a layer identity attached to whatever the loop produces.
+
+> The trust-root value above is the **rolling** channel's provisional root, copied here because
+> varve does not yet publish a canonical `varve-realms.toml` (pulseengine/varve#34). When it does,
+> reference that file instead of pasting the key.
+
 ### 1. Start in spar — model the architecture
 
 If the feature changes architecture (new component, new mode, new interaction, new resource sharing):