neuvikon 0.2.27 → 0.2.29

package/dist/index.mjs

@@ -22,11 +22,21 @@ var NetworkError = class extends Error {
 };
 const TIMEOUT_MS = 15e3;
 /**
-* The one place an HTTP failure becomes a typed error. Callers decide what a
-* failure means — a hook wrapping the agent's turn wants to swallow it, `login`
-* wants to shout about it.
+* A long-running ticket's `stop`/`report` calls matter more than a quick
+* command's — losing one of those to a blip on a flaky connection is what
+* leaves a session "active" server-side but silently stale on the board,
+* since nothing else will ever tell the server this session ended. Three
+* tries with a short, fixed backoff absorbs a transient blip (DNS hiccup,
+* one dropped packet) without retrying forever: a genuinely dead connection
+* still fails after three `TIMEOUT_MS` waits plus two short delays, same as
+* it always would have, just with two extra chances to succeed first.
 */
-async function post(url, path, body) {
+const RETRY_ATTEMPTS = 3;
+const RETRY_DELAY_MS = 1e3;
+function sleep$1(ms) {
+	return new Promise((resolve) => setTimeout(resolve, ms));
+}
+async function postOnce(url, path, body) {
 	let response;
 	try {
 		response = await fetch(`${url}${path}`, {
@@ -43,6 +53,24 @@ async function post(url, path, body) {
 	if (!response.ok) throw new ApiError(typeof error === "string" ? error : `Request failed with status ${response.status}`, response.status);
 	return payload;
 }
+/**
+* The one place an HTTP failure becomes a typed error. Callers decide what a
+* failure means — a hook wrapping the agent's turn wants to swallow it, `login`
+* wants to shout about it.
+*
+* Retries only on `NetworkError` — the request never reached the server, so
+* trying again can only help. An `ApiError` means the server answered (a bad
+* token, an unknown ticket, a validation failure); retrying that gets the
+* same answer every time, so it still fails on the first try.
+*/
+async function post(url, path, body) {
+	for (let attempt = 1;; attempt++) try {
+		return await postOnce(url, path, body);
+	} catch (error) {
+		if (!(error instanceof NetworkError) || attempt >= RETRY_ATTEMPTS) throw error;
+		await sleep$1(RETRY_DELAY_MS);
+	}
+}
 function normalizeUrl(url) {
 	return url.trim().replace(/\/+$/, "");
 }
@@ -823,27 +851,30 @@ const START_MARKER = "<!-- neuvikon:start -->";
 const END_MARKER = "<!-- neuvikon:end -->";
 const INSTRUCTION_BODY = `## Neuvikon ticket tracking
 
-When the user hands you a Neuvikon ticket — text beginning with a reference like
-\`EWWQ-1:\` — run this before you start working on it:
-
-    npx neuvikon start --ticket EWWQ-1
-
-Before doing anything else, judge how difficult the ticket actually is, and
-match both your model and your reasoning effort to it instead of defaulting
-to maximum for everything:
+**The moment you receive a Neuvikon ticket — text beginning with a reference
+like \`EWWQ-1:\` — before reading any file, before running \`start\`, before
+anything else: judge its difficulty and act on it.** This is a real step, not
+background bookkeeping — if your CLI supports switching model or reasoning
+effort mid-session (Claude Code: \`/model\`, \`/effort\`; Codex: \`/model\`,
+\`/reasoning\`), the command to do that is the literal first thing you send,
+on its own, before you touch the ticket:
 
 - 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 if your CLI supports doing so mid-session (e.g. \`/model haiku\`), and
-  drop reasoning effort to its lowest setting (e.g. \`/effort low\` in Claude
-  Code, \`/reasoning low\` in Codex). There's no reason to spend a frontier
-  model thinking hard about something this small.
+  trivial styling tweak, a one-line config change: send \`/model haiku\` (or
+  your CLI's equivalent cheap/fast model) and \`/effort low\` (or
+  \`/reasoning low\`) right now, as their own messages, before doing anything
+  else. There's no reason to spend a frontier model thinking hard about
+  something this small, and downgrading after you've already started reading
+  code is too late to save anything.
 - Needs real design judgment, touches multiple systems, or you're unsure:
   stay on your current model and effort level — don't downgrade either just
   to save cost on something that actually needs it.
+- Your CLI doesn't expose a way to change model or effort mid-session: skip
+  this and go straight to the ticket.
 
-If your CLI doesn't expose a way to change model or effort mid-session,
-skip this and just work the ticket.
+Only after that's decided, run this before you start working on the ticket:
+
+    npx neuvikon start --ticket EWWQ-1
 
 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
@@ -963,16 +994,23 @@ Then decide, based on what's actually true, not on finishing your turn:
       npx neuvikon comment --ticket EWWQ-1 --text "Handing off — blocked on design"
 
 A ticket that isn't actually finished should never land on a terminal column
-just because you're done for now. When you finish that ticket, or the user
-moves you to a different one, also run:
+just because you're done for now.
+
+**Whenever you stop working a ticket — finished or not — \`move\`/\`comment\`
+always comes first, \`stop\` always comes last.** \`stop\` only tells the team
+you're no longer working on it; it does not move the ticket, and running it
+before the move leaves the board showing stale status for a ticket nobody's
+touching anymore. So the last two things you do on a ticket, in this order,
+are:
 
-    npx neuvikon stop
+1. \`npx neuvikon move ...\` (finished) or \`npx neuvikon comment ...\`
+   (not finished) — reflect the real status first.
+2. \`npx neuvikon stop\` — only after step 1, whether you're done or just
+   handing off.
 
-\`stop\` only tells the team you're no longer working on it — it does not move
-the ticket, since stopping and finishing are not the same thing. This is
-bookkeeping that tells the user's team which ticket you are on. You do not
-need to narrate these commands, and if one fails, carry on with the actual
-work — never let it block you.`;
+This is bookkeeping that tells the user's team which ticket you are on. You
+do not need to narrate these commands, and if one fails, carry on with the
+actual work — never let it block you.`;
 function instructionBlock() {
 	return `${START_MARKER}\n${INSTRUCTION_BODY}\n${END_MARKER}`;
 }

package/package.json

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