@skrr-ai/cli 0.1.32 → 0.1.33

package/dist/lib/{sky-code.js → first-party-harness.js}

@@ -1,27 +1,37 @@
 "use strict";
 /**
- * WL-2.2 — locate and forward to the local `sky-code` engine.
+ * WL-2.2 — locate and forward to the local first-party harness engine.
  *
  * The same `gh → git` shape `exec-runtime-binary.ts` uses, for the same reason: the
- * Sky CLI is a REST client, the engine is a separately-built, separately-
+ * skrr CLI is a REST client, the engine is a separately-built, separately-
  * released binary with its own lifetime and failure model. Unifying them at
  * the command surface (`skrr code`) gives users one thing to type without
  * coupling the two release cycles.
  *
  * The naming constraint from the plan (§3) is load-bearing and easy to get
  * wrong: skrr already publishes `oversky` (daemon) and `skrr` (control
- * plane). This must NOT become a third top-level executable. `sky-code` is an
- * internal binary name; `skrr code` is the only public entry point.
+ * plane). This must NOT become a third top-level executable. The engine's file
+ * name (`firstPartyHarnessBinaryName()`) is internal; `skrr code` is the only
+ * public entry point.
+ *
+ * ── No product name in this file ──────────────────────────────────────────
+ *
+ * Every product-named value — the binary's file name, the engine home, the env
+ * var names, the display name — is read from the identity module in
+ * `@skrr-ai/auth-core` (`docs/architecture/skrr-code-identifier-rename-2026-09-13.md`).
+ * The engine's file name has more than one spelling while a rename is in
+ * flight, so resolution tries every spelling, canonical first, in each location.
  */
 var __importDefault = (this && this.__importDefault) || function (mod) {
     return (mod && mod.__esModule) ? mod : { "default": mod };
 };
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.ENGINE_START_REFUSED_EXIT_CODE = exports.EngineStartRefusedError = exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = exports.DEDICATED_WORKLOAD_UID_ENV = exports.ENGINE_PATH_ENV = void 0;
+exports.ENGINE_START_REFUSED_EXIT_CODE = exports.EngineStartRefusedError = exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = exports.DEDICATED_WORKLOAD_UID_ENV = exports.ENGINE_NOT_INSTALLED = void 0;
 exports.engineHome = engineHome;
-exports.skyCodeInstructionHome = skyCodeInstructionHome;
+exports.engineInstructionHome = engineInstructionHome;
 exports.managedEnginePath = managedEnginePath;
-exports.legacyManagedEnginePath = legacyManagedEnginePath;
+exports.legacyManagedEnginePaths = legacyManagedEnginePaths;
+exports.legacyManagedEngineBinDirs = legacyManagedEngineBinDirs;
 exports.resolveEngine = resolveEngine;
 exports.buildEngineArgs = buildEngineArgs;
 exports.isDedicatedRuntimeWorkload = isDedicatedRuntimeWorkload;
@@ -30,6 +40,7 @@ exports.inheritedProviderCredentials = inheritedProviderCredentials;
 exports.hasProviderCredential = hasProviderCredential;
 exports.strippedProviderCredentialNames = strippedProviderCredentialNames;
 exports.engineSpawnEnv = engineSpawnEnv;
+exports.engineOwnedEnv = engineOwnedEnv;
 exports.execEngine = execEngine;
 const node_child_process_1 = require("node:child_process");
 const node_fs_1 = require("node:fs");
@@ -42,25 +53,42 @@ const config_1 = require("./config");
 // 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
 // step back toward inferring a security-relevant fact from a string.
-/** Env override, mirroring the daemon's `OVERSKY_SKY_CODE_PATH`. */
-exports.ENGINE_PATH_ENV = 'OVERSKY_SKY_CODE_PATH';
 /**
- * The engine's user-state root. skrr Code's child of skrr's `~/.skrr/`.
+ * The error `execEngine` throws when no engine resolves. A value the commands
+ * compare against, so it is exported rather than retyped at each catch site.
+ */
+exports.ENGINE_NOT_INSTALLED = 'engine-not-installed';
+/**
+ * The engine's user-state root: the engine home under skrr's `~/.skrr/`.
  *
  * Honours `OVERSKY_CONFIG_DIR`, the same root override the daemon reads
  * (`daemon/src/bun-entry.ts`). Without it the CLI would keep looking under
  * `$HOME` for a user who relocated their skrr root, and would resolve a
  * different engine than the daemon — the exact divergence the managed-first
  * ordering below exists to prevent.
+ *
+ * The directory NAME follows the engine's own namespace, not the provider slug
+ * (`firstPartyHarnessHomeDirname`, contract §5): the engine reads its config and
+ * the managed `AGENTS.md` from here, so a home named after anything else would be
+ * a directory the engine never reads.
  */
 function engineHome(env = process.env) {
-    // `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 shared resolver and not a second reading of the environment: deriving
+    // the root twice is what let this function and `getConfigPath()` disagree
+    // (OSK-300).
+    return (0, auth_core_1.firstPartyHarnessHomeDir)(env);
 }
