@webpresso/plugin-claude 0.0.4 → 0.0.6

package/.claude-plugin/marketplace.json

@@ -6,7 +6,7 @@
   },
   "metadata": {
     "description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
-    "version": "0.0.4"
+    "version": "0.0.6"
   },
   "plugins": [
     {
@@ -17,5 +17,5 @@
       "keywords": ["agent", "blueprint", "claude-code", "skills", "mcp"]
     }
   ],
-  "version": "0.0.4"
+  "version": "0.0.6"
 }

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-kit",
-  "version": "0.0.4",
+  "version": "0.0.6",
   "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
   "author": {
     "name": "Webpresso",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@webpresso/plugin-claude",
-  "version": "0.0.4",
+  "version": "0.0.6",
   "private": false,
   "description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
   "homepage": "https://github.com/webpresso/app#readme",
@@ -38,4 +38,4 @@
   "engines": {
     "node": ">=24"
   }
-}
+}

package/plugin-skill-ownership.json

@@ -2,7 +2,7 @@
   "schemaVersion": 1,
   "host": "claude",
   "packageName": "@webpresso/plugin-claude",
-  "packageVersion": "0.0.4",
+  "packageVersion": "0.0.6",
   "runtimeDirs": [".claude/skills"],
   "skills": {
     "ai-deslop": {
@@ -72,10 +72,10 @@
       "digest": "sha256:b728dad90254d4c9f81b3818321d34ab53519b79ce20ff3bfe08bfacb2aa3e86"
     },
     "plan-refine": {
-      "digest": "sha256:fb883aa53d933324a7979301ca452aed356a8b452827e3695703fb16ccd9e236"
+      "digest": "sha256:f8c186eb1656d7e0a4615c659c26ed6de09bf4603b5902a541385739e606cb0a"
     },
     "ralplan": {
-      "digest": "sha256:db285d477f43ed23df990d4c03750d9916cdc7809356c1bf025efdf6a9add9ed"
+      "digest": "sha256:0353a909e92411f3ccab6fce2d31f4a4fe0e705d865711ad6e5857ec750eda83"
     },
     "team": {
       "digest": "sha256:bf9843f11c2c683bb0e0929c4030a728a93c5ff8087f2c3dc43b88faa7cbd427"
@@ -84,7 +84,7 @@
       "digest": "sha256:8b1f30e55ec6e5ab185ff19ecf15384438dbd619f675c2c65f2e53cedecbae5c"
     },
     "testing-philosophy": {
-      "digest": "sha256:43fa05bcb7eaf8efd4a8dcc0f9fb9c30ae9f80079d9b3dbfdc926734a64a2973"
+      "digest": "sha256:22533e26549b60494f042b5f4d7c97abf2019fc0a60697f84a395fa48ef0147f"
     },
     "tph": {
       "digest": "sha256:bed3684a850651534f315d355cdeae50d951c429817df0f105cccdb7f4e1561b"
@@ -93,7 +93,7 @@
       "digest": "sha256:338952843c8f6b884a18be434daf5b2e190093796b3524e264e6f2c714bd01e1"
     },
     "verify": {
-      "digest": "sha256:0eaa83fa98b39aeb1b3616301cfb22fea7897a1e16c589986febb29811c5a73f"
+      "digest": "sha256:b37da4e7b3388617ec1244cd08cb57cc11c2330270fe20a9c2829e330f1adddf"
     }
   }
 }

package/skills/plan-refine/SKILL.md

@@ -45,6 +45,6 @@ Return a concise plan review with:
 - material corrections with evidence
 - task/dependency changes needed for parallel execution
 - required tests and audits
-- residual risks or explicit blockers
+- residual risks or explicit blockers — record each as a closed decision row (Material Decisions) or a tech-debt record with an owner and follow-up, never as prose left in the Trust Dossier's Residual Unknowns section, which must read exactly `None.` at promotion
 
 For the full historical checklist and examples, read `references/full-methodology.md` only when deeper plan surgery is needed.

package/skills/ralplan/SKILL.md

@@ -33,7 +33,7 @@ Use when the user invokes `$ralplan`, asks for RALPLAN, or wants consensus plann
    - material corrections
    - implementation tasks and dependencies
    - verification gates
-   - residual risks or blockers
+   - residual risks or blockers — record each as a closed decision row (Material Decisions) or a tech-debt record with an owner and follow-up; the Trust Dossier's Residual Unknowns section must still read exactly `None.` at promotion
 5. Stop at an approved plan or an explicit blocker. Do not edit implementation code from this skill unless the user explicitly changes the task from planning to execution.
 
 ## Output

package/skills/testing-philosophy/SKILL.md

@@ -21,7 +21,7 @@ Use when writing tests, reviewing test quality, debugging "tests pass but produc
 1. **Failing proof first.** Folded `/test-driven-development`: for behavior changes, write or strengthen the failing test/proof, watch it fail for the right reason, implement the smallest passing code, then refactor while green.
 2. **Integration-first confidence.** Prefer tests that exercise real boundaries and behavior. Use unit tests for pure logic speed; use integration/E2E where correctness depends on wiring, persistence, CLI/browser flows, or user experience.
 3. **Mocks only at real external boundaries.** Do not mock business logic, framework internals, persistence semantics, or the code under test. Over-mocking creates false confidence.
-4. **Assertions prove behavior.** Avoid tautologies, snapshot-only checks, spy-count implementation assertions, and broad "does not throw" claims.
+4. **Assertions prove behavior, and a claim about a set asserts a count.** Avoid tautologies, snapshot-only checks, spy-count implementation assertions, and broad "does not throw" claims. A guard that only proves a token is _present_ passes while the defect is live — when the claim is "every site is fixed", assert the cardinality (`expect(hits.length).toBe(sites.length)`), not the presence.
 5. **Mutation pressure.** New logic should be written so mutation testing could catch weak assertions; target the repo's 85% mutation-score standard where mutation is in scope.
 
 ## Test-shape checklist

package/skills/verify/SKILL.md

@@ -55,12 +55,13 @@ No completion claim without fresh verification evidence.
 Before saying `done`, `fixed`, `passes`, or `clean`:
 
 1. Identify the command or log that proves the claim.
-2. Run it now, or cite the fresh log from the just-completed run.
+2. Run it **at the entry point the consumer or CI actually invokes** — not a narrower one that happens to be handy. If you substituted a narrower entry point, say which, and check the side effect (did the artifact appear?) rather than pass/fail alone.
 3. Read the exit code and summary — do not infer from partial output.
-4. State the actual result, including the log path when the repo records one.
-5. If another agent made the change, inspect the diff yourself before repeating the claim.
+4. If the claim covers a SET, enumerate it first: state the command, the count it returned, and that every member was addressed. "The one I found" is not the class.
+5. State the actual result, including the log path when the repo records one.
+6. If another agent made the change, inspect the diff yourself before repeating the claim.
 
-Not sufficient: "should pass", "looks correct", lint-only evidence for runtime claims, or another agent's success report without independent verification.
+Not sufficient: "should pass", "looks correct", lint-only evidence for runtime claims, another agent's success report without independent verification, or a guard that asserts a token is _present_ when the claim is that every site was fixed.
 
 ## Usage