@skrr-ai/cli 0.1.9 → 0.1.10

package/dist/commands/login.js

@@ -155,7 +155,8 @@ class Login extends base_command_1.BaseCommand {
                 // Only now is the new pointer earned.
                 undoBaseURL = null;
                 this.log('');
-                this.log(`Signed in via ${result.flow}. Run \`${this.config.bin} whoami\` to confirm your identity.`);
+                this.log(`Signed in via ${result.flow} on ${(0, config_1.describeDeployment)(this.cliConfig.baseURL)}. ` +
+                    `Run \`${this.config.bin} whoami\` to confirm your identity.`);
             }
             catch (err) {
                 // Everything structured in login.ts throws Error; surface the
@@ -201,7 +202,8 @@ class Login extends base_command_1.BaseCommand {
                 cliId,
             });
             this.log('');
-            this.log(`Signed in via ${result.flow} (OVERSKY_REFRESH_TOKEN). ` +
+            this.log(`Signed in via ${result.flow} (OVERSKY_REFRESH_TOKEN) on ` +
+                `${(0, config_1.describeDeployment)(this.cliConfig.baseURL)}. ` +
                 `Run \`${this.config.bin} whoami\` to confirm your identity.`);
         }
         catch (err) {
@@ -278,7 +280,8 @@ class Login extends base_command_1.BaseCommand {
                 : undefined,
         }, { serverOrigin: this.cliConfig.baseURL, clearReauth: true });
         this.log('');
-        this.log(`Signed in as ${result.user.email} via recovery code.`);
+        this.log(`Signed in as ${result.user.email} via recovery code on ` +
+            `${(0, config_1.describeDeployment)(this.cliConfig.baseURL)}.`);
         this.log(`Run \`${this.config.bin} whoami\` to confirm your identity.`);
     }
 }

package/dist/commands/whoami.js

@@ -130,7 +130,10 @@ class Whoami extends base_command_1.BaseCommand {
             : '-';
         this.log(`Workspace:      ${workspaceLabel}`);
         this.log(`Daemon ID:      ${daemonId ?? '-'}`);
-        this.log(`Server:         ${this.cliConfig.baseURL}`);
+        // Named, not just spelled: `oversky.dev` and `skrr.ai` do not read as a
+        // dev/prod pair to anyone who has not seen the constants, and `whoami` is
+        // where the login message sends you to find out where you are (OSK-301).
+        this.log(`Server:         ${(0, config_1.describeDeployment)(this.cliConfig.baseURL)}`);
         this.log(`Profile:        ${(0, keychain_1.getActiveProfile)()}`);
         if (this.cliConfig.cliId) {
             this.log(`CLI ID:         ${this.cliConfig.cliId}`);

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;
@@ -97,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://');
@@ -113,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
@@ -205,8 +240,27 @@ 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.
@@ -288,10 +342,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/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('~/'))