@skrr-ai/cli 0.1.9 → 0.1.11

package/dist/lib/daemonHandoff.js

@@ -0,0 +1,297 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.handOffToLocalDaemon = handOffToLocalDaemon;
+const node_child_process_1 = require("node:child_process");
+const data_provider_1 = require("@skrr-ai/data-provider");
+const config_1 = require("./config");
+const exec_oversky_1 = require("./exec-oversky");
+const keychain_1 = require("./keychain");
+/**
+ * Ceilings, not expectations. Both calls finish in milliseconds when anything is
+ * working; these exist so that when something is NOT working the login ends.
+ *
+ * The failure this prevents is the worst one available here: `skrr login` has
+ * already printed "Login successful", and an unbounded wait on a child process
+ * leaves the user staring at a terminal that will never return, with no way to
+ * tell a hung handoff from a slow one. A blocked keychain prompt, a daemon
+ * binary wedged on a lock, an NFS home directory — none of them are exotic, and
+ * all of them used to hang the command.
+ *
+ * The accept side gets the longer budget because it may have to unlock a
+ * keychain. Killing it mid-write is the cost, and it is the lesser one: the
+ * credential write is a few milliseconds at the end of that window, so a timeout
+ * overwhelmingly lands BEFORE it rather than during it, and `skrr daemon login`
+ * recovers either way.
+ */
+const PROBE_TIMEOUT_MS = 15_000;
+const ACCEPT_TIMEOUT_MS = 60_000;
+function runOversky(binary, args, opts) {
+    const { input, timeoutMs } = opts;
+    return new Promise((resolve) => {
+        // A Windows npm-global install ships a `.cmd` shim, which `spawn` cannot
+        // execute without a shell — Node fires ENOENT instead. `execOversky` has
+        // handled this since it was written; this function did not, so the handoff
+        // failed on EVERY Windows login and reported it as the daemon refusing the
+        // bundle. Restricted to the shim case so real binaries keep the argv-array
+        // exec path, which needs no quoting rules to be right.
+        const isWinShim = process.platform === 'win32' && /\.(cmd|bat)$/i.test(binary);
+        const child = (0, node_child_process_1.spawn)(binary, args, {
+            // stderr is CAPTURED, not discarded. Discarding it cost a debugging cycle
+            // on the first real run: the daemon exited non-zero with
+            // `OVERSKY_KEK_REQUIRED`, and all the user saw was "the daemon refused the
+            // handoff" — an outcome with its reason thrown away. A wrapper that hides
+            // the wrapped program's error is worse than one that does not wrap.
+            stdio: [input === undefined ? 'ignore' : 'pipe', 'pipe', 'pipe'],
+            ...(isWinShim ? { shell: true } : {}),
+        });
+        let stdout = '';
+        let stderr = '';
+        let settled = false;
+        const settle = (value) => {
+            if (settled)
+                return;
+            settled = true;
+            clearTimeout(timer);
+            resolve(value);
+        };
+        const timer = setTimeout(() => {
+            child.kill('SIGKILL');
+            settle({
+                ok: false,
+                stdout,
+                stderr: `timed out after ${Math.round(timeoutMs / 1000)}s`,
+            });
+        }, timeoutMs);
+        // Never hold the event loop open on the timer alone.
+        if (typeof timer.unref === 'function')
+            timer.unref();
+        child.stdout?.on('data', (c) => (stdout += String(c)));
+        child.stderr?.on('data', (c) => (stderr += String(c)));
+        child.on('error', (err) => settle({ ok: false, stdout, stderr: err.message }));
+        child.on('close', (code) => settle({ ok: code === 0, stdout, stderr }));
+        if (input !== undefined) {
+            // An EPIPE here is the child having already exited — its own exit code and
+            // stderr are the real diagnosis, and an unhandled stream error would
+            // instead crash the CLI one line after a successful login.
+            child.stdin?.on('error', () => {
+                /* reported by the close handler */
+            });
+            child.stdin?.end(input);
+        }
+    });
+}
+/**
+ * The profile flags to pass to `skrrd`, so both spawns land in the same tenancy
+ * the CLI is signed in to.
+ *
+ * A profile is the daemon's tenancy boundary — separate config, state, keychain
+ * namespace and service label. The CLI resolves its own; the daemon resolves its
+ * own, from `--profile` → `OVERSKY_PROFILE` → its `profile.lock` → `default`.
+ * Passing nothing let those two answers differ, and the failure was silent in the
+ * damaging direction: `skrr --profile work login` would mint against the id
+ * printed by whichever profile the daemon's lock happened to name, then write a
+ * work-profile credential over THAT profile's store.
+ *
+ * `skrr daemon login` already binds the profile this way (`bindToCliSession`);
+ * this is the same rule for the path that runs without being asked.
+ */
+function profileArgs() {
+    const profile = (0, keychain_1.getActiveProfile)();
+    return profile && profile !== keychain_1.DEFAULT_PROFILE ? ['--profile', profile] : [];
+}
+/**
+ * Parse the machine-readable line `accept-handoff --print-id` writes to stderr.
+ *
+ * Absent on a daemon that predates it, which is a normal state during a rollout
+ * and not an error — the caller degrades to the older, less careful behaviour
+ * rather than refusing.
+ */
+function parseIdProvenance(stderr) {
+    const line = stderr.split('\n').find((l) => l.includes('skrrd:accept-handoff'));
+    if (!line)
+        return {};
+    const idSource = /id-source=([A-Za-z0-9._:-]+)/.exec(line)?.[1];
+    const machineUuid = /machine-uuid=([A-Za-z0-9._:-]+)/.exec(line)?.[1];
+    // Any non-space run: this one is a URL, and a URL contains characters the
+    // other two never do.
+    const daemonServer = /server=(\S+)/.exec(line)?.[1];
+    return { idSource, machineUuid, daemonServer };
+}
+/**
+ * What actually changed on this machine, said out loud.
+ *
+ * A handoff can re-point the machine to a different ACCOUNT (you signed in as
+ * someone else) or a different DEPLOYMENT (your daemon was on dev, your CLI is
+ * on prod). Both are the feature working — the machine follows the human, and
+ * moving a dev-bound daemon to prod is the exact story this path was written for
+ * — and both are state changes an operator should watch happen rather than
+ * discover later, when a daemon they thought was on dev answers from prod.
+ *
+ * Degrades cleanly: an older server sends no account, an older daemon reports no
+ * server, and the sentence simply says less rather than guessing.
+ */
+function describeDelivery(opts) {
+    const parts = [];
+    parts.push(opts.accountLabel
+        ? `now signed in as ${opts.accountLabel} on ${(0, config_1.describeDeployment)(opts.cliBaseURL)}`
+        : 'the local daemon now has its own credential');
+    if (opts.daemonServer &&
+        canonicalServer(opts.daemonServer) !== canonicalServer(opts.cliBaseURL)) {
+        parts.push(`moved from ${(0, config_1.describeDeployment)(opts.daemonServer)}`);
+    }
+    return parts.join(', ');
+}
+/**
+ * Compare deployments, not spellings.
+ *
+ * `https://oversky.ai` and `https://skrr.ai` are one deployment under two names,
+ * and the first is still what every daemon installed before the cutover carries.
+ * Trimming and lowercasing alone would report a move on every login from every
+ * one of those machines — a warning that is wrong for the largest group of users
+ * who would see it, which is how a signal becomes noise. `canonicalizeKnownBaseURL`
+ * is the fold the rest of the CLI already compares through.
+ */
+function canonicalServer(url) {
+    return (0, config_1.canonicalizeKnownBaseURL)(url).trim().replace(/\/+$/, '').toLowerCase();
+}
+/** The most useful line of a failure, so a remedy can name the cause. */
+function firstMeaningfulLine(text) {
+    const line = text
+        .split('\n')
+        .map((l) => l.trim())
+        .find((l) => l &&
+        !l.startsWith('at ') &&
+        !/^[{}]/.test(l) &&
+        // The provenance line is a protocol between these two programs, not a
+        // diagnosis. Reporting it as one would answer "why did this fail?" with
+        // a machine's own bookkeeping.
+        !l.includes('skrrd:accept-handoff'));
+    return line ? line.slice(0, 160) : 'no output';
+}
+async function handOffToLocalDaemon(env = process.env, opts = {}) {
+    // Mirrors `OVERSKY_SKIP_DAEMON_BROKER` on the other direction. An operator
+    // deliberately running a daemon against a different deployment than their CLI is
+    // doing a legitimate thing, and this must not overrule it.
+    if (env.OVERSKY_SKIP_DAEMON_HANDOFF === '1' || env.SKRR_SKIP_DAEMON_HANDOFF === '1') {
+        return { status: 'skipped', detail: 'skipped by OVERSKY_SKIP_DAEMON_HANDOFF' };
+    }
+    // The daemon brokered this login, which means it just used its OWN credential
+    // against this server and that credential works. There is nothing to fix.
+    //
+    // Running anyway is not merely redundant, it is destructive: it mints a
+    // replacement, writes it over the working one, revokes the family the daemon is
+    // authenticated with, and restarts the process — killing whatever sessions it
+    // was running. `skrr login` on a healthy machine is the path where the least
+    // should happen, and it was the path where the most did.
+    if (opts.loginFlow === 'daemon-broker') {
+        return {
+            status: 'skipped',
+            detail: 'the local daemon brokered this login, so it already has a working credential',
+        };
+    }
+    const binary = (0, exec_oversky_1.findOverskyBinary)();
+    if (!binary) {
+        return { status: 'skipped', detail: 'no local daemon installed' };
+    }
+    // An older daemon has no `accept-handoff`, and spawning it would fail with
+    // commander's "unknown command" rather than anything a reader could act on. A
+    // CLI that outruns the daemon on the machine is the normal case during a
+    // staged rollout, not an error.
+    const supported = await (0, exec_oversky_1.overskySupportsSubcommand)('accept-handoff');
+    if (supported === false) {
+        return {
+            status: 'skipped',
+            detail: 'the installed daemon predates `accept-handoff`; run `skrr daemon login` once',
+        };
+    }
+    // Ask the daemon which id it will bind, rather than deriving it here. The id
+    // comes from cwd + profile, and a second copy of that derivation in the CLI
+    // would drift — producing a credential minted for a daemon that does not exist,
+    // which is indistinguishable from a login that simply did not work.
+    const printed = await runOversky(binary, ['accept-handoff', '--print-id', ...profileArgs()], {
+        timeoutMs: PROBE_TIMEOUT_MS,
+    });
+    const daemonId = printed.ok ? printed.stdout.trim() : '';
+    if (!daemonId) {
+        return {
+            status: 'failed',
+            detail: `could not read the local daemon id — ${firstMeaningfulLine(printed.stderr)}`,
+        };
+    }
+    const { idSource, machineUuid, daemonServer } = parseIdProvenance(printed.stderr);
+    // A well-formed id is not the same as a real daemon. With no service installed
+    // the daemon derives one from whatever directory this process is in, so the id
+    // above names a daemon that does not exist and will not exist under that id if
+    // one is ever installed from a different directory. Minting for it leaves an
+    // orphaned daemon-scope family on the account and hands the credential to
+    // nothing — which is the case the design record says to skip, and which the
+    // binary-presence check alone never detected because a binary on PATH is not a
+    // service.
+    //
+    // Only a daemon that reports its provenance can be skipped this way. An older
+    // one says nothing, and is left on the previous behaviour rather than refused.
+    if (idSource === 'cwd') {
+        return {
+            status: 'skipped',
+            detail: 'no daemon service is installed on this machine',
+        };
+    }
+    let bundle;
+    try {
+        bundle = (await data_provider_1.dataService.mintDaemonHandoff({
+            daemonId,
+            ...(machineUuid ? { machineUuid } : {}),
+        }));
+    }
+    catch (err) {
+        return { status: 'failed', detail: err.message };
+    }
+    const payload = JSON.stringify({
+        refreshToken: bundle.refreshToken,
+        refreshExpiresAt: bundle.refreshExpiresAt,
+        serverUrl: (0, config_1.loadConfig)().baseURL,
+        daemonId,
+    });
+    // No restart from here. `accept-handoff` runs the runtime's own
+    // `restartDisconnectedServiceAfterLogin` after it writes the credential — the
+    // same reconcile every other credential-write path in the daemon uses — and it
+    // is the better of the two: it checks that a service is installed and running,
+    // refuses to yank a daemon another profile owns, and gives the in-process
+    // watcher a window to converge before reaching for the heavy hammer.
+    //
+    // A second restart out here does not add a guarantee, it adds an outage. Each
+    // one kills in-flight Claude/Codex sessions and browser CDP attachments, and
+    // the second would land on a process that is seconds into starting up.
+    const accepted = await runOversky(binary, ['accept-handoff', ...profileArgs()], {
+        input: payload,
+        timeoutMs: ACCEPT_TIMEOUT_MS,
+    });
+    if (!accepted.ok) {
+        // Deliberately NOT confirming. The machine still holds the credential it had
+        // before this ran, and it still works — the mint no longer revokes anything,
+        // so the cost of a refused handoff is one unused family that the next
+        // successful login sweeps, rather than a signed-out machine.
+        return { status: 'failed', detail: firstMeaningfulLine(accepted.stderr) };
+    }
+    // Only now is the predecessor retired: the daemon has written the new
+    // credential to its own store, so "the old one dies iff the new one is in
+    // place" holds. Best-effort — a confirm that does not land leaves one extra
+    // live family, bounded by the server's concurrent-session cap and swept by the
+    // next confirm, which is a far cheaper failure than the one it replaces.
+    if (bundle.familyId) {
+        try {
+            await data_provider_1.dataService.confirmDaemonHandoff({ daemonId, familyId: bundle.familyId });
+        }
+        catch {
+            /* the credential is delivered; the sweep is bookkeeping */
+        }
+    }
+    return {
+        status: 'delivered',
+        detail: describeDelivery({
+            accountLabel: bundle.accountLabel,
+            daemonServer,
+            cliBaseURL: (0, config_1.loadConfig)().baseURL,
+        }),
+    };
+}

