nimai-core 0.5.1 → 0.5.6
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/data/nimai-spec-full.md +15 -0
- package/dist/lint.d.ts.map +1 -1
- package/dist/lint.js +1 -0
- package/dist/lint.js.map +1 -1
- package/dist/prompts.d.ts.map +1 -1
- package/dist/prompts.js +52 -13
- package/dist/prompts.js.map +1 -1
- package/package.json +1 -1
package/data/nimai-spec-full.md
CHANGED
|
@@ -21,6 +21,13 @@
|
|
|
21
21
|
|---|---|---|---|---|
|
|
22
22
|
| 1 | | — | | |
|
|
23
23
|
|
|
24
|
+
## Acceptance Criteria
|
|
25
|
+
*Binary and checkable. Leave every box unchecked — they are checked by the reviewer, not the author.*
|
|
26
|
+
|
|
27
|
+
Done when ALL of these are true:
|
|
28
|
+
- [ ]
|
|
29
|
+
- [ ]
|
|
30
|
+
|
|
24
31
|
## Mechanism Decisions
|
|
25
32
|
*One block per core choice. A builder must never have to pick an approach mid-build.*
|
|
26
33
|
|
|
@@ -38,6 +45,14 @@
|
|
|
38
45
|
- API/trigger flow:
|
|
39
46
|
- Entity states and transitions:
|
|
40
47
|
- Auth:
|
|
48
|
+
- Security / authorization rules (who can read, write, delete each resource — and under what conditions; write "N/A — no server-side authorization layer" if genuinely not applicable):
|
|
49
|
+
|
|
50
|
+
## Navigation / Screen Map
|
|
51
|
+
*Every distinct view or screen the user can reach. For SPAs, list the route paths. For CLIs or non-UI specs, write "N/A — no user-facing navigation."*
|
|
52
|
+
|
|
53
|
+
| Route / View | Description | Auth required? |
|
|
54
|
+
|---|---|---|
|
|
55
|
+
| | | |
|
|
41
56
|
|
|
42
57
|
## Change Surface
|
|
43
58
|
*Every existing file this work touches, classified. The builder may not touch anything outside this table.*
|
package/dist/lint.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"lint.d.ts","sourceRoot":"","sources":["../src/lint.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,SAAS,EAAiB,MAAM,SAAS,CAAC;
|
|
1
|
+
{"version":3,"file":"lint.d.ts","sourceRoot":"","sources":["../src/lint.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,SAAS,EAAiB,MAAM,SAAS,CAAC;AA8GnD,wBAAgB,QAAQ,CAAC,QAAQ,EAAE,MAAM,GAAG,SAAS,EAAE,CAQtD;AAED,wBAAgB,WAAW,CAAC,OAAO,EAAE,MAAM,GAAG,SAAS,EAAE,CAkDxD"}
|
package/dist/lint.js
CHANGED
package/dist/lint.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"lint.js","sourceRoot":"","sources":["../src/lint.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
|
|
1
|
+
{"version":3,"file":"lint.js","sourceRoot":"","sources":["../src/lint.ts"],"names":[],"mappings":";;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;AA+GA,4BAQC;AAED,kCAkDC;AA3KD,uCAAyB;AAEzB,yCAAiD;AAEjD,mEAAmE;AACnE,MAAM,oBAAoB,GAAG,OAAO,CAAC;AACrC,uCAAuC;AACvC,MAAM,OAAO,GAAG,sBAAsB,CAAC;AACvC,iEAAiE;AACjE,MAAM,eAAe,GAAG,iDAAiD,CAAC;AAE1E,+EAA+E;AAC/E,8DAA8D;AAE9D,MAAM,sBAAsB,GAAG;IAC7B,aAAa;IACb,OAAO;IACP,qBAAqB;IACrB,qBAAqB;IACrB,kBAAkB;CACnB,CAAC;AAEF,MAAM,sBAAsB,GAAG;IAC7B,GAAG,sBAAsB;IACzB,oBAAoB;IACpB,mBAAmB;IACnB,yBAAyB;IACzB,gBAAgB;IAChB,8BAA8B;CAC/B,CAAC;AAEF;;;GAGG;AACH,SAAS,wBAAwB,CAAC,KAAe;IAC/C,MAAM,MAAM,GAAa,EAAE,CAAC;IAC5B,MAAM,aAAa,GAAG,IAAI,GAAG,CAAC,CAAC,qBAAqB,EAAE,oBAAoB,CAAC,CAAC,CAAC;IAC7E,IAAI,OAAO,GAAG,KAAK,CAAC;IAEpB,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,KAAK,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;QACtC,MAAM,YAAY,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,iBAAiB,CAAC,CAAC;QACvD,IAAI,YAAY,EAAE,CAAC;YACjB,OAAO,GAAG,aAAa,CAAC,GAAG,CAAC,YAAY,CAAC,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;YACpD,SAAS;QACX,CAAC;QACD,IAAI,OAAO,IAAI,gBAAgB,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;YAC/C,MAAM,CAAC,IAAI,CAAC,CAAC,GAAG,CAAC,CAAC,CAAC;QACrB,CAAC;IACH,CAAC;IACD,OAAO,MAAM,CAAC;AAChB,CAAC;AAED;;;;;;GAMG;AACH,SAAS,iBAAiB,CAAC,KAAe;IACxC,MAAM,MAAM,GAAgB,EAAE,CAAC;IAE/B,MAAM,eAAe,GAAG,KAAK,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,gCAAgC,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC;IAEvF,IAAI,eAAe,KAAK,CAAC,CAAC,EAAE,CAAC;QAC3B,OAAO,CAAC,KAAK,CAAC,CAAC,EAAE,6BAA6B,EAC5C,gIAAgI,CAAC,CAAC,CAAC;IACvI,CAAC;IAED,MAAM,YAAY,GAAG,CAAC,KAAK,CAAC,eAAe,CAAC,CAAC,KAAK,CAAC,WAAW,CAAC,IAAI,CAAC,EAAE,EAAE,GAAG,CAAC,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,CAAC;IACxF,IAAI,aAAa,GAAG,KAAK,CAAC,MAAM,CAAC;IACjC,KAAK,IAAI,CAAC,GAAG,eAAe,GAAG,CAAC,EAAE,CAAC,GAAG,KAAK,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;QACxD,MAAM,CAAC,GAAG,KAAK,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,cAAc,CAAC,CAAC;QACzC,IAAI,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC,CAAC,MAAM,IAAI,YAAY,EAAE,CAAC;YAAC,aAAa,GAAG,CAAC,CAAC;YAAC,MAAM;QAAC,CAAC;IACrE,CAAC;IACD,MAAM,YAAY,GAAG,KAAK,CAAC,KAAK,CAAC,eAAe,EAAE,aAAa,CAAC,CAAC;IAEjE,MAAM,cAAc,GAAqC;QACvD,EAAE,GAAG,EAAE,iBAAiB,EAAE,KAAK,EAAE,gBAAgB,EAAE;QACnD,EAAE,GAAG,EAAE,wBAAwB,EAAE,KAAK,EAAE,uBAAuB,EAAE;KAClE,CAAC;IAEF,KAAK,MAAM,EAAE,GAAG,EAAE,KAAK,EAAE,IAAI,cAAc,EAAE,CAAC;QAC5C,MAAM,OAAO,GAAG,YAAY,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,UAAU,CAAC,GAAG,CAAC,CAAC,CAAC;QACpF,IAAI,OAAO,KAAK,CAAC,CAAC,EAAE,CAAC;YACnB,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,eAAe,GAAG,CAAC,EAAE,wBAAwB,EAC7D,uDAAuD,KAAK,gCAAgC,CAAC,CAAC,CAAC;YACjG,SAAS;QACX,CAAC;QACD,MAAM,OAAO,GAAG,eAAe,GAAG,OAAO,GAAG,CAAC,CAAC;QAC9C,MAAM,KAAK,GAAG,YAAY,CAAC,OAAO,CAAC,CAAC,KAAK,CAAC,YAAY,CAAC,OAAO,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC;QACzF,IAAI,KAAK,KAAK,GAAG,EAAE,CAAC;YAClB,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,OAAO,EAAE,wBAAwB,EACjD,IAAI,KAAK,aAAa,OAAO,QAAQ,KAAK,yCAAyC,CAAC,CAAC,CAAC;QAC1F,CAAC;IACH,CAAC;IAED,MAAM,UAAU,GAAG,YAAY,CAAC,SAAS,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC,UAAU,CAAC,kBAAkB,CAAC,CAAC,CAAC;IACtG,IAAI,UAAU,KAAK,CAAC,CAAC,EAAE,CAAC;QACtB,MAAM,OAAO,GAAG,eAAe,GAAG,UAAU,GAAG,CAAC,CAAC;QACjD,MAAM,KAAK,GAAG,YAAY,CAAC,UAAU,CAAC,CAAC,KAAK,CAAC,YAAY,CAAC,UAAU,CAAC,CAAC,OAAO,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,CAAC,IAAI,EAAE,CAAC,WAAW,EAAE,CAAC;QAC7G,IAAI,KAAK,KAAK,IAAI,EAAE,CAAC;YACnB,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,OAAO,EAAE,wBAAwB,EACjD,6BAA6B,OAAO,4DAA4D,CAAC,CAAC,CAAC;QACvG,CAAC;IACH,CAAC;IAED,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,SAAgB,QAAQ,CAAC,QAAgB;IACvC,IAAI,OAAe,CAAC;IACpB,IAAI,CAAC;QACH,OAAO,GAAG,EAAE,CAAC,YAAY,CAAC,QAAQ,EAAE,OAAO,CAAC,CAAC;IAC/C,CAAC;IAAC,OAAO,GAAG,EAAE,CAAC;QACb,MAAM,IAAI,KAAK,CAAC,wBAAwB,QAAQ,MAAO,GAA6B,CAAC,OAAO,EAAE,CAAC,CAAC;IAClG,CAAC;IACD,OAAO,WAAW,CAAC,OAAO,CAAC,CAAC;AAC9B,CAAC;AAED,SAAgB,WAAW,CAAC,OAAe;IACzC,MAAM,MAAM,GAAgB,EAAE,CAAC;IAC/B,MAAM,KAAK,GAAG,OAAO,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC;IAElC,yEAAyE;IACzE,KAAK,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC,GAAG,KAAK,CAAC,MAAM,EAAE,CAAC,EAAE,EAAE,CAAC;QACtC,IAAI,oBAAoB,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;YACxC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,EAAE,mBAAmB,EAC1C,gCAAgC,CAAC,GAAG,CAAC,4CAA4C,CAAC,CAAC,CAAC;QACxF,CAAC;QACD,IAAI,OAAO,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;YAC3B,wDAAwD;YACxD,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,GAAG,CAAC,EAAE,mBAAmB,EAC1C,+CAA+C,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,CAAC;QAC7D,CAAC;IACH,CAAC;IAED,iEAAiE;IACjE,IAAI,CAAC,eAAe,CAAC,IAAI,CAAC,OAAO,CAAC,EAAE,CAAC;QACnC,MAAM,CAAC,IAAI,CAAC,aAAa,CAAC,CAAC,EAAE,gBAAgB,EAC3C,2GAA2G,CAAC,CAAC,CAAC;IAClH,CAAC;IAED,uEAAuE;IACvE,MAAM,IAAI,GAAG,IAAA,8BAAmB,EAAC,OAAO,CAAC,CAAC;IAC1C,MAAM,gBAAgB,GAAG,IAAI,KAAK,MAAM,CAAC,CAAC,CAAC,sBAAsB,CAAC,CAAC,CAAC,sBAAsB,CAAC;IAE3F,wEAAwE;IACxE,MAAM,QAAQ,GAAG,KAAK;SACnB,MAAM,CAAC,CAAC,CAAC,EAAE,CAAC,YAAY,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;SACjC,GAAG,CAAC,CAAC,CAAC,EAAE,CAAC,CAAC,CAAC,OAAO,CAAC,YAAY,EAAE,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC,CAAC;IAEhD,KAAK,MAAM,OAAO,IAAI,gBAAgB,EAAE,CAAC;QACvC,IAAI,CAAC,QAAQ,CAAC,QAAQ,CAAC,OAAO,CAAC,EAAE,CAAC;YAChC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,CAAC,EAAE,0BAA0B,EAC7C,gCAAgC,IAAI,mBAAmB,OAAO,GAAG,CAAC,CAAC,CAAC;QACxE,CAAC;IACH,CAAC;IAED,oFAAoF;IACpF,MAAM,eAAe,GAAG,wBAAwB,CAAC,KAAK,CAAC,CAAC;IACxD,KAAK,MAAM,OAAO,IAAI,eAAe,EAAE,CAAC;QACtC,MAAM,CAAC,IAAI,CAAC,KAAK,CAAC,OAAO,EAAE,gBAAgB,EACzC,4BAA4B,OAAO,gEAAgE,CAAC,CAAC,CAAC;IAC1G,CAAC;IAED,kFAAkF;IAClF,MAAM,CAAC,IAAI,CAAC,GAAG,iBAAiB,CAAC,KAAK,CAAC,CAAC,CAAC;IAEzC,OAAO,MAAM,CAAC;AAChB,CAAC;AAED,SAAS,KAAK,CAAC,IAAY,EAAE,IAAmB,EAAE,OAAe;IAC/D,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,OAAO,EAAE,CAAC;AACjC,CAAC;AAED,SAAS,aAAa,CAAC,IAAY,EAAE,IAAmB,EAAE,OAAe;IACvE,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,OAAO,EAAE,QAAQ,EAAE,IAAI,EAAE,CAAC;AACjD,CAAC"}
|
package/dist/prompts.d.ts.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAC/B,OAAO,EAAE,MAAM,EACf,QAAQ,EAAE,MAAM,EAChB,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,GACnB,MAAM,
|
|
1
|
+
{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":"AAAA;;;;;;;GAOG;AAEH;;;;;;;;;GASG;AACH,wBAAgB,iBAAiB,CAC/B,OAAO,EAAE,MAAM,EACf,QAAQ,EAAE,MAAM,EAChB,YAAY,EAAE,MAAM,EACpB,YAAY,EAAE,MAAM,GACnB,MAAM,CA+IR;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CA4GzD;AAED;;;;GAIG;AACH,wBAAgB,YAAY,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAgBxD"}
|
package/dist/prompts.js
CHANGED
|
@@ -65,9 +65,22 @@ If the repository is empty or this is a new project, note "greenfield"
|
|
|
65
65
|
and move on. Ask the user nothing during this phase.
|
|
66
66
|
|
|
67
67
|
PHASE 2 — INTERVIEW
|
|
68
|
-
|
|
69
|
-
|
|
70
|
-
|
|
68
|
+
A spec has two layers: (1) the desired features and outcomes — what the
|
|
69
|
+
product does, for whom, and what "done" feels like — and (2) the
|
|
70
|
+
architecture and technology that deliver them. The interview's job is
|
|
71
|
+
layer 1. That is the part only the user can supply; it is their idea.
|
|
72
|
+
Architecture is layer 2 and is mostly yours to resolve in PHASE 3.
|
|
73
|
+
|
|
74
|
+
Early on, gauge how much the user wants to own technical decisions. Some
|
|
75
|
+
have strong opinions on stack and design and should be invited into
|
|
76
|
+
them; many do not, and must never be made to adjudicate framework, data
|
|
77
|
+
model, or algorithm choices they do not care about. Ask outcome
|
|
78
|
+
questions of everyone; raise a technical question only with a user who
|
|
79
|
+
has signalled they want to engage it.
|
|
80
|
+
|
|
81
|
+
Write 5–8 clarifying questions SPECIFIC to this request — never generic
|
|
82
|
+
ones, and weighted toward outcomes, not implementation. Good questions
|
|
83
|
+
force a decision the user does not realize they have not made:
|
|
71
84
|
- Who uses this, and what do they see first?
|
|
72
85
|
- When [specific failure you can foresee] happens, what is the right
|
|
73
86
|
behavior?
|
|
@@ -81,23 +94,49 @@ single line, then ask the next. Never present the whole list at once —
|
|
|
81
94
|
one decision at a time keeps the user thinking instead of skimming. If
|
|
82
95
|
an answer opens a new gap, follow up before moving on.
|
|
83
96
|
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
97
|
+
Feature inspiration (optional — new product ideas only; skip for bug
|
|
98
|
+
fixes, refactors, and changes to existing code): after the questions,
|
|
99
|
+
propose 3–5 battle-tested patterns drawn from comparable successful
|
|
100
|
+
products that would strengthen THIS idea — e.g. streaks/gamification
|
|
101
|
+
(Duolingo), community flagging (Waze), neighborhood identity
|
|
102
|
+
(Nextdoor), trust badges (Bumble), ephemeral prompts (BeReal). For each:
|
|
103
|
+
name the source, the pattern, and one line on why it fits this product.
|
|
104
|
+
Do not invent a long list — quality over quantity, and only patterns
|
|
105
|
+
that genuinely serve the product. Then triage each accepted pattern WITH
|
|
106
|
+
the user into a release slice (see PHASE 3): is it part of the first
|
|
107
|
+
release, or a later one? Everything the user wants stays in the spec —
|
|
108
|
+
nothing is discarded for being "later." Only patterns the user rejects
|
|
109
|
+
outright go in Scope "Out of scope."
|
|
110
|
+
|
|
111
|
+
Scope discipline: capture the FULL outcome the user wants — do not push
|
|
112
|
+
them toward a smaller product than they intend. Most people are specing
|
|
113
|
+
a complete app, not a minimum one, and that is correct. The only real
|
|
114
|
+
failure is handing a builder one large undifferentiated task list with
|
|
115
|
+
no order. So when scope is large, reflect the full feature set back and
|
|
116
|
+
sequence it WITH the user into ordered release slices (PHASE 3):
|
|
117
|
+
everything intended stays in the spec; the slices only decide build
|
|
118
|
+
order, with slice 1 a walking skeleton a real user can use. Order
|
|
119
|
+
features — do not cut the ones the user wants.
|
|
89
120
|
|
|
90
121
|
Then choose the tier and tell the user which and why:
|
|
91
122
|
- lite — small or low-risk work; the one-page spec.
|
|
92
123
|
- full — work that is medium/high risk, touches existing code, or has
|
|
93
124
|
architectural consequences; adds decomposition, architecture lock,
|
|
94
|
-
change surface, and edge cases.
|
|
125
|
+
navigation/screen map, change surface, and edge cases.
|
|
95
126
|
When unsure, choose full.
|
|
96
127
|
|
|
97
128
|
PHASE 3 — DRAFT
|
|
98
129
|
Fill the tier template below completely. Rules:
|
|
99
|
-
- Every Mechanism Decision commits to exactly ONE approach.
|
|
100
|
-
|
|
130
|
+
- Every Mechanism Decision commits to exactly ONE approach. Split gaps
|
|
131
|
+
by layer: a product/outcome gap (what a feature should do, who it is
|
|
132
|
+
for) is the user's to answer — ask them, never guess. A purely
|
|
133
|
+
technical or architectural choice (stack, framework, data model,
|
|
134
|
+
algorithm, auth mechanism) is yours: decide it from the captured
|
|
135
|
+
outcomes and sound engineering practice, and record it as a locked
|
|
136
|
+
decision with a one-line rationale. Do not push these onto a
|
|
137
|
+
non-technical user, and do not leave them as open questions — consult
|
|
138
|
+
the user on a technical choice only when they have signalled they want
|
|
139
|
+
to own it. Never leave a mechanism unresolved.
|
|
101
140
|
- Acceptance criteria are binary and left unchecked.
|
|
102
141
|
- full tier in an existing repository: the Change Surface table lists
|
|
103
142
|
every file the work touches; the builder may not go outside it.
|
|
@@ -163,7 +202,7 @@ A verdict without citation is treated as NO_GO — do not assert PASS without ev
|
|
|
163
202
|
**Dimensions:**
|
|
164
203
|
|
|
165
204
|
1. **Binary acceptance criteria** — are all sub-task ACs measurable and unambiguous? Are any ACs pre-checked (- [x]) in the draft, which is always invalid? If the Deliverable section defines a quantitative quality bar, the Acceptance Criteria section must include at least one AC that directly enforces that bar (same metric family and threshold intent). Otherwise, FAIL.
|
|
166
|
-
2. **Scope coherence** — are in-scope and out-of-scope boundaries in the Scope section clearly stated and non-contradictory? Check for conflicts between conceptual terminology (e.g., state names, entity names used in descriptions) and persisted/modelled representations (e.g., enums, schemas, data shapes). Any mismatch is a HARD_FAIL.
|
|
205
|
+
2. **Scope coherence** — are in-scope and out-of-scope boundaries in the Scope section clearly stated and non-contradictory? Check for conflicts between conceptual terminology (e.g., state names, entity names used in descriptions) and persisted/modelled representations (e.g., enums, schemas, data shapes). Any mismatch is a HARD_FAIL. Do not penalize a spec for being large or ambitious — a complete-product scope is legitimate; sequencing is checked separately in dimension 4, and a big spec is not a defect.
|
|
167
206
|
3. **Constraint sufficiency** — does the Scope Out-of-scope list cover the key risks? Check that the must-not constraints are explicit and complete enough to prevent the most likely forms of scope creep and builder drift for this specific request.
|
|
168
207
|
4. **Decomposition realism** — can each sub-task be completed within 2 hours by a skilled agent? Check that sub-task dependencies are stated explicitly (if task B requires task A's output, that must be documented). If the Deliverable section defines a benchmark/dataset path, at least one sub-task must explicitly own creating or curating that benchmark artifact. For greenfield full-tier specs: check that sub-tasks are grouped into numbered release slices and that slice 1 forms a complete, independently usable end-to-end core. Missing slices, or a slice 1 that a real user could not use on its own, is a SOFT_FAIL.
|
|
169
208
|
5. **Start-without-clarification viability** — can an agent begin immediately with the context provided, without asking the human for more information?
|
|
@@ -171,7 +210,7 @@ A verdict without citation is treated as NO_GO — do not assert PASS without ev
|
|
|
171
210
|
7. **Mechanism lock** — does every core flow (data pipeline, primary algorithm, key architecture choice) commit to exactly ONE implementation approach? Scan for "e.g.", "or", "could", "might", "such as" in Deliverable, Scope, Mechanism Decisions, and Task Decomposition sections. If any of these offer multiple options without making an explicit decision, that is a HARD_FAIL — a spec that leaves the mechanism unresolved forces the builder to choose architecture, creating drift in multi-builder workflows. Additional lock checks: (a) external service lock requires concrete vendor/model (env var names alone are not sufficient), (b) auth lock requires token/session type plus expiry policy, (c) endpoint lists without request/response field shapes are SOFT_FAIL. Option-language scan: flag any "could use X or Y", "such as X or Y", or "(e.g., X or Y)" in Mechanism Decisions that does not commit to a single choice. Unresolved-threshold scan: flag any comparison of the form "if X >= threshold" or "score < threshold" where "threshold" is not replaced by a concrete numeric value.
|
|
172
211
|
8. **Convergence declaration** — does the spec include a \`## Spec Convergence\` section with \`open_questions: 0\` and \`ambiguities_remaining: 0\`? If the section is absent, or either value is non-zero, or \`ready_for_build\` is "no", that is a HARD_FAIL. This is the formal GO gate — a spec with declared open questions is not agent-ready regardless of how well the other sections are written.
|
|
173
212
|
9. **Adversarial gap scan** — does the spec include an \`## Edge Cases and Failure Modes\` section that is substantively filled? Steelman the spec as a builder who will follow it exactly: what will you hit mid-execution that the spec does not answer? What implicit assumption is baked in but undeclared? What failure mode from the Nimai taxonomy (scope creep, hallucinated completion, intent drift, context collapse, runaway cost, overconfident output) does the spec not address? For mobile/capture flows, explicitly check offline/no-network behavior at capture time and retry/sync handling. An absent or blank section is a HARD_FAIL for full-tier specs. Placeholder-only content (\`___\`) is treated as absent.
|
|
174
|
-
10. **Architecture completeness** — for full-tier coding specs, does the spec include \`## Architecture Lock\` with all required fields resolved: Persistence layer, File/object storage, External services + env vars, API/trigger flow, Entity states and transitions, Auth? Any missing field, blank placeholder, or \`TBD\` is a HARD_FAIL. For lite-tier or non-coding specs, this is NOTE-only advisory. Also check the \`## Change Surface\` section for full-tier specs in existing repositories: the table must list every file the work touches; an empty table or missing section for a brownfield spec is a HARD_FAIL. Module-rule contradiction scan: if an Architecture Lock section declares a strict import chain (e.g., A → B → C → D) and a module boundary line says a layer "may call" a target not in its direct successor set, that is a HARD_FAIL.
|
|
213
|
+
10. **Architecture completeness** — for full-tier coding specs, does the spec include \`## Architecture Lock\` with all required fields resolved: Persistence layer, File/object storage, External services + env vars, API/trigger flow, Entity states and transitions, Auth, Security / authorization rules? Any missing field, blank placeholder, or \`TBD\` is a HARD_FAIL. Specifically: auth method alone is insufficient — the spec must also define authorization rules (who can read, write, and delete each resource, and under what conditions). For Firebase/Firestore/Supabase specs, this means explicit security rules for each collection and storage bucket. Auth without authorization is a HARD_FAIL. For lite-tier or non-coding specs, this is NOTE-only advisory. Also check for a \`## Navigation / Screen Map\` section: for full-tier web or mobile specs with multiple views, routes must be listed with auth requirements per route; a missing navigation map when the spec describes multiple distinct views is a SOFT_FAIL. Also check the \`## Change Surface\` section for full-tier specs in existing repositories: the table must list every file the work touches; an empty table or missing section for a brownfield spec is a HARD_FAIL. Module-rule contradiction scan: if an Architecture Lock section declares a strict import chain (e.g., A → B → C → D) and a module boundary line says a layer "may call" a target not in its direct successor set, that is a HARD_FAIL.
|
|
175
214
|
|
|
176
215
|
## Severity classification
|
|
177
216
|
|
package/dist/prompts.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":";AAAA;;;;;;;GAOG;;AAYH,
|
|
1
|
+
{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":";AAAA;;;;;;;GAOG;;AAYH,8CAoJC;AAeD,sCA4GC;AAOD,oCAgBC;AAhTD;;;;;;;;;GASG;AACH,SAAgB,iBAAiB,CAC/B,OAAe,EACf,QAAgB,EAChB,YAAoB,EACpB,YAAoB;IAEpB,MAAM,UAAU,GAAG,+BAA+B,YAAY,iCAAiC,YAAY,EAAE,CAAC;IAE9G,OAAO;;;;WAIE,OAAO;cACJ,QAAQ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAsIpB,UAAU,EAAE,CAAC;AACf,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,SAAgB,aAAa,CAAC,WAAmB;IAC/C,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA0GP,WAAW,EAAE,CAAC;AAChB,CAAC;AAED;;;;GAIG;AACH,SAAgB,YAAY,CAAC,WAAmB;IAC9C,OAAO;;;;;;;;;;;;;;EAcP,WAAW,EAAE,CAAC;AAChB,CAAC"}
|