@skrr-ai/cli 0.1.8 → 0.1.10

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;
@@ -48,6 +50,7 @@ exports.saveRawConfig = saveRawConfig;
 const fs = __importStar(require("node:fs"));
 const os = __importStar(require("node:os"));
 const path = __importStar(require("node:path"));
+const keychain_1 = require("./keychain");
 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
@@ -96,6 +99,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://');
@@ -112,10 +131,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
@@ -138,18 +174,46 @@ const ENV_VAR = {
     refreshToken: 'OVERSKY_REFRESH_TOKEN',
     cliId: 'OVERSKY_CLI_ID',
 };
+/**
+ * Read one overlay variable under either prefix.
+ *
+ * The ~921 `OVERSKY_*` variables are RETAINED by decision
+ * (docs/product/skrr-env-inventory.md), so this migrates nothing and changes no
+ * existing environment: the legacy spelling still wins when both are set. What
+ * it stops is the renamed product SILENTLY IGNORING the prefix its own
+ * contributor docs tell new code to use. `SKRR_BASE_URL=https://oversky.dev`
+ * previously did nothing at all — the command ran happily against production
+ * and reported success, which is the worst available outcome for a variable
+ * whose entire job is choosing the deployment.
+ *
+ * A disagreement is reported rather than resolved quietly, because two
+ * different values for one setting is a mistake either way.
+ */
+let warnedEnvPrefixConflict = false;
+function envOverlayValue(key) {
+    const legacyName = ENV_VAR[key];
+    const renamedName = legacyName.replace(/^OVERSKY_/, 'SKRR_');
+    const legacy = process.env[legacyName]?.trim();
+    const renamed = process.env[renamedName]?.trim();
+    if (legacy && renamed && legacy !== renamed && !warnedEnvPrefixConflict) {
+        warnedEnvPrefixConflict = true;
+        process.stderr.write(`warning: ${legacyName} and ${renamedName} are both set and disagree. ` +
+            `Using ${legacyName}=${legacy}.\n`);
+    }
+    return legacy && legacy.length > 0 ? legacy : renamed && renamed.length > 0 ? renamed : undefined;
+}
 function overlayEnv(cfg) {
     const out = { ...cfg };
-    const bu = process.env[ENV_VAR.baseURL] || process.env[ENV_VAR.serverUrl];
+    const bu = envOverlayValue('baseURL') || envOverlayValue('serverUrl');
     if (bu && bu.length > 0)
         out.baseURL = canonicalizeKnownBaseURL(bu);
-    const tok = process.env[ENV_VAR.token];
+    const tok = envOverlayValue('token');
     if (tok && tok.length > 0)
         out.token = tok;
-    const rt = process.env[ENV_VAR.refreshToken];
+    const rt = envOverlayValue('refreshToken');
     if (rt && rt.length > 0)
         out.refreshToken = rt;
-    const cid = process.env[ENV_VAR.cliId];
+    const cid = envOverlayValue('cliId');
     if (cid && cid.length > 0)
         out.cliId = cid;
     return out;
@@ -161,8 +225,9 @@ function overlayEnv(cfg) {
  * us persist a rotated pair that the next `loadConfig()` would shadow.
  */
 function isEnvAuthOverride() {
-    return !!((process.env[ENV_VAR.token] && process.env[ENV_VAR.token].length > 0) ||
-        (process.env[ENV_VAR.refreshToken] && process.env[ENV_VAR.refreshToken].length > 0));
+    // Both prefixes, or a credential injected as SKRR_TOKEN would be used for the
+    // request while the process still believed it could refresh and persist.
+    return !!(envOverlayValue('token') || envOverlayValue('refreshToken'));
 }
 /**
  * Storage layout (Phase H+).
@@ -175,12 +240,127 @@ 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) {
+    const root = (env.SKRR_CONFIG_DIR || env.OVERSKY_CONFIG_DIR)?.trim();
+    return root || path.join(os.homedir(), '.skrr');
+}
 function newConfigDir() {
-    return path.join(os.homedir(), '.skrr');
+    return configRoot();
+}
+/**
+ * Fields that belong to the MACHINE, not to a profile.
+ *
+ * `cliId` is the sharp one. Its own doc says it is presented at login and at
+ * every refresh rotation, and that the server binds it into the JWT `did` claim
+ * and rejects a rotation against a different one. Split it per profile and a
+ * second profile does not degrade — it fails to stay logged in.
+ *
+ * `credentials.store` is a machine posture (keychain / file / env-only), and
+ * `migrated` is a breadcrumb about this machine's DISK LAYOUT. Neither is a
+ * property of which deployment you are addressing.
+ *
+ * Everything else follows the profile, because everything else IS the
+ * deployment: `baseURL`, who you are there (`userId`, `email`), and what you
+ * chose there (`workspaceId`, `skyCodeAgentId`).
+ */
+const MACHINE_SCOPED_KEYS = ['cliId', 'credentials', 'migrated'];
+/**
+ * Where this profile's config lives.
+ *
+ * The DEFAULT profile keeps `~/.skrr/cli-config.json` — the exact path it has
+ * always used. That is the whole reason this change needs no migration and
+ * carries almost no risk: profiles are ADDITIVE. An existing install is the
+ * default profile, its file does not move, and nothing about it is rewritten.
+ *
+ * A named profile gets `~/.skrr/profiles/<name>/cli-config.json`, sharing the
+ * tree the daemon already uses for the same idea. Sharing rather than inventing
+ * `cli-profiles/` is deliberate: today's worst failure is the CLI and the daemon
+ * pointing at different deployments (OSK-279), and one profile namespace makes
+ * that harder to produce, not easier.
+ */
+function profileConfigDir() {
+    const profile = (0, keychain_1.getActiveProfile)();
+    if (!profile || profile === keychain_1.DEFAULT_PROFILE)
+        return newConfigDir();
+    return path.join(newConfigDir(), 'profiles', profile);
 }
 function newConfigFile() {
+    return path.join(profileConfigDir(), 'cli-config.json');
+}
+/** The machine-scoped file, which never moves with the profile. */
+function machineConfigFile() {
     return path.join(newConfigDir(), 'cli-config.json');
 }
+/** Split a config into the half that follows the profile and the half that does not. */
+function splitByScope(config) {
+    const machine = {};
+    const profile = {};
+    for (const [key, value] of Object.entries(config)) {
+        if (MACHINE_SCOPED_KEYS.includes(key))
+            machine[key] = value;
+        else
+            profile[key] = value;
+    }
+    return { machine, profile };
+}
+/**
+ * Machine-scoped fields, read from the machine file regardless of profile.
+ *
+ * Returns an empty object rather than throwing: a named profile on a machine
+ * that has never run the default one has no machine file yet, and that is a
+ * first run, not a fault.
+ */
+function readMachineScoped() {
+    const p = machineConfigFile();
+    if (!fs.existsSync(p))
+        return {};
+    try {
+        return splitByScope(readJsonOrThrow(p)).machine;
+    }
+    catch {
+        return {};
+    }
+}
+/**
+ * The PRE-RENAME config root — the generation between `.sky` and `.skrr`.
+ *
+ * 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 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`.
+ */
+function priorConfigDir() {
+    return path.join(os.homedir(), '.oversky');
+}
+function priorConfigFile() {
+    return path.join(priorConfigDir(), 'cli-config.json');
+}
 function legacyConfigDir() {
     return path.join(os.homedir(), '.sky');
 }
@@ -188,41 +368,221 @@ function legacyConfigFile() {
     return path.join(legacyConfigDir(), 'config.json');
 }
 /**
- * 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 existing users don't have to re-login.
+ * Breadcrumb proving the carry-forward already ran on this machine.
+ *
+ * Deliberately OUTSIDE the file it produces. The migration's own record used to
+ * be the config it wrote, which made it one-shot only for as long as that file
+ * survived: any moment where `cli-config.json` was absent looked exactly like a
+ * first run, and the pre-rename config was adopted again — `baseURL` included.
+ *
+ * Follows the `.migrated-*` convention already used by the daemon's
+ * profile-migration and keychain-hygiene passes.
+ */
+const CARRY_FORWARD_BREADCRUMB = '.migrated-2026-09-02-cli-config-carry-forward';
+function carryForwardBreadcrumbPath() {
+    return path.join(newConfigDir(), CARRY_FORWARD_BREADCRUMB);
+}
+function hasCarriedForward() {
+    try {
+        return fs.existsSync(carryForwardBreadcrumbPath());
+    }
+    catch {
+        return false;
+    }
+}
+function markCarriedForward() {
+    try {
+        const dir = newConfigDir();
+        if (!fs.existsSync(dir))
+            fs.mkdirSync(dir, { recursive: true, mode: 0o700 });
+        fs.writeFileSync(carryForwardBreadcrumbPath(), `${new Date().toISOString()}\n`, {
+            mode: 0o600,
+        });
+    }
+    catch {
+        // Best effort. Failing to record it means the migration may run again,
+        // which is the old behaviour — not worse.
+    }
+}
+let announcedAdoptedDeployment = false;
+/**
+ * Say when the CLI adopts a deployment the user did not name in this command.
+ *
+ * Whatever the source, changing which DEPLOYMENT a session addresses is not a
+ * detail: the failure it produces is an empty list, not an error, because a
+ * successful `200 {"data": []}` from the wrong deployment is indistinguishable
+ * from having no rows.
+ */
+function announceAdoptedDeployment(baseURL, source) {
+    if (announcedAdoptedDeployment)
+        return;
+    announcedAdoptedDeployment = true;
+    process.stderr.write(`note: no CLI config found; using ${baseURL} (from ${source}).\n` +
+        `      If that is the wrong deployment:  skrr login --base-url <url>\n`);
+}
+/**
+ * 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
+ * existing users don't have to re-login.
  */
 function loadConfig() {
     const newPath = newConfigFile();
+    const named = newPath !== machineConfigFile();
     if (fs.existsSync(newPath)) {
-        return overlayEnv(migrateLegacyBaseURL(readJsonOrThrow(newPath)));
+        const current = migrateLegacyBaseURL(readJsonOrThrow(newPath));
+        warnIfStrandedPriorConfig(current);
+        // A named profile's file holds only its own half; the machine half is read
+        // from the machine file so `cliId` is one value for this machine no matter
+        // how many profiles exist.
+        return overlayEnv(named ? { ...current, ...readMachineScoped() } : current);
     }
-    const legacyPath = legacyConfigFile();
-    if (fs.existsSync(legacyPath)) {
-        const legacy = migrateLegacyBaseURL(readJsonOrThrow(legacyPath));
-        try {
-            saveConfig(legacy);
-        }
-        catch {
-            /* swallow — caller still has a usable config in memory */
+    // A named profile that has never been used is a FIRST RUN for that profile,
+    // not a machine without config. It must not adopt the default profile's
+    // deployment — that is how "switch to dev" would silently keep talking to
+    // prod — so it starts from the documented default, carrying only the machine
+    // half forward. The generation carry-forward below is deliberately skipped:
+    // there is no `.sky`/`.oversky` ancestor of a profile that did not exist then.
+    if (named) {
+        return overlayEnv({ ...DEFAULT_CONFIG, ...readMachineScoped() });
+    }
+    // Newest first, and ONCE per machine. Each generation is copied forward so a
+    // user never has to re-login because a directory was renamed — but only on a
+    // genuine first run. After the breadcrumb exists, a missing config means the
+    // file went away, not that this machine is pre-rename, and re-adopting the
+    // old file would silently move the session to the old DEPLOYMENT.
+    if (!hasCarriedForward()) {
+        for (const carriedPath of [priorConfigFile(), legacyConfigFile()]) {
+            if (!fs.existsSync(carriedPath))
+                continue;
+            const carried = migrateLegacyBaseURL(readJsonOrThrow(carriedPath));
+            try {
+                saveConfig(carried);
+            }
+            catch {
+                /* swallow — caller still has a usable config in memory */
+            }
+            markCarriedForward();
+            announceAdoptedDeployment(carried.baseURL, carriedPath);
+            return overlayEnv(carried);
         }
-        return overlayEnv(legacy);
     }
+    // Nothing to carry: fall through to the documented default. Deliberately NOT
+    // derived from the stored credential's origin — making config resolution read
+    // the keychain would let ambient machine state override a documented default,
+    // and a fresh install defaulting to dev is intended behaviour, not a bug.
     return overlayEnv({ ...DEFAULT_CONFIG });
 }
+/**
+ * Surface the one case this fix cannot repair on its own.
+ *
+ * A CLI that ran after the directory rename but before this migration existed
+ * already wrote a `.skrr` config from DEFAULT_CONFIG. The copy-forward above
+ * will not fire for it, and it must not: once a config exists, "the user chose
+ * this backend" and "the default landed here" are indistinguishable, and
+ * silently rewriting a deliberate choice is worse than the bug.
+ *
+ * So it says so instead of guessing. Warned once per process, to stderr, and
+ * only when the two disagree — agreement needs no warning.
+ */
+let warnedStrandedPriorConfig = false;
+function warnIfStrandedPriorConfig(current) {
+    if (warnedStrandedPriorConfig)
+        return;
+    // On EVERY command, forever, was the complaint — and it is fair: once you have
+    // read it and meant the deployment you are on, it is pure noise burying real
+    // stderr. Deleting the old file is one exit; this is the other, for a machine
+    // that wants to keep it.
+    if ((process.env[QUIET_ENV] ?? '').trim().length > 0)
+        return;
+    const priorPath = priorConfigFile();
+    if (!fs.existsSync(priorPath))
+        return;
+    let prior;
+    try {
+        prior = readJsonOrThrow(priorPath);
+    }
+    catch {
+        return; // an unreadable prior config is not evidence of anything
+    }
+    const priorBase = canonicalizeKnownBaseURL(prior.baseURL);
+    if (!priorBase || priorBase === canonicalizeKnownBaseURL(current.baseURL))
+        return;
+    warnedStrandedPriorConfig = true;
+    const stranded = strandedSettings(prior);
+    const alsoHolds = stranded.length > 0 ? ` (it also holds ${stranded.join(', ')})` : '';
+    process.stderr.write(`warning: ${priorPath} points at ${priorBase}; this CLI is using ${current.baseURL}.\n` +
+        `         Use it instead:  skrr login --base-url ${priorBase}\n` +
+        `         Or silence this: set ${QUIET_ENV}=1, or delete that file${alsoHolds}\n`);
+}
+/** Opt out once you have read the warning and meant the deployment you are on. */
+const QUIET_ENV = 'SKRR_QUIET_CONFIG_WARNING';
+/**
+ * The settings that deleting the prior config would discard.
+ *
+ * The migration did not carry these forward, so the old file is their only
+ * copy — naming them is the difference between an instruction and a trap.
+ */
+function strandedSettings(prior) {
+    const carried = new Set(['baseURL', 'migrated', 'cliId']);
+    return Object.keys(prior)
+        .filter((k) => !carried.has(k) && prior[k] !== undefined)
+        .sort();
+}
+function newPath() {
+    return newConfigFile();
+}
 /** Write the config file with mode 0600 inside a 0700 directory. */
 function saveConfig(config) {
-    const dir = newConfigDir();
-    if (!fs.existsSync(dir)) {
-        fs.mkdirSync(dir, { recursive: true, mode: 0o700 });
-    }
-    const p = newConfigFile();
     const canonical = {
         ...config,
         baseURL: canonicalizeKnownBaseURL(config.baseURL),
     };
-    fs.writeFileSync(p, JSON.stringify(canonical, null, 2), { mode: 0o600 });
-    fs.chmodSync(p, 0o600);
+    const target = newConfigFile();
+    const machineFile = machineConfigFile();
+    // Default profile: one file, exactly as before. Nothing is split, nothing
+    // moves, and an existing install cannot notice this change.
+    if (target === machineFile) {
+        writeConfigFile(target, canonical);
+        return;
+    }
+    const { machine, profile } = splitByScope(canonical);
+    writeConfigFile(target, profile);
+    // Machine-scoped fields are MERGED into the machine file rather than
+    // replacing it: the default profile's deployment, workspace and account live
+    // in that same file, and a named profile writing its own half over the top
+    // would sign the default profile out.
+    const existingMachine = fs.existsSync(machineFile) ? readJsonOrThrow(machineFile) : {};
+    const merged = { ...existingMachine, ...machine };
+    if (JSON.stringify(merged) !== JSON.stringify(existingMachine)) {
+        writeConfigFile(machineFile, merged);
+    }
+}
+/**
+ * Warn once when a write happens before the profile was chosen.
+ *
+ * Such a write lands in the default profile's file whatever `--profile` said,
+ * because the choice had not been made yet. It is silent, it is permanent, and
+ * the only way anyone finds it is by wondering why a named profile keeps
+ * forgetting things. The daemon carries the same guard for the same reason.
+ */
+let warnedUnresolvedProfile = false;
+function warnIfProfileUnresolved(target) {
+    if ((0, keychain_1.isProfileResolved)() || warnedUnresolvedProfile)
+        return;
+    warnedUnresolvedProfile = true;
+    process.stderr.write(`[profile] config written to ${target} before the profile was resolved; ` +
+        'it landed in the default profile. If this was not the crash path, it is a ' +
+        'regression — a writer is running before BaseCommand.init().\n');
+}
+/** Write one config file with the directory created and 0600 enforced. */
+function writeConfigFile(target, contents) {
+    warnIfProfileUnresolved(target);
+    const dir = path.dirname(target);
+    if (!fs.existsSync(dir)) {
+        fs.mkdirSync(dir, { recursive: true, mode: 0o700 });
+    }
+    fs.writeFileSync(target, JSON.stringify(contents, null, 2), { mode: 0o600 });
+    fs.chmodSync(target, 0o600);
 }
 /**
  * One-shot migration for clients installed before oversky.dev became the dev

package/dist/lib/created-line.d.ts

@@ -0,0 +1,22 @@
+/**
+ * One shape for "you just created a thing".
+ *
+ * The four core entities each printed a different confirmation: the identifier
+ * was a human ref for a project, a raw uuid for a goal and a space, and both for
+ * a task; the separator was an em dash for two and a hyphen for the other two;
+ * and goals and spaces appended context (`in space <uuid>`,
+ * `(subspace of <uuid>)`) that the link on the next line already carries.
+ *
+ * Reading four of these in a row, you cannot tell what you are being handed —
+ * which is what makes the difference between "did this work" and "what do I
+ * paste into the next command" harder than it should be.
+ *
+ * The rule: prefer the ref a person can type, fall back to the id, and put the
+ * title after a single em dash. The `View it at <url>` line that follows is
+ * already consistent and is left alone.
+ */
+export declare function createdLine(entity: string, opts: {
+    ref?: string | null;
+    id?: string | null;
+    title?: string | null;
+}): string;

package/dist/lib/created-line.js

@@ -0,0 +1,25 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.createdLine = createdLine;
+/**
+ * One shape for "you just created a thing".
+ *
+ * The four core entities each printed a different confirmation: the identifier
+ * was a human ref for a project, a raw uuid for a goal and a space, and both for
+ * a task; the separator was an em dash for two and a hyphen for the other two;
+ * and goals and spaces appended context (`in space <uuid>`,
+ * `(subspace of <uuid>)`) that the link on the next line already carries.
+ *
+ * Reading four of these in a row, you cannot tell what you are being handed —
+ * which is what makes the difference between "did this work" and "what do I
+ * paste into the next command" harder than it should be.
+ *
+ * The rule: prefer the ref a person can type, fall back to the id, and put the
+ * title after a single em dash. The `View it at <url>` line that follows is
+ * already consistent and is left alone.
+ */
+function createdLine(entity, opts) {
+    const label = (opts.ref ?? '').trim() || (opts.id ?? '').trim() || '?';
+    const title = (opts.title ?? '').trim() || '(no title)';
+    return `Created ${entity} ${label} — ${title}`;
+}

package/dist/lib/daemon-binding.d.ts

@@ -0,0 +1,29 @@
+/**
+ * Defaults for the flags that decide WHICH deployment and WHICH profile a
+ * newly installed daemon binds to.
+ *
+ * `skrr daemon *` are pass-throughs to the `skrrd` binary, and the two
+ * programs keep SEPARATE configuration: the CLI's deployment and profile live
+ * in `cli-config.json`, the daemon's in `daemon.json`. Nothing has ever made
+ * one follow the other, so the ordinary way to end up split is to do nothing
+ * unusual at all — log the CLI into one deployment and leave the daemon on
+ * whichever it was installed against. That is OSK-279, observed on this
+ * machine as a daemon on dev serving a CLI on prod.
+ *
+ * The fix is deliberately scoped to INSTALL, the moment a daemon is created
+ * and the only moment its binding is not yet somebody's decision. `start` is
+ * left alone on purpose: it starts a daemon that already has a binding, and
+ * silently overriding it would break the operator who split the two knowingly
+ * — running a dev daemon against a prod CLI is a legitimate thing to do, and
+ * it is not this function's place to overrule it. `skrr daemon status` reports
+ * a split instead of correcting one.
+ */
+/** Whether `argv` already carries `--name` or `--name=value` (or `-alias`). */
+export declare function hasFlag(argv: readonly string[], name: string, alias?: string): boolean;
+/**
+ * Append `--server` / `--profile` describing the CLI's own session, for any
+ * the caller did not pass. An explicit flag always wins — this only fills a
+ * silence, so `skrr daemon install --env prod` still installs against prod
+ * while the CLI sits on dev.
+ */
+export declare function bindToCliSession(argv: readonly string[]): string[];

package/dist/lib/daemon-binding.js

@@ -0,0 +1,63 @@
+"use strict";
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.hasFlag = hasFlag;
+exports.bindToCliSession = bindToCliSession;
+const config_1 = require("./config");
+const keychain_1 = require("./keychain");
+/**
+ * Defaults for the flags that decide WHICH deployment and WHICH profile a
+ * newly installed daemon binds to.
+ *
+ * `skrr daemon *` are pass-throughs to the `skrrd` binary, and the two
+ * programs keep SEPARATE configuration: the CLI's deployment and profile live
+ * in `cli-config.json`, the daemon's in `daemon.json`. Nothing has ever made
+ * one follow the other, so the ordinary way to end up split is to do nothing
+ * unusual at all — log the CLI into one deployment and leave the daemon on
+ * whichever it was installed against. That is OSK-279, observed on this
+ * machine as a daemon on dev serving a CLI on prod.
+ *
+ * The fix is deliberately scoped to INSTALL, the moment a daemon is created
+ * and the only moment its binding is not yet somebody's decision. `start` is
+ * left alone on purpose: it starts a daemon that already has a binding, and
+ * silently overriding it would break the operator who split the two knowingly
+ * — running a dev daemon against a prod CLI is a legitimate thing to do, and
+ * it is not this function's place to overrule it. `skrr daemon status` reports
+ * a split instead of correcting one.
+ */
+/** Whether `argv` already carries `--name` or `--name=value` (or `-alias`). */
+function hasFlag(argv, name, alias) {
+    return argv.some((arg) => {
+        if (arg === '--')
+            return false;
+        return (arg === name ||
+            arg.startsWith(`${name}=`) ||
+            (alias !== undefined && (arg === alias || arg.startsWith(`${alias}=`))));
+    });
+}
+/**
+ * Append `--server` / `--profile` describing the CLI's own session, for any
+ * the caller did not pass. An explicit flag always wins — this only fills a
+ * silence, so `skrr daemon install --env prod` still installs against prod
+ * while the CLI sits on dev.
+ */
+function bindToCliSession(argv) {
+    const extra = [];
+    // `--env` resolves to a server URL inside the daemon, so passing one is
+    // passing the other. Adding `--server` beside it would be an ambiguous
+    // instruction where the daemon's own precedence, not ours, decides.
+    if (!hasFlag(argv, '--server', '-s') && !hasFlag(argv, '--env', '-e')) {
+        const { baseURL } = (0, config_1.loadConfig)();
+        if (baseURL)
+            extra.push('--server', baseURL);
+    }
+    if (!hasFlag(argv, '--profile')) {
+        // The CLI's own profile, resolved the same way `BaseCommand` resolves it.
+        // These commands extend `Command`, so `init()` never ran and the module
+        // state `getActiveProfile()` reads was never set — asking it here would
+        // report `default` no matter what the user typed.
+        const profile = (0, keychain_1.resolveProfileFromArgv)(argv) ?? process.env.OVERSKY_PROFILE ?? null;
+        if (profile && profile !== keychain_1.DEFAULT_PROFILE)
+            extra.push('--profile', profile);
+    }
+    return [...argv, ...extra];
+}