package/dist/lib/exec-oversky.d.ts

@@ -1,5 +1,35 @@
 /** Runtime binary names, current first. */
 export declare const RUNTIME_BINARY_NAMES: readonly ["skrrd", "oversky"];
+/**
+ * The sentence a `skrr daemon` pass-through appends to its description.
+ *
+ * OSK-296 made these commands forward their flags to `skrrd` instead of
+ * rejecting them, and stopped there. oclif renders the FLAGS section of help
+ * from a command's declared flags, and a pass-through declares none — so help
+ * kept describing the old, broken behaviour where these commands took nothing,
+ * while `skrr daemon status --profile work` quietly worked. The entire flag
+ * surface of the wrapped binary became reachable and undiscoverable in the
+ * same commit.
+ *
+ * `skrr code` hit this first and fixed BOTH halves: its description says out
+ * loud that engine flags are not listed there and where to find them. This is
+ * that sentence, for the other wrapper, in one place so eight commands cannot
+ * drift into eight wordings.
+ *
+ * It names `skrrd --help` separately because `--profile` is a GLOBAL option on
+ * the runtime, so a reader sent only to the subcommand's help would not find
+ * the flag they are most likely to want.
+ *
+ * This is a command's `description`, and each command keeps a short `summary`
+ * beside it. oclif renders `summary` in the topic listing and `description`
+ * only in the command's own help, so the note reaches someone asking about
+ * THIS command without turning `skrr daemon --help` into eight paragraphs of
+ * the same boilerplate — which is what it did when this text was appended to
+ * `description` alone.
+ */
+export declare function forwardedFlagsNote(verb: string, opts?: {
+    binds?: boolean;
+}): string;
 /** Resolve the absolute path of `oversky` if it exists, else return null. */
 export declare function findOverskyBinary(): string | null;
 /**

package/dist/lib/exec-oversky.js

@@ -4,6 +4,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 };
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.RUNTIME_BINARY_NAMES = void 0;
+exports.forwardedFlagsNote = forwardedFlagsNote;
 exports.findOverskyBinary = findOverskyBinary;
 exports.notInstalledMessage = notInstalledMessage;
 exports.execOversky = execOversky;
@@ -31,6 +32,46 @@ const node_fs_1 = require("node:fs");
 const node_path_1 = __importDefault(require("node:path"));
 /** Runtime binary names, current first. */
 exports.RUNTIME_BINARY_NAMES = ['skrrd', 'oversky'];
