nimai-core 0.5.0 → 0.5.2
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 +8 -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 +44 -10
- package/dist/prompts.js.map +1 -1
- package/package.json +1 -1
package/data/nimai-spec-full.md
CHANGED
|
@@ -38,6 +38,14 @@
|
|
|
38
38
|
- API/trigger flow:
|
|
39
39
|
- Entity states and transitions:
|
|
40
40
|
- Auth:
|
|
41
|
+
- 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):
|
|
42
|
+
|
|
43
|
+
## Navigation / Screen Map
|
|
44
|
+
*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."*
|
|
45
|
+
|
|
46
|
+
| Route / View | Description | Auth required? |
|
|
47
|
+
|---|---|---|
|
|
48
|
+
| | | |
|
|
41
49
|
|
|
42
50
|
## Change Surface
|
|
43
51
|
*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,CAwGR;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
|
@@ -30,12 +30,31 @@ implementing it — write no application code during this protocol.
|
|
|
30
30
|
Request: ${request}
|
|
31
31
|
Repository: ${repoPath}
|
|
32
32
|
|
|
33
|
-
Run the
|
|
34
|
-
|
|
33
|
+
Run the phases in order; say which phase you are in as you work.
|
|
34
|
+
Phase 0 is optional; phases 1–4 are mandatory.
|
|
35
|
+
|
|
36
|
+
PHASE 0 — MARKET SCAN (optional)
|
|
37
|
+
Run this phase when you have web search available AND either:
|
|
38
|
+
(a) the request is a brand-new product idea, or
|
|
39
|
+
(b) the user asks for it in any form — "is this viable", "does this
|
|
40
|
+
already exist", "is this project worth continuing" — including for
|
|
41
|
+
an existing codebase whose direction they are unsure about.
|
|
42
|
+
Run a few searches to learn what already exists, where the gap is, and
|
|
43
|
+
whether the need is real. Share a short summary and confirm the idea —
|
|
44
|
+
or a sharpened or redirected version of it — is worth specing before
|
|
45
|
+
you interview. For an existing project this may mean a change of
|
|
46
|
+
trajectory: say so plainly if the evidence points that way. Skip this
|
|
47
|
+
phase for routine changes to existing code, or when you have no web
|
|
48
|
+
access.
|
|
35
49
|
|
|
36
50
|
PHASE 1 — EXPLORE
|
|
37
|
-
|
|
38
|
-
|
|
51
|
+
First, confirm the Repository path above is the project this spec is
|
|
52
|
+
for — the folder where the code lives, or will live for a new idea. If
|
|
53
|
+
it points anywhere else (a parent directory, your current working
|
|
54
|
+
directory by accident, an unrelated repository), stop and tell the
|
|
55
|
+
user to re-run with the correct path before going further.
|
|
56
|
+
Then use your own tools to learn the ground truth before asking the
|
|
57
|
+
user anything:
|
|
39
58
|
- Read the manifest and build files (package.json or equivalent) for
|
|
40
59
|
stack, dependencies, and scripts.
|
|
41
60
|
- Read the README and any schema, model, or type definition files.
|
|
@@ -56,14 +75,23 @@ user does not realize they have not made:
|
|
|
56
75
|
which one?
|
|
57
76
|
- What is explicitly NOT part of this?
|
|
58
77
|
- How will you know it works — what would you check by hand?
|
|
59
|
-
Skip any question the request already answers. Ask
|
|
60
|
-
|
|
78
|
+
Skip any question the request already answers. Ask the questions ONE AT
|
|
79
|
+
A TIME: ask one, wait for the answer, acknowledge the decision in a
|
|
80
|
+
single line, then ask the next. Never present the whole list at once —
|
|
81
|
+
one decision at a time keeps the user thinking instead of skimming. If
|
|
82
|
+
an answer opens a new gap, follow up before moving on.
|
|
83
|
+
|
|
84
|
+
Scope discipline: if scope grows during the interview — the user keeps
|
|
85
|
+
adding features, or you suggest some and they say yes to all — do not
|
|
86
|
+
silently absorb it. Before drafting, reflect the full feature list back
|
|
87
|
+
and ask which items can move to v2 so v1 stays shippable. A small spec
|
|
88
|
+
that ships beats a complete one that doesn't.
|
|
61
89
|
|
|
62
90
|
Then choose the tier and tell the user which and why:
|
|
63
91
|
- lite — small or low-risk work; the one-page spec.
|
|
64
92
|
- full — work that is medium/high risk, touches existing code, or has
|
|
65
93
|
architectural consequences; adds decomposition, architecture lock,
|
|
66
|
-
change surface, and edge cases.
|
|
94
|
+
navigation/screen map, change surface, and edge cases.
|
|
67
95
|
When unsure, choose full.
|
|
68
96
|
|
|
69
97
|
PHASE 3 — DRAFT
|
|
@@ -73,6 +101,12 @@ Fill the tier template below completely. Rules:
|
|
|
73
101
|
- Acceptance criteria are binary and left unchecked.
|
|
74
102
|
- full tier in an existing repository: the Change Surface table lists
|
|
75
103
|
every file the work touches; the builder may not go outside it.
|
|
104
|
+
- full tier greenfield: add a "Slice" column to the Task Decomposition
|
|
105
|
+
table and group the sub-tasks into numbered release slices. Slice 1
|
|
106
|
+
is the walking skeleton — the smallest set of sub-tasks that makes
|
|
107
|
+
the core flow work end to end for a real user. Later slices layer on
|
|
108
|
+
(trust, gamification, polish). The full vision belongs in the spec;
|
|
109
|
+
the slices declare the order it ships in.
|
|
76
110
|
- No placeholder text or blank required fields may remain.
|
|
77
111
|
Save the spec to specs/<short-name>.md with the tier marker as the
|
|
78
112
|
final line of the file.
|
|
@@ -129,15 +163,15 @@ A verdict without citation is treated as NO_GO — do not assert PASS without ev
|
|
|
129
163
|
**Dimensions:**
|
|
130
164
|
|
|
131
165
|
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.
|
|
132
|
-
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.
|
|
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. Additionally, for greenfield specs: assess scope realism — if the v1 in-scope list is larger than a small team could ship as a first release, issue a SOFT_FAIL naming the feature clusters that could move to v2 without breaking the core flow. A spec can be internally coherent and still too big to ship.
|
|
133
167
|
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.
|
|
134
|
-
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.
|
|
168
|
+
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.
|
|
135
169
|
5. **Start-without-clarification viability** — can an agent begin immediately with the context provided, without asking the human for more information?
|
|
136
170
|
6. **Internal consistency** — are terms, names, and concepts used consistently throughout the spec? Flag any case where the same entity is described differently in different sections (e.g., "webhook event" in Scope, "push notification" in Acceptance Criteria — are these the same thing?). Treat data-type/precision mismatches as consistency defects (e.g., float vs decimal/cents representation). Also FAIL if obvious template artifact text remains (example guidance that should have been replaced by project-specific content).
|
|
137
171
|
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.
|
|
138
172
|
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.
|
|
139
173
|
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.
|
|
140
|
-
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.
|
|
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, 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.
|
|
141
175
|
|
|
142
176
|
## Severity classification
|
|
143
177
|
|
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,8CA6GC;AAeD,sCA4GC;AAOD,oCAgBC;AAzQD;;;;;;;;;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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA+FpB,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"}
|