rhachet-roles-bhuild 0.13.2 → 0.13.3
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.
- package/dist/domain.operations/behavior/init/templates/3.3.blueprint.v1.guard.heavy +79 -12
- package/dist/domain.operations/behavior/init/templates/3.3.blueprint.v1.guard.light +79 -12
- package/dist/domain.operations/behavior/init/templates/5.1.execution.phase0_to_phaseN.v1.guard +79 -12
- package/package.json +1 -1
|
@@ -85,7 +85,78 @@ reviews:
|
|
|
85
85
|
|
|
86
86
|
expose weak points before they undermine us.
|
|
87
87
|
|
|
88
|
-
# 8.
|
|
88
|
+
# 8. minimalism - yagni
|
|
89
|
+
- slug: has-pruned-yagni
|
|
90
|
+
say: |
|
|
91
|
+
review for extras that were not prescribed.
|
|
92
|
+
|
|
93
|
+
YAGNI = "you ain't gonna need it"
|
|
94
|
+
|
|
95
|
+
for each component in the blueprint, ask:
|
|
96
|
+
- was this explicitly requested in the vision or criteria?
|
|
97
|
+
- is this the minimum viable way to satisfy the requirement?
|
|
98
|
+
- did we add abstraction "for future flexibility"?
|
|
99
|
+
- did we add features "while we're here"?
|
|
100
|
+
- did we optimize before we knew it was needed?
|
|
101
|
+
|
|
102
|
+
if a component was not requested, delete it or flag it as an open question
|
|
103
|
+
for the wisher to decide.
|
|
104
|
+
|
|
105
|
+
# 9. minimalism - backwards compat
|
|
106
|
+
- slug: has-pruned-backcompat
|
|
107
|
+
say: |
|
|
108
|
+
review for backwards compatibility that was not explicitly requested.
|
|
109
|
+
|
|
110
|
+
for each backwards-compat concern in the blueprint, ask:
|
|
111
|
+
- did the wisher explicitly say to maintain this compatibility?
|
|
112
|
+
- is there evidence this backwards compat is needed?
|
|
113
|
+
- or did we assume it "to be safe"?
|
|
114
|
+
|
|
115
|
+
if backwards compat was not explicitly requested:
|
|
116
|
+
1. flag it as an open question for the wisher
|
|
117
|
+
2. eliminate it if not confirmed as required
|
|
118
|
+
3. make the open question very clearly reported
|
|
119
|
+
|
|
120
|
+
# 10. consistency - mechanisms
|
|
121
|
+
- slug: has-consistent-mechanisms
|
|
122
|
+
say: |
|
|
123
|
+
review for new mechanisms that duplicate extant functionality.
|
|
124
|
+
|
|
125
|
+
unless the ask was to refactor, be consistent with extant mechanisms.
|
|
126
|
+
|
|
127
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
128
|
+
research stone). look for extant utilities, helpers, and patterns.
|
|
129
|
+
|
|
130
|
+
then for each new mechanism in the blueprint, ask:
|
|
131
|
+
- does the codebase already have a mechanism that does this?
|
|
132
|
+
- do we duplicate extant utilities, helpers, or patterns?
|
|
133
|
+
- could we reuse an extant component instead of a new one?
|
|
134
|
+
|
|
135
|
+
if a new mechanism duplicates extant functionality:
|
|
136
|
+
1. replace with the extant mechanism
|
|
137
|
+
2. or flag as an open question if unsure
|
|
138
|
+
|
|
139
|
+
# 11. consistency - conventions
|
|
140
|
+
- slug: has-consistent-conventions
|
|
141
|
+
say: |
|
|
142
|
+
review for divergence from extant names and patterns.
|
|
143
|
+
|
|
144
|
+
unless the ask was to refactor, be consistent with extant conventions.
|
|
145
|
+
|
|
146
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
147
|
+
research stone). identify extant name conventions and patterns.
|
|
148
|
+
|
|
149
|
+
then for each name choice in the blueprint, ask:
|
|
150
|
+
- what name conventions does the codebase use?
|
|
151
|
+
- do we use a different namespace, prefix, or suffix pattern?
|
|
152
|
+
- do we introduce new terms when extant terms exist?
|
|
153
|
+
- does our structure match extant patterns?
|
|
154
|
+
|
|
155
|
+
if we diverge from extant conventions:
|
|
156
|
+
1. align with the extant convention
|
|
157
|
+
2. or flag as an open question if the extant convention seems wrong
|
|
158
|
+
|
|
159
|
+
# 12. behavior declaration - coverage
|
|
89
160
|
- slug: has-behavior-declaration-coverage
|
|
90
161
|
say: |
|
|
91
162
|
review for coverage of the behavior declaration.
|
|
@@ -100,10 +171,9 @@ reviews:
|
|
|
100
171
|
- is every criterion from the criteria satisfied?
|
|
101
172
|
- did the junior skip or forget any part of the spec?
|
|
102
173
|
|
|
103
|
-
|
|
104
|
-
then fix all gaps before you continue.
|
|
174
|
+
fix all gaps before you continue.
|
|
105
175
|
|
|
106
|
-
#
|
|
176
|
+
# 13. behavior declaration - adherance
|
|
107
177
|
- slug: has-behavior-declaration-adherance
|
|
108
178
|
say: |
|
|
109
179
|
review for adherance to the behavior declaration.
|
|
@@ -118,10 +188,9 @@ reviews:
|
|
|
118
188
|
- does the blueprint satisfy the criteria correctly?
|
|
119
189
|
- did the junior misinterpret or deviate from the spec?
|
|
120
190
|
|
|
121
|
-
|
|
122
|
-
then fix all gaps before you continue.
|
|
191
|
+
fix all gaps before you continue.
|
|
123
192
|
|
|
124
|
-
#
|
|
193
|
+
# 14. role standards - adherance
|
|
125
194
|
- slug: has-role-standards-adherance
|
|
126
195
|
say: |
|
|
127
196
|
review for adherance to mechanic role standards.
|
|
@@ -139,10 +208,9 @@ reviews:
|
|
|
139
208
|
- are there violations of required patterns?
|
|
140
209
|
- did the junior introduce anti-patterns, bad practices, or deviations from our conventions?
|
|
141
210
|
|
|
142
|
-
|
|
143
|
-
then fix all gaps before you continue.
|
|
211
|
+
fix all gaps before you continue.
|
|
144
212
|
|
|
145
|
-
#
|
|
213
|
+
# 15. role standards - coverage
|
|
146
214
|
- slug: has-role-standards-coverage
|
|
147
215
|
say: |
|
|
148
216
|
review for coverage of mechanic role standards.
|
|
@@ -160,8 +228,7 @@ reviews:
|
|
|
160
228
|
- are there patterns that should be present but are absent?
|
|
161
229
|
- did the junior forget to include error handle, validation, tests, types, or other required practices?
|
|
162
230
|
|
|
163
|
-
|
|
164
|
-
then fix all gaps before you continue.
|
|
231
|
+
fix all gaps before you continue.
|
|
165
232
|
|
|
166
233
|
peer:
|
|
167
234
|
- bash -c ". .agent/repo=.this/role=any/skills/use.apikeys.sh && npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.prod/pitofsuccess.errors/rule.*.md' --diffs since-main --paths-with '$route/3.3.blueprint.*.md' --join intersect --output '$route/.reviews/$stone.peer-review.failhides.md' --mode hard 2>&1"
|
|
@@ -33,7 +33,78 @@ reviews:
|
|
|
33
33
|
|
|
34
34
|
surface all technical assumptions and question each one.
|
|
35
35
|
|
|
36
|
-
# 3.
|
|
36
|
+
# 3. minimalism - yagni
|
|
37
|
+
- slug: has-pruned-yagni
|
|
38
|
+
say: |
|
|
39
|
+
review for extras that were not prescribed.
|
|
40
|
+
|
|
41
|
+
YAGNI = "you ain't gonna need it"
|
|
42
|
+
|
|
43
|
+
for each component in the blueprint, ask:
|
|
44
|
+
- was this explicitly requested in the vision or criteria?
|
|
45
|
+
- is this the minimum viable way to satisfy the requirement?
|
|
46
|
+
- did we add abstraction "for future flexibility"?
|
|
47
|
+
- did we add features "while we're here"?
|
|
48
|
+
- did we optimize before we knew it was needed?
|
|
49
|
+
|
|
50
|
+
if a component was not requested, delete it or flag it as an open question
|
|
51
|
+
for the wisher to decide.
|
|
52
|
+
|
|
53
|
+
# 4. minimalism - backwards compat
|
|
54
|
+
- slug: has-pruned-backcompat
|
|
55
|
+
say: |
|
|
56
|
+
review for backwards compatibility that was not explicitly requested.
|
|
57
|
+
|
|
58
|
+
for each backwards-compat concern in the blueprint, ask:
|
|
59
|
+
- did the wisher explicitly say to maintain this compatibility?
|
|
60
|
+
- is there evidence this backwards compat is needed?
|
|
61
|
+
- or did we assume it "to be safe"?
|
|
62
|
+
|
|
63
|
+
if backwards compat was not explicitly requested:
|
|
64
|
+
1. flag it as an open question for the wisher
|
|
65
|
+
2. eliminate it if not confirmed as required
|
|
66
|
+
3. make the open question very clearly reported
|
|
67
|
+
|
|
68
|
+
# 5. consistency - mechanisms
|
|
69
|
+
- slug: has-consistent-mechanisms
|
|
70
|
+
say: |
|
|
71
|
+
review for new mechanisms that duplicate extant functionality.
|
|
72
|
+
|
|
73
|
+
unless the ask was to refactor, be consistent with extant mechanisms.
|
|
74
|
+
|
|
75
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
76
|
+
research stone). look for extant utilities, helpers, and patterns.
|
|
77
|
+
|
|
78
|
+
then for each new mechanism in the blueprint, ask:
|
|
79
|
+
- does the codebase already have a mechanism that does this?
|
|
80
|
+
- do we duplicate extant utilities, helpers, or patterns?
|
|
81
|
+
- could we reuse an extant component instead of a new one?
|
|
82
|
+
|
|
83
|
+
if a new mechanism duplicates extant functionality:
|
|
84
|
+
1. replace with the extant mechanism
|
|
85
|
+
2. or flag as an open question if unsure
|
|
86
|
+
|
|
87
|
+
# 6. consistency - conventions
|
|
88
|
+
- slug: has-consistent-conventions
|
|
89
|
+
say: |
|
|
90
|
+
review for divergence from extant names and patterns.
|
|
91
|
+
|
|
92
|
+
unless the ask was to refactor, be consistent with extant conventions.
|
|
93
|
+
|
|
94
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
95
|
+
research stone). identify extant name conventions and patterns.
|
|
96
|
+
|
|
97
|
+
then for each name choice in the blueprint, ask:
|
|
98
|
+
- what name conventions does the codebase use?
|
|
99
|
+
- do we use a different namespace, prefix, or suffix pattern?
|
|
100
|
+
- do we introduce new terms when extant terms exist?
|
|
101
|
+
- does our structure match extant patterns?
|
|
102
|
+
|
|
103
|
+
if we diverge from extant conventions:
|
|
104
|
+
1. align with the extant convention
|
|
105
|
+
2. or flag as an open question if the extant convention seems wrong
|
|
106
|
+
|
|
107
|
+
# 7. behavior declaration - coverage
|
|
37
108
|
- slug: has-behavior-declaration-coverage
|
|
38
109
|
say: |
|
|
39
110
|
review for coverage of the behavior declaration.
|
|
@@ -48,10 +119,9 @@ reviews:
|
|
|
48
119
|
- is every criterion from the criteria satisfied?
|
|
49
120
|
- did the junior skip or forget any part of the spec?
|
|
50
121
|
|
|
51
|
-
|
|
52
|
-
then fix all gaps before you continue.
|
|
122
|
+
fix all gaps before you continue.
|
|
53
123
|
|
|
54
|
-
#
|
|
124
|
+
# 8. behavior declaration - adherance
|
|
55
125
|
- slug: has-behavior-declaration-adherance
|
|
56
126
|
say: |
|
|
57
127
|
review for adherance to the behavior declaration.
|
|
@@ -66,10 +136,9 @@ reviews:
|
|
|
66
136
|
- does the blueprint satisfy the criteria correctly?
|
|
67
137
|
- did the junior misinterpret or deviate from the spec?
|
|
68
138
|
|
|
69
|
-
|
|
70
|
-
then fix all gaps before you continue.
|
|
139
|
+
fix all gaps before you continue.
|
|
71
140
|
|
|
72
|
-
#
|
|
141
|
+
# 9. role standards - adherance
|
|
73
142
|
- slug: has-role-standards-adherance
|
|
74
143
|
say: |
|
|
75
144
|
review for adherance to mechanic role standards.
|
|
@@ -87,10 +156,9 @@ reviews:
|
|
|
87
156
|
- are there violations of required patterns?
|
|
88
157
|
- did the junior introduce anti-patterns, bad practices, or deviations from our conventions?
|
|
89
158
|
|
|
90
|
-
|
|
91
|
-
then fix all gaps before you continue.
|
|
159
|
+
fix all gaps before you continue.
|
|
92
160
|
|
|
93
|
-
#
|
|
161
|
+
# 10. role standards - coverage
|
|
94
162
|
- slug: has-role-standards-coverage
|
|
95
163
|
say: |
|
|
96
164
|
review for coverage of mechanic role standards.
|
|
@@ -108,8 +176,7 @@ reviews:
|
|
|
108
176
|
- are there patterns that should be present but are absent?
|
|
109
177
|
- did the junior forget to include error handle, validation, tests, types, or other required practices?
|
|
110
178
|
|
|
111
|
-
|
|
112
|
-
then fix all gaps before you continue.
|
|
179
|
+
fix all gaps before you continue.
|
|
113
180
|
|
|
114
181
|
peer:
|
|
115
182
|
- bash -c ". .agent/repo=.this/role=any/skills/use.apikeys.sh && npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.prod/pitofsuccess.errors/rule.*.md' --diffs since-main --paths-with '$route/3.3.blueprint.*.md' --join intersect --output '$route/.reviews/$stone.peer-review.failhides.md' --mode hard 2>&1"
|
package/dist/domain.operations/behavior/init/templates/5.1.execution.phase0_to_phaseN.v1.guard
CHANGED
|
@@ -3,7 +3,78 @@
|
|
|
3
3
|
|
|
4
4
|
reviews:
|
|
5
5
|
self:
|
|
6
|
-
# 1.
|
|
6
|
+
# 1. minimalism - yagni
|
|
7
|
+
- slug: has-pruned-yagni
|
|
8
|
+
say: |
|
|
9
|
+
review for extras that were not prescribed.
|
|
10
|
+
|
|
11
|
+
YAGNI = "you ain't gonna need it"
|
|
12
|
+
|
|
13
|
+
for each component in the code, ask:
|
|
14
|
+
- was this explicitly requested in the vision or criteria?
|
|
15
|
+
- is this the minimum viable way to satisfy the requirement?
|
|
16
|
+
- did we add abstraction "for future flexibility"?
|
|
17
|
+
- did we add features "while we're here"?
|
|
18
|
+
- did we optimize before we knew it was needed?
|
|
19
|
+
|
|
20
|
+
if a component was not requested, delete it or flag it as an open question
|
|
21
|
+
for the wisher to decide.
|
|
22
|
+
|
|
23
|
+
# 2. minimalism - backwards compat
|
|
24
|
+
- slug: has-pruned-backcompat
|
|
25
|
+
say: |
|
|
26
|
+
review for backwards compatibility that was not explicitly requested.
|
|
27
|
+
|
|
28
|
+
for each backwards-compat concern in the code, ask:
|
|
29
|
+
- did the wisher explicitly say to maintain this compatibility?
|
|
30
|
+
- is there evidence this backwards compat is needed?
|
|
31
|
+
- or did we assume it "to be safe"?
|
|
32
|
+
|
|
33
|
+
if backwards compat was not explicitly requested:
|
|
34
|
+
1. flag it as an open question for the wisher
|
|
35
|
+
2. eliminate it if not confirmed as required
|
|
36
|
+
3. make the open question very clearly reported
|
|
37
|
+
|
|
38
|
+
# 3. consistency - mechanisms
|
|
39
|
+
- slug: has-consistent-mechanisms
|
|
40
|
+
say: |
|
|
41
|
+
review for new mechanisms that duplicate extant functionality.
|
|
42
|
+
|
|
43
|
+
unless the ask was to refactor, be consistent with extant mechanisms.
|
|
44
|
+
|
|
45
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
46
|
+
research stone). look for extant utilities, helpers, and patterns.
|
|
47
|
+
|
|
48
|
+
then for each new mechanism in the code, ask:
|
|
49
|
+
- does the codebase already have a mechanism that does this?
|
|
50
|
+
- do we duplicate extant utilities, helpers, or patterns?
|
|
51
|
+
- could we reuse an extant component instead of a new one?
|
|
52
|
+
|
|
53
|
+
if a new mechanism duplicates extant functionality:
|
|
54
|
+
1. replace with the extant mechanism
|
|
55
|
+
2. or flag as an open question if unsure
|
|
56
|
+
|
|
57
|
+
# 4. consistency - conventions
|
|
58
|
+
- slug: has-consistent-conventions
|
|
59
|
+
say: |
|
|
60
|
+
review for divergence from extant names and patterns.
|
|
61
|
+
|
|
62
|
+
unless the ask was to refactor, be consistent with extant conventions.
|
|
63
|
+
|
|
64
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
65
|
+
research stone). identify extant name conventions and patterns.
|
|
66
|
+
|
|
67
|
+
then for each name choice in the code, ask:
|
|
68
|
+
- what name conventions does the codebase use?
|
|
69
|
+
- do we use a different namespace, prefix, or suffix pattern?
|
|
70
|
+
- do we introduce new terms when extant terms exist?
|
|
71
|
+
- does our structure match extant patterns?
|
|
72
|
+
|
|
73
|
+
if we diverge from extant conventions:
|
|
74
|
+
1. align with the extant convention
|
|
75
|
+
2. or flag as an open question if the extant convention seems wrong
|
|
76
|
+
|
|
77
|
+
# 5. review against behavior declaration - coverage
|
|
7
78
|
- slug: behavior-declaration-coverage
|
|
8
79
|
say: |
|
|
9
80
|
review for coverage of the behavior declaration.
|
|
@@ -19,10 +90,9 @@ reviews:
|
|
|
19
90
|
- is every component from the blueprint implemented?
|
|
20
91
|
- did the junior skip or forget any part of the spec?
|
|
21
92
|
|
|
22
|
-
|
|
23
|
-
then fix all gaps before you continue.
|
|
93
|
+
fix all gaps before you continue.
|
|
24
94
|
|
|
25
|
-
#
|
|
95
|
+
# 6. review against behavior declaration - adherance
|
|
26
96
|
- slug: behavior-declaration-adherance
|
|
27
97
|
say: |
|
|
28
98
|
review for adherance to the behavior declaration.
|
|
@@ -38,10 +108,9 @@ reviews:
|
|
|
38
108
|
- does the implementation follow the blueprint accurately?
|
|
39
109
|
- did the junior misinterpret or deviate from the spec?
|
|
40
110
|
|
|
41
|
-
|
|
42
|
-
then fix all gaps before you continue.
|
|
111
|
+
fix all gaps before you continue.
|
|
43
112
|
|
|
44
|
-
#
|
|
113
|
+
# 7. review against role standards - adherance
|
|
45
114
|
- slug: role-standards-adherance
|
|
46
115
|
say: |
|
|
47
116
|
review for adherance to mechanic role standards.
|
|
@@ -59,10 +128,9 @@ reviews:
|
|
|
59
128
|
- are there violations of required patterns?
|
|
60
129
|
- did the junior introduce anti-patterns, bad practices, or deviations from our conventions?
|
|
61
130
|
|
|
62
|
-
|
|
63
|
-
then fix all gaps before you continue.
|
|
131
|
+
fix all gaps before you continue.
|
|
64
132
|
|
|
65
|
-
#
|
|
133
|
+
# 8. review against role standards - coverage
|
|
66
134
|
- slug: role-standards-coverage
|
|
67
135
|
say: |
|
|
68
136
|
review for coverage of mechanic role standards.
|
|
@@ -80,8 +148,7 @@ reviews:
|
|
|
80
148
|
- are there patterns that should be present but are absent?
|
|
81
149
|
- did the junior forget to add error handle, validation, tests, types, or other required practices?
|
|
82
150
|
|
|
83
|
-
|
|
84
|
-
then fix all gaps before you continue.
|
|
151
|
+
fix all gaps before you continue.
|
|
85
152
|
|
|
86
153
|
peer:
|
|
87
154
|
- bash -c ". .agent/repo=.this/role=any/skills/use.apikeys.sh && npx rhachet run --repo bhrain --skill review --rules '.agent/repo=ehmpathy/role=mechanic/briefs/practices/code.prod/pitofsuccess.errors/rule.*.md' --diffs since-main --paths-with 'src/**/*.ts' --join intersect --output '$route/.reviews/$stone.peer-review.failhides.md' --mode hard 2>&1"
|
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.13.
|
|
5
|
+
"version": "0.13.3",
|
|
6
6
|
"repository": "ehmpathy/rhachet-roles-bhuild",
|
|
7
7
|
"homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
|
|
8
8
|
"keywords": [
|