rhachet-roles-bhuild 0.16.0 → 0.17.1

package/dist/domain.operations/behavior/init/templates/3.3.1.blueprint.product.v1.guard.heavy

@@ -185,7 +185,71 @@ reviews:
         2. eliminate it if not confirmed as required
         3. make the open question very clearly reported
 
-    # 11. consistent mechanisms
+    # 11. test coverage thoroughness
+    - slug: has-thorough-test-coverage
+      say: |
+        review the blueprint for thorough test coverage declaration.
+
+        test coverage is MANDATORY and equal weight to implementation.
+        a blueprint without thorough test coverage is incomplete.
+
+        ## layer coverage
+
+        for each codepath in the blueprint, verify test coverage by layer:
+
+        | layer | required test type |
+        |-------|-------------------|
+        | transformers (pure computation, format conversion) | unit tests |
+        | communicators (sdks, daos, service clients) | integration tests |
+        | orchestrators (composition of transformers + communicators) | integration tests |
+        | contracts (cli, api, sdk entry points) | integration + acceptance tests |
+
+        ask for each codepath:
+        - does this blueprint declare the appropriate test type for this layer?
+        - are transformers covered by unit tests?
+        - are communicators covered by integration tests?
+        - are orchestrators covered by integration tests?
+        - are contracts covered by both integration and acceptance tests?
+
+        ## case coverage
+
+        for each codepath, verify coverage across case types:
+
+        | case type | what it must cover |
+        |-----------|-------------------|
+        | positive | expected inputs → expected outputs |
+        | negative | invalid inputs → expected errors |
+        | happy path | typical successful flow |
+        | edge cases | boundary conditions, empty inputs, max limits |
+
+        ask for each codepath:
+        - are positive cases declared?
+        - are negative cases declared?
+        - is the happy path covered?
+        - are edge cases identified and covered?
+
+        ## snapshot coverage
+
+        acceptance tests MUST snapshot contract stdouts — exhaustive for positive and negative cases:
+        - cli stdout/stderr (success + all error paths)
+        - api responses (success + all error responses)
+        - sdk returns (success + all thrown errors)
+
+        ask:
+        - does the blueprint declare snapshots for all contract outputs?
+        - are snapshots exhaustive for both positive and negative cases?
+        - is every error path covered by a snapshot?
+
+        ## test tree
+
+        verify the blueprint includes a test tree that shows:
+        - which test files will be created/updated
+        - test file locations match convention
+        - test types match layer requirements
+
+        fix all gaps before you continue.
+
+    # 12. consistent mechanisms
     - slug: has-consistent-mechanisms
       say: |
         review for new mechanisms that duplicate extant functionality.
@@ -204,7 +268,7 @@ reviews:
         1. replace with the extant mechanism
         2. or flag as an open question if unsure
 
-    # 12. consistent conventions
+    # 13. consistent conventions
     - slug: has-consistent-conventions
       say: |
         review for divergence from extant names and patterns.
@@ -224,7 +288,7 @@ reviews:
         1. align with the extant convention
         2. or flag as an open question if the extant convention seems wrong
 
-    # 13. behavior coverage
+    # 14. behavior coverage
     - slug: has-behavior-declaration-coverage
       say: |
         review for coverage of the behavior declaration.
@@ -241,7 +305,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 14. behavior adherance
+    # 15. behavior adherance
     - slug: has-behavior-declaration-adherance
       say: |
         review for adherance to the behavior declaration.
@@ -258,7 +322,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 15. standards adherance
+    # 16. standards adherance
     - slug: has-role-standards-adherance
       say: |
         review for adherance to mechanic role standards.
@@ -278,7 +342,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 16. standards coverage
+    # 17. standards coverage
     - slug: has-role-standards-coverage
       say: |
         review for coverage of mechanic role standards.

package/dist/domain.operations/behavior/init/templates/3.3.1.blueprint.product.v1.guard.light

@@ -133,7 +133,71 @@ reviews:
         2. eliminate it if not confirmed as required
         3. make the open question very clearly reported
 
