@skrr-ai/cli 0.1.32 → 0.1.34

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

@@ -0,0 +1,147 @@
+/**
+ * First-party harness update channels and feed resolution — the vocabulary, in
+ * the ONE place both readers resolve.
+ *
+ * It lived in `daemon/src/sky-code/channels.ts`, whose only importer was the
+ * daemon's own installer. That was fine while the daemon was the only thing that
+ * needed it, and it stopped being fine the moment a user could be told to go
+ * looking: `skrr code`'s not-installed message promised that `skrr code doctor`
+ * would name "which channel this machine follows and whether that channel has a
+ * published release", and the CLI had no access to any of it — so the sentence
+ * described a diagnosis nobody had written (dogfood OSK-274).
+ *
+ * A MIRROR in the CLI was the obvious alternative and is the wrong answer here,
+ * with precedent: OSK-3894 shipped exactly that for the harness trust tiers and
+ * OSK-3897 removed it, because a mirror proves two copies agree rather than
+ * proving there is one copy. `harnessTrust.ts` moved into this package for that
+ * reason, the daemon re-exports it, and a static check keeps the daemon from
+ * quietly redeclaring. This follows that road rather than reopening the one it
+ * replaced.
+ *
+ * Only the VOCABULARY lives here — channel names, the env var, the default, the
+ * URL shape and the feed candidates. The installer, the signature verification
+ * and the promotion machinery stay in the daemon, which is the only process that
+ * performs them.
+ *
+ * Every product-named value comes from `firstPartyHarness.ts`; nothing in this
+ * file spells the product.
+ */
+/** Channels in promotion order. Index order IS the promotion order. */
+export declare const FIRST_PARTY_HARNESS_CHANNELS: readonly ["internal", "canary", "beta", "stable"];
+export type FirstPartyHarnessChannel = (typeof FIRST_PARTY_HARNESS_CHANNELS)[number];
+/**
+ * The channel a build without an explicit setting follows.
+ *
+ * `stable`, and never inferred from anything else. A default that drifted with
+ * the build (say, dev builds silently on `canary`) would mean a user's update
+ * path depended on how their binary happened to be produced.
+ */
+export declare const DEFAULT_FIRST_PARTY_HARNESS_CHANNEL: FirstPartyHarnessChannel;
+export declare function isFirstPartyHarnessChannel(value: unknown): value is FirstPartyHarnessChannel;
+/**
+ * The channel this process should follow.
+ *
+ * An unrecognised value falls back to the default rather than throwing. A
+ * typo'd channel must not brick updates altogether — that turns a harmless
+ * mistake into an un-updatable machine, which is the failure the updater exists
+ * to prevent. The caller is handed `invalid` so it can say so out loud, and
+ * `source` so it can name the variable it read.
+ */
+export declare function resolveFirstPartyHarnessChannel(env?: NodeJS.ProcessEnv): {
+    channel: FirstPartyHarnessChannel;
+    invalid?: string;
+    source?: string;
+};
+/**
+ * Where a channel's signed manifest lives, relative to a feed base.
+ *
+ * `stable` is NOT special-cased to `latest/`. Two paths that must always agree
+ * is a pair that eventually will not, and the one that disagrees silently is
+ * the one serving production. `latest/` remains for the daemon feed and for
+ * anything already pointing at it; first-party harness channel clients read
+ * `channels/<name>/` uniformly.
+ */
+export declare function firstPartyHarnessChannelPrefix(channel: FirstPartyHarnessChannel): string;
+/**
+ * Manifest URL for a channel, or for a pinned version.
+ *
+ * A pinned version wins over the channel and reads its immutable per-release
+ * copy: pinning means "this exact build", and a channel pointer that moved
+ * underneath would make the pin a suggestion.
+ *
+ * Builds only MANIFEST urls, never artifact ones. `buildManifestMessage` signs
+ * version, minimum, forceUpdate and the per-platform sha256s; `buildArtifactMessage`
+ * signs the artifact URL. Neither signs a channel — so artifact URLs stay
+ * channel-independent and promotion is a COPY OF AN ALREADY-SIGNED OBJECT that
+ * never needs the release key. Put the channel in the artifact URL instead and
+ * every promotion becomes a re-signing ceremony, which decides whether the
+ * ed25519 key has to be reachable from routine automation. A helper here that
+ * adjusted artifact urls would silently reintroduce exactly that coupling.
+ *
+ * The same property is what lets one signed manifest be served under every
+ * spelling's prefix: the manifest's own path is not inside the signature.
+ */
+export declare function resolveChannelManifestUrl(input: {
+    base: string;
+    manifestFilename: string;
+    channel: FirstPartyHarnessChannel;
+    pinnedVersion?: string | null;
+}): string;
+/**
+ * The feed base this process uses for the CANONICAL spelling.
+ *
+ * Explicit-only override: a production user must never be silently enrolled
+ * onto a different feed. Selecting a feed changes WHICH signed manifest is read,
+ * never WHETHER the signature is checked — every artifact is verified against
+ * the pinned keys regardless of where it came from.
+ */
+export declare function firstPartyHarnessFeedBase(env?: NodeJS.ProcessEnv): string;
+export interface FirstPartyHarnessFeedCandidate {
+    /** Feed base URL, no trailing slash. */
+    readonly base: string;
+    /** Manifest file name under that base. */
+    readonly manifestFilename: string;
+    /** The spelling this candidate was published under. */
+    readonly provider: string;
+}
+/**
+ * Every place a manifest may be published, in the order an installer should
+ * try them: the canonical spelling first, then each alias.
+ *
+ * Why a list: publishing writes every spelling, but an installer can ship before
+ * the first release that does, and a machine can point at a feed published by
+ * an older pipeline. An installer that asked only for the canonical path would
+ * then find NOTHING and report "no release" on a feed that has one. Trying the
+ * aliases on not-found closes that window in both directions without anyone
+ * having to deploy in a particular order.
+ *
+ * An operator override keeps its base and still tries each manifest filename,
+ * since a dev feed staged by an older script names the file the old way.
+ */
+export declare function firstPartyHarnessFeedCandidates(env?: NodeJS.ProcessEnv): readonly FirstPartyHarnessFeedCandidate[];
+/** @deprecated Use `FIRST_PARTY_HARNESS_CHANNELS`. */
+export declare const SKY_CODE_CHANNELS: readonly ["internal", "canary", "beta", "stable"];
+/** @deprecated Use `FirstPartyHarnessChannel`. */
+export type SkyCodeChannel = FirstPartyHarnessChannel;
+/** @deprecated Use `DEFAULT_FIRST_PARTY_HARNESS_CHANNEL`. */
+export declare const DEFAULT_SKY_CODE_CHANNEL: "stable";
+/** @deprecated Read the channel with `resolveFirstPartyHarnessChannel`; the variable has a neutral name now. */
+export declare const SKY_CODE_CHANNEL_ENV: string;
+/** @deprecated Use `firstPartyHarnessManifestFile()`. Names the legacy file. */
+export declare const SKY_CODE_MANIFEST_FILE: string;
+/** @deprecated Use `isFirstPartyHarnessChannel`. */
+export declare const isSkyCodeChannel: typeof isFirstPartyHarnessChannel;
+/** @deprecated Use `resolveFirstPartyHarnessChannel`. */
+export declare const resolveSkyCodeChannel: typeof resolveFirstPartyHarnessChannel;
+/** @deprecated Use `firstPartyHarnessChannelPrefix`. */
+export declare const skyCodeChannelPrefix: typeof firstPartyHarnessChannelPrefix;
+/** @deprecated Use `firstPartyHarnessDefaultFeedBase()`. Names the legacy feed. */
+export declare const DEFAULT_SKY_CODE_FEED_BASE: string;
+/** @deprecated Read the feed with `firstPartyHarnessFeedBase`; the variable has a neutral name now. */
+export declare const SKY_CODE_FEED_BASE_ENV: string;
+/**
+ * @deprecated Use `firstPartyHarnessFeedCandidates`. Keeps the LEGACY feed as its
+ * default, because that is the only feed a caller compiled against this name knows
+ * how to read.
+ */
+export declare function skyCodeFeedBase(env?: NodeJS.ProcessEnv): string;

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

