@skrr-ai/cli 0.1.44 → 0.1.46

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/credentialEnvelopeBridge.js

@@ -10,6 +10,7 @@ exports.resetCredEnvelope = resetCredEnvelope;
 exports.shutdownCredEnvelope = shutdownCredEnvelope;
 exports.__resetShutdownGuardForTest = __resetShutdownGuardForTest;
 exports.isCredEnvelopeActive = isCredEnvelopeActive;
+exports.hasCredEnvelopePathConflict = hasCredEnvelopePathConflict;
 exports.describeCredEnvelopeState = describeCredEnvelopeState;
 exports.maybeEncryptForWrite = maybeEncryptForWrite;
 exports.wrapIfActiveOrPassthrough = wrapIfActiveOrPassthrough;
@@ -23,12 +24,27 @@ exports.__wrappedDekFilePathForTest = __wrappedDekFilePathForTest;
  * implementation. The daemon and CLI both consume this module so they
  * land on the SAME on-disk artifacts:
  *
- *   <configDir>/profiles/<p>/cred-dek-wrapped     — KEK-wrapped DEK
- *   <configDir>/profiles/<p>/cred-envelope.lock   — proper-lockfile sentinel
+ *   <machine root>/profiles/<p>/cred-dek-wrapped     — KEK-wrapped DEK
+ *   <machine root>/profiles/<p>/cred-envelope.lock   — proper-lockfile sentinel
  *
- * `<configDir>` is supplied by the consumer via `configureAuthCore({configDir})`
- * — both binaries today resolve to `~/.skrr` so first-enrollment races
- * between `sky` and `oversky` serialize against the same lockfile.
+ * `<machine root>` comes from `profileStateDir.ts`, which derives it from
+ * `getAuthMachineConfigDir()`. That indirection is not decoration. This header
+ * used to say the paths were built from `configDir` and that "both binaries
+ * today resolve to `~/.skrr` so first-enrollment races between `sky` and
+ * `oversky` serialize against the same lockfile" — and it had been false for as
+ * long as the daemon has been profile-aware. The daemon passes a configDir that
+ * is ALREADY `~/.skrr/profiles/<p>`, so it wrote to
+ * `~/.skrr/profiles/<p>/profiles/<p>/…` while the CLI wrote to
+ * `~/.skrr/profiles/<p>/…`. One profile, two wrapped DEKs, two lockfiles, and
+ * the mutex this module exists to share serialized neither process against the
+ * other (OSK-10314). Reading the machine root is what makes the sentence above
+ * true rather than aspirational.
+ *
+ * On a machine that already has both, `profileStateDir.ts` keeps each process
+ * reading the copy it has been using until the migration has proved the two are
+ * equivalent, and refuses to pick a winner when they are not — see that file.
+ * The LOCK is always taken at the canonical path regardless, because a mutex
+ * that is per-consumer is not a mutex.
  *
  * NAMING NOTE — the suffix `Bridge` distinguishes this composed runtime
  * (init + sign + persist + telemetry) from the pure-crypto primitive
@@ -42,11 +58,13 @@ exports.__wrappedDekFilePathForTest = __wrappedDekFilePathForTest;
  *     when not active. CLI leaves it unset; legacy `OVERSKY_KEK_REQUIRED=1`
  *     env var is still honored as a back-compat trigger.
  */
+const node_crypto_1 = require("node:crypto");
 const node_fs_1 = __importDefault(require("node:fs"));
 const node_path_1 = __importDefault(require("node:path"));
 const proper_lockfile_1 = __importDefault(require("proper-lockfile"));
 const credentialEnvelope_js_1 = require("./credentialEnvelope.js");
 const index_js_1 = require("./kek/index.js");
