@skrr-ai/cli 0.1.9 → 0.1.11

package/dist/lib/command-miss.js

@@ -0,0 +1,128 @@
+"use strict";
+/**
+ * What to say when a command id does not resolve — ONE description, shared by
+ * every surface that can produce a miss.
+ *
+ * There are two such surfaces, and they used to disagree. `skrr daemon reload`
+ * goes through the `command_not_found` hook and gets a message naming the real
+ * command, the mistake, and the next step. `skrr daemon reload --help` goes
+ * through oclif's HELP command, which does its own lookup and never reaches
+ * that hook — so it answered `Command daemon:reload not found.`: raw
+ * boilerplate naming an internal colon-form id the user never typed and cannot
+ * type, with no route forward.
+ *
+ * The audience is what makes that the wrong way round. Someone exploring a
+ * service-manager CLI types `--help` on a guessed subcommand FIRST. So the
+ * readers most likely to hit a miss were exactly the readers the good message
+ * was written for, and they systematically got the bad one.
+ *
+ * Keeping the text here rather than in either caller is the point: a fix to one
+ * phrasing reaches both, and neither surface can quietly drift from the other.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.editDistance = editDistance;
+exports.nearestCommands = nearestCommands;
+exports.describeCommandMiss = describeCommandMiss;
+exports.lookupFromConfig = lookupFromConfig;
+/** A uuid-ish token, which is what a stray space id looks like. */
+const LOOKS_LIKE_ID = /^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$/i;
+/** Cheap edit distance, bounded — this runs only on a miss. */
+function editDistance(a, b) {
+    const rows = a.length + 1;
+    const cols = b.length + 1;
+    let prev = Array.from({ length: cols }, (_, j) => j);
+    for (let i = 1; i < rows; i += 1) {
+        const cur = [i, ...Array(cols - 1).fill(0)];
+        for (let j = 1; j < cols; j += 1) {
+            cur[j] = Math.min(prev[j] + 1, cur[j - 1] + 1, prev[j - 1] + (a[i - 1] === b[j - 1] ? 0 : 1));
+        }
+        prev = cur;
+    }
+    return prev[cols - 1];
+}
+/**
+ * The closest real command ids, so a typo gets a route forward rather than
+ * only a verdict.
+ */
+function nearestCommands(id, all, limit = 3) {
+    // Deduped, because oclif registers a TOPIC for a command path as well as the
+    // command itself — `daemon:status` is in `commandIDs` and in `topics`, so the
+    // combined candidate list held it twice and a near-miss was answered with
+    // "Did you mean: `skrr daemon status`, `skrr daemon status`, …?", spending
+    // two of the three suggestion slots saying one thing.
+    return ([...new Set(all)]
+        .map((candidate) => ({ candidate, d: editDistance(id, candidate) }))
+        // A third of the length keeps this to genuine near-misses; without a bound
+        // every miss suggests three unrelated commands, which is noise wearing the
+        // shape of help.
+        .filter(({ d }) => d <= Math.max(2, Math.floor(id.length / 3)))
+        .sort((x, y) => x.d - y.d)
+        .slice(0, limit)
+        .map(({ candidate }) => candidate));
+}
+/**
+ * The message for a colon-joined id that did not resolve.
+ *
+ * Two shapes, in order:
+ *
+ *  1. A PREFIX of the id is a real command, so the extra tokens are arguments
+ *     it did not want. Longest prefix first, because `a:b:c` should report
+ *     `a b`, not `a`.
+ *  2. Nothing resolved, so the command genuinely is not there — say so, and
+ *     suggest the nearest siblings under the same topic before falling back to
+ *     the whole command list.
+ */
+function describeCommandMiss(config, id) {
+    const parts = String(id ?? '')
+        .split(':')
+        .filter(Boolean);
+    for (let take = parts.length - 1; take >= 1; take -= 1) {
+        const found = config.findCommand(parts.slice(0, take).join(':'));
+        if (!found)
+            continue;
+        const extras = parts.slice(take);
+        const spoken = `${config.bin} ${parts.slice(0, take).join(' ')}`;
+        // Suggest the flag only when the command actually has it, so the hint can
+        // never point at something that does not exist.
+        const flags = Object.keys(found.flags ?? {});
+        const hint = extras.some((e) => LOOKS_LIKE_ID.test(e)) && flags.includes('space')
+            ? ` Pass it as \`--space ${extras[0]}\`.`
+            : flags.includes('space')
+                ? ' It takes `--space <id>`.'
+                : '';
+        const plural = extras.length === 1 ? 'argument' : 'arguments';
+        return (`\`${spoken}\` exists, but does not take the positional ${plural} ` +
+            `${extras.map((e) => `\`${e}\``).join(' ')}.${hint}\n` +
+            `See \`${spoken} --help\`.`);
+    }
+    // Topic names are candidates too, so a near-miss on a bare topic gets routed
+    // to the topic rather than nothing (OSK-4869): `skrr harness` (singular) is
+    // one edit from the `harnesses` topic, but that topic owns no command whose
+    // id is close to `harness`, so a command-id-only search suggests nothing.
+    //
+    // Siblings first: `commitments:archive:<id>` is a long way from every real
+    // command id, so a whole-string comparison finds nothing and the reader is
+    // told only that they are wrong — when the useful answer is "that topic
+    // exists and here is what it does have".
+    const siblings = config.commandIDs.filter((c) => c.startsWith(`${parts[0]}:`));
+    const suggestions = siblings.length
+        ? nearestCommands(parts.slice(0, 2).join(':'), siblings)
+        : nearestCommands(parts.join(':'), [...config.commandIDs, ...config.topicNames]);
+    return (`\`${config.bin} ${parts.join(' ')}\` is not a command.` +
+        (suggestions.length
+            ? `\nDid you mean: ${suggestions
+                .map((s) => `\`${config.bin} ${s.split(':').join(' ')}\``)
+                .join(', ')}?`
+            : `\nRun \`${config.bin} --help\` to see the topics.`));
+}
+/** Adapt an oclif `Config` to the lookup shape above. */
+function lookupFromConfig(config) {
+    return {
+        bin: config.bin,
+        findCommand: (id) => config.findCommand(id),
+        commandIDs: config.commandIDs.map((c) => String(c)),
+        topicNames: Array.isArray(config.topics)
+            ? config.topics.map((t) => String(t?.name ?? '')).filter(Boolean)
+            : [],
+    };
+}