@@ -0,0 +1,180 @@
+"use strict";
+/**
+ * First-party harness update channels and feed resolution — the vocabulary, in
+ * the ONE place both readers resolve.
+ *
+ * It lived in `daemon/src/sky-code/channels.ts`, whose only importer was the
+ * daemon's own installer. That was fine while the daemon was the only thing that
+ * needed it, and it stopped being fine the moment a user could be told to go
+ * looking: `skrr code`'s not-installed message promised that `skrr code doctor`
+ * would name "which channel this machine follows and whether that channel has a
+ * published release", and the CLI had no access to any of it — so the sentence
+ * described a diagnosis nobody had written (dogfood OSK-274).
+ *
+ * A MIRROR in the CLI was the obvious alternative and is the wrong answer here,
+ * with precedent: OSK-3894 shipped exactly that for the harness trust tiers and
+ * OSK-3897 removed it, because a mirror proves two copies agree rather than
+ * proving there is one copy. `harnessTrust.ts` moved into this package for that
+ * reason, the daemon re-exports it, and a static check keeps the daemon from
+ * quietly redeclaring. This follows that road rather than reopening the one it
+ * replaced.
+ *
+ * Only the VOCABULARY lives here — channel names, the env var, the default, the
+ * URL shape and the feed candidates. The installer, the signature verification
+ * and the promotion machinery stay in the daemon, which is the only process that
+ * performs them.
+ *
+ * Every product-named value comes from `firstPartyHarness.ts`; nothing in this
+ * file spells the product.
+ */
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.SKY_CODE_FEED_BASE_ENV = exports.DEFAULT_SKY_CODE_FEED_BASE = exports.skyCodeChannelPrefix = exports.resolveSkyCodeChannel = exports.isSkyCodeChannel = exports.SKY_CODE_MANIFEST_FILE = exports.SKY_CODE_CHANNEL_ENV = exports.DEFAULT_SKY_CODE_CHANNEL = exports.SKY_CODE_CHANNELS = exports.DEFAULT_FIRST_PARTY_HARNESS_CHANNEL = exports.FIRST_PARTY_HARNESS_CHANNELS = void 0;
+exports.isFirstPartyHarnessChannel = isFirstPartyHarnessChannel;
+exports.resolveFirstPartyHarnessChannel = resolveFirstPartyHarnessChannel;
+exports.firstPartyHarnessChannelPrefix = firstPartyHarnessChannelPrefix;
+exports.resolveChannelManifestUrl = resolveChannelManifestUrl;
+exports.firstPartyHarnessFeedBase = firstPartyHarnessFeedBase;
+exports.firstPartyHarnessFeedCandidates = firstPartyHarnessFeedCandidates;
+exports.skyCodeFeedBase = skyCodeFeedBase;
+const firstPartyHarness_js_1 = require("./firstPartyHarness.js");
+/** Channels in promotion order. Index order IS the promotion order. */
+exports.FIRST_PARTY_HARNESS_CHANNELS = ['internal', 'canary', 'beta', 'stable'];
+/**
+ * The channel a build without an explicit setting follows.
+ *
+ * `stable`, and never inferred from anything else. A default that drifted with
+ * the build (say, dev builds silently on `canary`) would mean a user's update
+ * path depended on how their binary happened to be produced.
+ */
+exports.DEFAULT_FIRST_PARTY_HARNESS_CHANNEL = 'stable';
+function isFirstPartyHarnessChannel(value) {
+    return (typeof value === 'string' && exports.FIRST_PARTY_HARNESS_CHANNELS.includes(value));
+}
+/**
+ * The channel this process should follow.
+ *
+ * An unrecognised value falls back to the default rather than throwing. A
+ * typo'd channel must not brick updates altogether — that turns a harmless
+ * mistake into an un-updatable machine, which is the failure the updater exists
+ * to prevent. The caller is handed `invalid` so it can say so out loud, and
+ * `source` so it can name the variable it read.
+ */
+function resolveFirstPartyHarnessChannel(env = process.env) {
+    const reading = (0, firstPartyHarness_js_1.readFirstPartyHarnessEnv)(env, 'channel');
+    if (!reading.value)
+        return { channel: exports.DEFAULT_FIRST_PARTY_HARNESS_CHANNEL };
+    if (isFirstPartyHarnessChannel(reading.value)) {
+        return { channel: reading.value, source: reading.name };
+    }
+    return {
+        channel: exports.DEFAULT_FIRST_PARTY_HARNESS_CHANNEL,
+        invalid: reading.value,
+        source: reading.name,
+    };
+}
+/**
+ * Where a channel's signed manifest lives, relative to a feed base.
+ *
+ * `stable` is NOT special-cased to `latest/`. Two paths that must always agree
+ * is a pair that eventually will not, and the one that disagrees silently is
+ * the one serving production. `latest/` remains for the daemon feed and for
+ * anything already pointing at it; first-party harness channel clients read
+ * `channels/<name>/` uniformly.
+ */
+function firstPartyHarnessChannelPrefix(channel) {
+    return `channels/${channel}/`;
+}
+/**
+ * Manifest URL for a channel, or for a pinned version.
+ *
+ * A pinned version wins over the channel and reads its immutable per-release
+ * copy: pinning means "this exact build", and a channel pointer that moved
+ * underneath would make the pin a suggestion.
+ *
+ * Builds only MANIFEST urls, never artifact ones. `buildManifestMessage` signs
+ * version, minimum, forceUpdate and the per-platform sha256s; `buildArtifactMessage`
+ * signs the artifact URL. Neither signs a channel — so artifact URLs stay
+ * channel-independent and promotion is a COPY OF AN ALREADY-SIGNED OBJECT that
+ * never needs the release key. Put the channel in the artifact URL instead and
+ * every promotion becomes a re-signing ceremony, which decides whether the
+ * ed25519 key has to be reachable from routine automation. A helper here that
+ * adjusted artifact urls would silently reintroduce exactly that coupling.
+ *
+ * The same property is what lets one signed manifest be served under every
+ * spelling's prefix: the manifest's own path is not inside the signature.
+ */
+function resolveChannelManifestUrl(input) {
+    const base = input.base.replace(/\/+$/, '');
+    if (input.pinnedVersion) {
+        return `${base}/releases/${input.pinnedVersion}/${input.manifestFilename}`;
+    }
+    return `${base}/${firstPartyHarnessChannelPrefix(input.channel)}${input.manifestFilename}`;
+}
+/**
+ * The feed base this process uses for the CANONICAL spelling.
+ *
+ * Explicit-only override: a production user must never be silently enrolled
+ * onto a different feed. Selecting a feed changes WHICH signed manifest is read,
+ * never WHETHER the signature is checked — every artifact is verified against
+ * the pinned keys regardless of where it came from.
+ */
+function firstPartyHarnessFeedBase(env = process.env) {
+    const override = (0, firstPartyHarness_js_1.readFirstPartyHarnessEnv)(env, 'updateFeedBase').value;
+    return (override || (0, firstPartyHarness_js_1.firstPartyHarnessDefaultFeedBase)()).replace(/\/+$/, '');
+}
+/**
+ * Every place a manifest may be published, in the order an installer should
+ * try them: the canonical spelling first, then each alias.
+ *
+ * Why a list: publishing writes every spelling, but an installer can ship before
+ * the first release that does, and a machine can point at a feed published by
+ * an older pipeline. An installer that asked only for the canonical path would
+ * then find NOTHING and report "no release" on a feed that has one. Trying the
+ * aliases on not-found closes that window in both directions without anyone
+ * having to deploy in a particular order.
+ *
+ * An operator override keeps its base and still tries each manifest filename,
+ * since a dev feed staged by an older script names the file the old way.
+ */
+function firstPartyHarnessFeedCandidates(env = process.env) {
+    const override = (0, firstPartyHarness_js_1.readFirstPartyHarnessEnv)(env, 'updateFeedBase').value?.replace(/\/+$/, '');
+    return (0, firstPartyHarness_js_1.firstPartyHarnessSpellings)().map((provider) => ({
+        base: override || (0, firstPartyHarness_js_1.firstPartyHarnessDefaultFeedBase)(provider),
+        manifestFilename: (0, firstPartyHarness_js_1.firstPartyHarnessManifestFile)(provider),
+        provider,
+    }));
+}
+/* ── Deprecated names ───────────────────────────────────────────────────────
+ *
+ * `@skrr-ai/auth-core` is PUBLISHED, and the released CLI resolves it with a
+ * caret range. An installed CLI that picks up this version must still find the
+ * names it was compiled against, or it crashes at import. These aliases leave in
+ * the contract phase (OSK-8663), with a minor-version bump — never a patch.
+ */
+/** @deprecated Use `FIRST_PARTY_HARNESS_CHANNELS`. */
+exports.SKY_CODE_CHANNELS = exports.FIRST_PARTY_HARNESS_CHANNELS;
+/** @deprecated Use `DEFAULT_FIRST_PARTY_HARNESS_CHANNEL`. */
+exports.DEFAULT_SKY_CODE_CHANNEL = exports.DEFAULT_FIRST_PARTY_HARNESS_CHANNEL;
+/** @deprecated Read the channel with `resolveFirstPartyHarnessChannel`; the variable has a neutral name now. */
+exports.SKY_CODE_CHANNEL_ENV = firstPartyHarness_js_1.FIRST_PARTY_HARNESS_ENV.channel.legacy[0];
+/** @deprecated Use `firstPartyHarnessManifestFile()`. Names the legacy file. */
+exports.SKY_CODE_MANIFEST_FILE = (0, firstPartyHarness_js_1.firstPartyHarnessManifestFile)(firstPartyHarness_js_1.FIRST_PARTY_HARNESS.wireProvider);
+/** @deprecated Use `isFirstPartyHarnessChannel`. */
+exports.isSkyCodeChannel = isFirstPartyHarnessChannel;
+/** @deprecated Use `resolveFirstPartyHarnessChannel`. */
+exports.resolveSkyCodeChannel = resolveFirstPartyHarnessChannel;
+/** @deprecated Use `firstPartyHarnessChannelPrefix`. */
+exports.skyCodeChannelPrefix = firstPartyHarnessChannelPrefix;
+/** @deprecated Use `firstPartyHarnessDefaultFeedBase()`. Names the legacy feed. */
+exports.DEFAULT_SKY_CODE_FEED_BASE = (0, firstPartyHarness_js_1.firstPartyHarnessDefaultFeedBase)(firstPartyHarness_js_1.FIRST_PARTY_HARNESS.wireProvider);
+/** @deprecated Read the feed with `firstPartyHarnessFeedBase`; the variable has a neutral name now. */
+exports.SKY_CODE_FEED_BASE_ENV = firstPartyHarness_js_1.FIRST_PARTY_HARNESS_ENV.updateFeedBase.legacy[0];
+/**
+ * @deprecated Use `firstPartyHarnessFeedCandidates`. Keeps the LEGACY feed as its
+ * default, because that is the only feed a caller compiled against this name knows
+ * how to read.
+ */
+function skyCodeFeedBase(env = process.env) {
+    const override = (0, firstPartyHarness_js_1.readFirstPartyHarnessEnv)(env, 'updateFeedBase').value;
+    return (override || (0, firstPartyHarness_js_1.firstPartyHarnessDefaultFeedBase)(firstPartyHarness_js_1.FIRST_PARTY_HARNESS.wireProvider)).replace(/\/+$/, '');
+}

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

