rhachet-roles-bhuild 0.15.2 → 0.15.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.
- package/dist/domain.operations/behavior/init/getAllTemplatesBySize.d.ts +9 -2
- package/dist/domain.operations/behavior/init/getAllTemplatesBySize.js +23 -8
- package/dist/domain.operations/behavior/init/getAllTemplatesBySize.js.map +1 -1
- package/dist/domain.operations/behavior/init/templates/5.1.execution.from_vision.v1.guard +159 -0
- package/dist/domain.operations/behavior/init/templates/5.1.execution.from_vision.v1.stone +15 -0
- package/dist/domain.operations/behavior/init/templates/5.3.verification.v1.guard +58 -16
- package/dist/domain.operations/behavior/init/templates/5.3.verification.v1.stone +70 -3
- package/dist/domain.operations/behavior/init/templates/5.5.playtest.v1.guard +23 -3
- package/dist/domain.operations/behavior/init/templates/5.5.playtest.v1.stone +14 -1
- package/dist/domain.roles/behaver/briefs/practices/behavior.verification/philosophy.verification-strictness.md +98 -0
- package/dist/domain.roles/behaver/briefs/practices/behavior.verification/rule.require.contract-snapshot-exhaustiveness.md +51 -0
- package/dist/domain.roles/behaver/briefs/practices/behavior.verification/rule.require.external-contract-integration-tests.md +52 -0
- package/package.json +1 -1
|
@@ -18,23 +18,28 @@
|
|
|
18
18
|
declare const BEHAVIOR_SIZE_CONFIG: {
|
|
19
19
|
readonly nano: {
|
|
20
20
|
readonly order: 0;
|
|
21
|
-
readonly adds: readonly ["0.wish.md", "refs/template.[feedback].v1.[given].by_human.md", "1.vision.stone", "1.vision.guard", "
|
|
21
|
+
readonly adds: readonly ["0.wish.md", "refs/template.[feedback].v1.[given].by_human.md", "1.vision.stone", "1.vision.guard", "5.1.execution.from_vision.v1.stone", "5.1.execution.from_vision.v1.guard", "5.3.verification.v1.stone", "5.3.verification.v1.guard"];
|
|
22
|
+
readonly dels: readonly [];
|
|
22
23
|
};
|
|
23
24
|
readonly mini: {
|
|
24
25
|
readonly order: 1;
|
|
25
|
-
readonly adds: readonly ["2.1.criteria.blackbox.stone", "2.1.criteria.blackbox.guard", "2.2.criteria.blackbox.matrix.stone", "3.1.3.research.internal.product.code.prod._.v1.stone", "3.1.3.research.internal.product.code.test._.v1.stone", "
|
|
26
|
+
readonly adds: readonly ["2.1.criteria.blackbox.stone", "2.1.criteria.blackbox.guard", "2.2.criteria.blackbox.matrix.stone", "3.1.3.research.internal.product.code.prod._.v1.stone", "3.1.3.research.internal.product.code.test._.v1.stone", "3.3.1.blueprint.product.v1.stone", "3.3.1.blueprint.product.v1.guard", "4.1.roadmap.v1.stone", "5.1.execution.phase0_to_phaseN.v1.stone", "5.1.execution.phase0_to_phaseN.v1.guard"];
|
|
27
|
+
readonly dels: readonly ["5.1.execution.from_vision.v1.stone", "5.1.execution.from_vision.v1.guard"];
|
|
26
28
|
};
|
|
27
29
|
readonly medi: {
|
|
28
30
|
readonly order: 2;
|
|
29
31
|
readonly adds: readonly ["2.3.criteria.blueprint.stone", "3.1.1.research.external.product.access._.v1.stone", "3.1.1.research.external.product.claims._.v1.stone", "3.1.5.research.reflection.product.premortem._.v1.stone", "3.1.5.research.reflection.product.rootcause._.v1.stone", "3.1.5.research.reflection.product.audience._.v1.stone", "3.2.distill.repros.experience._.v1.stone", "3.2.distill.repros.experience._.v1.guard", "5.2.evaluation.v1.stone", "5.2.evaluation.v1.guard", "5.5.playtest.v1.stone", "5.5.playtest.v1.guard"];
|
|
32
|
+
readonly dels: readonly [];
|
|
30
33
|
};
|
|
31
34
|
readonly mega: {
|
|
32
35
|
readonly order: 3;
|
|
33
36
|
readonly adds: readonly ["3.1.1.research.external.product.domain._.v1.stone", "3.1.1.research.external.product.domain.terms.v1.stone", "3.1.1.research.external.product.references._.v1.stone", "3.1.2.research.external.factory.testloops._.v1.stone", "3.1.2.research.external.factory.oss.levers._.v1.stone", "3.1.2.research.external.factory.templates._.v1.stone", "3.1.4.research.internal.factory.blockers._.v1.stone", "3.1.4.research.internal.factory.opports._.v1.stone", "3.2.distill.domain._.v1.stone", "3.2.distill.domain._.v1.guard", "3.2.distill.factory.upgrades._.v1.stone", "3.3.0.blueprint.factory.v1.stone"];
|
|
37
|
+
readonly dels: readonly [];
|
|
34
38
|
};
|
|
35
39
|
readonly giga: {
|
|
36
40
|
readonly order: 4;
|
|
37
41
|
readonly adds: readonly [];
|
|
42
|
+
readonly dels: readonly [];
|
|
38
43
|
};
|
|
39
44
|
};
|
|
40
45
|
export type BehaviorSizeLevel = keyof typeof BEHAVIOR_SIZE_CONFIG;
|
|
@@ -43,6 +48,8 @@ declare const BEHAVIOR_SIZE_ORDER: ("nano" | "mini" | "medi" | "mega" | "giga")[
|
|
|
43
48
|
* .what = get all templates for a given size level (cumulative)
|
|
44
49
|
*
|
|
45
50
|
* .why = sizes are additive: mini = nano + mini adds, medi = nano + mini + medi adds, etc.
|
|
51
|
+
* dels allow larger sizes to replace smaller size templates (e.g., mini replaces
|
|
52
|
+
* nano's from_vision execution with phased execution)
|
|
46
53
|
*/
|
|
47
54
|
export declare const getAllTemplatesBySize: (input: {
|
|
48
55
|
size: BehaviorSizeLevel;
|
|
@@ -26,12 +26,12 @@ const BEHAVIOR_SIZE_CONFIG = {
|
|
|
26
26
|
'refs/template.[feedback].v1.[given].by_human.md',
|
|
27
27
|
'1.vision.stone',
|
|
28
28
|
'1.vision.guard', // .light or .heavy variant
|
|
29
|
-
'
|
|
30
|
-
'
|
|
31
|
-
'
|
|
32
|
-
'5.
|
|
33
|
-
'5.1.execution.phase0_to_phaseN.v1.guard',
|
|
29
|
+
'5.1.execution.from_vision.v1.stone', // vision → done (no blueprint/roadmap)
|
|
30
|
+
'5.1.execution.from_vision.v1.guard',
|
|
31
|
+
'5.3.verification.v1.stone', // tests should never be forgotten
|
|
32
|
+
'5.3.verification.v1.guard',
|
|
34
33
|
],
|
|
34
|
+
dels: [],
|
|
35
35
|
},
|
|
36
36
|
mini: {
|
|
37
37
|
order: 1,
|
|
@@ -41,8 +41,15 @@ const BEHAVIOR_SIZE_CONFIG = {
|
|
|
41
41
|
'2.2.criteria.blackbox.matrix.stone',
|
|
42
42
|
'3.1.3.research.internal.product.code.prod._.v1.stone',
|
|
43
43
|
'3.1.3.research.internal.product.code.test._.v1.stone',
|
|
44
|
-
'
|
|
45
|
-
'
|
|
44
|
+
'3.3.1.blueprint.product.v1.stone',
|
|
45
|
+
'3.3.1.blueprint.product.v1.guard', // .light or .heavy variant
|
|
46
|
+
'4.1.roadmap.v1.stone',
|
|
47
|
+
'5.1.execution.phase0_to_phaseN.v1.stone', // roadmap → phased execution
|
|
48
|
+
'5.1.execution.phase0_to_phaseN.v1.guard',
|
|
49
|
+
],
|
|
50
|
+
dels: [
|
|
51
|
+
'5.1.execution.from_vision.v1.stone', // replaced by phased version
|
|
52
|
+
'5.1.execution.from_vision.v1.guard',
|
|
46
53
|
],
|
|
47
54
|
},
|
|
48
55
|
medi: {
|
|
@@ -61,6 +68,7 @@ const BEHAVIOR_SIZE_CONFIG = {
|
|
|
61
68
|
'5.5.playtest.v1.stone',
|
|
62
69
|
'5.5.playtest.v1.guard',
|
|
63
70
|
],
|
|
71
|
+
dels: [],
|
|
64
72
|
},
|
|
65
73
|
mega: {
|
|
66
74
|
order: 3,
|
|
@@ -78,10 +86,12 @@ const BEHAVIOR_SIZE_CONFIG = {
|
|
|
78
86
|
'3.2.distill.factory.upgrades._.v1.stone',
|
|
79
87
|
'3.3.0.blueprint.factory.v1.stone',
|
|
80
88
|
],
|
|
89
|
+
dels: [],
|
|
81
90
|
},
|
|
82
91
|
giga: {
|
|
83
92
|
order: 4,
|
|
84
93
|
adds: [], // same as mega; reserved for future decomposition subroutes
|
|
94
|
+
dels: [],
|
|
85
95
|
},
|
|
86
96
|
};
|
|
87
97
|
exports.BEHAVIOR_SIZE_CONFIG = BEHAVIOR_SIZE_CONFIG;
|
|
@@ -92,10 +102,15 @@ exports.BEHAVIOR_SIZE_ORDER = BEHAVIOR_SIZE_ORDER;
|
|
|
92
102
|
* .what = get all templates for a given size level (cumulative)
|
|
93
103
|
*
|
|
94
104
|
* .why = sizes are additive: mini = nano + mini adds, medi = nano + mini + medi adds, etc.
|
|
105
|
+
* dels allow larger sizes to replace smaller size templates (e.g., mini replaces
|
|
106
|
+
* nano's from_vision execution with phased execution)
|
|
95
107
|
*/
|
|
96
108
|
const getAllTemplatesBySize = (input) => {
|
|
97
109
|
const index = BEHAVIOR_SIZE_ORDER.indexOf(input.size);
|
|
98
|
-
|
|
110
|
+
const sizesUpTo = BEHAVIOR_SIZE_ORDER.slice(0, index + 1);
|
|
111
|
+
const adds = sizesUpTo.flatMap((s) => BEHAVIOR_SIZE_CONFIG[s].adds);
|
|
112
|
+
const dels = sizesUpTo.flatMap((s) => BEHAVIOR_SIZE_CONFIG[s].dels);
|
|
113
|
+
return adds.filter((t) => !dels.includes(t));
|
|
99
114
|
};
|
|
100
115
|
exports.getAllTemplatesBySize = getAllTemplatesBySize;
|
|
101
116
|
/**
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"getAllTemplatesBySize.js","sourceRoot":"","sources":["../../../../src/domain.operations/behavior/init/getAllTemplatesBySize.ts"],"names":[],"mappings":";AAAA;;;;;GAKG;;;AAEH;;;;;;;;;;GAUG;AACH,MAAM,oBAAoB,GAAG;IAC3B,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE;YACJ,WAAW;YACX,iDAAiD;YACjD,gBAAgB;YAChB,gBAAgB,EAAE,2BAA2B;YAC7C,
|
|
1
|
+
{"version":3,"file":"getAllTemplatesBySize.js","sourceRoot":"","sources":["../../../../src/domain.operations/behavior/init/getAllTemplatesBySize.ts"],"names":[],"mappings":";AAAA;;;;;GAKG;;;AAEH;;;;;;;;;;GAUG;AACH,MAAM,oBAAoB,GAAG;IAC3B,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE;YACJ,WAAW;YACX,iDAAiD;YACjD,gBAAgB;YAChB,gBAAgB,EAAE,2BAA2B;YAC7C,oCAAoC,EAAE,uCAAuC;YAC7E,oCAAoC;YACpC,2BAA2B,EAAE,kCAAkC;YAC/D,2BAA2B;SAC5B;QACD,IAAI,EAAE,EAAE;KACT;IACD,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE;YACJ,6BAA6B;YAC7B,6BAA6B,EAAE,4CAA4C;YAC3E,oCAAoC;YACpC,sDAAsD;YACtD,sDAAsD;YACtD,kCAAkC;YAClC,kCAAkC,EAAE,2BAA2B;YAC/D,sBAAsB;YACtB,yCAAyC,EAAE,6BAA6B;YACxE,yCAAyC;SAC1C;QACD,IAAI,EAAE;YACJ,oCAAoC,EAAE,6BAA6B;YACnE,oCAAoC;SACrC;KACF;IACD,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE;YACJ,8BAA8B;YAC9B,mDAAmD;YACnD,mDAAmD;YACnD,wDAAwD;YACxD,wDAAwD;YACxD,uDAAuD;YACvD,0CAA0C;YAC1C,0CAA0C;YAC1C,yBAAyB;YACzB,yBAAyB;YACzB,uBAAuB;YACvB,uBAAuB;SACxB;QACD,IAAI,EAAE,EAAE;KACT;IACD,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE;YACJ,mDAAmD;YACnD,uDAAuD;YACvD,uDAAuD;YACvD,sDAAsD;YACtD,uDAAuD;YACvD,sDAAsD;YACtD,qDAAqD;YACrD,oDAAoD;YACpD,+BAA+B;YAC/B,+BAA+B;YAC/B,yCAAyC;YACzC,kCAAkC;SACnC;QACD,IAAI,EAAE,EAAE;KACT;IACD,IAAI,EAAE;QACJ,KAAK,EAAE,CAAC;QACR,IAAI,EAAE,EAAE,EAAE,4DAA4D;QACtE,IAAI,EAAE,EAAE;KACT;CAIF,CAAC;AA2DO,oDAAoB;AAtD7B,4DAA4D;AAC5D,MAAM,mBAAmB,GACvB,MAAM,CAAC,IAAI,CAAC,oBAAoB,CACjC,CAAC,IAAI,CAAC,CAAC,CAAC,EAAE,CAAC,EAAE,EAAE,CAAC,oBAAoB,CAAC,CAAC,CAAC,CAAC,KAAK,GAAG,oBAAoB,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC;AAmDjD,kDAAmB;AAjDlD;;;;;;GAMG;AACI,MAAM,qBAAqB,GAAG,CAAC,KAErC,EAAY,EAAE;IACb,MAAM,KAAK,GAAG,mBAAmB,CAAC,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IACtD,MAAM,SAAS,GAAG,mBAAmB,CAAC,KAAK,CAAC,CAAC,EAAE,KAAK,GAAG,CAAC,CAAC,CAAC;IAE1D,MAAM,IAAI,GAAG,SAAS,CAAC,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,oBAAoB,CAAC,CAAC,CAAC,CAAC,IAAI,CAAC,CAAC;IACpE,MAAM,IAAI,GAAsB,SAAS,CAAC,OAAO,CAC/C,CAAC,CAAC,EAAE,EAAE,CAAC,oBAAoB,CAAC,CAAC,CAAC,CAAC,IAAI,CACpC,CAAC;IAEF,OAAO,IAAI,CAAC,MAAM,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC,IAAI,CAAC,QAAQ,CAAC,CAAC,CAAC,CAAC,CAAC;AAC/C,CAAC,CAAC;AAZW,QAAA,qBAAqB,yBAYhC;AAEF;;;;;;GAMG;AACI,MAAM,gBAAgB,GAAG,CAAC,KAGhC,EAAW,EAAE;IACZ,MAAM,SAAS,GAAG,IAAA,6BAAqB,EAAC,EAAE,IAAI,EAAE,KAAK,CAAC,IAAI,EAAE,CAAC,CAAC;IAE9D,eAAe;IACf,IAAI,SAAS,CAAC,QAAQ,CAAC,KAAK,CAAC,YAAY,CAAC,EAAE,CAAC;QAC3C,OAAO,IAAI,CAAC;IACd,CAAC;IAED,wFAAwF;IACxF,MAAM,QAAQ,GAAG,KAAK,CAAC,YAAY,CAAC,OAAO,CAAC,kBAAkB,EAAE,EAAE,CAAC,CAAC;IACpE,IAAI,QAAQ,KAAK,KAAK,CAAC,YAAY,IAAI,SAAS,CAAC,QAAQ,CAAC,QAAQ,CAAC,EAAE,CAAC;QACpE,OAAO,IAAI,CAAC;IACd,CAAC;IAED,OAAO,KAAK,CAAC;AACf,CAAC,CAAC;AAlBW,QAAA,gBAAgB,oBAkB3B"}
|
|
@@ -0,0 +1,159 @@
|
|
|
1
|
+
# guard for execution stone (from vision - nano size)
|
|
2
|
+
# includes standardized self-review frame
|
|
3
|
+
|
|
4
|
+
artifacts:
|
|
5
|
+
# track execution progress
|
|
6
|
+
- "$route/5.1.execution.from_vision.v1.i1.md"
|
|
7
|
+
# track actual implementation in src/
|
|
8
|
+
- "src/**/*"
|
|
9
|
+
|
|
10
|
+
reviews:
|
|
11
|
+
self:
|
|
12
|
+
# 1. minimalism - yagni
|
|
13
|
+
- slug: has-pruned-yagni
|
|
14
|
+
say: |
|
|
15
|
+
review for extras that were not prescribed.
|
|
16
|
+
|
|
17
|
+
YAGNI = "you ain't gonna need it"
|
|
18
|
+
|
|
19
|
+
for each component in the code, ask:
|
|
20
|
+
- was this explicitly requested in the vision or criteria?
|
|
21
|
+
- is this the minimum viable way to satisfy the requirement?
|
|
22
|
+
- did we add abstraction "for future flexibility"?
|
|
23
|
+
- did we add features "while we're here"?
|
|
24
|
+
- did we optimize before we knew it was needed?
|
|
25
|
+
|
|
26
|
+
if a component was not requested, delete it or flag it as an open question
|
|
27
|
+
for the wisher to decide.
|
|
28
|
+
|
|
29
|
+
# 2. minimalism - backwards compat
|
|
30
|
+
- slug: has-pruned-backcompat
|
|
31
|
+
say: |
|
|
32
|
+
review for backwards compatibility that was not explicitly requested.
|
|
33
|
+
|
|
34
|
+
for each backwards-compat concern in the code, ask:
|
|
35
|
+
- did the wisher explicitly say to maintain this compatibility?
|
|
36
|
+
- is there evidence this backwards compat is needed?
|
|
37
|
+
- or did we assume it "to be safe"?
|
|
38
|
+
|
|
39
|
+
if backwards compat was not explicitly requested:
|
|
40
|
+
1. flag it as an open question for the wisher
|
|
41
|
+
2. eliminate it if not confirmed as required
|
|
42
|
+
3. make the open question very clearly reported
|
|
43
|
+
|
|
44
|
+
# 3. consistency - mechanisms
|
|
45
|
+
- slug: has-consistent-mechanisms
|
|
46
|
+
say: |
|
|
47
|
+
review for new mechanisms that duplicate extant functionality.
|
|
48
|
+
|
|
49
|
+
unless the ask was to refactor, be consistent with extant mechanisms.
|
|
50
|
+
|
|
51
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
52
|
+
research stone). look for extant utilities and patterns.
|
|
53
|
+
|
|
54
|
+
then for each new mechanism in the code, ask:
|
|
55
|
+
- does the codebase already have a mechanism that does this?
|
|
56
|
+
- do we duplicate extant utilities or patterns?
|
|
57
|
+
- could we reuse an extant component instead of a new one?
|
|
58
|
+
|
|
59
|
+
if a new mechanism duplicates extant functionality:
|
|
60
|
+
1. replace with the extant mechanism
|
|
61
|
+
2. or flag as an open question if unsure
|
|
62
|
+
|
|
63
|
+
# 4. consistency - conventions
|
|
64
|
+
- slug: has-consistent-conventions
|
|
65
|
+
say: |
|
|
66
|
+
review for divergence from extant names and patterns.
|
|
67
|
+
|
|
68
|
+
unless the ask was to refactor, be consistent with extant conventions.
|
|
69
|
+
|
|
70
|
+
first, search for related codepaths in the codebase (if not done in prior
|
|
71
|
+
research stone). identify extant name conventions and patterns.
|
|
72
|
+
|
|
73
|
+
then for each name choice in the code, ask:
|
|
74
|
+
- what name conventions does the codebase use?
|
|
75
|
+
- do we use a different namespace, prefix, or suffix pattern?
|
|
76
|
+
- do we introduce new terms when extant terms exist?
|
|
77
|
+
- does our structure match extant patterns?
|
|
78
|
+
|
|
79
|
+
if we diverge from extant conventions:
|
|
80
|
+
1. align with the extant convention
|
|
81
|
+
2. or flag as an open question if the extant convention seems wrong
|
|
82
|
+
|
|
83
|
+
# 5. review against behavior declaration - coverage
|
|
84
|
+
- slug: behavior-declaration-coverage
|
|
85
|
+
say: |
|
|
86
|
+
review for coverage of the behavior declaration.
|
|
87
|
+
|
|
88
|
+
our systems have detected that a junior touched this pr since your
|
|
89
|
+
last changes. we need you to be diligent - they may have omitted
|
|
90
|
+
requirements or left features unimplemented.
|
|
91
|
+
|
|
92
|
+
go through the behavior's vision and wish, then check
|
|
93
|
+
each requirement against the code line by line:
|
|
94
|
+
- is every requirement from the vision addressed?
|
|
95
|
+
- did the junior skip or forget any part of the spec?
|
|
96
|
+
|
|
97
|
+
fix all gaps before you continue.
|
|
98
|
+
|
|
99
|
+
# 6. review against behavior declaration - adherance
|
|
100
|
+
- slug: behavior-declaration-adherance
|
|
101
|
+
say: |
|
|
102
|
+
review for adherance to the behavior declaration.
|
|
103
|
+
|
|
104
|
+
our systems have detected that a junior touched this pr since your
|
|
105
|
+
last changes. we need you to be diligent - they may have drifted
|
|
106
|
+
from the spec or implemented items incorrectly.
|
|
107
|
+
|
|
108
|
+
go through each file changed in this pr, line by line, and check
|
|
109
|
+
against the behavior's vision:
|
|
110
|
+
- does the implementation match what the vision describes?
|
|
111
|
+
- did the junior misinterpret or deviate from the spec?
|
|
112
|
+
|
|
113
|
+
fix all gaps before you continue.
|
|
114
|
+
|
|
115
|
+
# 7. review against role standards - adherance
|
|
116
|
+
- slug: role-standards-adherance
|
|
117
|
+
say: |
|
|
118
|
+
review for adherance to mechanic role standards.
|
|
119
|
+
|
|
120
|
+
our systems have detected that a junior touched this pr since your
|
|
121
|
+
last changes. we need you to be diligent - they may have introduced
|
|
122
|
+
bad practices or violated patterns that we require.
|
|
123
|
+
|
|
124
|
+
first, enumerate the rule directories you will check:
|
|
125
|
+
- list each briefs/ subdirectory relevant to this code
|
|
126
|
+
- confirm you have not missed any rule categories
|
|
127
|
+
|
|
128
|
+
then go through each file changed in this pr, line by line, and check:
|
|
129
|
+
- does the code follow mechanic standards correctly?
|
|
130
|
+
- are there violations of required patterns?
|
|
131
|
+
- did the junior introduce anti-patterns, bad practices, or deviations from our conventions?
|
|
132
|
+
|
|
133
|
+
fix all gaps before you continue.
|
|
134
|
+
|
|
135
|
+
# 8. review against role standards - coverage
|
|
136
|
+
- slug: role-standards-coverage
|
|
137
|
+
say: |
|
|
138
|
+
review for coverage of mechanic role standards.
|
|
139
|
+
|
|
140
|
+
our systems have detected that a junior touched this pr since your
|
|
141
|
+
last changes. we need you to be diligent - they may have forgotten
|
|
142
|
+
best practices or omitted patterns that should be present.
|
|
143
|
+
|
|
144
|
+
first, enumerate the rule directories you will check:
|
|
145
|
+
- list each briefs/ subdirectory relevant to this code
|
|
146
|
+
- confirm you have not missed any rule categories
|
|
147
|
+
|
|
148
|
+
then go through each file changed in this pr, line by line, and check:
|
|
149
|
+
- are all relevant mechanic standards applied?
|
|
150
|
+
- are there patterns that should be present but are absent?
|
|
151
|
+
- did the junior forget to add error handle, validation, tests, types, or other required practices?
|
|
152
|
+
|
|
153
|
+
fix all gaps before you continue.
|
|
154
|
+
|
|
155
|
+
peer:
|
|
156
|
+
- 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
|
|
157
|
+
|
|
158
|
+
judges:
|
|
159
|
+
- npx rhachet run --repo bhrain --skill route.stone.judge --mechanism reviewed? --stone $stone --route $route --allow-blockers 0 --allow-nitpicks 3
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
bootup your mechanic's role via `npx rhachet roles boot --repo ehmpathy --role mechanic`
|
|
2
|
+
|
|
3
|
+
then, execute the vision directly
|
|
4
|
+
- $BEHAVIOR_DIR_REL/1.vision.md
|
|
5
|
+
|
|
6
|
+
ref:
|
|
7
|
+
- $BEHAVIOR_DIR_REL/0.wish.md
|
|
8
|
+
|
|
9
|
+
|
|
10
|
+
---
|
|
11
|
+
|
|
12
|
+
track your progress
|
|
13
|
+
|
|
14
|
+
emit todos and check them off into
|
|
15
|
+
- $BEHAVIOR_DIR_REL/5.1.execution.from_vision.v1.i1.md
|
|
@@ -24,11 +24,23 @@ reviews:
|
|
|
24
24
|
|
|
25
25
|
- slug: has-all-tests-passed
|
|
26
26
|
say: |
|
|
27
|
-
double-check: did all tests pass?
|
|
27
|
+
double-check: did all tests pass? prove it.
|
|
28
28
|
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
29
|
+
**zero unproven claims.** you must cite the exact command and output.
|
|
30
|
+
|
|
31
|
+
for each test suite:
|
|
32
|
+
- what command did you run?
|
|
33
|
+
- what was the exit code?
|
|
34
|
+
- how many tests passed?
|
|
35
|
+
|
|
36
|
+
example proof:
|
|
37
|
+
```
|
|
38
|
+
$ npm run test:unit
|
|
39
|
+
> exit 0
|
|
40
|
+
> 47 tests passed
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
if you cannot cite the command and output, you did not prove it.
|
|
32
44
|
|
|
33
45
|
zero tolerance for extant failures:
|
|
34
46
|
- "it was already broken" is not an excuse — fix it
|
|
@@ -36,6 +48,16 @@ reviews:
|
|
|
36
48
|
- flaky tests must be stabilized, not tolerated
|
|
37
49
|
- every failure is your responsibility now
|
|
38
50
|
|
|
51
|
+
zero tolerance for fake tests:
|
|
52
|
+
- tests that always pass are fraud
|
|
53
|
+
- tests that mock the system under test prove nothingness
|
|
54
|
+
- tests must verify real behavior
|
|
55
|
+
|
|
56
|
+
zero tolerance for credential excuses:
|
|
57
|
+
- "i don't have creds" means get them or mock them
|
|
58
|
+
- silent bypasses are forbidden
|
|
59
|
+
- if creds block tests, that is a BLOCKER — not a deferral
|
|
60
|
+
|
|
39
61
|
- slug: has-preserved-test-intentions
|
|
40
62
|
say: |
|
|
41
63
|
double-check: did you preserve test intentions?
|
|
@@ -75,26 +97,35 @@ reviews:
|
|
|
75
97
|
|
|
76
98
|
- slug: has-contract-output-variants-snapped
|
|
77
99
|
say: |
|
|
78
|
-
double-check: does each public contract have snapshots
|
|
100
|
+
double-check: does each public contract have EXHAUSTIVE snapshots?
|
|
101
|
+
|
|
102
|
+
**zero gaps in caller experience.** every contract must snap every output variant.
|
|
79
103
|
|
|
80
|
-
for each new or modified public contract
|
|
81
|
-
- is there a dedicated snapshot file with `.toMatchSnapshot()` or equivalent?
|
|
82
|
-
- does the snapshot capture what the caller would actually see?
|
|
83
|
-
- does it exercise the success case?
|
|
84
|
-
- does it exercise error cases?
|
|
85
|
-
- does it exercise edge cases and variants (e.g., --help, empty input)?
|
|
104
|
+
for each new or modified public contract:
|
|
86
105
|
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
106
|
+
| contract type | what to snap | required variants |
|
|
107
|
+
|---------------|--------------|-------------------|
|
|
108
|
+
| cli command | stdout + stderr | success, error, --help, edge cases |
|
|
109
|
+
| api endpoint | response body | 2xx, 4xx, 5xx, edge cases |
|
|
110
|
+
| sdk method | return value | success, error, edge cases |
|
|
111
|
+
|
|
112
|
+
checklist per contract:
|
|
113
|
+
- [ ] positive path (success) is snapped
|
|
114
|
+
- [ ] negative path (error) is snapped
|
|
115
|
+
- [ ] help/usage is snapped (for cli)
|
|
116
|
+
- [ ] edge cases are snapped (empty, invalid, boundary)
|
|
117
|
+
- [ ] snapshot shows actual output, not placeholder
|
|
91
118
|
|
|
92
119
|
why this matters:
|
|
93
120
|
- snapshots enable vibecheck in prs — reviewers see actual output without execute
|
|
94
121
|
- snapshots detect drift over time — output changes surface in diffs
|
|
95
122
|
- absent variants mean blind spots in review
|
|
123
|
+
- exhaustive coverage proves the contract works for all callers
|
|
124
|
+
|
|
125
|
+
**zero leniency.** if a contract lacks any variant, add the test case now.
|
|
96
126
|
|
|
97
|
-
if
|
|
127
|
+
if you find yourself about to say "this variant isn't worth a snapshot" — stop.
|
|
128
|
+
that is the variant that will break in prod. snap it.
|
|
98
129
|
|
|
99
130
|
- slug: has-snap-changes-rationalized
|
|
100
131
|
say: |
|
|
@@ -159,3 +190,14 @@ reviews:
|
|
|
159
190
|
- are journey tests in the right location?
|
|
160
191
|
- do they have the `.play.` suffix?
|
|
161
192
|
- if not supported, is the fallback convention used?
|
|
193
|
+
|
|
194
|
+
peer:
|
|
195
|
+
# verify contract snapshot exhaustiveness
|
|
196
|
+
- 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
|
|
197
|
+
|
|
198
|
+
# verify external contract integration tests
|
|
199
|
+
- npx rhachet run --repo bhrain --skill review --rules '.agent/repo=bhuild/role=behaver/briefs/practices/behavior.verification/rule.require.external-contract-integration-tests.md' --diffs since-main --paths-with '{src,blackbox}/**/*.{test,integration}.ts' --join intersect --output '$route/.reviews/$stone.peer-review.external-contracts.md' --mode hard
|
|
200
|
+
|
|
201
|
+
judges:
|
|
202
|
+
# enforce peer reviews pass with zero blockers
|
|
203
|
+
- npx rhachet run --repo bhrain --skill route.stone.judge --mechanism reviewed? --stone $stone --route $route --allow-blockers 0 --allow-nitpicks 0
|
|
@@ -6,6 +6,23 @@ prove the deliverable works via test verification
|
|
|
6
6
|
|
|
7
7
|
this is the verification gate. you cannot pass execution without proof that all tests pass.
|
|
8
8
|
|
|
9
|
+
## .strictness: zero tolerance, zero exceptions
|
|
10
|
+
|
|
11
|
+
**this gate enforces absolute standards. there is no leniency.**
|
|
12
|
+
|
|
13
|
+
| constraint | definition |
|
|
14
|
+
|------------|------------|
|
|
15
|
+
| zero deferrals | you cannot defer any test to later. all tests pass now or you fail. |
|
|
16
|
+
| zero fake tests | tests must verify real behavior. assertions that always pass are fraud. |
|
|
17
|
+
| zero unproven claims | every claim of "test passes" must cite the exact command run and output. |
|
|
18
|
+
| zero credential excuses | "i don't have creds" is not an excuse. get them, mock them, or fail. |
|
|
19
|
+
| zero skips | .skip() and .only() are forbidden. silent bypasses are forbidden. |
|
|
20
|
+
| zero exceptions | there are no special cases. the rules apply to all. |
|
|
21
|
+
|
|
22
|
+
**if a blocker prevents tests from run, that is a BLOCKER. full stop.**
|
|
23
|
+
|
|
24
|
+
you do not proceed. you do not defer. you fix it or you fail the gate.
|
|
25
|
+
|
|
9
26
|
## .why
|
|
10
27
|
|
|
11
28
|
**why does this gate exist?**
|
|
@@ -27,6 +44,7 @@ with this gate:
|
|
|
27
44
|
**the cardinal rules**:
|
|
28
45
|
1. never leave behavior without true, dependable test coverage
|
|
29
46
|
2. never offload work onto your crew unless there is truly, fundamentally no other option
|
|
47
|
+
3. never claim a test passes without cite of the exact command and output
|
|
30
48
|
|
|
31
49
|
you fix it yourself. you exhaust every option: debug, research, try alternatives. only when you hit a wall that is physically impossible to climb alone — credentials only the foreman possesses, access only they can grant — only then may you ask for help.
|
|
32
50
|
|
|
@@ -100,8 +118,44 @@ checklist:
|
|
|
100
118
|
- [ ] intended changes have clear rationale
|
|
101
119
|
- [ ] accidental changes have been reverted or justified as improvements
|
|
102
120
|
|
|
103
|
-
### tests executed
|
|
104
|
-
|
|
121
|
+
### tests executed — with proof
|
|
122
|
+
|
|
123
|
+
**every test run must be proven with exact command and output.**
|
|
124
|
+
|
|
125
|
+
| test suite | command run | result | proof (exit code + summary) |
|
|
126
|
+
|------------|-------------|--------|----------------------------|
|
|
127
|
+
| types | `npm run test:types` | ✓ / ✗ | exit 0, no errors |
|
|
128
|
+
| lint | `npm run test:lint` | ✓ / ✗ | exit 0, no errors |
|
|
129
|
+
| format | `npm run test:format` | ✓ / ✗ | exit 0, no errors |
|
|
130
|
+
| unit | `npm run test:unit` | ✓ / ✗ | exit 0, N tests passed |
|
|
131
|
+
| integration | `npm run test:integration` | ✓ / ✗ | exit 0, N tests passed |
|
|
132
|
+
| acceptance | `npm run test:acceptance` | ✓ / ✗ | exit 0, N tests passed |
|
|
133
|
+
|
|
134
|
+
checklist:
|
|
135
|
+
- [ ] every test command was run (not "i think it passed")
|
|
136
|
+
- [ ] every test command output was observed (not assumed)
|
|
137
|
+
- [ ] the exact exit code was verified (0 = pass, non-zero = fail)
|
|
138
|
+
- [ ] no tests were skipped, mocked, or faked
|
|
139
|
+
|
|
140
|
+
**zero unproven claims.** if you claim a test passes, cite the command and output.
|
|
141
|
+
|
|
142
|
+
### contract output snapshot exhaustiveness
|
|
143
|
+
|
|
144
|
+
**every user-faced contract must have exhaustive snapshot coverage.**
|
|
145
|
+
|
|
146
|
+
| contract type | contract | positive path snapped? | negative path snapped? | edge cases snapped? |
|
|
147
|
+
|---------------|----------|------------------------|------------------------|---------------------|
|
|
148
|
+
| cli | {command} | ✓ / ✗ | ✓ / ✗ | ✓ / ✗ |
|
|
149
|
+
| api | {endpoint} | ✓ / ✗ | ✓ / ✗ | ✓ / ✗ |
|
|
150
|
+
| sdk | {method} | ✓ / ✗ | ✓ / ✗ | ✓ / ✗ |
|
|
151
|
+
|
|
152
|
+
checklist:
|
|
153
|
+
- [ ] every cli command has stdout/stderr snapshots for success, error, and help
|
|
154
|
+
- [ ] every api endpoint has response snapshots for success and error codes
|
|
155
|
+
- [ ] every sdk method has return value snapshots for success and error
|
|
156
|
+
- [ ] every contract has edge case snapshots (empty input, invalid input, boundary)
|
|
157
|
+
|
|
158
|
+
**zero gaps in caller experience.** the reviewer must see exactly what callers see.
|
|
105
159
|
|
|
106
160
|
### blockers
|
|
107
161
|
- none (or list handoff references)
|
|
@@ -139,7 +193,18 @@ if you find skips, remove them. all tests must run. update your checklist.
|
|
|
139
193
|
|
|
140
194
|
### step 4: run all tests and fix all failures
|
|
141
195
|
|
|
142
|
-
run
|
|
196
|
+
run each test suite and **cite the exact command and output**.
|
|
197
|
+
|
|
198
|
+
```bash
|
|
199
|
+
npm run test:types # cite exit code
|
|
200
|
+
npm run test:lint # cite exit code
|
|
201
|
+
npm run test:format # cite exit code
|
|
202
|
+
npm run test:unit # cite exit code + test count
|
|
203
|
+
npm run test:integration # cite exit code + test count
|
|
204
|
+
npm run test:acceptance # cite exit code + test count
|
|
205
|
+
```
|
|
206
|
+
|
|
207
|
+
all must pass — no exceptions. no deferrals. no "i'll fix it later."
|
|
143
208
|
|
|
144
209
|
if tests fail, fix them. that is the job.
|
|
145
210
|
|
|
@@ -151,6 +216,8 @@ if a test was broken before you started — fix it. if a test is flaky — fix i
|
|
|
151
216
|
|
|
152
217
|
**preserve test intentions.** when you fix a test, you fix why it failed — not what it tests. to change what a test verifies is not a fix. it is at worst malicious deception, at best reckless negligence. the test knew a truth. if it fails, either the code is wrong or the test has a bug. fix the cause, not the assertion.
|
|
153
218
|
|
|
219
|
+
**zero fake tests.** a test that always passes is fraud. a test that skips is a lie. a test that mocks the system under test proves nothingness. tests must verify real behavior against real code.
|
|
220
|
+
|
|
154
221
|
**escalation path:**
|
|
155
222
|
1. debug the failure — read the error, understand the cause
|
|
156
223
|
2. research — search for similar issues, read docs
|
|
@@ -34,26 +34,43 @@ reviews:
|
|
|
34
34
|
say: |
|
|
35
35
|
coverage check: cite the acceptance test for each playtest step.
|
|
36
36
|
|
|
37
|
+
**zero unproven steps.** every step must map to an acceptance test.
|
|
38
|
+
|
|
37
39
|
for each step in the playtest:
|
|
38
40
|
- which acceptance test file verifies this behavior?
|
|
39
41
|
- which specific test case (given/when/then) covers it?
|
|
40
42
|
- cite the exact file path and test name
|
|
41
43
|
|
|
44
|
+
example citation:
|
|
45
|
+
```
|
|
46
|
+
step: "run `bhuild behavior init`"
|
|
47
|
+
test: src/contract/cli/behavior.init.acceptance.test.ts
|
|
48
|
+
case: given('[case1] fresh repo') when('[t0] init') then('creates .behavior')
|
|
49
|
+
```
|
|
50
|
+
|
|
42
51
|
if a step lacks acceptance test coverage:
|
|
43
|
-
- is
|
|
44
|
-
-
|
|
52
|
+
- this is a BLOCKER — write the test before you proceed
|
|
53
|
+
- "untestable via automation" is almost never true — find a way
|
|
45
54
|
|
|
46
|
-
|
|
55
|
+
**zero gaps.** if you cannot cite a test, the step is unproven.
|
|
56
|
+
unproven steps do not pass this gate.
|
|
47
57
|
|
|
48
58
|
- slug: has-self-run-verification
|
|
49
59
|
say: |
|
|
50
60
|
dogfood check: did you run the playtest yourself?
|
|
51
61
|
|
|
62
|
+
**zero self-skip.** you must run every step before emit.
|
|
63
|
+
|
|
52
64
|
before you hand off to the foreman, run every step yourself:
|
|
53
65
|
- follow each instruction exactly as written
|
|
54
66
|
- verify each expected outcome matches reality
|
|
55
67
|
- note any friction, confusion, or absent context
|
|
56
68
|
|
|
69
|
+
**cite your run.** for each step, note:
|
|
70
|
+
- command you ran
|
|
71
|
+
- output you observed
|
|
72
|
+
- whether it matched expected
|
|
73
|
+
|
|
57
74
|
if you found issues while you ran it:
|
|
58
75
|
- did you fix the instructions?
|
|
59
76
|
- did you update expected outcomes?
|
|
@@ -61,5 +78,8 @@ reviews:
|
|
|
61
78
|
|
|
62
79
|
the foreman deserves a playtest that works. prove it works by self-test first.
|
|
63
80
|
|
|
81
|
+
**if you did not run it yourself, you did not verify it.**
|
|
82
|
+
this is a BLOCKER, not a suggestion.
|
|
83
|
+
|
|
64
84
|
judges:
|
|
65
85
|
- npx rhachet run --repo bhrain --skill route.stone.judge --mechanism approved? --stone $stone --route $route
|
|
@@ -8,13 +8,26 @@ this is the playtest gate. you emit a step-by-step byhand quality assurance chec
|
|
|
8
8
|
|
|
9
9
|
automated tests prove the code works. the playtest proves the experience works.
|
|
10
10
|
|
|
11
|
+
## .strictness: zero tolerance, zero exceptions
|
|
12
|
+
|
|
13
|
+
**this gate enforces absolute standards. there is no leniency.**
|
|
14
|
+
|
|
15
|
+
| constraint | definition |
|
|
16
|
+
|------------|------------|
|
|
17
|
+
| zero unproven steps | every step must cite the acceptance test that verifies it |
|
|
18
|
+
| zero untested paths | every playtest step must have automated coverage |
|
|
19
|
+
| zero self-skip | you must run the playtest yourself before emit |
|
|
20
|
+
| zero ambiguity | every step must be copy-pasteable with explicit expected output |
|
|
21
|
+
|
|
22
|
+
**every playtest step maps to an acceptance test.** if a step lacks automated coverage, write the test first.
|
|
23
|
+
|
|
11
24
|
## .why
|
|
12
25
|
|
|
13
26
|
**your crew deserves confidence.** they're about to approve work they didn't do themselves. the playtest gives them a path to verify with their own hands.
|
|
14
27
|
|
|
15
28
|
**automated tests have blind spots.** they verify behavior but miss ux friction, unclear flows, edge cases that "work" but feel wrong. the playtest catches what tests can't.
|
|
16
29
|
|
|
17
|
-
**the playtest is a contract.** it says: "if you follow these steps and
|
|
30
|
+
**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.
|
|
18
31
|
|
|
19
32
|
## .how
|
|
20
33
|
|
|
@@ -0,0 +1,98 @@
|
|
|
1
|
+
# philosophy: verification strictness
|
|
2
|
+
|
|
3
|
+
## .what
|
|
4
|
+
|
|
5
|
+
this brief explains why verification gates enforce absolute standards with zero tolerance and zero exceptions.
|
|
6
|
+
|
|
7
|
+
## .the fundamental guarantee
|
|
8
|
+
|
|
9
|
+
a behavior is a promise. it says: "this is what the system does."
|
|
10
|
+
|
|
11
|
+
verification is the proof. it says: "we have evidence the promise is true."
|
|
12
|
+
|
|
13
|
+
without strict verification:
|
|
14
|
+
- there is no guarantee the behavior works as advertised in this release
|
|
15
|
+
- there is no guarantee the behavior will continue to work in subsequent releases
|
|
16
|
+
- there is no evidence to cite when the behavior breaks
|
|
17
|
+
- there is no defense against regression
|
|
18
|
+
|
|
19
|
+
## .why zero tolerance
|
|
20
|
+
|
|
21
|
+
**zero deferrals** — a deferred test is a lie. it says "coverage exists" when it does not. deferrals accumulate. deferrals become permanent. deferrals ship as broken code.
|
|
22
|
+
|
|
23
|
+
**zero fake tests** — a fake test is fraud. it provides false confidence. it passes when the system is broken. it masks defects until production.
|
|
24
|
+
|
|
25
|
+
**zero unproven claims** — a claim without cite is a guess. "i think it passes" is not verification. cite the command. cite the output. prove the claim.
|
|
26
|
+
|
|
27
|
+
**zero credential excuses** — "i don't have creds" is a blocker, not a deferral. get the creds. mock the boundary. find another way. do not ship unverified.
|
|
28
|
+
|
|
29
|
+
**zero skips** — a skip is a hidden lie. it pretends coverage exists. it passes ci. it lets broken code through. skips are forbidden.
|
|
30
|
+
|
|
31
|
+
**zero exceptions** — special cases accumulate. exceptions become rules. "just this once" becomes "always." the line must be absolute.
|
|
32
|
+
|
|
33
|
+
## .why exhaustive contract coverage
|
|
34
|
+
|
|
35
|
+
callers experience contracts through outputs:
|
|
36
|
+
- cli callers see stdout and stderr
|
|
37
|
+
- api callers see response bodies
|
|
38
|
+
- sdk callers see return values
|
|
39
|
+
|
|
40
|
+
if a contract output is not snapped:
|
|
41
|
+
- reviewers cannot vibecheck the output in prs
|
|
42
|
+
- drift goes undetected over releases
|
|
43
|
+
- regressions ship without notice
|
|
44
|
+
- caller experience degrades silently
|
|
45
|
+
|
|
46
|
+
exhaustive means: every positive path, every negative path, every edge case. no gaps. no blind spots.
|
|
47
|
+
|
|
48
|
+
## .why integration tests for external contracts
|
|
49
|
+
|
|
50
|
+
mocks lie. mocks drift from the real service. mocks create false confidence.
|
|
51
|
+
|
|
52
|
+
a test that mocks stripe does not prove stripe works. it proves the mock works.
|
|
53
|
+
|
|
54
|
+
only a real call to the real service proves the integration works.
|
|
55
|
+
|
|
56
|
+
credential difficulty is not an exception. it is a blocker. solve it or fail the gate.
|
|
57
|
+
|
|
58
|
+
## .the cost of leniency
|
|
59
|
+
|
|
60
|
+
leniency compounds:
|
|
61
|
+
- one deferral becomes ten
|
|
62
|
+
- one fake test becomes a pattern
|
|
63
|
+
- one unproven claim becomes normal
|
|
64
|
+
- one credential excuse becomes standard
|
|
65
|
+
|
|
66
|
+
leniency erodes trust:
|
|
67
|
+
- "tests pass" means nothingness
|
|
68
|
+
- "verified" means "probably"
|
|
69
|
+
- "covered" means "we hope"
|
|
70
|
+
|
|
71
|
+
leniency ships defects:
|
|
72
|
+
- broken code reaches users
|
|
73
|
+
- regressions go undetected
|
|
74
|
+
- contracts drift without notice
|
|
75
|
+
|
|
76
|
+
## .the benefit of strictness
|
|
77
|
+
|
|
78
|
+
strictness compounds:
|
|
79
|
+
- every test is proven
|
|
80
|
+
- every claim is cited
|
|
81
|
+
- every contract is snapped
|
|
82
|
+
- every release is verified
|
|
83
|
+
|
|
84
|
+
strictness builds trust:
|
|
85
|
+
- "tests pass" means proven
|
|
86
|
+
- "verified" means cited
|
|
87
|
+
- "covered" means exhaustive
|
|
88
|
+
|
|
89
|
+
strictness prevents defects:
|
|
90
|
+
- broken code fails the gate
|
|
91
|
+
- regressions surface in diffs
|
|
92
|
+
- contracts are visible in snapshots
|
|
93
|
+
|
|
94
|
+
## .summary
|
|
95
|
+
|
|
96
|
+
verification gates exist to guarantee behavior works. strictness is not cruelty — it is the mechanism that makes the guarantee real. without strictness, there is no guarantee. with strictness, there is proof.
|
|
97
|
+
|
|
98
|
+
zero tolerance. zero exceptions. that is the price of trust.
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
.rule = require.contract-snapshot-exhaustiveness
|
|
2
|
+
|
|
3
|
+
.what = every user-faced contract must have exhaustive snapshot coverage for all output variants
|
|
4
|
+
|
|
5
|
+
.why = snapshots prove the contract works for all callers; gaps in coverage are blind spots in review; without snapshots, drift goes undetected and regressions ship
|
|
6
|
+
|
|
7
|
+
.how = verify every cli command, api endpoint, and sdk method has snapshots for positive path, negative path, and edge cases; check stdout/stderr for cli, response body for api, return value for sdk
|
|
8
|
+
|
|
9
|
+
.examples:
|
|
10
|
+
.positive:
|
|
11
|
+
- |
|
|
12
|
+
## cli snapshots
|
|
13
|
+
|
|
14
|
+
| command | variants | snapshot file |
|
|
15
|
+
|---------|----------|---------------|
|
|
16
|
+
| behavior init | success, error, --help | behavior.init.snap |
|
|
17
|
+
| behavior bind | success, not-found, --help | behavior.bind.snap |
|
|
18
|
+
|
|
19
|
+
each variant exercises:
|
|
20
|
+
- positive path: command succeeds
|
|
21
|
+
- negative path: command fails with clear error
|
|
22
|
+
- help: --help output documented
|
|
23
|
+
- edge: empty input, invalid input, boundary conditions
|
|
24
|
+
- |
|
|
25
|
+
## sdk snapshots
|
|
26
|
+
|
|
27
|
+
| method | variants | snapshot file |
|
|
28
|
+
|--------|----------|---------------|
|
|
29
|
+
| getBehavior | found, not-found, invalid-id | getBehavior.snap |
|
|
30
|
+
| setBehavior | created, updated, validation-error | setBehavior.snap |
|
|
31
|
+
|
|
32
|
+
.negative:
|
|
33
|
+
- |
|
|
34
|
+
## tests
|
|
35
|
+
|
|
36
|
+
tests verify the behavior works.
|
|
37
|
+
- |
|
|
38
|
+
## cli tests
|
|
39
|
+
|
|
40
|
+
- behavior init creates the directory
|
|
41
|
+
- behavior bind works
|
|
42
|
+
|
|
43
|
+
(no snapshots, no error cases, no edge cases)
|
|
44
|
+
- |
|
|
45
|
+
## snapshots
|
|
46
|
+
|
|
47
|
+
- behavior.init.snap (only success path)
|
|
48
|
+
|
|
49
|
+
.severity = BLOCKER
|
|
50
|
+
|
|
51
|
+
.note = zero gaps in caller experience. every variant that a caller could encounter must be snapped. if you find yourself about to skip a variant, that is the variant that will break in prod.
|
|
@@ -0,0 +1,52 @@
|
|
|
1
|
+
.rule = require.external-contract-integration-tests
|
|
2
|
+
|
|
3
|
+
.what = every external contract (sdk, api, service) must have integration tests that call the real service and verify the response
|
|
4
|
+
|
|
5
|
+
.why = mocks lie; mocks drift from reality; mocks create false confidence; only real calls prove the integration works
|
|
6
|
+
|
|
7
|
+
.how = verify every external contract has at least one integration test that calls the real service with real credentials; check that responses are validated against expected shapes; ensure no silent credential bypasses
|
|
8
|
+
|
|
9
|
+
.examples:
|
|
10
|
+
.positive:
|
|
11
|
+
- |
|
|
12
|
+
## external contract coverage
|
|
13
|
+
|
|
14
|
+
| sdk | integration test | real call? | response validated? |
|
|
15
|
+
|-----|-----------------|------------|---------------------|
|
|
16
|
+
| stripe | stripe.integration.test.ts | yes | yes, schema check |
|
|
17
|
+
| github | github.integration.test.ts | yes | yes, shape assert |
|
|
18
|
+
| openai | openai.integration.test.ts | yes | yes, content check |
|
|
19
|
+
|
|
20
|
+
each integration test:
|
|
21
|
+
- calls the real service (not a mock)
|
|
22
|
+
- validates the response shape
|
|
23
|
+
- handles error cases with real error responses
|
|
24
|
+
- |
|
|
25
|
+
## exception: mocked by vision
|
|
26
|
+
|
|
27
|
+
vision.md declares: "github api may be mocked for ci/cd tests due to rate limits"
|
|
28
|
+
|
|
29
|
+
| sdk | mock allowed? | reason | real test exists? |
|
|
30
|
+
|-----|--------------|--------|-------------------|
|
|
31
|
+
| github | yes (ci only) | rate limits | yes, in .integration.test.ts |
|
|
32
|
+
|
|
33
|
+
even with exception, at least one real test must exist.
|
|
34
|
+
|
|
35
|
+
.negative:
|
|
36
|
+
- |
|
|
37
|
+
## external calls
|
|
38
|
+
|
|
39
|
+
stripe api is mocked in tests to avoid charges.
|
|
40
|
+
- |
|
|
41
|
+
## integration tests
|
|
42
|
+
|
|
43
|
+
- stripe.test.ts (uses mock stripe client)
|
|
44
|
+
- no real stripe calls in test suite
|
|
45
|
+
- |
|
|
46
|
+
## external contracts
|
|
47
|
+
|
|
48
|
+
integration tests call mocks because "credentials are hard to get"
|
|
49
|
+
|
|
50
|
+
.severity = BLOCKER
|
|
51
|
+
|
|
52
|
+
.note = "lack of credentials" is not an excuse. get them, or fail the gate. if the vision explicitly marks an exception for a specific sdk to be mocked, document that exception and cite the vision. even then, at least one real integration test must exist somewhere, with atleast the lack of creds failure case.
|
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.15.
|
|
5
|
+
"version": "0.15.4",
|
|
6
6
|
"repository": "ehmpathy/rhachet-roles-bhuild",
|
|
7
7
|
"homepage": "https://github.com/ehmpathy/rhachet-roles-bhuild",
|
|
8
8
|
"keywords": [
|