-/** The user-level instruction root owned by skrr Code. */
-function skyCodeInstructionHome(env = process.env) {
-    const configured = env.SKY_CODE_HOME?.trim();
+/**
+ * The user-level instruction root the engine owns.
+ *
+ * Read under the neutral variable first and its older name second
+ * (`readFirstPartyHarnessEnv`). The older name is also the one the ENGINE reads,
+ * which is why {@link engineOwnedEnv} hands the resolved value to the engine under
+ * that name — otherwise the doctor would honour the neutral variable and the
+ * engine would not.
+ */
+function engineInstructionHome(env = process.env) {
+    const configured = (0, auth_core_1.readFirstPartyHarnessEnv)(env, 'home').value;
     // 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).
@@ -73,14 +101,16 @@ function skyCodeInstructionHome(env = process.env) {
     return node_path_1.default.resolve(configured);
 }
 /**
- * The managed install location — where the daemon, the Desktop app, and
- * `scripts/sky-code/build.mjs --install` all put the engine.
+ * The managed install location for one spelling of the binary (canonical by
+ * default) — where the daemon, the Desktop app, and
+ * `scripts/first-party-harness/build.mjs --install` all put the engine.
  */
-function managedEnginePath(exeName, env = process.env) {
-    return node_path_1.default.join(engineHome(env), 'bin', exeName);
+function managedEnginePath(env = process.env, provider = auth_core_1.FIRST_PARTY_HARNESS.provider) {
+    return (0, auth_core_1.firstPartyHarnessInstalledBinaryPath)(env, provider, process.platform);
 }
 /**
- * The same managed location under the PREVIOUS config root.
+ * The same managed location under the PREVIOUS config root, for every spelling of
+ * the binary and every engine home name, canonical first.
  *
  * The root moved `~/.oversky` → `~/.skrr` in the skrr rename, and an engine
  * installed before that is still on disk under the old one. `daemon/src/
@@ -88,14 +118,22 @@ function managedEnginePath(exeName, env = process.env) {
  * the same machine the daemon found the engine and `skrr code` reported that no
  * engine was installed — the same product, the same 106 MB binary, two answers.
  *
- * Returns null when an explicit `OVERSKY_CONFIG_DIR` is set, matching the
- * daemon: that override names one root deliberately, and reaching past it to a
- * hard-coded home would defeat the pinning {@link engineHome} relies on.
+ * The engine-home move (`migrateFirstPartyHarnessHome`) only ever works under the
+ * CURRENT root, so nothing renames a binary here — which is why this list carries
+ * every spelling rather than only the canonical one.
+ *
+ * Empty when an explicit `OVERSKY_CONFIG_DIR` is set, matching the daemon: that
+ * override names one root deliberately, and reaching past it to a hard-coded home
+ * would defeat the pinning {@link engineHome} relies on.
  */
-function legacyManagedEnginePath(exeName, env = process.env) {
+function legacyManagedEnginePaths(env = process.env) {
+    return legacyManagedEngineBinDirs(env).flatMap((dir) => (0, auth_core_1.firstPartyHarnessBinaryNames)(process.platform).map((name) => node_path_1.default.join(dir, name)));
+}
+/** The `bin` directories {@link legacyManagedEnginePaths} looks in. */
+function legacyManagedEngineBinDirs(env = process.env) {
     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);
+        return [];
+    return [(0, auth_core_1.firstPartyHarnessHomeDirname)(), ...auth_core_1.FIRST_PARTY_HARNESS_ENGINE.legacyAppNames].map((home) => node_path_1.default.join((0, config_1.priorConfigDir)(), home, 'bin'));
 }
 /**
  * Unmanaged well-known locations, checked after PATH.
@@ -110,6 +148,15 @@ function fallbackPaths(exeName) {
         node_path_1.default.join((0, node_os_1.homedir)(), '.local', 'bin', exeName),
     ];
 }
+/**
+ * The file names a PATH directory may hold the engine under, canonical first.
+ * Windows also accepts a `.cmd` shim, as a package manager may install one.
+ */
+function pathExecutableNames(platform) {
+    return (0, auth_core_1.firstPartyHarnessSpellings)().flatMap((spelling) => platform === 'win32'
+        ? [(0, auth_core_1.firstPartyHarnessBinaryName)(spelling, platform), `${spelling}.cmd`]
+        : [(0, auth_core_1.firstPartyHarnessBinaryName)(spelling, platform)]);
+}
 function isExecutable(p) {
     try {
         (0, node_fs_1.accessSync)(p, node_fs_1.constants.X_OK);
@@ -126,19 +173,23 @@ function isExecutable(p) {
  * binary am I actually running" is the first question when a managed session
  * and an interactive session behave differently.
  *
- * `env` is checked first and is absolute-only. A relative `OVERSKY_SKY_CODE_PATH`
+ * The env override is checked first and is absolute-only. A relative override
  * would resolve against the caller's cwd, which for an agent-invoked command is
- * attacker-influenced: a repo containing `./sky-code` could hijack the engine.
+ * attacker-influenced: a repo containing a file named like the engine could
+ * hijack it. It is read under its neutral name first and its older name second.
  *
- * **Order: env → managed → PATH → well-known (WL-6.2).**
+ * **Order: env → managed → PATH → well-known (WL-6.2).** Within each location
+ * every spelling of the binary is tried, canonical first — the daemon's order —
+ * so an engine installed under an older name still resolves, and the canonical
+ * one wins wherever both exist.
  *
  * The managed location beating `PATH` is the load-bearing part, and it is a
  * deliberate reversal of the obvious ordering.
  *
  * WL-6.2's acceptance criterion is that "Desktop-bundled and standalone
  * installations resolve the same version deterministically". With `PATH` first
- * they do not: a Desktop app that ships a pinned, signed engine into
- * `~/.skrr/sky-code/bin` silently loses to whatever `sky-code` happens to sit
+ * they do not: a Desktop app that ships a pinned, signed engine into the managed
+ * `bin` directory silently loses to whatever engine binary happens to sit
  * earlier on the user's `PATH` — a months-old dev build, a Homebrew copy of a
  * different version, a shim from an uninstalled package manager. The user sees
  * one product and gets two engines depending on their shell, and the daemon
@@ -151,33 +202,40 @@ function isExecutable(p) {
  *
  * `skrr code doctor` prints the winning `source`, so a surprising resolution is
  * one command away from being explained rather than being a mystery.
+ *
+ * Pure: it reads the filesystem and moves nothing. The engine-home move runs in
+ * {@link execEngine}, before it resolves, so the doctor stays safe to run anywhere.
  */
 function resolveEngine(env = process.env) {
-    const exeName = process.platform === 'win32' ? 'sky-code.exe' : 'sky-code';
-    const override = env[exports.ENGINE_PATH_ENV];
-    if (override && override.trim()) {
-        const candidate = override.trim();
+    const platform = process.platform;
+    const override = (0, auth_core_1.readFirstPartyHarnessEnv)(env, 'path');
+    if (override.value && override.name) {
+        const origin = { envName: override.name, legacyEnv: override.legacy };
+        const candidate = override.value;
         if (!node_path_1.default.isAbsolute(candidate))
-            return { path: null, source: 'unresolved' };
+            return { path: null, source: 'unresolved', ...origin };
         return isExecutable(candidate)
-            ? { path: candidate, source: 'env' }
-            : { path: null, source: 'unresolved' };
+            ? { path: candidate, source: 'env', ...origin }
+            : { path: null, source: 'unresolved', ...origin };
+    }
+    for (const spelling of (0, auth_core_1.firstPartyHarnessSpellings)()) {
+        const managed = managedEnginePath(env, spelling);
+        if (isExecutable(managed))
+            return { path: managed, source: 'managed' };
     }
-    const managed = managedEnginePath(exeName, env);
-    if (isExecutable(managed))
-        return { path: managed, source: 'managed' };
     // The pre-rename managed location, SECOND. After the current one, so a fresh
     // install always wins; before PATH, for the same WL-6.2 reason the current one
     // beats PATH — a binary skrr installed outranks whatever happens to sit on the
     // user's PATH, and which config root it was installed under does not change
     // that. Reported as its own `source` so `skrr code doctor` can say where it
     // came from rather than quietly resolving something surprising.
-    const legacy = legacyManagedEnginePath(exeName, env);
-    if (legacy && isExecutable(legacy))
-        return { path: legacy, source: 'legacy-managed' };
+    for (const legacy of legacyManagedEnginePaths(env)) {
+        if (isExecutable(legacy))
+            return { path: legacy, source: 'legacy-managed' };
+    }
     const PATH = env.PATH ?? '';
-    const sep = process.platform === 'win32' ? ';' : ':';
-    const exeNames = process.platform === 'win32' ? ['sky-code.exe', 'sky-code.cmd'] : ['sky-code'];
+    const sep = platform === 'win32' ? ';' : ':';
+    const exeNames = pathExecutableNames(platform);
     for (const dir of PATH.split(sep)) {
         if (!dir)
             continue;
@@ -187,9 +245,11 @@ function resolveEngine(env = process.env) {
                 return { path: candidate, source: 'path' };
         }
     }
-    for (const candidate of fallbackPaths(exeName)) {
-        if (isExecutable(candidate))
-            return { path: candidate, source: 'fallback' };
+    for (const exeName of (0, auth_core_1.firstPartyHarnessBinaryNames)(platform)) {
+        for (const candidate of fallbackPaths(exeName)) {
+            if (isExecutable(candidate))
+                return { path: candidate, source: 'fallback' };
+        }
     }
     return { path: null, source: 'unresolved' };
 }
@@ -239,20 +299,20 @@ exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = 'On a Dedicated Runtime, coding engin
  * Message shown when no engine is installed.
  *
  * Points at the DAEMON's managed installer rather than at a package manager.
- * The earlier version of this text offered `brew install
- * dush1023/oversky/sky-code` and `curl .../sky-code/install.sh | bash`; neither
- * exists — the tap carries only the `oversky` formula and the feed serves no
- * install script — so a user following it hit a 404 and a 403 and reasonably
- * concluded the engine was not real.
+ * The earlier version of this text offered a Homebrew formula for the engine and
+ * a `curl .../install.sh | bash` on the update feed; neither exists — the tap
+ * carries only the `oversky` formula and the feed serves no install script — so
+ * a user following it hit a 404 and a 403 and reasonably concluded the engine
+ * was not real.
  *
  * The managed path is also the only one that establishes provenance: it
  * verifies the signed manifest and writes the sidecar the daemon reads before
  * it will hand the engine a platform credential. A hand-placed binary works, and
  * since the owner decision of 2026-08-11 it runs at the SAME tier as a managed
- * one — the daemon's floor for `sky-code` is Tier 1 regardless of provenance
- * (OSK-3894; this said "stays at Tier 2"). The managed path is still the
- * recommendation, but the reason is now "you can prove which bytes ran" rather
- * than "otherwise you get a weaker credential".
+ * one — the daemon's floor for the first-party harness is Tier 1 regardless of
+ * provenance (OSK-3894; this said "stays at Tier 2"). The managed path is still
+ * the recommendation, but the reason is now "you can prove which bytes ran"
+ * rather than "otherwise you get a weaker credential".
  *
  * Keep this in step with what actually ships. An install instruction that does
  * not work is worse than none: it moves the failure from "I could not find how
@@ -262,9 +322,10 @@ exports.DEDICATED_RUNTIME_ENGINE_MESSAGE = 'On a Dedicated Runtime, coding engin
  * below fails there (see {@link DEDICATED_RUNTIME_ENGINE_MESSAGE}).
  */
 function notInstalledMessage(env = process.env) {
+    const { command, displayName } = auth_core_1.FIRST_PARTY_HARNESS;
     if (isDedicatedRuntimeWorkload(env)) {
         return [
-            'The skrr Code engine is not on this machine.',
+            `The ${displayName} engine (\`${(0, auth_core_1.firstPartyHarnessBinaryName)()}\`) is not on this machine.`,
             '',
             exports.DEDICATED_RUNTIME_ENGINE_MESSAGE,
             'This machine was built from an image without it; it arrives when the',
@@ -272,18 +333,18 @@ function notInstalledMessage(env = process.env) {
         ].join('\n');
     }
     return [
-        'The skrr Code engine (`sky-code`) is not installed on this machine.',
+        `The ${displayName} engine (\`${(0, auth_core_1.firstPartyHarnessBinaryName)()}\`) is not installed on this machine.`,
         '',
         'Install it through the daemon, which verifies the signed release:',
-        '  • `skrr code install`  — from here, no browser needed',
-        '  • Or in the web app: the runtime menu beside the chat input → skrr Code → Install',
+        `  • \`${command} install\`  — from here, no browser needed`,
+        `  • Or in the web app: the runtime menu beside the chat input → ${displayName} → Install`,
         '  • Either way a daemon must be running here: `skrr daemon status`',
         '',
-        `Or point the CLI at an existing build:  export ${exports.ENGINE_PATH_ENV}=/absolute/path/to/sky-code`,
+        `Or point the CLI at an existing build:  export ${auth_core_1.FIRST_PARTY_HARNESS_ENV.path.name}=/absolute/path/to/${(0, auth_core_1.firstPartyHarnessBinaryName)()}`,
         '  (an unsigned build runs, and since 2026-08-11 at the same trust tier as a',
-        '   signed one — see `skrr code doctor` under trust-tier)',
+        `   signed one — see \`${command} doctor\` under trust-tier)`,
         '',
-        'Run `skrr code doctor` for a full diagnosis. Its `release-channel` line',
+        `Run \`${command} doctor\` for a full diagnosis. Its \`release-channel\` line`,
         'names the channel this machine follows and the exact manifest URL to check',
         'for a published release.',
     ].join('\n');
@@ -344,7 +405,7 @@ const BYOK_CREDENTIAL_NAMES = new Set(['HUGGINGFACE_HUB_TOKEN']);
  * shared config, a file the engine can read anyway. Stripping them therefore
  * protected nothing and cost an entire provider.
  *
- * Dogfooded as OSK-262, where `sky-code run "say hi"` answered on a Bedrock
+ * Dogfooded as OSK-262, where the bare engine's `run "say hi"` answered on a Bedrock
  * model and the identical run through `skrr code` died in the engine's generic
  * error handler — because `AWS_PROFILE` did not survive the sanitizer.
  * `env -u AWS_PROFILE` on the bare engine reproduced the failure exactly.
@@ -389,7 +450,7 @@ const ENGINE_NEVER_INHERITS_PREFIXES = ['OVERSKY_', 'AWS_'];
  *
  * Exported because two callers need ONE answer to "does this machine have a
  * provider key at all": this module, to decide what the engine inherits, and the
- * BYOK fallback line in `sky-code-broker.ts`, which used to promise "continuing
+ * BYOK fallback line in `first-party-harness-broker.ts`, which used to promise "continuing
  * with your own provider credentials" on a machine that had none (invariant I4 —
  * managed, BYOK and offline must never be confused). Two definitions of that
  * question is how the promise and the reality drift apart.
@@ -495,10 +556,14 @@ function strippedProviderCredentialNames(env = process.env) {
  *
  * One sharp edge to know about before adding a subcommand: the shared sanitizer
  * strips anything ending in `_PASSWORD`, which includes the engine's own
- * `SKY_CODE_SERVER_PASSWORD` (Basic auth for `sky-code serve` / `web`). No
- * `skrr code` subcommand reaches those today — they are run against the engine
- * binary directly — so nothing regresses; a future `skrr code serve` would have to
- * pass that credential deliberately rather than rely on inheritance.
+ * server-password variable (`FIRST_PARTY_HARNESS_ENGINE.env.serverPassword`, Basic
+ * auth for the engine's `serve` / `web`). No `skrr code` subcommand reaches those
+ * today — they are run against the engine binary directly — so nothing regresses;
+ * a future `skrr code serve` would have to pass that credential deliberately,
+ * under that name, rather than rely on inheritance.
+ *
+ * The layering, in full: sanitized parent → the user's own model credential (BYOK
+ * only) → {@link engineOwnedEnv} → `extraEnv`.
  */
 function engineSpawnEnv(env, extraEnv, 
 // Required, not defaulted: the safe value differs per call and a parameter that
@@ -507,6 +572,7 @@ mode) {
     const spawnEnv = {
         ...(0, auth_core_1.sanitizeSpawnEnv)(env),
         ...(mode === 'managed' ? {} : inheritedProviderCredentials(env)),
+        ...engineOwnedEnv(env),
         ...extraEnv,
     };
     if (mode !== 'managed')
@@ -519,7 +585,40 @@ mode) {
     // otherwise have received rather than replacing it.
     return { ...spawnEnv, ...(0, inference_broker_1.inferenceBrokerNoProxyEnv)(spawnEnv) };
 }
+/**
+ * Settings the platform reads under NEUTRAL names, handed to the engine under the
+ * engine's OWN names.
+ *
+ * The engine is a fork with its own variable namespace
+ * (`FIRST_PARTY_HARNESS_ENGINE.env`), and it reads none of the platform's neutral
+ * names. So an operator who sets the neutral home override would see
+ * `skrr code doctor` honour it while the engine it launches ignored it — two
+ * answers to "where do my instructions live" from one command.
+ *
+ * Only when the value came from a name the engine does NOT read: a value set under
+ * the engine's own name is inherited already, and rewriting it would only replace
+ * the user's spelling of a path with ours. The resolved path is passed rather than
+ * the raw value, so the engine and the doctor agree on `~` expansion too.
+ *
+ * Not a credential and never one: it cannot reintroduce anything the sanitizer
+ * strips, and `extraEnv` still layers over it.
+ */
+function engineOwnedEnv(env) {
+    const out = {};
+    const home = (0, auth_core_1.readFirstPartyHarnessEnv)(env, 'home');
+    if (home.value && home.name !== auth_core_1.FIRST_PARTY_HARNESS_ENGINE.env.home) {
+        out[auth_core_1.FIRST_PARTY_HARNESS_ENGINE.env.home] = engineInstructionHome(env);
+    }
+    return out;
+}
 async function execEngine(args, env = process.env, options = {}) {
+    // Move an engine installed under an older binary name onto the canonical one,
+    // BEFORE resolving. Idempotent, lossless, and it never throws: a move that
+    // cannot be made leaves every file where it was, and `resolveEngine` still tries
+    // every spelling — so the worst case is today's path, never a missing engine.
+    // Here and not in `resolveEngine`, which the doctor also calls and which must
+    // not move anything.
+    (0, auth_core_1.migrateFirstPartyHarnessHome)({ env });
     // Resolve the binary FIRST, before `prepare` runs.
     //
     // Order matters: a caller learns "not installed" from here, and starting a
@@ -527,7 +626,7 @@ async function execEngine(args, env = process.env, options = {}) {
     // engine that never runs.
     const { path: bin } = resolveEngine(env);
     if (!bin)
-        throw new Error('sky-code-not-installed');
+        throw new Error(exports.ENGINE_NOT_INSTALLED);
     // Assumed until the spawn tells us otherwise, so a teardown that runs after a
     // spawn ERROR does not claim the run was interrupted.
     const outcome = { interrupted: false };

package/dist/lib/harness-provider-input.d.ts

@@ -0,0 +1,35 @@
+/**
+ * Harness-valued INPUT, normalised at the edge.
+ *
+ * The first-party harness has more than one accepted spelling while a rename is
+ * in flight (`FIRST_PARTY_HARNESS.aliases`). Every flag, setting and filter that
+ * takes a harness name must accept all of them — a script written against either
+ * spelling keeps working — and must hand the rest of the CLI ONE value, so no
+ * comparison downstream has to know there were two
+ * (`docs/architecture/skrr-code-identifier-rename-2026-09-13.md` §2).
+ *
+ * Two destinations, two spellings, and the difference is the point:
+ *
+ *   - to the SERVER (HTTP bodies, query params) and to the terminal: CANONICAL,
+ *     which is what the platform stores and returns;
+ *   - to the local DAEMON binary: the WIRE spelling, which every daemon version
+ *     already installed on a user's machine understands. A daemon that predates
+ *     the rename cannot be taught a new spelling by the CLI that talks to it.
+ *
+ * Every other harness name passes through unchanged — this normalises one
+ * harness's spellings, it is not a general lower-caser, and silently rewriting a
+ * name this module knows nothing about would be a behaviour change nobody asked for.
+ */
+/** The canonical provider for any spelling of the first-party harness; anything else trimmed. */
+export declare function canonicalHarnessInput(value: string): string;
+/** Canonicalise a repeatable flag, keeping the first occurrence of each value. */
+export declare function canonicalHarnessInputs(values: readonly string[]): string[];
+/** The spelling to hand the LOCAL daemon binary for a harness-valued argument. */
+export declare function daemonHarnessArgument(value: string): string;
+/**
+ * The `options` list for an oclif flag that enumerates harness names: the given
+ * names with every spelling of the first-party harness in place of its canonical
+ * one, so oclif's own validation accepts an alias instead of rejecting it before
+ * the command ever runs.
+ */
+export declare function harnessFlagOptions(names: readonly string[]): string[];

package/dist/lib/harness-provider-input.js

@@ -0,0 +1,57 @@
+"use strict";
+/**
+ * Harness-valued INPUT, normalised at the edge.
+ *
+ * The first-party harness has more than one accepted spelling while a rename is
+ * in flight (`FIRST_PARTY_HARNESS.aliases`). Every flag, setting and filter that
+ * takes a harness name must accept all of them — a script written against either
+ * spelling keeps working — and must hand the rest of the CLI ONE value, so no
+ * comparison downstream has to know there were two
+ * (`docs/architecture/skrr-code-identifier-rename-2026-09-13.md` §2).
+ *
+ * Two destinations, two spellings, and the difference is the point:
+ *
+ *   - to the SERVER (HTTP bodies, query params) and to the terminal: CANONICAL,
+ *     which is what the platform stores and returns;
+ *   - to the local DAEMON binary: the WIRE spelling, which every daemon version
+ *     already installed on a user's machine understands. A daemon that predates
+ *     the rename cannot be taught a new spelling by the CLI that talks to it.
+ *
+ * Every other harness name passes through unchanged — this normalises one
+ * harness's spellings, it is not a general lower-caser, and silently rewriting a
+ * name this module knows nothing about would be a behaviour change nobody asked for.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.canonicalHarnessInput = canonicalHarnessInput;
+exports.canonicalHarnessInputs = canonicalHarnessInputs;
+exports.daemonHarnessArgument = daemonHarnessArgument;
+exports.harnessFlagOptions = harnessFlagOptions;
+const auth_core_1 = require("@skrr-ai/auth-core");
+/** The canonical provider for any spelling of the first-party harness; anything else trimmed. */
+function canonicalHarnessInput(value) {
+    const trimmed = value.trim();
+    return String((0, auth_core_1.canonicalHarnessProvider)(trimmed));
+}
+/** Canonicalise a repeatable flag, keeping the first occurrence of each value. */
+function canonicalHarnessInputs(values) {
+    const out = [];
+    for (const value of values) {
+        const canonical = canonicalHarnessInput(value);
+        if (canonical && !out.includes(canonical))
+            out.push(canonical);
+    }
+    return out;
+}
+/** The spelling to hand the LOCAL daemon binary for a harness-valued argument. */
+function daemonHarnessArgument(value) {
+    return (0, auth_core_1.wireHarnessProvider)(canonicalHarnessInput(value));
+}
+/**
+ * The `options` list for an oclif flag that enumerates harness names: the given
+ * names with every spelling of the first-party harness in place of its canonical
+ * one, so oclif's own validation accepts an alias instead of rejecting it before
+ * the command ever runs.
+ */
+function harnessFlagOptions(names) {
+    return canonicalHarnessInputs(names).flatMap((name) => (0, auth_core_1.isFirstPartyHarnessProvider)(name) ? [...(0, auth_core_1.firstPartyHarnessSpellings)()] : [name]);
+}

package/dist/lib/harness-tiers.d.ts

@@ -3,7 +3,7 @@
  *
  * ── What this file used to be, and why it changed twice ────────────────────
  *
- * `skrr code doctor` reported "sky-code is Tier 2 … its tool calls are adjudicated
+ * `skrr code doctor` reported "<the first-party harness> is Tier 2 … its tool calls are adjudicated
  * per call by the daemon" while the daemon had recorded Tier 1 since the owner
  * decision of 2026-08-11. The audience that runs `doctor` runs it BECAUSE
  * permissions are confusing them, so that line was wrong to exactly the people it
@@ -44,7 +44,13 @@ export { HARNESS_TIERS, getHarnessTier };
  */
 export declare const HARNESS_TIER_TABLE = "packages/auth-core/src/harnessTrust.ts";
 export declare const HARNESS_TIER_AUTHORITY = "daemon/src/harness-trust.ts";
-/** The tier the shared table records for a harness, or `null` for an unknown name. */
+/**
+ * The tier the shared table records for a harness, or `null` for an unknown name.
+ *
+ * Canonicalised first, so no spelling of the first-party harness can reach the
+ * lookup as an unknown name — the shared table also carries every spelling, and
+ * this keeps the answer right even for one written in a different case.
+ */
 export declare function mirroredTier(harness: string): HarnessTrustTier | null;
 export interface TierDescription {
     /** What is true, in one line. */

package/dist/lib/harness-tiers.js

@@ -4,7 +4,7 @@
  *
  * ── What this file used to be, and why it changed twice ────────────────────
  *
- * `skrr code doctor` reported "sky-code is Tier 2 … its tool calls are adjudicated
+ * `skrr code doctor` reported "<the first-party harness> is Tier 2 … its tool calls are adjudicated
  * per call by the daemon" while the daemon had recorded Tier 1 since the owner
  * decision of 2026-08-11. The audience that runs `doctor` runs it BECAUSE
  * permissions are confusing them, so that line was wrong to exactly the people it
@@ -49,11 +49,16 @@ Object.defineProperty(exports, "getHarnessTier", { enumerable: true, get: functi
  */
 exports.HARNESS_TIER_TABLE = 'packages/auth-core/src/harnessTrust.ts';
 exports.HARNESS_TIER_AUTHORITY = 'daemon/src/harness-trust.ts';
-/** The tier the shared table records for a harness, or `null` for an unknown name. */
+/**
+ * The tier the shared table records for a harness, or `null` for an unknown name.
+ *
+ * Canonicalised first, so no spelling of the first-party harness can reach the
+ * lookup as an unknown name — the shared table also carries every spelling, and
+ * this keeps the answer right even for one written in a different case.
+ */
 function mirroredTier(harness) {
-    return Object.prototype.hasOwnProperty.call(auth_core_1.HARNESS_TIERS, harness)
-        ? (0, auth_core_1.getHarnessTier)(harness)
-        : null;
+    const key = String((0, auth_core_1.canonicalHarnessProvider)(harness));
+    return Object.prototype.hasOwnProperty.call(auth_core_1.HARNESS_TIERS, key) ? (0, auth_core_1.getHarnessTier)(key) : null;
 }
 /**
  * Render the user-facing meaning of a tier.
@@ -79,7 +84,7 @@ function describeTier(harness, tier) {
             detail: `${harness} is Tier 1: an operator-configured \`auto\` permission mode STANDS ` +
                 '(it is not downgraded to per-call adjudication), and direct platform-key ' +
                 'delivery is permitted. A tier still never approves an individual tool call.',
-            remedy: 'skrr does not yet sign sky-code releases, so in practice an UNSIGNED build can ' +
+            remedy: `skrr does not yet sign ${auth_core_1.FIRST_PARTY_HARNESS.displayName} releases, so in practice an UNSIGNED build can ` +
                 'receive the platform master key. The provenance machinery still runs and still ' +
                 'verifies binaries — signing stops being what earns the key and becomes what lets ' +
                 `you prove which bytes held it. Reverting to the strict posture is one line in ${exports.HARNESS_TIER_TABLE}.`,

package/dist/lib/task-instruction-offer.js

@@ -1,6 +1,7 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.maybeOfferTaskManagementInstructions = maybeOfferTaskManagementInstructions;
+const auth_core_1 = require("@skrr-ai/auth-core");
 const data_provider_1 = require("@skrr-ai/data-provider");
 const config_1 = require("./config");
 const daemon_target_1 = require("./daemon-target");
@@ -31,8 +32,11 @@ function detectedProviders(daemon) {
         providers.push('claude');
     if (capabilities.includes('codex_session'))
         providers.push('codex');
-    if (capabilities.includes('sky-code_session'))
-        providers.push('sky-code');
+    // A daemon advertises the first-party harness under whichever spelling its
+    // version speaks; any of them means the harness is there, and the offer names
+    // it canonically, which is what the server stores.
+    if (capabilities.some(auth_core_1.isFirstPartyHarnessCapability))
+        providers.push(auth_core_1.FIRST_PARTY_HARNESS_PROVIDER);
     return providers;
 }
 function providerLabel(provider) {
@@ -40,14 +44,16 @@ function providerLabel(provider) {
         return 'Claude Code';
     if (provider === 'codex')
         return 'Codex';
-    return 'skrr Code';
+    return auth_core_1.FIRST_PARTY_HARNESS.displayName;
 }
 function providerPath(provider) {
     if (provider === 'claude')
         return '~/.claude/CLAUDE.md';
     if (provider === 'codex')
         return '~/.codex/AGENTS.md';
-    return '~/.skrr/sky-code/AGENTS.md';
+    // The engine home follows the ENGINE's namespace, not the provider slug — the
+    // engine reads its managed `AGENTS.md` from there (contract §5).
+    return `~/.skrr/${(0, auth_core_1.firstPartyHarnessHomeDirname)()}/AGENTS.md`;
 }
 function shouldSkipOffer() {
     return Boolean(!process.stdin.isTTY ||

package/dist/lib/worklogs.js

@@ -14,8 +14,8 @@ exports.renderWorklogEntry = renderWorklogEntry;
  * ── Why this file exists ──────────────────────────────────────────────────
  *
  * Worklog writing was an MCP capability, and MCP tools execute in the CLOUD.
- * An agent pinned to a LOCAL daemon runtime — Claude Code, Codex, skrr Code
- * alike — could read a worklog and could not write one, because the route
+ * An agent pinned to a LOCAL daemon runtime — Claude Code, Codex, the
+ * first-party harness alike — could read a worklog and could not write one, because the route
  * exposed three endpoints and all three were reads (OSK-3495).
  *
  * That is the same gap the CLI already closes for every sibling domain: tasks,