+const profileStateDir_js_1 = require("./profileStateDir.js");
 const runtime_js_1 = require("./runtime.js");
 /**
  * Account name the wrapped DEK lives under (file fallback). Keeping the
@@ -73,15 +91,15 @@ function __getStateForTest() {
     return _state;
 }
 /**
- * Per-profile config directory. Uses the consumer-supplied configDir from
- * `configureAuthCore()`; the whole point of this module is shared on-disk
- * artifacts, so daemon/CLI MUST configure the same root.
+ * The wrapped DEK this process must read and write for `profile`.
+ *
+ * Canonical on any machine that has only ever had one location, and on one that
+ * has been consolidated. On a machine that still has two, this returns the copy
+ * this process has been using — see `profileStateDir.ts` for why swapping it out
+ * from under a daemon that has sealed credentials with it is not an option.
  */
-function profileConfigDir(profile) {
-    return node_path_1.default.join((0, runtime_js_1.getAuthConfigDir)(), 'profiles', profile);
-}
 function wrappedDekFilePath(profile) {
-    return node_path_1.default.join(profileConfigDir(profile), ACCOUNT_CRED_DEK_WRAPPED);
+    return (0, profileStateDir_js_1.resolveProfileStateFile)(profile, ACCOUNT_CRED_DEK_WRAPPED).path;
 }
 /**
  * Atomic 0600 write — tmp+fsync+rename+dir-fsync. Same shape as the
@@ -148,8 +166,15 @@ const CRED_LOCK_STALE_MS = 30_000;
 const CRED_LOCK_RETRY_MS = 100;
 // Exponential retry capped at 400 ms: 50 retries are ~20 s total, not 5 s.
 const CRED_LOCK_MAX_RETRIES = 50;
+/**
+ * ALWAYS the canonical directory, even when this process is reading a legacy
+ * wrapped DEK. The lock's job is to serialize first enrollment for one profile
+ * on one machine across both binaries; resolving it the way the DEK resolves
+ * would give each consumer its own sentinel, which is how the mutex documented
+ * in this file's header came to protect nobody.
+ */
 function credEnvelopeLockPath(profile) {
-    return node_path_1.default.join(profileConfigDir(profile), 'cred-envelope.lock');
+    return node_path_1.default.join((0, profileStateDir_js_1.profileStateDir)(profile), 'cred-envelope.lock');
 }
 /**
  * Acquire the cross-process credential-envelope lock for a profile, run
@@ -200,6 +225,94 @@ async function withCredEnvelopeLock(profile, body) {
         }
     }
 }
+/**
+ * Sticky record of the last consolidation refusal for this process — two usable
+ * and DIFFERENT wrapped DEKs for one profile. Surfaced through
+ * `describeCredEnvelopeState()` so `skrr status` / `oversky status` can say so:
+ * the split cannot be repaired here (each side's secrets live in its own
+ * keychain namespace, sealed under its own DEK, and re-sealing them is not
+ * auth-core's to do), so being loud about it IS the remedy.
+ */
+let _pathConflict = null;
+/**
+ * Identity of a wrapped DEK: the SHA-256 of the key it unwraps to.
+ *
+ * Not of the file. `kek.wrap` draws a fresh nonce, so wrapping ONE key twice
+ * gives two different files — comparing bytes would call two copies of the same
+ * key a conflict and refuse a migration that was safe. `unwrapExisting` is the
+ * read-only probe: it must never mint a KEK as a side effect of asking whether
+ * an old file is still readable.
+ */
+async function wrappedDekIdentity(target, kek, aad) {
+    let dek = null;
+    try {
+        if (!kek.unwrapExisting)
+            return null;
+        dek = await kek.unwrapExisting(node_fs_1.default.readFileSync(target), aad);
+        if (dek.length !== 32)
+            return null;
+        return (0, node_crypto_1.createHash)('sha256').update(dek).digest('hex');
+    }
+    catch {
+        return null;
+    }
+    finally {
+        dek?.fill(0);
+    }
+}
+/**
+ * Run the OSK-10314 consolidation for this profile's wrapped DEK.
+ *
+ * Under the canonical lock, because the window it closes is real: a daemon
+ * copying its legacy DEK into an empty canonical slot must not race a CLI
+ * enrolling a fresh one there — the loser's key would be overwritten and
+ * anything already sealed under it lost. That is the same race the lock was
+ * introduced for, one layer up.
+ *
+ * Never fatal. A migration that cannot run leaves the process exactly where it
+ * was, which is the state it has been operating in all along.
+ */
+async function consolidateWrappedDek(profile, kek, aad) {
+    const resolved = (0, profileStateDir_js_1.resolveProfileStateFile)(profile, ACCOUNT_CRED_DEK_WRAPPED);
+    if (!resolved.usingLegacy) {
+        _pathConflict = null;
+        return;
+    }
+    let outcome;
+    try {
+        outcome = await withCredEnvelopeLock(profile, () => (0, profileStateDir_js_1.consolidateProfileState)(profile, {
+            files: [ACCOUNT_CRED_DEK_WRAPPED],
+            primary: ACCOUNT_CRED_DEK_WRAPPED,
+            identify: (dir) => wrappedDekIdentity(node_path_1.default.join(dir, ACCOUNT_CRED_DEK_WRAPPED), kek, aad),
+            onEvent: (name, success, meta) => emit(`cred_envelope.${name}`, success, meta),
+        }));
+    }
+    catch (err) {
+        emit('cred_envelope.path_consolidation.failed', false, {
+            profile,
+            message: err?.message ?? 'unknown',
+        });
+        return;
+    }
+    if (outcome.status !== 'conflict') {
+        _pathConflict = null;
+        return;
+    }
+    _pathConflict = {
+        canonicalPath: node_path_1.default.join(outcome.canonicalDir, ACCOUNT_CRED_DEK_WRAPPED),
+        legacyPath: node_path_1.default.join(outcome.legacyDir ?? '', ACCOUNT_CRED_DEK_WRAPPED),
+    };
+    // The paths go in the MESSAGE, not only the metadata: a log pipeline that
+    // drops structured fields would otherwise render this as an unactionable
+    // noun. Naming the remedy matters too — logging out on one side deletes that
+    // side's key and lets the next start adopt the other.
+    (0, runtime_js_1.getAuthLogger)().warn(`[credEnvelope] profile "${profile}" has two different usable wrapped DEKs; ` +
+        `refusing to choose. Keeping ${_pathConflict.legacyPath} and leaving ` +
+        `${_pathConflict.canonicalPath} untouched. Each side can still read its own ` +
+        "credentials, and neither can read the other's. To converge, log out on one " +
+        `side (\`${(0, runtime_js_1.getAuthBinaryName)()} logout\` here) and log back in; the surviving key ` +
+        'is then adopted by both.');
+}
 /**
  * Initialize the envelope path. Idempotent — second call when state is
  * non-uninit returns immediately.
@@ -247,6 +360,11 @@ async function initCredEnvelope(profile) {
         return;
     }
     const aad = (0, credentialEnvelope_js_1.buildCredentialAad)(profile);
+    // OSK-10314 — converge this profile's two possible locations BEFORE any path
+    // is resolved, so the rest of init sees one answer. A no-op costing one string
+    // comparison on a machine that only ever had one location (every CLI process,
+    // and every daemon installed after this change).
+    await consolidateWrappedDek(profile, kek, aad);
     const targetPath = wrappedDekFilePath(profile);
     // Capture the kek's tier-aware kind once at init so transform-side events
     // can include it without holding a live `kek` reference. macOS sets `kind`
@@ -395,18 +513,29 @@ async function initCredEnvelope(profile) {
  * Reset state. With `clearOnDisk` deletes the wrapped DEK file too —
  * used by `oversky logout` / `sky logout`. Zeroes the in-memory DEK
  * before dropping state for forward secrecy on the active credential.
+ *
+ * It deletes EVERY location this profile's key can occupy, plus the
+ * consolidation marker. `profileStateDir.ts` never deletes anything and says so;
+ * this is the one caller that must, and the reason is not symmetry — a logout
+ * that removed only the canonical copy would leave the pre-consolidation copy
+ * behind, and the next init would adopt it straight back. That is a deleted
+ * credential key resurrecting itself, which is a worse bug than the one this
+ * whole change is fixing.
  */
 async function resetCredEnvelope(opts) {
     if (opts?.clearOnDisk && opts.profile) {
-        try {
-            node_fs_1.default.unlinkSync(wrappedDekFilePath(opts.profile));
-        }
-        catch (err) {
-            if (err.code !== 'ENOENT') {
-                emit('cred_envelope.clear_failed', false, {
-                    profile: opts.profile,
-                    message: err?.message ?? 'unknown',
-                });
+        for (const target of (0, profileStateDir_js_1.profileStateFilePathsToClear)(opts.profile, ACCOUNT_CRED_DEK_WRAPPED)) {
+            try {
+                node_fs_1.default.unlinkSync(target);
+            }
+            catch (err) {
+                if (err.code !== 'ENOENT') {
+                    emit('cred_envelope.clear_failed', false, {
+                        profile: opts.profile,
+                        path: target,
+                        message: err?.message ?? 'unknown',
+                    });
+                }
             }
         }
     }
@@ -415,6 +544,7 @@ async function resetCredEnvelope(opts) {
     }
     _state = { kind: 'uninit' };
     _kekRotationDetected = false;
+    _pathConflict = null;
 }
 /**
  * Idempotent shutdown — must be called from the daemon's graceful-exit
@@ -452,6 +582,7 @@ function shutdownCredEnvelope() {
     }
     _state = { kind: 'uninit' };
     _kekRotationDetected = false;
+    _pathConflict = null;
 }
 /** @internal Test seam — re-arm `shutdownCredEnvelope` so it can run again. */
 function __resetShutdownGuardForTest() {
@@ -464,6 +595,19 @@ function __resetShutdownGuardForTest() {
 function isCredEnvelopeActive() {
     return _state.kind === 'active';
 }
+/**
+ * True while this profile holds two usable and different wrapped DEKs.
+ *
+ * Read by `deviceIdentityBridge` before it migrates anything of its own. The
+ * device private key is sealed with whichever DEK is active, so moving it to the
+ * canonical directory while the two binaries are still on DIFFERENT DEKs hands
+ * the other one a key it cannot open — it regenerates, overwrites, and the two
+ * processes then destroy each other's device identity on every start. Unresolved
+ * conflicts freeze the whole profile's layout, not just the DEK's.
+ */
+function hasCredEnvelopePathConflict() {
+    return _pathConflict !== null;
+}
 /**
  * Operator-readable summary of envelope state. Used by `oversky status`
  * and CLI debug commands. Never includes the DEK or any key material.
@@ -479,6 +623,7 @@ function describeCredEnvelopeState() {
             kind: 'disabled',
             reason: _state.reason,
             ...(_kekRotationDetected ? { kekRotated: true } : {}),
+            ...(_pathConflict ? { pathConflict: _pathConflict } : {}),
         };
     }
     if (_state.kind === 'active') {
@@ -488,9 +633,10 @@ function describeCredEnvelopeState() {
             kekKind: _state.kekKind,
             profile: _state.profile,
             ...(_kekRotationDetected ? { kekRotated: true } : {}),
+            ...(_pathConflict ? { pathConflict: _pathConflict } : {}),
         };
     }
-    return { kind: 'uninit' };
+    return { kind: 'uninit', ...(_pathConflict ? { pathConflict: _pathConflict } : {}) };
 }
 /**
  * Sync write transform. Returns the wrapped serialized form when active.

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/deviceIdentityBridge.js

@@ -25,15 +25,25 @@ exports.enrollWithServer = enrollWithServer;
  * implementation. Daemon and CLI both consume this module so they land
  * on the SAME on-disk artifacts:
  *
- *   <configDir>/profiles/<p>/device-public-key.jwk    — plaintext JWK
- *   <configDir>/profiles/<p>/device-private-key       — L12-wrapped JSON
- *   <configDir>/profiles/<p>/device-enrollment.json   — server-ack marker
+ *   <machine root>/profiles/<p>/device-public-key.jwk    — plaintext JWK
+ *   <machine root>/profiles/<p>/device-private-key       — L12-wrapped JSON
+ *   <machine root>/profiles/<p>/device-enrollment.json   — server-ack marker
  *
  * Architectural decision (locked): CLI shares the daemon's keypair on
  * the same machine. Same machine = same device identity. The scope
  * discriminator is the JWT claim (`scope: 'cli'` vs `scope: 'daemon'`),
  * not the key.
  *
+ * That decision was locked and then quietly broken. This file spelled the
+ * directory `path.join(getAuthConfigDir(), 'profiles', profile)` — the same
+ * expression `credentialEnvelopeBridge` spelled independently — and the daemon's
+ * `configDir` is already profile-scoped, so the two consumers minted two
+ * keypairs per profile and neither noticed (OSK-10314). The directory now comes
+ * from `profileStateDir.ts`, and the four files below resolve as a GROUP: a
+ * public JWK from one copy beside a private key from the other is a keypair
+ * mismatch, which `loadKeypair` correctly rejects and would then paper over by
+ * regenerating.
+ *
  * NAMING NOTE — the suffix `Bridge` distinguishes this composed runtime
  * (init + sign + enroll + telemetry) from the pure-crypto primitive
  * file `deviceKey.ts` it composes.
@@ -42,11 +52,24 @@ const node_fs_1 = __importDefault(require("node:fs"));
 const node_path_1 = __importDefault(require("node:path"));
 const deviceKey_js_1 = require("./deviceKey.js");
 const credentialEnvelopeBridge_js_1 = require("./credentialEnvelopeBridge.js");
+const profileStateDir_js_1 = require("./profileStateDir.js");
 const runtime_js_1 = require("./runtime.js");
 const PUBLIC_KEY_FILENAME = 'device-public-key.jwk';
 const PRIVATE_KEY_FILENAME = 'device-private-key';
 const ENROLLMENT_MARKER_FILENAME = 'device-enrollment.json';
 const ENROLLMENT_BACKOFF_FILENAME = 'device-enrollment-backoff.json';
+/**
+ * The device identity's files, in the order they are copied by a migration.
+ * The public JWK goes first so a reader that catches the directory mid-copy sees
+ * a public key without a private one — which `loadKeypair` treats as "no
+ * keypair" — rather than a private key it will pair with a stale public one.
+ */
+const DEVICE_IDENTITY_FILES = [
+    PUBLIC_KEY_FILENAME,
+    PRIVATE_KEY_FILENAME,
+    ENROLLMENT_MARKER_FILENAME,
+    ENROLLMENT_BACKOFF_FILENAME,
+];
 // A missing Daemon row cannot become enrollable until registration changes
 // server state. Persist the negative result across short-lived `sky` processes
 // so every CLI command does not repeat the same guaranteed 404.
@@ -62,8 +85,13 @@ function __setStateForTest(next) {
 function __getStateForTest() {
     return _state;
 }
+/**
+ * The directory holding this profile's device identity, anchored on the PRIVATE
+ * key: that is the file `loadKeypair` cannot proceed without, so it is the one
+ * that decides which copy the group is read from.
+ */
 function profileConfigDir(profile) {
-    return node_path_1.default.join((0, runtime_js_1.getAuthConfigDir)(), 'profiles', profile);
+    return (0, profileStateDir_js_1.resolveProfileStateDir)(profile, PRIVATE_KEY_FILENAME).dir;
 }
 function publicKeyPath(profile) {
     return node_path_1.default.join(profileConfigDir(profile), PUBLIC_KEY_FILENAME);
@@ -214,6 +242,55 @@ function loadKeypair(profile) {
         thumbprint: recomputed,
     };
 }
+/**
+ * Identity of a device-identity directory: the thumbprint of the PLAINTEXT
+ * public JWK.
+ *
+ * The private key is envelope-wrapped with a random nonce, so its bytes say
+ * nothing about whether two copies are the same key. The public JWK is written
+ * in the clear and is derived from the private one, so it answers the question
+ * exactly and without needing the DEK.
+ */
+function deviceIdentityOf(dir) {
+    try {
+        const parsed = JSON.parse(node_fs_1.default.readFileSync(node_path_1.default.join(dir, PUBLIC_KEY_FILENAME), 'utf-8'));
+        if (!parsed.publicJwk || typeof parsed.publicJwk.x !== 'string')
+            return null;
+        return (0, deviceKey_js_1.jwkThumbprint)(parsed.publicJwk);
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * Run the OSK-10314 consolidation for this profile's device identity.
+ *
+ * Refuses outright while the credential envelope is holding two different DEKs:
+ * see `hasCredEnvelopePathConflict`. Never fatal — a failed migration leaves the
+ * process reading exactly what it read before.
+ */
+async function consolidateDeviceIdentity(profile) {
+    if (!(0, profileStateDir_js_1.resolveProfileStateDir)(profile, PRIVATE_KEY_FILENAME).usingLegacy)
+        return;
+    if ((0, credentialEnvelopeBridge_js_1.hasCredEnvelopePathConflict)()) {
+        emit('path_consolidation.deferred', true, { profile, reason: 'cred_envelope_path_conflict' }, { logLevel: 'info' });
+        return;
+    }
+    try {
+        await (0, profileStateDir_js_1.consolidateProfileState)(profile, {
+            files: DEVICE_IDENTITY_FILES,
+            primary: PRIVATE_KEY_FILENAME,
+            identify: deviceIdentityOf,
+            onEvent: (name, success, meta) => emit(name, success, meta),
+        });
+    }
+    catch (err) {
+        emit('path_consolidation.failed', false, {
+            profile,
+            message: err?.message ?? 'unknown',
+        });
+    }
+}
 /**
  * Initialize device identity. Idempotent.
  *
@@ -232,6 +309,11 @@ async function initDeviceIdentity(profile) {
         emit('init_failed', false, { reason: 'empty_profile' });
         return;
     }
+    // OSK-10314 — converge the two directories this profile may have before
+    // resolving any of the four files. Must run after `initCredEnvelope`, which
+    // both consumers already guarantee, because the private key's readability
+    // depends on which DEK ended up active.
+    await consolidateDeviceIdentity(profile);
     let keypair = null;
     try {
         keypair = loadKeypair(profile);
@@ -299,7 +381,11 @@ async function initDeviceIdentity(profile) {
  */
 async function resetDeviceIdentity(opts) {
     if (opts?.clearOnDisk && opts.profile) {
-        for (const p of [publicKeyPath(opts.profile), privateKeyPath(opts.profile)]) {
+        // Every location, not just the resolved one. A reset that cleared only the
+        // canonical copy would leave the pre-consolidation copy for the next init to
+        // adopt — a deleted device key that reappears.
+        const targets = [PUBLIC_KEY_FILENAME, PRIVATE_KEY_FILENAME].flatMap((name) => (0, profileStateDir_js_1.profileStateFilePathsToClear)(opts.profile, name));
+        for (const p of targets) {
             try {
                 node_fs_1.default.unlinkSync(p);
             }

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarness.d.ts

@@ -313,6 +313,13 @@ declare const ENGINE_ENV_SUFFIXES: Readonly<{
     allowUpstreamEgress: "ALLOW_UPSTREAM_EGRESS";
     compatOpencode: "COMPAT_OPENCODE";
     noCompatPrompts: "NO_COMPAT_PROMPTS";
+    /**
+     * Advisory input-token budget for a managed session, set by the daemon from
+     * the server-issued `requestEnvelope.maxInputTokens` so the engine's
+     * auto-compaction can trigger before the relay refuses the request. The
+     * engine must treat it as a hint: enforcement stays server-side.
+     */
+    maxInputTokens: "MAX_INPUT_TOKENS";
 }>;
 export type FirstPartyHarnessEngineEnvKey = keyof typeof ENGINE_ENV_SUFFIXES;
 /**
@@ -350,7 +357,7 @@ export declare const FIRST_PARTY_HARNESS_ENGINE: Readonly<{
      * `readFirstPartyHarnessEngineEnv` to read one the way the engine does and
      * `firstPartyHarnessEngineEnvEntries` to set one every engine build honours.
      */
-    env: Readonly<Record<"appName" | "serverPassword" | "serverUsername" | "home" | "config" | "scriptName" | "allowUpstreamEgress" | "compatOpencode" | "noCompatPrompts", string>>;
+    env: Readonly<Record<"appName" | "serverPassword" | "serverUsername" | "home" | "config" | "scriptName" | "allowUpstreamEgress" | "compatOpencode" | "noCompatPrompts" | "maxInputTokens", string>>;
 }>;
 /**
  * Every name the engine reads for one purpose, current namespace first — the

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarness.js

@@ -450,6 +450,13 @@ const ENGINE_ENV_SUFFIXES = Object.freeze({
     allowUpstreamEgress: 'ALLOW_UPSTREAM_EGRESS',
     compatOpencode: 'COMPAT_OPENCODE',
     noCompatPrompts: 'NO_COMPAT_PROMPTS',
+    /**
+     * Advisory input-token budget for a managed session, set by the daemon from
+     * the server-issued `requestEnvelope.maxInputTokens` so the engine's
+     * auto-compaction can trigger before the relay refuses the request. The
+     * engine must treat it as a hint: enforcement stays server-side.
+     */
+    maxInputTokens: 'MAX_INPUT_TOKENS',
 });
 function engineEnvName(appName, key) {
     return `${appName.toUpperCase().replace(/-/g, '_')}_${ENGINE_ENV_SUFFIXES[key]}`;

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/firstPartyHarnessHome.js

@@ -64,6 +64,13 @@ const firstPartyHarness_js_1 = require("./firstPartyHarness.js");
 function olderSpellings() {
     return (0, firstPartyHarness_js_1.firstPartyHarnessArtifactSpellings)().filter((spelling) => spelling !== firstPartyHarness_js_1.FIRST_PARTY_HARNESS.provider);
 }
+/**
+ * Entries rescued from a legacy home when the canonical one already exists as a
+ * shell. `bin` is what managed resolution needs; `skills` is the user's own
+ * data. Deliberately a short, named list rather than "everything": a merge this
+ * module cannot enumerate (there is no readdir here) would be guessing.
+ */
+const STRANDED_HOME_ENTRIES = ['bin', 'skills'];
 /** Suffix of the rollback copy the installer keeps beside the binary. */
 exports.FIRST_PARTY_HARNESS_PREVIOUS_SUFFIX = '.previous';
 /**
@@ -186,6 +193,44 @@ function migrateFirstPartyHarnessHome(options = {}) {
             break;
         }
     }
+    else if (isRealDirectory(fs.lstat(canonicalHome))) {
+        // 1b. The canonical home EXISTS, so the rename above is impossible — but it
+        // may be a shell rather than the real home. A managed write that reaches
+        // `<root>/<appName>` before this migration runs creates the directory, and
+        // from then on step 1 skips forever and the legacy home keeps the binary.
+        // Observed on a real machine: `<root>/<appName>` holding a 2-byte `{}`
+        // config written hours after `<root>/<legacy appName>/bin` received the
+        // signed 107MB engine, which left managed resolution pointing at a bin
+        // directory that did not exist and every managed session with no engine to
+        // spawn.
+        //
+        // A rename cannot merge two directories, and this module has no readdir, so
+        // this moves the two entries that carry weight and nothing else: `bin`,
+        // which is what resolution needs, and `skills`, which is user data. An
+        // entry already present at the canonical home is never touched — the shell
+        // may be empty, but it is not automatically wrong.
+        for (const legacyAppName of firstPartyHarness_js_1.FIRST_PARTY_HARNESS_ENGINE.legacyAppNames) {
+            const aliasHome = node_path_1.default.join(root, legacyAppName);
+            if (!isRealDirectory(fs.lstat(aliasHome)))
+                continue;
+            for (const entry of STRANDED_HOME_ENTRIES) {
+                const from = node_path_1.default.join(aliasHome, entry);
+                const to = node_path_1.default.join(canonicalHome, entry);
+                if (!isRealDirectory(fs.lstat(from)))
+                    continue;
+                if (fs.lstat(to) !== null)
+                    continue;
+                try {
+                    fs.rename(from, to);
+                    moved.push(`${from} -> ${to}`);
+                }
+                catch (err) {
+                    errors.push(`could not move ${from} to ${to}: ${describe(err)}`);
+                }
+            }
+            break;
+        }
+    }
     // 2. The binary and its companions — follow the provider — inside the home.
     const binDir = node_path_1.default.join(canonicalHome, 'bin');
     if (!isRealDirectory(fs.lstat(binDir))) {

package/dist/node_modules/@skrr-ai/auth-core/dist/cjs/harnessSkillLayout.d.ts

@@ -0,0 +1,65 @@
+/**
+ * OSK-10409 — which harnesses resolve the `.claude/skills/<name>/SKILL.md`
+ * layout, shared by the server and the daemon.
+ *
+ * ── Why this lives in auth-core ────────────────────────────────────────────
+ *
+ * The same reason `harnessTrust.ts` does: it is a DECLARED per-harness fact
+ * that several processes have to agree on, and the cost of them disagreeing is
+ * silent. It is not auth, and it does not pretend to be — auth-core is where
+ * this repo already keeps the small tables that a harness's identity answers.
+ *
+ * ── What the fact IS ───────────────────────────────────────────────────────
+ *
+ * The daemon materializes a session's skills at
+ * `<root>/.claude/skills/<name>/SKILL.md` and hands `<root>` to the harness —
+ * `--add-dir` for the Claude CLI, ACP `additionalDirectories` for Devin. A
+ * harness on this list READS that layout: it enumerates the tree, surfaces the
+ * manifest line, and resolves the body from disk. A harness that is not on it
+ * ignores the tree entirely, so nothing laid there ever reaches its model.
+ *
+ * It is a capability with EVIDENCE, never a brand check. The gate this replaced
+ * read `provider !== 'claude'` on the stated premise that every other harness
+ * ignores the layout, and the premise was false for Devin (OSK-10264): the
+ * daemon lays the same tree, passes it on `additionalDirectories`, and Devin
+ * loads it — measured live on 3000.10.31. Add a harness here only with the same
+ * kind of evidence, that its sessions actually surface a skill laid out this
+ * way. A harness that ignores the layout gains nothing and pays for the wire.
+ *
+ * ── Three readers, in three directions ─────────────────────────────────────
+ *
+ *  1. The server's PUSH gate (`buildDaemonServerSkills`): a harness on this
+ *     list is one a pushed skill should be sent to.
+ *  2. The server's INVOKED-BODY gate (`buildInvokedSkillsPrompt`, OSK-10361):
+ *     a harness on this list must NOT also have the body pasted into its
+ *     prompt — it already has it from the tree, and on ACP the paste lands in
+ *     the transcript at full skill size on every invoked turn.
+ *  3. The daemon's SHADOWING protection (`skill-shadowing.ts`, OSK-10044): a
+ *     harness on this list resolves `/<name>` from its own `.claude/skills`
+ *     roots, so a picked skill can be shadowed there by a same-named one — and
+ *     the daemon is the only place that collision can be seen. That gate spelled
+ *     `claude` and so never reached Devin, which the server-side paste was
+ *     accidentally masking until (2) stopped pasting.
+ *
+ * Reader 3 is why the table moved out of the API: the daemon cannot require an
+ * api-side module, and a second copy of a table whose whole value is that every
+ * reader agrees is worse than no table at all.
+ */
+/**
+ * Harness provider → the evidence that its sessions load the layout.
+ *
+ * The reason string is part of the entry, not decoration: an entry added
+ * without one is an entry nobody can audit later.
+ */
+export declare const HARNESSES_LOADING_CLAUDE_SKILLS_LAYOUT: ReadonlyMap<string, string>;
+/**
+ * Whether this harness resolves a skill from the `.claude/skills` tree the
+ * daemon materializes, so the body reaches it without being pasted anywhere.
+ *
+ * An absent provider is NOT a native resolver. "We do not know what this is"
+ * must never mean "it reads the layout" — that direction withholds the body
+ * from a harness that needed it, which is a turn that looks like the skill ran.
+ */
+export declare function harnessLoadsClaudeSkillsLayout(provider: string | null | undefined): boolean;
+/** The stated evidence for a harness on the list, or `null` when it is not. */
+export declare function claudeSkillsLayoutEvidence(provider: string | null | undefined): string | null;