package/dist/lib/commitment-analytics.d.ts

@@ -22,10 +22,18 @@ export declare const ANALYTICS_REPORTS: {
         readonly path: "/api/commitment-analytics/distribution";
         readonly summary: "How commitments are spread across agents, tiers and cadences";
     };
+    readonly 'distribution-tripwire': {
+        readonly path: "/api/commitment-analytics/distribution/tripwire";
+        readonly summary: "Persistent weekly confirmation of portfolio overload risk";
+    };
     readonly 'attention-budget': {
         readonly path: "/api/commitment-analytics/attention-budget";
         readonly summary: "How much user attention the fleet is actually spending";
     };
+    readonly 'decision-inbox': {
+        readonly path: "/api/commitment-analytics/decision-inbox";
+        readonly summary: "One ranked owner inbox across approvals, blockers, attention and held surfaces";
+    };
     readonly 'action-adapters-audit': {
         readonly path: "/api/commitment-analytics/action-adapters/audit";
         readonly summary: "Which action adapters are installed and what they are permitted to do";
@@ -54,7 +62,9 @@ export declare const commitmentAnalyticsApi: {
     operationsQueue: (query?: Query) => Promise<Record<string, unknown>>;
     governanceExceptions: (query?: Query) => Promise<Record<string, unknown>>;
     distribution: (query?: Query) => Promise<Record<string, unknown>>;
+    distributionTripwire: (query?: Query) => Promise<Record<string, unknown>>;
     attentionBudget: (query?: Query) => Promise<Record<string, unknown>>;
+    decisionInbox: () => Promise<Record<string, unknown>>;
     actionAdapterAudit: () => Promise<Record<string, unknown>>;
     recoveryMetrics: (query?: Query) => Promise<Record<string, unknown>>;
     recovery: (query?: Query) => Promise<Record<string, unknown>>;

package/dist/lib/commitment-analytics.js

@@ -41,10 +41,18 @@ exports.ANALYTICS_REPORTS = {
         path: `${MOUNT}/distribution`,
         summary: 'How commitments are spread across agents, tiers and cadences',
     },
+    'distribution-tripwire': {
+        path: `${MOUNT}/distribution/tripwire`,
+        summary: 'Persistent weekly confirmation of portfolio overload risk',
+    },
     'attention-budget': {
         path: `${MOUNT}/attention-budget`,
         summary: 'How much user attention the fleet is actually spending',
     },
+    'decision-inbox': {
+        path: `${MOUNT}/decision-inbox`,
+        summary: 'One ranked owner inbox across approvals, blockers, attention and held surfaces',
+    },
     'action-adapters-audit': {
         path: `${MOUNT}/action-adapters/audit`,
         summary: 'Which action adapters are installed and what they are permitted to do',
@@ -72,7 +80,9 @@ exports.commitmentAnalyticsApi = {
     operationsQueue: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/operations/queue`, query)),
     governanceExceptions: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/governance/exceptions`, query)),
     distribution: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/distribution`, query)),
+    distributionTripwire: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/distribution/tripwire`, query)),
     attentionBudget: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/attention-budget`, query)),
+    decisionInbox: () => data_provider_1.request.get(`${MOUNT}/decision-inbox`),
     actionAdapterAudit: () => data_provider_1.request.get(`${MOUNT}/action-adapters/audit`),
     recoveryMetrics: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/recovery-metrics`, query)),
     recovery: (query = {}) => data_provider_1.request.get((0, triggers_1.withQuery)(`${MOUNT}/recovery`, query)),