@@ -0,0 +1,111 @@
+/**
+ * Where the first-party harness lives on disk, and the one-time move that keeps
+ * that true across a rename.
+ *
+ * ── Why one implementation ────────────────────────────────────────────────
+ *
+ * Three processes put an engine under the skrr root and read it back: the daemon
+ * installer, the CLI (`skrr code`), and the desktop app's bundled-engine
+ * install. Each used to build `<root>/sky-code/bin/sky-code` itself, and they
+ * already disagreed once about which root that was (see `configRoot.ts`). A
+ * rename that every one of them had to perform independently would disagree
+ * again, so the paths AND the move live here.
+ *
+ * ── The move ──────────────────────────────────────────────────────────────
+ *
+ * Idempotent, lossless, and safe to run concurrently from all three:
+ *
+ *   1. The HOME follows the engine's namespace. If `<root>/<appName>` does not
+ *      exist and `<root>/<legacyAppName>` is a real directory, rename it and
+ *      leave the legacy name as a relative symlink. (No legacy app name exists
+ *      yet; this step is what an engine-namespace rename will use.)
+ *   2. The BINARY follows the provider. Inside `<home>/bin`, if the canonical
+ *      binary does not exist and an alias binary is a real file, rename it and
+ *      each companion (rollback copy, provenance sidecar), leaving a relative
+ *      symlink at every old name.
+ *
+ * The two follow different names on purpose: the home is shared with the
+ * engine, which reads its config and managed `AGENTS.md` from it, so it can only
+ * move when the engine's namespace does (`firstPartyHarnessHomeDirname`). The
+ * symlinks are the compatibility story, not an afterthought: every CLI and
+ * daemon already installed reads the legacy binary path, and a symlink keeps
+ * them working with no coordination.
+ *
+ * It never overwrites, never deletes, and never renames THROUGH a symlink, so
+ * running it twice, or after a downgrade, changes nothing. Any error leaves the
+ * tree exactly as it was and is reported rather than thrown: a failed move must
+ * degrade to reading the old path, not to an engine that cannot start.
+ *
+ * Skipped on Windows, where creating a symlink needs a privilege a normal user
+ * does not hold, and where no engine artifact is published anyway.
+ */
+import { type Stats } from 'node:fs';
+/** Suffix of the rollback copy the installer keeps beside the binary. */
+export declare const FIRST_PARTY_HARNESS_PREVIOUS_SUFFIX = ".previous";
+/**
+ * Suffix of the provenance record beside the binary. The `oversky` in it is a
+ * persisted file name that already exists on machines, not the product name.
+ */
+export declare const FIRST_PARTY_HARNESS_PROVENANCE_SUFFIX = ".oversky-provenance.json";
+/** `<root>/<engine appName>` — the engine home, shared by the platform and the engine. */
+export declare function firstPartyHarnessHomeDir(env?: NodeJS.ProcessEnv): string;
+/** `<home>/bin`, where the platform installs the engine binary. */
+export declare function firstPartyHarnessBinDir(env?: NodeJS.ProcessEnv): string;
+/** The installed binary path for a spelling (canonical by default) — lookup order is canonical first. */
+export declare function firstPartyHarnessInstalledBinaryPath(env?: NodeJS.ProcessEnv, provider?: string, platform?: string): string;
+export interface FirstPartyHarnessHomeMigration {
+    /** Human-readable record of each change made, in order. Empty when nothing moved. */
+    readonly moved: readonly string[];
+    /** Why a step was not taken when it looked applicable. Never thrown. */
+    readonly errors: readonly string[];
+    /** Set when the whole migration was skipped by design. */
+    readonly skipped?: 'unsupported-platform';
+}
+/** The minimal filesystem surface the move needs; injectable for tests. */
+export interface FirstPartyHarnessHomeFs {
+    lstat(p: string): Stats | null;
+    /** The raw link text of a symlink, or null when `p` is not one. */
+    readlink(p: string): string | null;
+    rename(from: string, to: string): void;
+    symlink(target: string, at: string, type: 'dir' | 'file'): void;
+}
+/**
+ * Move a legacy engine home and binary onto the canonical names. See the file
+ * header for the exact contract. Returns what it did; never throws.
+ *
+ * Inside `<home>/bin` it resolves the three layouts a rename can leave:
+ *
+ *   - canonical ABSENT, an alias is a real file — the ordinary legacy install.
+ *     The alias moves to canonical and a link is left at its name.
+ *   - canonical is a LINK to an alias that is a real file — what an alias link
+ *     left DURING the expand phase becomes once the flip swaps which spelling is
+ *     canonical. Leaving it means the next install writes its provenance record
+ *     THROUGH the link onto the old binary's record, and the legacy name then
+ *     verifies as `tampered`. The real file is adopted onto the canonical name
+ *     (a rename replaces the link itself, never what it points at).
+ *   - canonical and an alias are BOTH real files and the alias is newer — a
+ *     client that predates the flip installed an update under the old name. The
+ *     newer engine is what every reader should run, so it is promoted: the older
+ *     canonical binary becomes the rollback copy, and the alias becomes a link.
+ *
+ * Any other layout is left exactly as it is.
+ */
+export declare function migrateFirstPartyHarnessHome(options?: {
+    env?: NodeJS.ProcessEnv;
+    platform?: string;
+    fs?: FirstPartyHarnessHomeFs;
+}): FirstPartyHarnessHomeMigration;
+/**
+ * Leave a relative symlink at every alias name — binary and provenance sidecar —
+ * that does not exist yet, pointing at the canonical file.
+ *
+ * Call after installing the canonical binary. A platform CLI or daemon installed
+ * before a rename resolves the legacy name; the link keeps it on the current
+ * engine. It never replaces anything that exists, whether a real file (an older
+ * engine someone may still run) or a link someone else placed. Never throws.
+ */
+export declare function linkFirstPartyHarnessAliases(options?: {
+    env?: NodeJS.ProcessEnv;
+    platform?: string;
+    fs?: FirstPartyHarnessHomeFs;
+}): FirstPartyHarnessHomeMigration;