-    # 7. consistent mechanisms
+    # 7. test coverage thoroughness
+    - slug: has-thorough-test-coverage
+      say: |
+        review the blueprint for thorough test coverage declaration.
+
+        test coverage is MANDATORY and equal weight to implementation.
+        a blueprint without thorough test coverage is incomplete.
+
+        ## layer coverage
+
+        for each codepath in the blueprint, verify test coverage by layer:
+
+        | layer | required test type |
+        |-------|-------------------|
+        | transformers (pure computation, format conversion) | unit tests |
+        | communicators (sdks, daos, service clients) | integration tests |
+        | orchestrators (composition of transformers + communicators) | integration tests |
+        | contracts (cli, api, sdk entry points) | integration + acceptance tests |
+
+        ask for each codepath:
+        - does this blueprint declare the appropriate test type for this layer?
+        - are transformers covered by unit tests?
+        - are communicators covered by integration tests?
+        - are orchestrators covered by integration tests?
+        - are contracts covered by both integration and acceptance tests?
+
+        ## case coverage
+
+        for each codepath, verify coverage across case types:
+
+        | case type | what it must cover |
+        |-----------|-------------------|
+        | positive | expected inputs → expected outputs |
+        | negative | invalid inputs → expected errors |
+        | happy path | typical successful flow |
+        | edge cases | boundary conditions, empty inputs, max limits |
+
+        ask for each codepath:
+        - are positive cases declared?
+        - are negative cases declared?
+        - is the happy path covered?
+        - are edge cases identified and covered?
+
+        ## snapshot coverage
+
+        acceptance tests MUST snapshot contract stdouts — exhaustive for positive and negative cases:
+        - cli stdout/stderr (success + all error paths)
+        - api responses (success + all error responses)
+        - sdk returns (success + all thrown errors)
+
+        ask:
+        - does the blueprint declare snapshots for all contract outputs?
+        - are snapshots exhaustive for both positive and negative cases?
+        - is every error path covered by a snapshot?
+
+        ## test tree
+
+        verify the blueprint includes a test tree that shows:
+        - which test files will be created/updated
+        - test file locations match convention
+        - test types match layer requirements
+
+        fix all gaps before you continue.
+
+    # 8. consistent mechanisms
     - slug: has-consistent-mechanisms
       say: |
         review for new mechanisms that duplicate extant functionality.
@@ -152,7 +216,7 @@ reviews:
         1. replace with the extant mechanism
         2. or flag as an open question if unsure
 
-    # 8. consistent conventions
+    # 9. consistent conventions
     - slug: has-consistent-conventions
       say: |
         review for divergence from extant names and patterns.
@@ -172,7 +236,7 @@ reviews:
         1. align with the extant convention
         2. or flag as an open question if the extant convention seems wrong
 
-    # 9. behavior coverage
+    # 10. behavior coverage
     - slug: has-behavior-declaration-coverage
       say: |
         review for coverage of the behavior declaration.
@@ -189,7 +253,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 10. behavior adherance
+    # 11. behavior adherance
     - slug: has-behavior-declaration-adherance
       say: |
         review for adherance to the behavior declaration.
@@ -206,7 +270,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 11. standards adherance
+    # 12. standards adherance
     - slug: has-role-standards-adherance
       say: |
         review for adherance to mechanic role standards.
@@ -226,7 +290,7 @@ reviews:
 
         fix all gaps before you continue.
 
-    # 12. standards coverage
+    # 13. standards coverage
     - slug: has-role-standards-coverage
       say: |
         review for coverage of mechanic role standards.

package/dist/domain.operations/behavior/init/templates/3.3.1.blueprint.product.v1.stone

@@ -44,11 +44,65 @@ include a treestruct of codepaths.
 
 ## test coverage
 