package/dist/lib/config.d.ts

@@ -119,6 +119,19 @@ export declare function environmentForBaseURL(value: string): 'dev' | 'prod' | '
  * display and not harmless for routing, because two spellings of prod are two
  * different keys to anything comparing base URLs.
  */
+/**
+ * A deployment, written so a human can tell which one it is.
+ *
+ * A published `npm i -g @skrr-ai/cli` defaults to the DEV deployment, and nothing
+ * in the login flow said so — you got "Signed in via browser" and no indication
+ * of which backend now holds your account (OSK-301). Naming the environment as
+ * well as the URL matters because `oversky.dev` and `skrr.ai` do not look like a
+ * dev/prod pair to anyone who has not read this file.
+ *
+ * Falls back to the bare URL for a deployment we do not recognise — a
+ * self-hosted or local server is legitimate, and labelling it would be a guess.
+ */
+export declare function describeDeployment(baseURL: string): string;
 export declare function canonicalizeKnownBaseURL(value: string): string;
 /**
  * True when any auth-carrying env var is set. In this mode credentials are
@@ -127,6 +140,33 @@ export declare function canonicalizeKnownBaseURL(value: string): string;
  * us persist a rotated pair that the next `loadConfig()` would shadow.
  */
 export declare function isEnvAuthOverride(): boolean;