+/**
+ * The sentence a `skrr daemon` pass-through appends to its description.
+ *
+ * OSK-296 made these commands forward their flags to `skrrd` instead of
+ * rejecting them, and stopped there. oclif renders the FLAGS section of help
+ * from a command's declared flags, and a pass-through declares none — so help
+ * kept describing the old, broken behaviour where these commands took nothing,
+ * while `skrr daemon status --profile work` quietly worked. The entire flag
+ * surface of the wrapped binary became reachable and undiscoverable in the
+ * same commit.
+ *
+ * `skrr code` hit this first and fixed BOTH halves: its description says out
+ * loud that engine flags are not listed there and where to find them. This is
+ * that sentence, for the other wrapper, in one place so eight commands cannot
+ * drift into eight wordings.
+ *
+ * It names `skrrd --help` separately because `--profile` is a GLOBAL option on
+ * the runtime, so a reader sent only to the subcommand's help would not find
+ * the flag they are most likely to want.
+ *
+ * This is a command's `description`, and each command keeps a short `summary`
+ * beside it. oclif renders `summary` in the topic listing and `description`
+ * only in the command's own help, so the note reaches someone asking about
+ * THIS command without turning `skrr daemon --help` into eight paragraphs of
+ * the same boilerplate — which is what it did when this text was appended to
+ * `description` alone.
+ */
+function forwardedFlagsNote(verb, opts = {}) {
+    const base = `Flags are forwarded to \`skrrd ${verb}\` unchanged, so they are not listed here —` +
+        ` run \`skrrd ${verb} --help\` for this verb's own flags, or \`skrrd --help\` for` +
+        ' global ones such as `--profile`.';
+    // `install` and `login` are not pure pass-throughs: they fill in the server
+    // and profile from the CLI's own session when the caller named neither, so a
+    // daemon cannot silently end up on a different deployment than the CLI that
+    // installed it (OSK-279). Saying so is the difference between a flag you may
+    // pass and a flag that is already being passed for you.
+    return opts.binds
+        ? `${base} \`--server\` and \`--profile\` are filled in from your CLI session unless you pass them.`
+        : base;
+}
 /** Extra well-known install locations to check when PATH lookup misses. */
 const FALLBACK_PATHS = exports.RUNTIME_BINARY_NAMES.flatMap((name) => [
     `/opt/homebrew/bin/${name}`,

package/dist/lib/format.d.ts

@@ -34,6 +34,13 @@ export declare function truncate(s: string, max: number): string;
  * reads as missing instead of as the string `undefined`.
  */
 export declare function formatCell(value: unknown, placeholder?: string): string;
+/**
+ * Collapse newlines/runs of whitespace so a value cannot break the table grid.
+ *
+ * Exported because `renderTable` applies it to EVERY cell, not just the ones
+ * that happened to come through `formatCell`.
+ */
+export declare function collapseWhitespace(value: string): string;
 /**
  * Render an array of row objects as a column-aligned table.
  *

package/dist/lib/format.js

@@ -4,6 +4,7 @@ exports.displayWidth = displayWidth;
 exports.pad = pad;
 exports.truncate = truncate;
 exports.formatCell = formatCell;
+exports.collapseWhitespace = collapseWhitespace;
 exports.renderTable = renderTable;
 exports.localStamp = localStamp;
 exports.localZone = localZone;
@@ -141,28 +142,49 @@ function stringifyCell(value, depth) {
         .filter(Boolean)
         .join(' ');
 }
-/** Collapse newlines/runs of whitespace so a value cannot break the table grid. */
+/**
+ * Collapse newlines/runs of whitespace so a value cannot break the table grid.
+ *
+ * Exported because `renderTable` applies it to EVERY cell, not just the ones
+ * that happened to come through `formatCell`.
+ */
 function collapseWhitespace(value) {
     return value.replace(/\s+/g, ' ').trim();
 }
 function renderTable(rows, columns, log) {
     if (rows.length === 0)
         return;
+    // Every cell is collapsed ONCE, here, before anything measures it. A
+    // fixed-width cell cannot legally contain a newline, and the table is the
+    // only place that knows that — a caller passing `String(item.preview)` has
+    // no idea whether the API's preview is one line or twelve.
+    //
+    // It has to happen before the width pass, not just at render: `displayWidth`
+    // counts a newline as one column, so an embedded one made the measurement
+    // wrong as well as the output. `tasks complete` writes a multi-line
+    // `---TASK_OUTPUT---` comment, so `tasks timeline` exploded one row across
+    // three physical lines and lost column alignment for everything after it —
+    // on every task that had been completed, which is all of them.
+    //
+    // `verbatim` is exempt from CLIPPING, not from this: an unclipped newline
+    // breaks the grid exactly as badly, and an id column never contains one.
+    const cells = rows.map((row) => Object.fromEntries(columns.map((col) => [String(col.key), collapseWhitespace(String(row[col.key] ?? ''))])));
     const widths = {};
     for (const col of columns) {
         const key = String(col.key);
         const headerWidth = displayWidth(col.header);
-        const dataWidth = Math.max(...rows.map((r) => displayWidth(String(r[col.key] ?? ''))));
+        const dataWidth = Math.max(0, ...cells.map((r) => displayWidth(r[key])));
         const natural = Math.max(headerWidth, dataWidth);
         widths[key] = col.maxWidth && !col.verbatim ? Math.min(natural, col.maxWidth) : natural;
     }
     const header = columns.map((col) => pad(col.header, widths[String(col.key)])).join('  ');
     log(header);
-    for (const row of rows) {
+    for (const row of cells) {
         const line = columns
             .map((col) => {
-            const raw = String(row[col.key] ?? '');
-            const width = widths[String(col.key)];
+            const key = String(col.key);
+            const raw = row[key];
+            const width = widths[key];
             return pad(col.verbatim ? raw : truncate(raw, width), width);
         })
             .join('  ');

package/dist/lib/login.js

@@ -52,6 +52,8 @@ async function cliLogin(opts = {}) {
     }
     const envForce = isTruthy(process.env.OVERSKY_FORCE_DEVICE_CODE);
     const ssh = (0, ssh_detect_1.detectSshSession)();
+    /** Set when the broker was refused for a reason that WAITING fixes. */
+    let brokerRateLimited = false;
     // --- Daemon-as-broker pre-flight ---------------------------------------
     // When the local `oversky` daemon is already authenticated for this user
     // on this machine, the cleanest UX is no second browser flow at all:
@@ -114,6 +116,20 @@ async function cliLogin(opts = {}) {
         // the PKCE flow opens a browser to a different URL than the
         // daemon. Continues to PKCE below — that's the right fallback for
         // "I'm logging into a different server than the daemon".
+        // Transient by construction — the ceiling is per 15-minute window — so the
+        // useful thing to say is "wait", not "here is a browser". An interactive
+        // user still gets the browser, because that genuinely works for them; the
+        // note exists so a surprise browser has a stated cause. Non-interactive
+        // callers get the real reason from the throw below instead of a sentence
+        // about terminals.
+        if (brokerResult.reason === 'rate_limited') {
+            brokerRateLimited = true;
+            if (!(0, ssh_detect_1.isNonInteractive)()) {
+                console.log('');
+                console.log('  The local skrr runtime has brokered several logins recently and the server is ' +
+                    'rate-limiting them. Falling back to the browser flow.');
+            }
+        }
         if (brokerResult.reason === 'base_url_mismatch' && brokerResult.daemonServerUrl) {
             console.log('');
             console.log(`  The local skrr runtime is logged in to ${brokerResult.daemonServerUrl}, but skrr is configured for ${serverUrl}.`);
@@ -121,8 +137,12 @@ async function cliLogin(opts = {}) {
         }
     }
     if ((0, ssh_detect_1.isNonInteractive)()) {
-        throw new Error('skrr login requires an interactive terminal or an SSH session. ' +
-            'For CI, use `skrr create-token` and set OVERSKY_TOKEN=osk_ci_...');
+        throw new Error(brokerRateLimited
+            ? 'The local skrr runtime is being rate-limited while brokering logins, and this ' +
+                'shell cannot run the browser flow instead. The limit is per 15-minute window — ' +
+                'retry shortly. For CI, use `skrr create-token` and set OVERSKY_TOKEN=osk_ci_...'
+            : 'skrr login requires an interactive terminal or an SSH session. ' +
+                'For CI, use `skrr create-token` and set OVERSKY_TOKEN=osk_ci_...');
     }
     // --- Decision tree (first match wins) ---
     if (opts.forceDeviceCode) {

package/dist/lib/sky-code.js

@@ -35,6 +35,7 @@ const node_fs_1 = require("node:fs");
 const node_os_1 = require("node:os");
 const node_path_1 = __importDefault(require("node:path"));
 const auth_core_1 = require("@skrr-ai/auth-core");
+const config_1 = require("./config");
 // Deliberately does NOT import the managed marker any more. This module used to
 // read it to decide whether a run was managed; that decision now arrives as a
 // declared `credentialMode`, and re-introducing the import here would be the first
@@ -51,14 +52,18 @@ exports.ENGINE_PATH_ENV = 'OVERSKY_SKY_CODE_PATH';
  * ordering below exists to prevent.
  */
 function engineHome(env = process.env) {
-    const root = env.OVERSKY_CONFIG_DIR?.trim();
-    return node_path_1.default.join(root || node_path_1.default.join((0, node_os_1.homedir)(), '.skrr'), 'sky-code');
+    // `configRoot` and not a second reading of the environment: deriving the root
+    // twice is what let this function and `getConfigPath()` disagree (OSK-300).
+    return node_path_1.default.join((0, config_1.configRoot)(env), 'sky-code');
 }
 /** The user-level instruction root owned by skrr Code. */
 function skyCodeInstructionHome(env = process.env) {
     const configured = env.SKY_CODE_HOME?.trim();
+    // Falls through to `engineHome()` rather than re-deriving `~/.skrr` — the two
+    // describe the same root, and re-deriving it is what made them disagree under
+    // `OVERSKY_CONFIG_DIR` (OSK-300).
     if (!configured)
-        return node_path_1.default.join((0, node_os_1.homedir)(), '.skrr', 'sky-code');
+        return engineHome(env);
     if (configured === '~')
         return (0, node_os_1.homedir)();
     if (configured.startsWith('~/'))
@@ -86,7 +91,7 @@ function managedEnginePath(exeName, env = process.env) {
  * hard-coded home would defeat the pinning {@link engineHome} relies on.
  */
 function legacyManagedEnginePath(exeName, env = process.env) {
-    if (env.OVERSKY_CONFIG_DIR?.trim())
+    if ((0, auth_core_1.isConfigRootOverridden)(env))
         return null;
     return node_path_1.default.join((0, node_os_1.homedir)(), '.oversky', 'sky-code', 'bin', exeName);
 }

package/dist/lib/task-transcript.d.ts

@@ -23,6 +23,15 @@ export type TaskOutputComment = {
     parsed: ParsedTaskOutput;
     /** Block lines the field parser could not attribute — see `unattributedBlockLines`. */
     unattributed: string[];
+    /**
+     * How many OLDER TASK_OUTPUT blocks this one supersedes.
+     *
+     * `tasks complete` can run twice on an already-done task, and each run posts
+     * its own block. Callers render the newest, so without this count a screen
+     * built from several completions is indistinguishable from one built from a
+     * single completion.
+     */
+    supersededCount: number;
 };
 /**
  * Mirror of `api/server/services/taskCompletionFormatting.js:parseTaskOutputBlock`.

package/dist/lib/task-transcript.js

@@ -130,21 +130,32 @@ async function fetchLatestTaskOutputComment(taskId, limit = 50) {
     const comments = response?.data ?? [];
     // listTaskComments returns newest-first; take the first parseable block so a
     // later "action items tracked" follow-up comment doesn't mask the real output.
+    // Keep walking after finding it, though — the REST are earlier completions,
+    // and their number is the only signal a caller has that the newest block is
+    // not the whole story.
+    let newest = null;
+    let blocks = 0;
     for (const comment of comments) {
         const body = String(comment.body ?? comment.content ?? '');
         const parsed = parseTaskOutputBlock(body);
         if (!parsed)
             continue;
-        return {
+        blocks += 1;
+        if (newest)
+            continue;
+        newest = {
             commentId: String(comment.id ?? comment._id ?? '-'),
             createdAt: comment.createdAt ? String(comment.createdAt) : null,
             author: String(comment.authorAgentId ?? comment.authorUserId ?? comment.author ?? '-'),
             body,
             parsed,
             unattributed: unattributedBlockLines(body),
+            supersededCount: 0,
         };
     }
-    return null;
+    if (newest)
+        newest.supersededCount = blocks - 1;
+    return newest;
 }
 /** Last message the agent (not the user) produced in the execution conversation. */
 function lastAssistantMessage(messages) {

package/dist/lib/tasks.d.ts

@@ -194,3 +194,37 @@ export declare function normalizeBulkUpdateInput(input: unknown): Array<{
     id: string;
     patch: TaskRecord;
 }>;
+/**
+ * Verdict strings the server recognises on a task completion.
+ *
+ * `--verdict` is free text: `skrr tasks complete <id> --verdict banana`
+ * succeeds and the value is permanently recorded, while `--status` beside it
+ * is enumerated and rejects a typo. So `--verdict aproved` closes a task with
+ * a verdict nothing matches, quietly.
+ *
+ * It cannot simply be enumerated, and that is the point worth recording:
+ *
+ *  - A REVIEWER task legitimately passes a JSON object
+ *    (`{"posture":"request_changes","confidence":0.82,"criteria":[…]}`) —
+ *    documented in the task-execution prompt and consumed by
+ *    `normalizeReviewPosture`. `options:` on the flag would refuse it.
+ *  - That normaliser accepts synonyms, and when it recognises NOTHING it does
+ *    not fail — it derives the posture from the criteria instead. So a typo
+ *    silently becomes whatever the criteria imply.
+ *
+ * Hence a warning, not a refusal, over the set the server actually matches.
+ * Mirrored from `normalizeReviewPosture` in
+ * `api/server/services/TasksMCP/taskExecutionHelpers.js` and pinned against it
+ * by `task-verdict-parity.spec.ts`, the same way TASK_WORK_EVENT_KINDS is.
+ */
+export declare const RECOGNIZED_TASK_VERDICTS: readonly ["request_changes", "changes_requested", "needs_changes", "needs_revision", "approved", "approve", "pass", "passed", "blocked"];
+/** The server's own normalisation, so the same spellings match here. */
+export declare function normalizeVerdict(value: string): string;
+/**
+ * Does this verdict mean anything to the server?
+ *
+ * `UNVERIFIED` is platform-stamped rather than user-supplied, and a JSON
+ * verdict is the reviewer shape — both are legitimate and neither is in the
+ * synonym list.
+ */
+export declare function verdictIsRecognized(value: string | undefined): boolean;