nimai-core 0.5.0 → 0.5.1

package/dist/prompts.d.ts.map

@@ -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,CAsER;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CA4GzD;AAED;;;;GAIG;AACH,wBAAgB,YAAY,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAgBxD"}
+{"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

@@ -30,12 +30,31 @@ implementing it — write no application code during this protocol.
 Request: ${request}
 Repository: ${repoPath}
 
-Run the four phases in order. Do not skip a phase; say which phase you
-are in as you work.
+Run the phases in order; say which phase you are in as you work.
+Phase 0 is optional; phases 1–4 are mandatory.
+
+PHASE 0 — MARKET SCAN (optional)
+Run this phase when you have web search available AND either:
+(a) the request is a brand-new product idea, or
+(b) the user asks for it in any form — "is this viable", "does this
+    already exist", "is this project worth continuing" — including for
+    an existing codebase whose direction they are unsure about.
+Run a few searches to learn what already exists, where the gap is, and
+whether the need is real. Share a short summary and confirm the idea —
+or a sharpened or redirected version of it — is worth specing before
+you interview. For an existing project this may mean a change of
+trajectory: say so plainly if the evidence points that way. Skip this
+phase for routine changes to existing code, or when you have no web
+access.
 
 PHASE 1 — EXPLORE
-Use your own tools to learn the ground truth before asking the user
-anything:
+First, confirm the Repository path above is the project this spec is
+for — the folder where the code lives, or will live for a new idea. If
+it points anywhere else (a parent directory, your current working
+directory by accident, an unrelated repository), stop and tell the
+user to re-run with the correct path before going further.
+Then use your own tools to learn the ground truth before asking the
+user anything:
 - Read the manifest and build files (package.json or equivalent) for
   stack, dependencies, and scripts.
 - Read the README and any schema, model, or type definition files.
@@ -56,8 +75,17 @@ user does not realize they have not made:
   which one?
 - What is explicitly NOT part of this?
 - How will you know it works — what would you check by hand?
-Skip any question the request already answers. Ask all questions in one
-message and wait for the answers.
+Skip any question the request already answers. Ask the questions ONE AT
+A TIME: ask one, wait for the answer, acknowledge the decision in a
+single line, then ask the next. Never present the whole list at once —
+one decision at a time keeps the user thinking instead of skimming. If
+an answer opens a new gap, follow up before moving on.
+
+Scope discipline: if scope grows during the interview — the user keeps
+adding features, or you suggest some and they say yes to all — do not
+silently absorb it. Before drafting, reflect the full feature list back
+and ask which items can move to v2 so v1 stays shippable. A small spec
+that ships beats a complete one that doesn't.
 
 Then choose the tier and tell the user which and why:
 - lite — small or low-risk work; the one-page spec.
@@ -73,6 +101,12 @@ Fill the tier template below completely. Rules:
 - Acceptance criteria are binary and left unchecked.
 - full tier in an existing repository: the Change Surface table lists
   every file the work touches; the builder may not go outside it.
+- full tier greenfield: add a "Slice" column to the Task Decomposition
+  table and group the sub-tasks into numbered release slices. Slice 1
+  is the walking skeleton — the smallest set of sub-tasks that makes
+  the core flow work end to end for a real user. Later slices layer on
+  (trust, gamification, polish). The full vision belongs in the spec;
+  the slices declare the order it ships in.
 - No placeholder text or blank required fields may remain.
 Save the spec to specs/<short-name>.md with the tier marker as the
 final line of the file.
@@ -129,9 +163,9 @@ A verdict without citation is treated as NO_GO — do not assert PASS without ev
 **Dimensions:**
 
 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.
-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.
+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.
 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.
-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.
+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.
 5. **Start-without-clarification viability** — can an agent begin immediately with the context provided, without asking the human for more information?
 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).
 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.

package/dist/prompts.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":";AAAA;;;;;;;GAOG;;AAYH,8CA2EC;AAeD,sCA4GC;AAOD,oCAgBC;AAvOD;;;;;;;;;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;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6DpB,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"}
+{"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"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nimai-core",
-  "version": "0.5.0",
+  "version": "0.5.1",
   "description": "Nimai core library — template loading, lint engine, context extraction. No LLM dependencies.",
   "keywords": [
     "nimai",