rhachet-roles-bhuild 0.14.3 → 0.14.5

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

@@ -11,6 +11,19 @@ reviews:
       say: |
         try hard to delete before you optimize:
 
+        ## features
+
+        for each feature in the blueprint, ask:
+        - does this feature trace to a requirement in the criteria?
+        - did the wisher explicitly ask for this feature?
+        - or did we assume it was needed?
+
+        if a feature has no traceability to vision or criteria:
+        1. delete it
+        2. or flag it as an open question for the wisher
+
+        ## components
+
         for each component, ask:
         - can this be removed entirely?
         - if we deleted this and had to add it back, would we?

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

@@ -11,6 +11,19 @@ reviews:
       say: |
         try hard to delete before you optimize:
 
+        ## features
+
+        for each feature in the blueprint, ask:
+        - does this feature trace to a requirement in the criteria?
+        - did the wisher explicitly ask for this feature?
+        - or did we assume it was needed?
+
+        if a feature has no traceability to vision or criteria:
+        1. delete it
+        2. or flag it as an open question for the wisher
+
+        ## components
+
         for each component, ask:
         - can this be removed entirely?
         - if we deleted this and had to add it back, would we?

package/dist/domain.operations/behavior/init/templates/5.1.execution.phase0_to_phaseN.v1.guard

@@ -1,6 +1,12 @@
 # guard for execution stone
 # includes standardized self-review frame
 
+artifacts:
+  # track execution progress
+  - "$route/5.1.execution.phase0_to_phaseN.v1.i1.md"
+  # track actual implementation in src/
+  - "src/**/*"
+
 reviews:
   self:
     # 1. minimalism - yagni

package/dist/domain.operations/behavior/init/templates/5.2.evaluation.v1.stone

@@ -3,8 +3,9 @@ evaluate what was implemented against the blueprint
 .what = articulate exactly what was implemented, then check for divergences from blueprint.
 
 .why = the blueprint declared what the execution would adhere to.
-- divergences may be intentional improvements or accidental drift
-- each divergence must be either repaired or backed up with rationale
+- divergences are NOT allowed
+- default action is REPAIR — fix implementation to match blueprint
+- if repair is impossible, raise BLOCKER and request human approval
 - this gate prevents silent deviations from approved design
 
 ---
@@ -68,20 +69,21 @@ for each section (summary, filediff, codepath, test coverage), compare:
 
 ### divergence resolution
 
-for each divergence, you must either:
+for each divergence:
 
-**repair** — fix the implementation to match the blueprint:
+**repair** (default) — fix the implementation to match the blueprint:
 - what needs to change to match blueprint?
 - make the change, then update the "as implemented" section above
 
-**backup** — document why the divergence is acceptable:
-- why did the implementation diverge?
-- why is the divergence better than the blueprint?
-- should the blueprint be updated for future reference?
+**blocker** (only if repair is impossible) — request human approval:
+- why is repair impossible?
+- what constraint prevents adherence to blueprint?
+- run `rhx route.stone.set --as blocked` to declare yourself blocked and request human approval
+- STOP and await human decision before you proceed
 
 | divergence | resolution | rationale |
 |------------|------------|-----------|
-| ... | repair/backup | ... |
+| ... | repair/blocker | ... |
 
 ---
 

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

@@ -1,3 +1,9 @@
+artifacts:
+  # track verification progress
+  - "$route/5.3.verification.v1.i1.md"
+  # track actual implementation in src/
+  - "src/**/*"
+
 reviews:
   self:
     - slug: has-behavior-coverage
@@ -67,19 +73,51 @@ reviews:
 
         if any journey was planned but not implemented, go back and add it.
 
-    - slug: has-snapshot-coverage
+    - slug: has-contract-output-variants-snapped
+      say: |
+        double-check: does each public contract have snapshots for all output variants?
+
+        for each new or modified public contract (cli command, sdk method, api endpoint):
+        - is there a dedicated snapshot file with `.toMatchSnapshot()` or equivalent?
+        - does the snapshot capture what the caller would actually see?
+        - does it exercise the success case?
+        - does it exercise error cases?
+        - does it exercise edge cases and variants (e.g., --help, empty input)?
+
+        output types to capture:
+        - for CLI: stdout/stderr
+        - for UI: screens
+        - for SDK: responses
+
+        why this matters:
+        - snapshots enable vibecheck in prs — reviewers see actual output without execute
+        - snapshots detect drift over time — output changes surface in diffs
+        - absent variants mean blind spots in review
+
+        if a contract lacks variant coverage, add the test cases now.
+
+    - slug: has-snap-changes-rationalized
       say: |
