neuvikon 0.2.24 → 0.2.26

package/dist/index.mjs

@@ -828,6 +828,15 @@ When the user hands you a Neuvikon ticket — text beginning with a reference li
 
     npx neuvikon start --ticket EWWQ-1
 
+Before doing anything else, judge how difficult the ticket actually is. If
+it's a small, mechanical change — swapping button placement, a copy/label
+edit, a trivial styling tweak, a one-line config change — switch to a
+cheaper/faster model for it if your CLI supports doing so mid-session (e.g.
+\`/model haiku\`): there's no reason to spend a frontier model's tokens on
+something that small. If it needs real design judgment, touches multiple
+systems, or you're unsure, stay on your current model — don't downgrade
+just to save cost on something that actually needs the stronger model.
+
 Before you start, and any time you need more context, read the ticket's
 project pages — this is the project's accumulated knowledge, not just this
 ticket's:
@@ -883,6 +892,42 @@ you're already touching doesn't need a ticket, and not everything you notice
 belongs on the board. File it when it's something the team would actually
 want to see and decide on — not for every passing thought.
 
+## Auditing the project on request
+
+Sometimes the ask isn't "work this ticket" but "find what's wrong with this
+project and file tickets for it" — a deliberate audit, not the incidental
+noticing above. Treat it as its own pass:
+
+- Nail down scope before filing anything: which project, and what kind of
+  gap ("security", "missing tests", "half-finished features", "tech debt")
+  — if the request is broad enough that guessing wrong means redoing the
+  whole pass, ask first.
+- Look for gaps you can point at, not vague impressions: missing auth
+  checks, silent failure paths, \`TODO\`/\`FIXME\` comments, untested new
+  logic, a doc that no longer matches the code, a feature that's built but
+  never wired in. State the concrete failure each one causes, not just a
+  category label — "returns undefined for an anonymous user and nothing
+  catches it" beats "improve error handling."
+- Check what's already tracked before filing anything new — a project's
+  pages and open tickets are exactly what an earlier pass (yours or someone
+  else's) may have already found:
+
+      npx neuvikon pages --ticket EWWQ-1
+      npx neuvikon board --ticket EWWQ-1
+
+  A gap that's already got a ticket gets a comment pointing at it, not a
+  duplicate.
+- File each real finding as its own ticket, not a sub-ticket of whatever
+  you were on — these are independent findings, not steps toward finishing
+  one ticket:
+
+      npx neuvikon create "Session cookie missing Secure flag" --ticket EWWQ-1
+
+  Put the concrete evidence in the description, not just the title.
+- Report back what actually landed — ref and a one-line title per ticket
+  filed — instead of a wall of prose. The ask was for tickets on the board,
+  not a summary in chat.
+
 Before you change the ticket's status, look at what columns this project's
 board actually has — they vary per project, and there may be no column
 literally called "Done":

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "neuvikon",
-  "version": "0.2.24",
+  "version": "0.2.26",
   "description": "Tell Neuvikon which ticket your coding agent is working on.",
   "keywords": [
     "neuvikon",