@novare-technologies/nvaid 0.2.3 → 0.2.4

package/dist/cli.js

@@ -119,6 +119,18 @@ function aidlcRootFor(agent) {
   return "nvaid/rules";
 }
 function withHeader(body) {
+  if (body.startsWith("---\n")) {
+    const end = body.indexOf("\n---", 4);
+    if (end !== -1) {
+      const closeLineEnd = body.indexOf("\n", end + 1);
+      const cut = closeLineEnd === -1 ? body.length : closeLineEnd + 1;
+      const front = body.slice(0, cut);
+      const rest = body.slice(cut);
+      return `${front}
+${DO_NOT_EDIT}
+${rest}`;
+    }
+  }
   return `${DO_NOT_EDIT}
 
 ${body}`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@novare-technologies/nvaid",
-  "version": "0.2.3",
+  "version": "0.2.4",
   "description": "nvaid — one CLI that installs an AI-DLC skills-and-workflow toolkit into any coding agent, and houses intents, config, and the design-code dictionary in a single nvaid/ folder.",
   "type": "module",
   "bin": {

package/templates/nvaid/config.yml

@@ -84,4 +84,4 @@ context: ""
 
 # nvaid version this repo was last generated against. `nvaid validate` compares the
 # installed CLI version to this and flags drift.
-generated_with: "0.2.3"
+generated_with: "0.2.4"

package/templates/rules/ISSUE-TRACKER-TEMPLATE.md

@@ -12,7 +12,7 @@ status: draft
 **What this file is:** the field shape and creation rules for how Fig. 2's Intent-to-Release
 artifacts show up in Jira or GitHub Projects — one Epic per Intent, one Story or Bug per
 Unit of Work, bundled for shipping by Release Checkpoint rather than by sprint — so the
-tracker and the `aidlc-docs/` artifacts never disagree about what was decided.
+tracker and the `nvaid/` artifacts never disagree about what was decided.
 
 **What this file is not:** not a replacement for `intent.md`, `unit-breakdown.md`, or any
 contract file. The tracker is the *tracking* layer — status, ownership, checkpoint
@@ -21,7 +21,7 @@ agreed, in full, versioned in git. A ticket field never carries content that onl
 the ticket; if it's worth writing down, it's worth writing into the file the AI agent
 actually reads, and the ticket links to it.
 
-**Companion files:** [PROJECT-RULES.md](./PROJECT-RULES.md) §7 rule 11 is the operating
+**Companion files:** [PROJECT-RULES.md](../PROJECT-RULES.md) §7 rule 11 is the operating
 rule this file implements. [unit-breakdown-rules.md](./unit-breakdown-rules.md) governs
 *how* a Unit of Work is decided and classified before it ever becomes the ticket
 described here. The worked example in `docs/templates/samples/` is what every link below
@@ -45,7 +45,7 @@ A ticket holds three kinds of information, and only two of them belong in ticket
 2. **Links to content** (the Intent, the contracts, the design docs) — belongs in ticket
    fields, as links, never as pasted text.
 3. **The content itself** (what the API contract actually says, what the acceptance
-   criteria actually are) — belongs *only* in the `aidlc-docs/` artifact. Pasting it into
+   criteria actually are) — belongs *only* in the `nvaid/` artifact. Pasting it into
    a ticket description creates a second copy that drifts the first time either one is
    edited without the other, and the AI agent isn't the one reading the ticket anyway — it
    reads the file.

package/templates/rules/unit-breakdown-rules.md

@@ -20,7 +20,7 @@ governs that), not the ceremony's choreography (the AI-Native Engineering Model'
 one specific judgment call: given an approved Intent, what its Units of Work are.
 
 **Companion files:** [ISSUE-TRACKER-TEMPLATE.md](./ISSUE-TRACKER-TEMPLATE.md) is where a
-Unit of Work, once decided here, becomes a ticket. [PROJECT-RULES.md](./PROJECT-RULES.md)
+Unit of Work, once decided here, becomes a ticket. [PROJECT-RULES.md](../PROJECT-RULES.md)
 §7 rule 12 is the operating rule this file implements.
 
 ---

package/templates/skills/r3-analytics/SKILL.md

@@ -2,7 +2,7 @@
 name: r3-analytics
 description: Gathers checkpoint-to-checkpoint performance indicators (lead time, gate pass rate, escaped defects, Known Gaps) for R3's Retrospective step. Use when asked to run the R3 Analytics Skill or prepare Retrospective data after a Release Checkpoint ships.
 invoked_by: R3 (Ceremony 4), triggered by a Release Checkpoint shipping
-output: file — process/retro-<checkpoint>.md
+output: file — nvaid/process/retro-<checkpoint>.md
 ---
 
 # R3 Analytics Skill
@@ -17,8 +17,8 @@ looks at, so "what does the data actually say" has an answer ready the moment R3
    escaped defects logged against this checkpoint's Units.
 3. Roll up every Known Gap logged across this checkpoint's Quality Architecture
    Contracts — a gap doesn't disappear just because the checkpoint shipped.
-4. Draft `process/retro-<checkpoint>.md` with the above, structured for the room to read
-   before proposing Regenerate edits.
+4. Draft `nvaid/process/retro-<checkpoint>.md` with the above, structured for the room to
+   read before proposing Regenerate edits.
 
 ## Boundaries