-enforce thorough test coverage for proof of behavior satisfaction:
-- unit tests for domain logic
-- integration tests for access boundaries (os, apis, sdks, daos)
-- integration tests for end-to-end flows
-- acceptance tests for blackbox behaviors
+test coverage is a MANDATORY requirement, equal weight to implementation.
+a blueprint without thorough test coverage is incomplete.
+
+### coverage by layer
+
+| layer | scope | test type |
+|-------|-------|-----------|
+| transformers | pure computation, format conversion | unit tests |
+| communicators | sdks, daos, service clients (i/o boundary) | integration tests |
+| orchestrators | composition of transformers + communicators | integration tests |
+| contracts | cli, api, sdk entry points | integration + acceptance tests |
+
+### coverage by case
+
+for each codepath, declare coverage across:
+
+| case type | what it covers |
+|-----------|----------------|
+| positive | expected inputs produce expected outputs |
+| negative | invalid inputs produce expected errors |
+| happy path | typical successful flow |
+| edge cases | boundary conditions, empty inputs, max limits |
+
+### snapshots
+
+acceptance tests MUST snapshot contract stdouts — exhaustive for positive and negative cases:
+- cli stdout/stderr formats (success + all error paths)
+- api response shapes (success + all error responses)
+- sdk return types (success + all thrown errors)
+
+snapshots enable visual review in PRs — verify outputs look correct.
+
+### test tree
+
+include a treestruct of test coverage for each codepath:
+
+```
+src/domain.operations/myTransformer/
+├── myTransformer.ts
+└── myTransformer.test.ts              # unit: transformer (pure)
+
+src/domain.operations/myCommunicator/
+├── myCommunicator.ts
+└── myCommunicator.integration.test.ts # integration: communicator (i/o)
+
+src/domain.operations/myOrchestrator/
+├── myOrchestrator.ts
+└── myOrchestrator.integration.test.ts # integration: orchestrator
+
+src/contract/cli/myCommand.ts
+└── myCommand.integration.test.ts      # integration: contract (also an orchestrator)
+
+blackbox/cli/myCommand.acceptance.test.ts  # acceptance: contract (blackbox)
+```
+
+**legend:**
+- `[+]` create — test to create
+- `[~]` update — test to update
+- `[○]` retain — test to retain
 
 ---
 

package/dist/domain.operations/behavior/init/templates/5.3.verification.v1.guard

@@ -14,14 +14,20 @@ reviews:
         - is every behavior in 1.vision.md covered?
         - can you point to each test file in the checklist?
 
+        **if any behavior lacks a test, write the test NOW.** do not pass this gate with gaps.
+
     - slug: has-zero-test-skips
       say: |
-        double-check: did you verify zero skips?
+        double-check: did you verify zero skips — and REMOVE any you found?
 
         - no .skip() or .only() found?
         - no silent credential bypasses?
         - no prior failures carried forward?
 
+        **if you found skips, did you remove them and make those tests pass?**
+
+        this is buttonup. skips are gaps. gaps get fixed, not noted.
+
     - slug: has-all-tests-passed
       say: |
         double-check: did all tests pass? prove it.
@@ -93,7 +99,10 @@ reviews:
         - does the test follow the BDD given/when/then structure?
         - does each `when([tN])` step exist?
 
-        if any journey was planned but not implemented, go back and add it.
+        **if any journey was planned but not implemented, go back and add it NOW.**
+
+        this is buttonup. absent journey tests = incomplete implementation.
+        test coverage proves prod coverage. no test = no proof = not done.
 
     - slug: has-contract-output-variants-snapped
       say: |
@@ -122,11 +131,13 @@ reviews:
         - absent variants mean blind spots in review
         - exhaustive coverage proves the contract works for all callers
 
-        **zero leniency.** if a contract lacks any variant, add the test case now.
+        **zero leniency.** if a contract lacks any variant, add the test case NOW.
 
         if you find yourself about to say "this variant isn't worth a snapshot" — stop.
         that is the variant that will break in prod. snap it.
 
+        this is buttonup. absent snapshots = absent proof. add them or fail this gate.
+
     - slug: has-snap-changes-rationalized
       say: |
         double-check: is every `.snap` file change intentional and justified?
@@ -191,6 +202,30 @@ reviews:
         - do they have the `.play.` suffix?
         - if not supported, is the fallback convention used?
 
