@webpresso/plugin-claude 0.0.5 → 0.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -6,7 +6,7 @@
6
6
  },
7
7
  "metadata": {
8
8
  "description": "Webpresso agent-kit Claude Code plugin: blueprints, skills, hooks, MCP server",
9
- "version": "0.0.5"
9
+ "version": "0.0.6"
10
10
  },
11
11
  "plugins": [
12
12
  {
@@ -17,5 +17,5 @@
17
17
  "keywords": ["agent", "blueprint", "claude-code", "skills", "mcp"]
18
18
  }
19
19
  ],
20
- "version": "0.0.5"
20
+ "version": "0.0.6"
21
21
  }
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "agent-kit",
3
- "version": "0.0.5",
3
+ "version": "0.0.6",
4
4
  "description": "Webpresso agent-kit: blueprints, skills, lore commit protocol, tech-debt lifecycle",
5
5
  "author": {
6
6
  "name": "Webpresso",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@webpresso/plugin-claude",
3
- "version": "0.0.5",
3
+ "version": "0.0.6",
4
4
  "private": false,
5
5
  "description": "Claude Code plugin adapter for Webpresso agent-kit skills, commands, and MCP runtime.",
6
6
  "homepage": "https://github.com/webpresso/app#readme",
@@ -2,7 +2,7 @@
2
2
  "schemaVersion": 1,
3
3
  "host": "claude",
4
4
  "packageName": "@webpresso/plugin-claude",
5
- "packageVersion": "0.0.5",
5
+ "packageVersion": "0.0.6",
6
6
  "runtimeDirs": [".claude/skills"],
7
7
  "skills": {
8
8
  "ai-deslop": {
@@ -72,10 +72,10 @@
72
72
  "digest": "sha256:b728dad90254d4c9f81b3818321d34ab53519b79ce20ff3bfe08bfacb2aa3e86"
73
73
  },
74
74
  "plan-refine": {
75
- "digest": "sha256:fb883aa53d933324a7979301ca452aed356a8b452827e3695703fb16ccd9e236"
75
+ "digest": "sha256:f8c186eb1656d7e0a4615c659c26ed6de09bf4603b5902a541385739e606cb0a"
76
76
  },
77
77
  "ralplan": {
78
- "digest": "sha256:db285d477f43ed23df990d4c03750d9916cdc7809356c1bf025efdf6a9add9ed"
78
+ "digest": "sha256:0353a909e92411f3ccab6fce2d31f4a4fe0e705d865711ad6e5857ec750eda83"
79
79
  },
80
80
  "team": {
81
81
  "digest": "sha256:bf9843f11c2c683bb0e0929c4030a728a93c5ff8087f2c3dc43b88faa7cbd427"
@@ -84,7 +84,7 @@
84
84
  "digest": "sha256:8b1f30e55ec6e5ab185ff19ecf15384438dbd619f675c2c65f2e53cedecbae5c"
85
85
  },
86
86
  "testing-philosophy": {
87
- "digest": "sha256:43fa05bcb7eaf8efd4a8dcc0f9fb9c30ae9f80079d9b3dbfdc926734a64a2973"
87
+ "digest": "sha256:22533e26549b60494f042b5f4d7c97abf2019fc0a60697f84a395fa48ef0147f"
88
88
  },
89
89
  "tph": {
90
90
  "digest": "sha256:bed3684a850651534f315d355cdeae50d951c429817df0f105cccdb7f4e1561b"
@@ -93,7 +93,7 @@
93
93
  "digest": "sha256:338952843c8f6b884a18be434daf5b2e190093796b3524e264e6f2c714bd01e1"
94
94
  },
95
95
  "verify": {
96
- "digest": "sha256:0eaa83fa98b39aeb1b3616301cfb22fea7897a1e16c589986febb29811c5a73f"
96
+ "digest": "sha256:b37da4e7b3388617ec1244cd08cb57cc11c2330270fe20a9c2829e330f1adddf"
97
97
  }
98
98
  }
99
99
  }
@@ -45,6 +45,6 @@ Return a concise plan review with:
45
45
  - material corrections with evidence
46
46
  - task/dependency changes needed for parallel execution
47
47
  - required tests and audits
48
- - residual risks or explicit blockers
48
+ - 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
49
49
 
50
50
  For the full historical checklist and examples, read `references/full-methodology.md` only when deeper plan surgery is needed.
@@ -33,7 +33,7 @@ Use when the user invokes `$ralplan`, asks for RALPLAN, or wants consensus plann
33
33
  - material corrections
34
34
  - implementation tasks and dependencies
35
35
  - verification gates
36
- - residual risks or blockers
36
+ - 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
37
37
  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.
38
38
 
39
39
  ## Output
@@ -21,7 +21,7 @@ Use when writing tests, reviewing test quality, debugging "tests pass but produc
21
21
  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.
22
22
  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.
23
23
  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.
24
- 4. **Assertions prove behavior.** Avoid tautologies, snapshot-only checks, spy-count implementation assertions, and broad "does not throw" claims.
24
+ 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.
25
25
  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.
26
26
 
27
27
  ## Test-shape checklist
@@ -55,12 +55,13 @@ No completion claim without fresh verification evidence.
55
55
  Before saying `done`, `fixed`, `passes`, or `clean`:
56
56
 
57
57
  1. Identify the command or log that proves the claim.
58
- 2. Run it now, or cite the fresh log from the just-completed run.
58
+ 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.
59
59
  3. Read the exit code and summary — do not infer from partial output.
60
- 4. State the actual result, including the log path when the repo records one.
61
- 5. If another agent made the change, inspect the diff yourself before repeating the claim.
60
+ 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.
61
+ 5. State the actual result, including the log path when the repo records one.
62
+ 6. If another agent made the change, inspect the diff yourself before repeating the claim.
62
63
 
63
- Not sufficient: "should pass", "looks correct", lint-only evidence for runtime claims, or another agent's success report without independent verification.
64
+ 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.
64
65
 
65
66
  ## Usage
66
67