+/**
+ * Storage layout (Phase H+).
+ *
+ * Canonical:  ~/.skrr/cli-config.json  (metadata only)
+ *            ~/.skrr/cli-auth.json    (file-backend auth storage)
+ *            Keychain                    (darwin-preferred auth storage)
+ * Legacy:    ~/.sky/config.json          (read-only fallback, copied forward once)
+ *
+ * The CLI shares the daemon's config root so `auth.lock` and
+ * `needs-reauth.json` are coordinated across binaries.
+ */
+/**
+ * The skrr root for this process — the ONE place every root-derived path comes
+ * from.
+ *
+ * It is exported and takes `env` because the alternative is what this replaced:
+ * two functions each deriving the root themselves, one honouring the override
+ * and one not, disagreeing only when someone relocated their root (OSK-300).
+ * Fixing that by teaching the second function the same two variable names would
+ * have re-created the split the moment a third name appeared — and did, briefly,
+ * when `SKRR_CONFIG_DIR` was added to one side only.
+ *
+ * `SKRR_CONFIG_DIR` is the spelling for anything new (root CLAUDE.md) and wins
+ * when both are set. `OVERSKY_CONFIG_DIR` keeps working: the daemon, the engine
+ * resolver and every existing install read it.
+ */
+export declare function configRoot(env?: NodeJS.ProcessEnv): string;
 /**
  * Read the config file. Returns defaults if missing. Throws on corrupt JSON.
  * Performs a one-shot legacy → new copy when only the legacy file exists, so

package/dist/lib/config.js

@@ -35,8 +35,10 @@ var __importStar = (this && this.__importStar) || (function () {
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.ENVIRONMENT_BASE_URLS = exports.LEGACY_PROD_BASE_URL = exports.LEGACY_DEV_BASE_URL = exports.CANONICAL_PROD_BASE_URL = exports.CANONICAL_DEV_BASE_URL = void 0;
 exports.environmentForBaseURL = environmentForBaseURL;
+exports.describeDeployment = describeDeployment;
 exports.canonicalizeKnownBaseURL = canonicalizeKnownBaseURL;
 exports.isEnvAuthOverride = isEnvAuthOverride;
+exports.configRoot = configRoot;
 exports.loadConfig = loadConfig;
 exports.saveConfig = saveConfig;
 exports.getConfigPath = getConfigPath;
@@ -49,6 +51,7 @@ const fs = __importStar(require("node:fs"));
 const os = __importStar(require("node:os"));
 const path = __importStar(require("node:path"));
 const keychain_1 = require("./keychain");
+const auth_core_1 = require("@skrr-ai/auth-core");
 const publicEndpoints_generated_1 = require("./publicEndpoints.generated");
 // Both from config/public-endpoints.json, the one domain contract, rather than a
 // fourth hand-copied pair. The CLI previously knew only about dev — there was no
@@ -97,6 +100,22 @@ function environmentForBaseURL(value) {
  * display and not harmless for routing, because two spellings of prod are two
  * different keys to anything comparing base URLs.
  */