+    - slug: has-fixed-all-gaps
+      say: |
+        final buttonup check: did you FIX every gap you found, or just detect it?
+
+        **this is the buttonup phase. detection is not enough — you must fix.**
+
+        look back at all the reviews above. for every gap you identified:
+        - absent test coverage → did you WRITE the test?
+        - absent prod coverage → did you IMPLEMENT the behavior?
+        - failed test → did you FIX the code or test?
+        - skipped test → did you REMOVE the skip and make it pass?
+
+        **zero omissions.** if any review above surfaced a gap, that gap must be fixed before you pass this gate.
+
+        ask yourself:
+        - did i just note the gap, or did i actually fix it?
+        - is there any item marked "todo" or "later"? (forbidden)
+        - is there any coverage marked incomplete? (forbidden)
+
+        **if you detected it, you fixed it.** prove it with citations.
+
+        this is the final self-review. you are about to hand off to peer review.
+        prove that all items above were addressed — not deferred.
+
   peer:
     # verify contract snapshot exhaustiveness
     - npx rhachet run --repo bhrain --skill review --rules '.agent/repo=bhuild/role=behaver/briefs/practices/behavior.verification/rule.require.contract-snapshot-exhaustiveness.md' --diffs since-main --paths-with '{src,blackbox}/**/*.{test,snap}.ts' --join intersect --output '$route/.reviews/$stone.peer-review.contract-snapshots.md' --mode hard

package/dist/domain.operations/behavior/init/templates/5.3.verification.v1.stone

@@ -1,10 +1,27 @@
-prove the deliverable works via test verification
+prove the deliverable works via test verification — fix all gaps
 
 ---
 
 ## .what
 
-this is the verification gate. you cannot pass execution without proof that all tests pass.
+this is the verification gate — the **buttonup phase**.
+
+you cannot pass execution without proof that all tests pass. more importantly: **test coverage enforces prod coverage**. if tests are absent, prod is incomplete. if prod is incomplete, fix it.
+
+## .the buttonup mandate: zero omissions
+
+**this is not a detection phase. this is a completion phase.**
+
+when you find a gap, you do not note it and move on. you **fix it**.
+
+| gap type | action |
+|----------|--------|
+| absent test coverage | write the test NOW |
+| absent prod coverage | implement the behavior NOW |
+| failed test | fix the code or fix the test NOW |
+| skipped test | remove the skip and make it pass NOW |
+
+**if you detect it, you fix it. no exceptions.**
 
 ## .strictness: zero tolerance, zero exceptions
 
@@ -18,6 +35,7 @@ this is the verification gate. you cannot pass execution without proof that all
 | zero credential excuses | "i don't have creds" is not an excuse. get them, mock them, or fail. |
 | zero skips | .skip() and .only() are forbidden. silent bypasses are forbidden. |
 | zero exceptions | there are no special cases. the rules apply to all. |
+| zero omissions | if you find a gap in coverage, you fix it — test or prod. |
 
 **if a blocker prevents tests from run, that is a BLOCKER. full stop.**
 
@@ -29,17 +47,21 @@ you do not proceed. you do not defer. you fix it or you fail the gate.
 
 your crew is about to review a pr you wrote. they need proof it works — not words, proof. tests are that proof.
 
+**test coverage drives prod coverage.** if a behavior lacks a test, that behavior is unproven. unproven behaviors are incomplete deliverables. the test proves the implementation exists and works.
+
 without this gate:
 - tests might fail and nobody notices
 - tests might be skipped and nobody notices
 - behaviors might lack coverage and nobody notices
 - broken code ships to peers
+- incomplete implementations slip through
 
 with this gate:
 - every test passes or you fix it
 - every behavior has coverage or you add it
 - every skip is removed or justified
 - proven code ships to peers
+- **gaps get fixed, not deferred**
 
 **the cardinal rules**:
 1. never leave behavior without true, dependable test coverage
@@ -165,7 +187,7 @@ update the checklist as you complete each step below.
 
 ---
 
-### step 2: verify behavior coverage
+### step 2: verify AND FIX behavior coverage
 
 walk through wish and vision:
 - every behavior promised must have an acceptance test
@@ -174,11 +196,15 @@ walk through wish and vision:
 
 **why?** your crew trusts the test suite. if a behavior isn't tested, it isn't proven. untested behaviors are unverified promises.
 