-        double-check: do snapshots capture input/output for caller visibility?
+        double-check: is every `.snap` file change intentional and justified?
+
+        for each `.snap` file in git diff:
+        1. what changed? (added, modified, deleted)
+        2. was this change intended or accidental?
+        3. if intended: what is the rationale?
+        4. if accidental: revert it or explain why the new output is an improvement
 
-        for each journey test:
-        - does it have `.toMatchSnapshot()` or equivalent assertions?
-        - does the snapshot show what the caller would actually see?
-        - for CLI: is stdout/stderr captured?
-        - for UI: are screens captured?
-        - for SDK: are responses captured?
+        common regressions caught here:
+        - output format degraded (lost alignment, lost structure)
+        - error messages became less helpful
+        - timestamps or ids leaked into snapshots (flaky)
+        - extra output added unintentionally
+
+        forbidden:
+        - "updated snapshots" without per-file rationale
+        - bulk snapshot updates without review
+        - regressions accepted without justification
 
-        snapshots let reviewers see the actual output without the need to run the code.
-        if snapshots are absent, the reviewer can't verify the user experience.
+        every snap change tells a story. make sure the story is intentional.
 
     - slug: has-critical-paths-frictionless
       say: |

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

@@ -68,9 +68,37 @@ for each journey sketched in repros, verify it was implemented with snapshots.
 - [ ] no prior failures carried forward
 
 ### snapshot coverage for contract outputs
-- [ ] new cli commands have `.snap` snapshots for stdout/stderr
-- [ ] new app screens have `.snap` snapshots for screenshots
-- [ ] snapshot demonstrates actual output, not just "it ran"
+
+each public contract needs dedicated snapshots that demonstrate its stdout for:
+- **vibechecks in prs** — reviewers see actual output without executing code
+- **drift detection** — changes to output surface in diffs over time
+
+| contract | output variants | snapshot file | status |
+|----------|-----------------|---------------|--------|
+| {command 1} | success, error, help | {path.snap} | ⏳ |
+| {command 2} | success, error, help | {path.snap} | ⏳ |
+...
+
+checklist:
+- [ ] every new cli command has `.snap` snapshots for stdout/stderr
+- [ ] every new app screen has `.snap` snapshots for screenshots
+- [ ] every new sdk method has `.snap` snapshots for responses
+- [ ] each output variant is exercised (success, error, edge cases)
+- [ ] snapshots demonstrate actual output, not just "it ran"
+
+### snapshot change rationalization
+
+for each `.snap` file changed, rationalize whether the change was intended or accidental:
+
+| snap file | change type | intended? | rationale |
+|-----------|-------------|-----------|-----------|
+| {path.snap} | added / modified / deleted | yes / no | {why this change is correct} |
+...
+
+checklist:
+- [ ] every `.snap` change has been reviewed
+- [ ] intended changes have clear rationale
+- [ ] accidental changes have been reverted or justified as improvements
 
 ### tests executed
 - [ ] `npm run test` — passed

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

@@ -1,3 +1,9 @@
+artifacts:
+  # track playtest progress
+  - "$route/5.5.playtest.v1.i1.md"
+  # track actual implementation in src/
+  - "src/**/*"
+
 reviews:
   self:
     - slug: has-clear-instructions

package/package.json

@@ -2,7 +2,7 @@
   "name": "rhachet-roles-bhuild",
   "author": "ehmpathy",
   "description": "roles for building resilient systems, via rhachet",
-  "version": "0.14.3",
+  "version": "0.14.5",
   "repository": "ehmpathy/rhachet-roles-bhuild",
   "homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
   "keywords": [
@@ -89,11 +89,11 @@
     "esbuild-register": "3.6.0",
     "husky": "8.0.3",
     "jest": "30.2.0",
-    "rhachet": "1.37.15",
-    "rhachet-brains-anthropic": "0.3.3",
-    "rhachet-roles-bhrain": "0.18.1",
+    "rhachet": "1.38.0",
+    "rhachet-brains-anthropic": "0.4.0",
+    "rhachet-roles-bhrain": "0.23.8",
     "rhachet-roles-bhuild": "link:.",
-    "rhachet-roles-ehmpathy": "1.27.13",
+    "rhachet-roles-ehmpathy": "1.34.9",
     "tsc-alias": "1.8.10",
     "tsx": "4.20.6",
     "typescript": "5.4.5",