rhachet-roles-bhuild 0.15.4 → 0.17.0

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.1.execution.phase0_to_phaseN.v1.guard

@@ -157,7 +157,8 @@ reviews:
         fix all gaps before you continue.
 
   peer:
-    - npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.{prod,test}/pitofsuccess.errors/rule.*.md' --diffs since-main --paths-with 'src/**/*.ts' --join intersect --output '$route/.reviews/$stone.peer-review.failhides.md' --mode hard
+    - npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.{prod,test}/pitofsuccess.errors/rule.*.md' --diffs since-main --paths-with 'src/**/*' --join intersect --output '$route/.reviews/$stone.peer-review.failhides.md' --mode hard
+    - npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=architect/briefs/practices/rule.{forbid.decode-friction-in-orchestrators,require.orchestrators-as-narrative}.md' --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.prod/readable.narrative/rule.{forbid.inline-decode-friction,require.named-transforms}.md' --refs '.agent/repo=ehmpathy/role=architect/briefs/practices/{define.domain-operation-grains,philosophy.transform-orchestrator-separation.[philosophy]}.md' --diffs since-main --paths-with 'src/**/*' --paths-without '**/*.test.ts' --join intersect --output '$route/.reviews/$stone.peer-review.decode-friction.md' --mode hard
 
 judges:
   - npx rhachet run --repo bhrain --skill route.stone.judge --mechanism reviewed? --stone $stone --route $route --allow-blockers 0 --allow-nitpicks 3

package/package.json

@@ -2,7 +2,7 @@
   "name": "rhachet-roles-bhuild",
   "author": "ehmpathy",
   "description": "roles for building resilient systems, via rhachet",
-  "version": "0.15.4",
+  "version": "0.17.0",
   "repository": "ehmpathy/rhachet-roles-bhuild",
   "homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
   "keywords": [
@@ -89,17 +89,19 @@
     "esbuild-register": "3.6.0",
     "husky": "8.0.3",
     "jest": "30.2.0",
-    "rhachet": "1.39.7",
+    "rhachet": "1.39.8",
     "rhachet-brains-anthropic": "0.4.0",
+    "rhachet-brains-xai": "0.3.3",
     "rhachet-roles-bhrain": "0.23.10",
     "rhachet-roles-bhuild": "link:.",
-    "rhachet-roles-ehmpathy": "1.34.19",
+    "rhachet-roles-ehmpathy": "1.34.21",
     "tsc-alias": "1.8.10",
     "tsx": "4.20.6",
     "typescript": "5.4.5",
     "yalc": "1.0.0-pre.53"
   },
   "peerDependencies": {
+    "rhachet-brains-xai": ">=0.3.3",
     "rhachet-roles-bhrain": ">=0.12.1"
   },
   "config": {