-if a behavior lacks a test, write one. update your checklist.
+**test coverage enforces prod coverage.** if a test is absent, either:
+1. the behavior was not implemented → IMPLEMENT IT NOW
+2. the behavior was implemented without a test → WRITE THE TEST NOW
+
+if a behavior lacks a test, **write one NOW**. do not move on with gaps. update your checklist when done.
 
 ---
 
-### step 3: verify zero skips
+### step 3: verify AND FIX zero skips
 
 scan for forbidden patterns:
 - `.skip()` or `.only()` in test files
@@ -187,11 +213,16 @@ scan for forbidden patterns:
 
 **why?** failures are better than skips. skips hide problems. failures expose them. a skipped test is a lie — it pretends coverage exists when it doesn't.
 
-if you find skips, remove them. all tests must run. update your checklist.
+**this is buttonup.** if you find skips:
+1. REMOVE the skip
+2. MAKE the test pass (fix the code or fix the test)
+3. update your checklist
+
+do not note skips and move on. fix them. all tests must run.
 
 ---
 
-### step 4: run all tests and fix all failures
+### step 4: run all tests AND FIX all failures
 
 run each test suite and **cite the exact command and output**.
 
@@ -206,7 +237,12 @@ npm run test:acceptance  # cite exit code + test count
 
 all must pass — no exceptions. no deferrals. no "i'll fix it later."
 
-if tests fail, fix them. that is the job.
+**this is buttonup.** if tests fail, fix them. that is the job.
+
+failures indicate one of:
+1. prod code is broken → FIX THE PROD CODE
+2. test has a bug → FIX THE TEST BUG (preserve intention)
+3. coverage gap exists → FILL THE GAP
 
 **consider all failures as defects from this pr.** there are no "prior failures."
 

package/dist/domain.operations/behavior/init/templates/5.5.playtest.v1.guard

@@ -14,6 +14,8 @@ reviews:
         - are commands copy-pasteable?
         - are expected outcomes explicit?
 
+        **if any instruction is unclear, fix it NOW.** this is buttonup.
+
     - slug: has-vision-coverage
       say: |
         double-check: does the playtest cover all behaviors?
@@ -22,6 +24,8 @@ reviews:
         - is every behavior in 1.vision.md verified?
         - are any requirements left untested?
 
+        **if any behavior lacks playtest coverage, add it NOW.** absent coverage = incomplete.
+
     - slug: has-edgecase-coverage
       say: |
         double-check: are edge cases covered?
@@ -30,6 +34,8 @@ reviews:
         - what inputs are unusual but valid?
         - are boundaries tested?
 
+        **if edge cases are absent, add them NOW.** this is buttonup — no gaps allowed.
+
     - slug: has-acceptance-test-citations
       say: |
         coverage check: cite the acceptance test for each playtest step.
