feat(skills): drive the right side of the V + check tool currency before filing gaps

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

@@ -1,6 +1,6 @@
 {
   "name": "pulseengine-claude",
-  "version": "0.17.0",
+  "version": "0.18.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/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.1.0"
+  version: "0.2.0"
 ---
 
 # PulseEngine feature loop
@@ -50,6 +50,32 @@ For each new property the feature claims:
 - Run `rivet validate` and `rivet check` — both must be green.
 - **Artifact:** new YAML in `requirements/`, `decisions/`, `tests/`. `rivet coverage` should show the trace topology now covering the new property.
 
+**Close the right side of the V when the test lands — don't defer it.** The
+left side grows fast because authoring it is natural; the right side gets
+skipped silently, every feature, until the debt is measured in the hundreds
+(one repo: **257 of 269 sw-reqs with no verification**; another: 20 artifacts
+and *one* `verifies` link). The cheap path is a **source marker**, not a
+hand-authored YAML artifact per test:
+
+```rust
+// rivet: verifies REQ-001          // also: #[rivet::verifies("REQ-001")]
+#[test]                             // Python: # rivet: verifies REQ-001
+fn add_does_not_overflow() { ... }  //         @rivet_verifies("REQ-001")
+```
+
+Then, the moment the oracle is green:
+
+```sh
+rivet coverage --tests    # marker → requirement map; the burn-down list
+rivet verify REQ-001      # advances implemented → verified, opt-in and auditable
+```
+
+`rivet verify` **refuses without evidence** — *"no verifying evidence. Add an
+incoming `verifies` link … or a `// rivet: verifies REQ-001` marker"* — so this
+is a mechanical check, not a prose step. Use `partially-verifies` when the test
+discharges only part of the requirement. If the loaded schema has no
+verification type at all, that is the finding: see [`traceability-audit`] step 0.
+
 ### 4. Write the code, oracle-gated per change
 
 Per [`oracle-gate-a-change`]:

claude-tooling/plugins/pulseengine-claude/skills/report-tool-friction/SKILL.md

@@ -3,7 +3,7 @@ name: report-tool-friction
 description: This skill should be used whenever a PulseEngine tool (rivet, spar, witness, sigil, meld, loom, synth, kiln, gale, scry, smithy, thrum, temper, mcp — the roster lives in the pulseengine-toolchain memory) produces friction during real work — it errors, crashes, produces wrong or surprising output, is missing a capability you needed, has confusing/undocumented behavior, or forced you into a workaround. ALWAYS use this skill the moment you notice yourself working *around* a tool instead of *with* it, or saying "this should just work but doesn't." The friction is the signal; capturing it as an issue in the tool's own repo is the action. Fires inside [`pulseengine-feature-loop`] and [`release-execution`] and any standalone tool use.
 metadata:
   author: pulseengine.eu
-  version: "0.1.0"
+  version: "0.2.0"
 ---
 
 # Report tool friction
@@ -30,6 +30,32 @@ File in the **tool's own repo** (`pulseengine/<tool>`), not in the consuming pro
 ### 2. Search for a duplicate first
 `gh issue list --repo pulseengine/<tool> --search "<key phrase>" --state all`. If an open issue already covers it, add a comment with your fresh repro instead of opening a new one. Label-search for the friction label too.
 
+### 2b. Check you are not reporting a gap that is already fixed
+
+**A missing *capability* is the one friction class that expires.** Before filing
+"tool X cannot do Y", confirm you are on a current version — record both numbers
+in the issue:
+
+```sh
+<tool> --version
+gh release list -R pulseengine/<tool> --limit 1
+```
+
+Embedded schemas and rule sets ship *inside* the binary, so a stale install
+reports a stale capability. Three measured instances of this exact waste:
+
+- a "the schema has no verification type" issue filed **13 days after** that type
+  shipped — the reporter's binary was one release behind, and the fix had
+  already landed;
+- an agent session pinned to the **oldest** installed plugin version, silently
+  hiding eight skills, so their absence looked like a capability gap;
+- a machine running rivet **0.28.0 against a v0.32.0 release** — four minor
+  versions of shipped fixes invisible to everything running there.
+
+A bug or a crash is worth filing immediately regardless. A *missing feature* is
+worth thirty seconds of version-checking first, because the cost of getting it
+wrong is a maintainer re-deriving a fix they already shipped.
+
 ### 3. File it automatically, then mention it
 Open the issue without pausing the work, then note it in your response to the user (link + one line). Don't batch, don't wait for permission — friction is cheap to capture and expensive to forget. The body, kept short: