nimai-core 0.4.6 → 0.4.8

package/dist/prompts.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH;;;GAGG;AACH,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,EAAE,cAAc,EAAE,MAAM,GAAG,MAAM,CAkC5E;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CA6FzD;AAED;;;GAGG;AACH,wBAAgB,YAAY,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAgBxD"}
+{"version":3,"file":"prompts.d.ts","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH;;;GAGG;AACH,wBAAgB,YAAY,CAAC,OAAO,EAAE,MAAM,EAAE,cAAc,EAAE,MAAM,GAAG,MAAM,CAkC5E;AAED;;;;;;;;;;;;GAYG;AACH,wBAAgB,aAAa,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAkGzD;AAED;;;GAGG;AACH,wBAAgB,YAAY,CAAC,WAAW,EAAE,MAAM,GAAG,MAAM,CAgBxD"}

package/dist/prompts.js

@@ -74,15 +74,15 @@ 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?
+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 Section 1.1 defines a quantitative quality bar, Section 1.4 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 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.
 3. **Constraint sufficiency** — do Must / Must-Not / Prefer / Escalate constraints cover the key risks?
-4. **Decomposition realism** — can each sub-task be completed within the stated 2-hour limit by a skilled agent? Check that sub-task dependencies are stated explicitly (if task B requires task A's output, that must be documented).
+4. **Decomposition realism** — can each sub-task be completed within the stated 2-hour limit 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 Section 1.1 defines a benchmark/dataset path, at least one sub-task must explicitly own creating or curating that benchmark artifact.
 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 ACs — are these the same thing?).
-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, Constraints, 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.
+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 ACs — 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, Constraints, 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.
 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.
-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 FORGE taxonomy (scope creep, hallucinated completion, intent drift, context collapse, runaway cost, overconfident output) does the spec not address? An absent or blank section is a HARD_FAIL for medium/high risk specs. Placeholder-only content (\`___\`) is treated as absent.
+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 FORGE 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 medium/high risk specs. Placeholder-only content (\`___\`) is treated as absent.
 10. **Architecture completeness** — for medium/high coding specs, does the spec include \`## 1.6 Architecture Lock\` with all required fields resolved: Persistence layer, File/object storage, External model/service + env var, API trigger flow, Entity status state machine, Auth implementation? Any missing field, blank placeholder, or \`TBD\` is a HARD_FAIL. For low/unknown/non-coding specs, this is NOTE-only advisory.
 
 ## Severity classification
@@ -96,24 +96,29 @@ A spec passes (passed: true) only if it has zero HARD_FAIL issues.
 
 ## Output format
 
-For each dimension, write:
+For each dimension, write exactly:
 **[PASS|FAIL] Dimension name** — one-sentence rationale. *Evidence: cite the specific section/line/text.*
 
-Then write a consolidated remediation list for all FAIL dimensions.
+Keep it brief: one sentence + one evidence citation per dimension. No preamble, no summaries, no commentary before or after the verdict block.
 
-Note: implementation correctness is explicitly out of scope for this review.
+Then write a consolidated remediation list for all FAIL dimensions.
 
-## Re-review closure requirement
+After writing the 10 dimensions, run one extra ambiguity sweep:
+- Ask: "Could two competent builders implement this spec in materially different ways while both claiming compliance?"
+- If yes, add those gaps as issues (SOFT_FAIL or HARD_FAIL based on impact) and include exact sections to fix.
+- If no, state one sentence: "No additional ambiguity gaps found in final sweep."
 
-If the user told you this is a re-review (the builder has fixed issues since the last verdict), check ## Review Closure before evaluating any dimension.
-Look for a section like:
+Note: implementation correctness is explicitly out of scope for this review.
 
-> ## Review Closure
-> | Issue | fixed_in_section | exact_text_changed | proof |
+## Re-review protocol
 
-**Any prior HARD_FAIL with no closure entry = automatic FAIL.**
-Do not evaluate the other dimensions until you confirm closure entries exist for all prior HARD_FAILs.
-If this is a first review (no prior verdict), skip this check.
+If this is a re-review (you were given the builder's fix summary):
+- Do NOT require any additional sections in the spec.
+- Do NOT require a Review Closure table or any tracking artifact.
+- Re-evaluate each previously-failed dimension directly against the current spec content.
+- Your evidence citation must quote or reference the specific text in the spec that shows the fix was applied.
+- If the fix is present, mark that dimension PASS. If it is absent or incomplete, mark it FAIL.
+- You are only authorized to evaluate the 10 dimensions defined above. Do not invent new dimensions, process gates, or required sections not in the FORGE spec template.
 
 ## Important
 
@@ -139,7 +144,7 @@ If the spec passes all dimensions with no HARD_FAIL issues, use:
 {"passed": true, "schema_version": "2", "issues": []}
 \`\`\`
 
-If and only if \`passed\` is false, immediately append this section after the verdict block:
+If \`issues\` is non-empty (including SOFT_FAIL/NOTE with \`passed: true\`), immediately append this section after the verdict block:
 
 ## Paste this to your builder session:
 

package/dist/prompts.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompts.js","sourceRoot":"","sources":["../src/prompts.ts"],"names":[],"mappings":";AAAA;;;;GAIG;;AAMH,oCAkCC;AAeD,sCA6FC;AAMD,oCAgBC;AAxKD;;;GAGG;AACH,SAAgB,YAAY,CAAC,OAAe,EAAE,cAAsB;IAClE,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6BP,cAAc,IAAI,2FAA2F;;;iBAG9F,OAAO,EAAE,CAAC;AAC3B,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,SAAgB,aAAa,CAAC,WAAmB;IAC/C,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA2FP,WAAW,EAAE,CAAC;AAChB,CAAC;AAED;;;GAGG;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;;;;GAIG;;AAMH,oCAkCC;AAeD,sCAkGC;AAMD,oCAgBC;AA7KD;;;GAGG;AACH,SAAgB,YAAY,CAAC,OAAe,EAAE,cAAsB;IAClE,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EA6BP,cAAc,IAAI,2FAA2F;;;iBAG9F,OAAO,EAAE,CAAC;AAC3B,CAAC;AAED;;;;;;;;;;;;GAYG;AACH,SAAgB,aAAa,CAAC,WAAmB;IAC/C,OAAO;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAgGP,WAAW,EAAE,CAAC;AAChB,CAAC;AAED;;;GAGG;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.4.6",
+  "version": "0.4.8",
   "description": "Nimai core library — template loading, lint engine, context extraction. No LLM dependencies.",
   "keywords": [
     "nimai",