@@ -49,15 +55,39 @@ reviews:
         ```
 
         if a step lacks acceptance test coverage:
-        - this is a BLOCKER — write the test before you proceed
+        - this is a BLOCKER — write the test NOW, before you proceed
         - "untestable via automation" is almost never true — find a way
 
         **zero gaps.** if you cannot cite a test, the step is unproven.
         unproven steps do not pass this gate.
 
+        **this is buttonup.** test coverage enforces prod coverage.
+        absent test = unproven behavior = incomplete implementation = fix it NOW.
+
+    - slug: has-fixed-all-gaps
+      say: |
+        buttonup check: did you FIX every gap you found, or just detect it?
+
+        **this is the buttonup phase. detection is not enough — you must fix.**
+
+        look back at all the reviews above. for every gap you identified:
+        - playtest step lacked acceptance test → did you WRITE the test?
+        - playtest revealed broken behavior → did you FIX the behavior?
+        - playtest revealed UX friction → did you FIX the UX?
+        - playtest step was ambiguous → did you CLARIFY it?
+
+        **zero omissions.** if any review above surfaced a gap, that gap must be fixed before you pass this gate.
+
+        ask yourself:
+        - did i just note the gap, or did i actually fix it?
+        - is there any item marked "todo" or "needs work"? (forbidden)
+        - is there any step without acceptance test citation? (forbidden)
+
+        **if you detected it, you fixed it.** prove it with citations.
+
     - slug: has-self-run-verification
       say: |
-        dogfood check: did you run the playtest yourself?
+        final proof: did you run the playtest yourself?
 
         **zero self-skip.** you must run every step before emit.
 
@@ -75,11 +105,15 @@ reviews:
         - did you fix the instructions?
         - did you update expected outcomes?
         - is the playtest now accurate to what you observed?
+        - **did you fix any broken behaviors you discovered?**
 
         the foreman deserves a playtest that works. prove it works by self-test first.
 
         **if you did not run it yourself, you did not verify it.**
         this is a BLOCKER, not a suggestion.
 
+        **this is the final proof.** you ran it, it worked, all gaps are fixed.
+        you are ready to hand off to foreman approval.
+
 judges:
   - npx rhachet run --repo bhrain --skill route.stone.judge --mechanism approved? --stone $stone --route $route

package/dist/domain.operations/behavior/init/templates/5.5.playtest.v1.stone

@@ -1,12 +1,29 @@
-emit a playtest for foreman byhand verification
+emit a playtest for foreman byhand verification — fix all gaps found
 
 ---
 
 ## .what
 
-this is the playtest gate. you emit a step-by-step byhand quality assurance checklist that your crew can walk through to verify the deliverable feels right.
+this is the playtest gate — the **final buttonup phase**.
 
-automated tests prove the code works. the playtest proves the experience works.
+you emit a step-by-step byhand quality assurance checklist that your crew can walk through to verify the deliverable feels right.
+
+automated tests prove the code works. the playtest proves the experience works. **if the playtest reveals gaps, you fix them.**
+
+## .the buttonup mandate: zero omissions
+
+**this is not a detection phase. this is a completion phase.**
+
+when you find a gap — while you write the playtest OR while you run it yourself — you **fix it**.
+
+| gap type | action |
+|----------|--------|
+| playtest step lacks acceptance test | write the acceptance test NOW |
+| playtest reveals broken behavior | fix the behavior NOW |
+| playtest reveals UX friction | fix the UX NOW |
+| playtest step is ambiguous | clarify it NOW |
+
+**if you detect it, you fix it. no exceptions.**
 
 ## .strictness: zero tolerance, zero exceptions
 
@@ -18,6 +35,7 @@ automated tests prove the code works. the playtest proves the experience works.
 | zero untested paths | every playtest step must have automated coverage |
 | zero self-skip | you must run the playtest yourself before emit |
 | zero ambiguity | every step must be copy-pasteable with explicit expected output |
+| zero omissions | if playtest reveals a gap, you fix it before you emit |
 
 **every playtest step maps to an acceptance test.** if a step lacks automated coverage, write the test first.
 
@@ -29,6 +47,8 @@ automated tests prove the code works. the playtest proves the experience works.
 
 **the playtest is a contract.** it says: "if you follow these steps and all pass as described, the deliverable is complete." it's explicit proof, not implicit trust.
 
+**test coverage enforces prod coverage.** every playtest step must trace to an acceptance test. if you cannot cite the test, the behavior is unproven. unproven = incomplete = fix it.
+
 ## .how
 
 reference the below for full context

package/package.json

@@ -2,7 +2,7 @@
   "name": "rhachet-roles-bhuild",
   "author": "ehmpathy",
   "description": "roles for building resilient systems, via rhachet",
-  "version": "0.16.0",
+  "version": "0.17.1",
   "repository": "ehmpathy/rhachet-roles-bhuild",
   "homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
   "keywords": [
@@ -89,12 +89,12 @@
     "esbuild-register": "3.6.0",
     "husky": "8.0.3",
     "jest": "30.2.0",
-    "rhachet": "1.39.8",
+    "rhachet": "1.39.9",
     "rhachet-brains-anthropic": "0.4.0",
     "rhachet-brains-xai": "0.3.3",
-    "rhachet-roles-bhrain": "0.23.10",
+    "rhachet-roles-bhrain": "0.23.11",
     "rhachet-roles-bhuild": "link:.",
-    "rhachet-roles-ehmpathy": "1.34.21",
+    "rhachet-roles-ehmpathy": "1.34.25",
     "tsc-alias": "1.8.10",
     "tsx": "4.20.6",
     "typescript": "5.4.5",