+/**
+ * A deployment, written so a human can tell which one it is.
+ *
+ * A published `npm i -g @skrr-ai/cli` defaults to the DEV deployment, and nothing
+ * in the login flow said so — you got "Signed in via browser" and no indication
+ * of which backend now holds your account (OSK-301). Naming the environment as
+ * well as the URL matters because `oversky.dev` and `skrr.ai` do not look like a
+ * dev/prod pair to anyone who has not read this file.
+ *
+ * Falls back to the bare URL for a deployment we do not recognise — a
+ * self-hosted or local server is legitimate, and labelling it would be a guess.
+ */
+function describeDeployment(baseURL) {
+    const env = environmentForBaseURL(baseURL);
+    return env ? `${env} (${baseURL})` : baseURL;
+}
 function canonicalizeKnownBaseURL(value) {
     const trimmed = value.trim().replace(/\/+$/, '');
     const normalized = trimmed.toLowerCase().replace(/^http:\/\//, 'https://');
@@ -113,10 +132,27 @@ function canonicalizeKnownBaseURL(value) {
     return value;
 }
 const DEFAULT_CONFIG = {
-    // Dev remains the default for an unconfigured CLI, matching the daemon
-    // (daemon/src/config.ts → ENVIRONMENT_URLS.dev). Reach prod with
-    // `skrr login --env prod`, `--base-url https://oversky.ai`, or OVERSKY_BASE_URL.
-    baseURL: exports.CANONICAL_DEV_BASE_URL,
+    // PROD for an unconfigured CLI, matching the daemon
+    // (daemon/src/config.ts → ENVIRONMENT_URLS.prod). Reach dev with
+    // `skrr login --env dev`, `--base-url https://oversky.dev`, or OVERSKY_BASE_URL.
+    //
+    // This was dev, which was right when the CLI was something the team installed
+    // from the repo. `@skrr-ai/cli` is a PUBLIC npm package now, and the default
+    // decides where a stranger's first `skrr login` creates their account,
+    // workspace and agents. `oversky.dev` is the integration environment: it
+    // deploys on every push to `dev` and, by design, without waiting for the api or
+    // client suites. A reasonable place for the team to live, a poor place to send
+    // someone who typed `npm install` (OSK-301).
+    //
+    // It moves with the daemon or not at all. The two defaults are ONE decision:
+    // changing this alone would put every fresh machine into the CLI-on-prod /
+    // daemon-on-dev split that OSK-279 exists to prevent — which is exactly the
+    // state this machine was found in. `cli/src/__tests__/default-deployment.spec.ts`
+    // reads the daemon's own source and fails if they diverge.
+    //
+    // Nobody's existing setup moves: a stored `cli-config.json` wins over this, so
+    // only an install with no configuration at all is affected.
+    baseURL: exports.CANONICAL_PROD_BASE_URL,
 };
 /**
  * Environment-variable overlay for headless use (CI, Secrets Manager, EC2
@@ -205,8 +241,30 @@ function isEnvAuthOverride() {
  * The CLI shares the daemon's config root so `auth.lock` and
  * `needs-reauth.json` are coordinated across binaries.
  */
+/**
+ * The skrr root for this process — the ONE place every root-derived path comes
+ * from.
+ *
+ * It is exported and takes `env` because the alternative is what this replaced:
+ * two functions each deriving the root themselves, one honouring the override
+ * and one not, disagreeing only when someone relocated their root (OSK-300).
+ * Fixing that by teaching the second function the same two variable names would
+ * have re-created the split the moment a third name appeared — and did, briefly,
+ * when `SKRR_CONFIG_DIR` was added to one side only.
+ *
+ * `SKRR_CONFIG_DIR` is the spelling for anything new (root CLAUDE.md) and wins
+ * when both are set. `OVERSKY_CONFIG_DIR` keeps working: the daemon, the engine
+ * resolver and every existing install read it.
+ */
+function configRoot(env = process.env) {
+    // Delegates. The variable list lives in ONE place (`@skrr-ai/auth-core`)
+    // because every copy of it became a place `skrr` and `skrrd` could disagree —
+    // twice in one day, each time as a correct local fix that created the next
+    // defect. `scripts/config-root-single-source.spec` fails if this is re-derived.
+    return (0, auth_core_1.resolveConfigRoot)(env);
+}
 function newConfigDir() {
-    return path.join(os.homedir(), '.skrr');
+    return configRoot();
 }
 /**
  * Fields that belong to the MACHINE, not to a profile.
@@ -288,10 +346,15 @@ function readMachineScoped() {
  * This was missing from the fallback chain, which went straight from `.skrr` to
  * `.sky` and skipped the directory that every current install actually has.
  * The effect is not a missing preference: with no config found, `loadConfig`
- * returns DEFAULT_CONFIG, whose baseURL is the production apex — so a CLI that
- * had been pointed at the dev deployment silently starts addressing PRODUCTION,
- * and its `workspaceId` is gone. Nothing errors; commands just answer about a
- * different backend.
+ * returns DEFAULT_CONFIG, whose baseURL is the DEV deployment — so a CLI that
+ * had been pointed at production silently starts addressing dev, and its
+ * `workspaceId` is gone. Nothing errors; commands just answer about a different
+ * backend.
+ *
+ * This read "the production apex", and said the drift ran the other way. It did
+ * not: DEFAULT_CONFIG has been dev since it was written, forty lines further up.
+ * The direction matters here more than most stale comments, because it is the
+ * difference between a lost session and one that silently addresses production.
  *
  * Note the filename differs by generation: `.sky` used `config.json`, `.oversky`
  * and `.skrr` use `cli-config.json`.

package/dist/lib/daemonBroker.d.ts

@@ -80,6 +80,12 @@ export interface DaemonBrokerResult {
     cliId: string;
     userId: string;
     email: string | null;
+    /**
+     * The refresh family this credential belongs to, named so the caller can
+     * retire its predecessors AFTER persisting it. Absent on servers that predate
+     * the mint/confirm split, where the mint still revoked eagerly.
+     */
+    familyId?: string;
 }
 /**
  * Explicit reasons the broker path could fail. These exist to keep the
@@ -87,7 +93,7 @@ export interface DaemonBrokerResult {
  * fall through to PKCE; `ci_token_refused` is the one we surface
  * because re-driving it via PKCE would not change the outcome.
  */
-export type DaemonBrokerErrorReason = 'no_bootstrap' | 'stale_bootstrap' | 'bootstrap_parse' | 'base_url_mismatch' | 'daemon_not_authed' | 'ci_token_refused' | 'server_error' | 'network' | 'timeout' | 'unknown';
+export type DaemonBrokerErrorReason = 'no_bootstrap' | 'stale_bootstrap' | 'bootstrap_parse' | 'base_url_mismatch' | 'daemon_not_authed' | 'ci_token_refused' | 'rate_limited' | 'server_error' | 'network' | 'timeout' | 'unknown';
 export interface DaemonBrokerFailure {
     ok: false;
     reason: DaemonBrokerErrorReason;

package/dist/lib/daemonBroker.js

@@ -351,6 +351,22 @@ async function attemptDaemonBrokerLogin(opts) {
         if (response.status === 503 && code === 'DAEMON_NOT_AUTHED') {
             return { ok: false, reason: 'daemon_not_authed', detail: message, status: 503, code };
         }
+        // 429 is TRANSIENT and its remedy is time, which makes it the one failure
+        // here that a fall-through cannot substitute for. Left in the `unknown`
+        // bucket it fell silently through to PKCE, and in a non-interactive shell
+        // that surfaced as "skrr login requires an interactive terminal" — a
+        // sentence about the wrong thing entirely. Reachable in the ordinary way: a
+        // cold machine running several skrr commands at once has every process
+        // brokering, because none of them has a token yet.
+        if (response.status === 429) {
+            return {
+                ok: false,
+                reason: 'rate_limited',
+                detail: message,
+                status: 429,
+                ...(code ? { code } : {}),
+            };
+        }
         if (response.status === 400 && code === 'BASE_URL_MISMATCH') {
             // Older daemon binary that lacked the bootstrap.serverUrl field
             // ended up here despite the CLI sending baseURL. Treat as the
@@ -397,8 +413,52 @@ async function attemptDaemonBrokerLogin(opts) {
         cliId: parsedBody.cliId,
         userId: parsedBody.userId,
         email: parsedBody.email ?? null,
+        ...(typeof parsedBody.familyId === 'string' ? { familyId: parsedBody.familyId } : {}),
     };
 }
+/** Bound the confirm so a slow server cannot stall a login that already worked. */
+const CONFIRM_TIMEOUT_MS = 10_000;
+/**
+ * Retire the cli credentials this one replaces — after it is on disk, never
+ * before.
+ *
+ * The mint deliberately no longer does this. Between the server's response and
+ * the credential being usable there are two more hops (the daemon's loopback
+ * broker forwarding the body, this process writing it to the keychain), and a
+ * failure at either one used to leave the user with no working cli credential at
+ * all, recoverable only by a full browser login.
+ *
+ * Called with the NEW access token explicitly rather than through the shared
+ * client. That is the point rather than a detail: the route refuses unless the
+ * bearer's own `did` claim is the cliId being swept, so this call is not a claim
+ * that the delivery happened — it is a demonstration that it did.
+ *
+ * Best-effort and silent. The credential is already persisted and working by the
+ * time this runs; a failure leaves one extra live family, which the server's
+ * session cap bounds and the next confirm sweeps.
+ */
+async function confirmCliHandoff(opts) {
+    const controller = new AbortController();
+    const timer = setTimeout(() => controller.abort(), CONFIRM_TIMEOUT_MS);
+    try {
+        await fetch(`${opts.serverOrigin}/api/daemons/cli-handoff/confirm`, {
+            method: 'POST',
+            headers: {
+                Authorization: `Bearer ${opts.accessToken}`,
+                'Content-Type': 'application/json',
+                Accept: 'application/json',
+            },
+            body: JSON.stringify({ cliId: opts.cliId, familyId: opts.familyId }),
+            signal: controller.signal,
+        });
+    }
+    catch {
+        /* bookkeeping — the credential is already delivered */
+    }
+    finally {
+        clearTimeout(timer);
+    }
+}
 /**
  * Helper: coerce an ISO-string or numeric expiry to epoch ms for
  * `writeToBackend`. Returns undefined on missing / unparseable input.
@@ -436,6 +496,17 @@ async function attemptDaemonBrokerLoginAndPersist(opts) {
             ? { refreshExpiresAt: expiryToEpochMs(outcome.refreshExpiresAt) }
             : {}),
     }, { serverOrigin, clearReauth: true });
+    // Only now: the credential is on disk, so "the predecessor dies iff the
+    // replacement is in place" holds. A server that predates the split ships no
+    // `familyId` and has already revoked eagerly — nothing to do there.
+    if (outcome.familyId) {
+        await confirmCliHandoff({
+            serverOrigin,
+            accessToken: outcome.accessToken,
+            cliId: outcome.cliId,
+            familyId: outcome.familyId,
+        });
+    }
     return outcome;
 }
 // ---------------------------------------------------------------------

package/dist/lib/daemonHandoff.d.ts

@@ -0,0 +1,38 @@
+/**
+ * Hand the local daemon a credential of its own, right after `skrr login`.
+ *
+ * The inverse of the daemon-as-broker path that already ships. That one lets an
+ * authenticated DAEMON mint a cli-scope credential so the CLI can skip the
+ * browser; this lets an authenticated HUMAN mint a daemon-scope one so the
+ * machine is logged in by the same act. The direction added here is the safer of
+ * the two: daemon scope is deliberately lower-privileged than cli scope
+ * (`requireHumanScope` refuses it from billing, account management, password
+ * change and deletion), so this is a de-escalation, while the shipping direction
+ * is an escalation.
+ *
+ * Design record: docs/architecture/machine-login-broker-inversion-2026-09-03.md
+ *
+ * Three properties are deliberate:
+ *
+ *   - **Best-effort, never fatal.** `skrr login` has already SUCCEEDED by the time
+ *     this runs. A failure here must not fail the login or discard the credential
+ *     the user just earned — it degrades to exactly the old behaviour, with a hint.
+ *   - **Skipped when no daemon service is installed.** There is nothing to hand a
+ *     credential to, and minting one anyway leaves an orphaned daemon-scope family
+ *     on the account. A binary on PATH is not a service, so this is decided by the
+ *     daemon's own answer about where its id came from — not by whether `skrrd`
+ *     exists.
+ *   - **The bundle goes over STDIN**, never a file. It is a live credential; a temp
+ *     file would put it at rest with a lifetime nobody owns.
+ *   - **The predecessor is retired only after the new credential is written.** The
+ *     mint no longer revokes anything; `confirmDaemonHandoff` does, once the daemon
+ *     has accepted. So a handoff that fails leaves the machine exactly as it was,
+ *     rather than signed out.
+ */
+export interface DaemonHandoffOutcome {
+    status: 'delivered' | 'skipped' | 'failed';
+    detail: string;
+}
+export declare function handOffToLocalDaemon(env?: NodeJS.ProcessEnv, opts?: {
+    loginFlow?: string;
+}): Promise<DaemonHandoffOutcome>;