neuvikon 0.2.26 → 0.2.28

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(/\/+$/, "");
 }
@@ -828,14 +856,22 @@ 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 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:
+
+- 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.
+- 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.
+
+If your CLI doesn't expose a way to change model or effort mid-session,
+skip this and just work the ticket.
 
 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
@@ -955,16 +991,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.26",
+  "version": "0.2.28",
   "description": "Tell Neuvikon which ticket your coding agent is working on.",
   "keywords": [
     "neuvikon",