rhachet-roles-bhuild 0.14.2 → 0.14.4
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.
|
@@ -67,19 +67,51 @@ reviews:
|
|
|
67
67
|
|
|
68
68
|
if any journey was planned but not implemented, go back and add it.
|
|
69
69
|
|
|
70
|
-
- slug: has-
|
|
70
|
+
- slug: has-contract-output-variants-snapped
|
|
71
71
|
say: |
|
|
72
|
-
double-check:
|
|
72
|
+
double-check: does each public contract have snapshots for all output variants?
|
|
73
73
|
|
|
74
|
-
for each
|
|
75
|
-
-
|
|
76
|
-
- does the snapshot
|
|
77
|
-
-
|
|
78
|
-
-
|
|
79
|
-
-
|
|
74
|
+
for each new or modified public contract (cli command, sdk method, api endpoint):
|
|
75
|
+
- is there a dedicated snapshot file with `.toMatchSnapshot()` or equivalent?
|
|
76
|
+
- does the snapshot capture what the caller would actually see?
|
|
77
|
+
- does it exercise the success case?
|
|
78
|
+
- does it exercise error cases?
|
|
79
|
+
- does it exercise edge cases and variants (e.g., --help, empty input)?
|
|
80
80
|
|
|
81
|
-
|
|
82
|
-
|
|
81
|
+
output types to capture:
|
|
82
|
+
- for CLI: stdout/stderr
|
|
83
|
+
- for UI: screens
|
|
84
|
+
- for SDK: responses
|
|
85
|
+
|
|
86
|
+
why this matters:
|
|
87
|
+
- snapshots enable vibecheck in prs — reviewers see actual output without execute
|
|
88
|
+
- snapshots detect drift over time — output changes surface in diffs
|
|
89
|
+
- absent variants mean blind spots in review
|
|
90
|
+
|
|
91
|
+
if a contract lacks variant coverage, add the test cases now.
|
|
92
|
+
|
|
93
|
+
- slug: has-snap-changes-rationalized
|
|
94
|
+
say: |
|
|
95
|
+
double-check: is every `.snap` file change intentional and justified?
|
|
96
|
+
|
|
97
|
+
for each `.snap` file in git diff:
|
|
98
|
+
1. what changed? (added, modified, deleted)
|
|
99
|
+
2. was this change intended or accidental?
|
|
100
|
+
3. if intended: what is the rationale?
|
|
101
|
+
4. if accidental: revert it or explain why the new output is an improvement
|
|
102
|
+
|
|
103
|
+
common regressions caught here:
|
|
104
|
+
- output format degraded (lost alignment, lost structure)
|
|
105
|
+
- error messages became less helpful
|
|
106
|
+
- timestamps or ids leaked into snapshots (flaky)
|
|
107
|
+
- extra output added unintentionally
|
|
108
|
+
|
|
109
|
+
forbidden:
|
|
110
|
+
- "updated snapshots" without per-file rationale
|
|
111
|
+
- bulk snapshot updates without review
|
|
112
|
+
- regressions accepted without justification
|
|
113
|
+
|
|
114
|
+
every snap change tells a story. make sure the story is intentional.
|
|
83
115
|
|
|
84
116
|
- slug: has-critical-paths-frictionless
|
|
85
117
|
say: |
|
|
@@ -68,9 +68,37 @@ for each journey sketched in repros, verify it was implemented with snapshots.
|
|
|
68
68
|
- [ ] no prior failures carried forward
|
|
69
69
|
|
|
70
70
|
### snapshot coverage for contract outputs
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
-
|
|
71
|
+
|
|
72
|
+
each public contract needs dedicated snapshots that demonstrate its stdout for:
|
|
73
|
+
- **vibechecks in prs** — reviewers see actual output without executing code
|
|
74
|
+
- **drift detection** — changes to output surface in diffs over time
|
|
75
|
+
|
|
76
|
+
| contract | output variants | snapshot file | status |
|
|
77
|
+
|----------|-----------------|---------------|--------|
|
|
78
|
+
| {command 1} | success, error, help | {path.snap} | ⏳ |
|
|
79
|
+
| {command 2} | success, error, help | {path.snap} | ⏳ |
|
|
80
|
+
...
|
|
81
|
+
|
|
82
|
+
checklist:
|
|
83
|
+
- [ ] every new cli command has `.snap` snapshots for stdout/stderr
|
|
84
|
+
- [ ] every new app screen has `.snap` snapshots for screenshots
|
|
85
|
+
- [ ] every new sdk method has `.snap` snapshots for responses
|
|
86
|
+
- [ ] each output variant is exercised (success, error, edge cases)
|
|
87
|
+
- [ ] snapshots demonstrate actual output, not just "it ran"
|
|
88
|
+
|
|
89
|
+
### snapshot change rationalization
|
|
90
|
+
|
|
91
|
+
for each `.snap` file changed, rationalize whether the change was intended or accidental:
|
|
92
|
+
|
|
93
|
+
| snap file | change type | intended? | rationale |
|
|
94
|
+
|-----------|-------------|-----------|-----------|
|
|
95
|
+
| {path.snap} | added / modified / deleted | yes / no | {why this change is correct} |
|
|
96
|
+
...
|
|
97
|
+
|
|
98
|
+
checklist:
|
|
99
|
+
- [ ] every `.snap` change has been reviewed
|
|
100
|
+
- [ ] intended changes have clear rationale
|
|
101
|
+
- [ ] accidental changes have been reverted or justified as improvements
|
|
74
102
|
|
|
75
103
|
### tests executed
|
|
76
104
|
- [ ] `npm run test` — passed
|
|
@@ -24,5 +24,36 @@ reviews:
|
|
|
24
24
|
- what inputs are unusual but valid?
|
|
25
25
|
- are boundaries tested?
|
|
26
26
|
|
|
27
|
+
- slug: has-acceptance-test-citations
|
|
28
|
+
say: |
|
|
29
|
+
coverage check: cite the acceptance test for each playtest step.
|
|
30
|
+
|
|
31
|
+
for each step in the playtest:
|
|
32
|
+
- which acceptance test file verifies this behavior?
|
|
33
|
+
- which specific test case (given/when/then) covers it?
|
|
34
|
+
- cite the exact file path and test name
|
|
35
|
+
|
|
36
|
+
if a step lacks acceptance test coverage:
|
|
37
|
+
- is this a gap that needs a new test?
|
|
38
|
+
- or is this behavior untestable via automation?
|
|
39
|
+
|
|
40
|
+
the playtest and acceptance tests should align. cite the proof.
|
|
41
|
+
|
|
42
|
+
- slug: has-self-run-verification
|
|
43
|
+
say: |
|
|
44
|
+
dogfood check: did you run the playtest yourself?
|
|
45
|
+
|
|
46
|
+
before you hand off to the foreman, run every step yourself:
|
|
47
|
+
- follow each instruction exactly as written
|
|
48
|
+
- verify each expected outcome matches reality
|
|
49
|
+
- note any friction, confusion, or absent context
|
|
50
|
+
|
|
51
|
+
if you found issues while you ran it:
|
|
52
|
+
- did you fix the instructions?
|
|
53
|
+
- did you update expected outcomes?
|
|
54
|
+
- is the playtest now accurate to what you observed?
|
|
55
|
+
|
|
56
|
+
the foreman deserves a playtest that works. prove it works by self-test first.
|
|
57
|
+
|
|
27
58
|
judges:
|
|
28
59
|
- npx rhachet run --repo bhrain --skill route.stone.judge --mechanism approved? --stone $stone --route $route
|
package/package.json
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
"name": "rhachet-roles-bhuild",
|
|
3
3
|
"author": "ehmpathy",
|
|
4
4
|
"description": "roles for building resilient systems, via rhachet",
|
|
5
|
-
"version": "0.14.
|
|
5
|
+
"version": "0.14.4",
|
|
6
6
|
"repository": "ehmpathy/rhachet-roles-bhuild",
|
|
7
7
|
"homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
|
|
8
8
|
"keywords": [
|
|
@@ -89,11 +89,11 @@
|
|
|
89
89
|
"esbuild-register": "3.6.0",
|
|
90
90
|
"husky": "8.0.3",
|
|
91
91
|
"jest": "30.2.0",
|
|
92
|
-
"rhachet": "1.37.
|
|
93
|
-
"rhachet-brains-anthropic": "0.
|
|
94
|
-
"rhachet-roles-bhrain": "0.
|
|
92
|
+
"rhachet": "1.37.17",
|
|
93
|
+
"rhachet-brains-anthropic": "0.4.0",
|
|
94
|
+
"rhachet-roles-bhrain": "0.20.2",
|
|
95
95
|
"rhachet-roles-bhuild": "link:.",
|
|
96
|
-
"rhachet-roles-ehmpathy": "1.
|
|
96
|
+
"rhachet-roles-ehmpathy": "1.29.1",
|
|
97
97
|
"tsc-alias": "1.8.10",
|
|
98
98
|
"tsx": "4.20.6",
|
|
99
99
|
"typescript": "5.4.5",
|