@intentic/sandbox-contract 1.247.0 → 1.249.0

package/src/listener-protocol.ts

@@ -1,96 +0,0 @@
-import { z } from "zod";
-import { ActivityStatusSchema } from "./schemas/activity.js";
-
-/* The wire between the daemon and an extension's realtime-listener GATEWAY process (ext-discord, ext-slack,
- * ext-telegram, ext-whatsapp, ext-imap): the four provider-scoped routes app.ts mounts under
- * /listeners/:provider, state, dispatch, failure, status. These shapes used to live daemon-side only, with
- * every gateway hand-writing its own copy of the payloads as untyped literals; a field rename broke five
- * producers silently. They live in the contract now so BOTH ends compile against one declaration, the daemon
- * parses with the schemas, the gateways (via @intentic/connector-runtime) type against the inferred types. */
-
-// One normalized inbound event, serialized as a JSON line in the automation's payload, and the JSON body a
-// realtime source POSTs to /listeners/<provider>/dispatch. A zod schema (not a bare interface) because it's
-// parsed from an extension gateway's request; `provider` and `type` are open strings, the source is
-// extension-declared (contributes.listener), not a core enum.
-export const ListenerMessageSchema = z.object({
-    provider: z.string().min(1),
-    type: z.string().min(1),
-    id: z.string(),
-    channelId: z.string(),
-    author: z.object({ id: z.string(), name: z.string() }),
-    content: z.string(),
-    // Discord message: it @mentions one of our bots or replies to a bot's message. Voice events never set it.
-    mentioned: z.boolean().optional(),
-    // CI pipeline event: the ref it ran on. Top-level rather than inside `extra` for the same reason
-    // `mentioned` is, the dispatcher MATCHES on it, and a narrowing axis the trigger can name has to be
-    // a field of the message rather than a key in a provider's opaque bag.
-    branch: z.string().optional(),
-    // Prior channel messages (chronological) fetched when a bot is tagged, so the agent can reason about why.
-    // Kept a top-level field (not in `extra`) so it reaches the model's payload but stays out of the activity
-    // feed, which logs only content/extra.
-    history: z
-        .array(
-            z.object({
-                author: z.object({ id: z.string(), name: z.string() }),
-                content: z.string(),
-                timestamp: z.string(),
-                self: z.boolean().optional(),
-            }),
-        )
-        .optional(),
-    timestamp: z.string(),
-    // Provider-specific fields (discord message: guildId, attachments; voice_utterance: path;
-    // voice_transcript: path, participants, durationSeconds).
-    extra: z.record(z.string(), z.unknown()).optional(),
-});
-export type ListenerMessage = z.infer<typeof ListenerMessageSchema>;
-
-// One ndjson frame of a /listeners/<provider>/dispatch?stream=1 response, a text delta for one automation's
-// reply, the provider's own failure sentence, or that automation's terminal marker. A type, not a schema: the
-// DAEMON produces these (listener.routes.ts), so nothing parses them from untrusted input.
-export interface ListenerDispatchFrame {
-    readonly automationId: string;
-    readonly delta?: string;
-    // The turn refused or broke, in the provider's own words, forwarded verbatim because a gateway delivers
-    // into the owner's own channel, where the actual sentence is the useful thing.
-    readonly failed?: string;
-    readonly end?: boolean;
-}
-
-/* WHERE ONE CAPABILITY'S LINK-A-DEVICE CEREMONY STANDS (whatsapp), reported every status tick.
- *
- * A CODE IS NOT THE ONLY THING WORTH SAYING, and publishing only codes is what made a phone that had never
- * linked read as connected: the seconds before the first code, a gateway that just restarted, and a number
- * WhatsApp refused all looked identical from the daemon's side, an absent code, so the card fell through to
- * "ready" and the owner was sent away from the one screen that could have shown them the step. Each of those is
- * its own state here, and every one of them means NOT PAIRED YET.
- *
- * `since` stamps the CURRENT code. WhatsApp closes an unpaired socket after a minute or so and each reopen mints
- * a fresh code, so a code is a thing with an age, the card says how old the one on screen is rather than
- * leaving the owner to type a dead one twice. */
-export const ListenerPairingSchema = z.object({
-    // waiting: a socket is up and the code hasn't arrived (or the last one died with its socket).
-    // code: `code` is live, type it on the phone. failed: `detail` says what WhatsApp refused.
-    state: z.enum(["waiting", "code", "failed"]),
-    code: z.string().optional(),
-    detail: z.string().optional(),
-    since: z.number().optional(),
-});
-export type ListenerPairing = z.infer<typeof ListenerPairingSchema>;
-
-// Push-based listener status: a gateway process POSTs its live connection/voice snapshot to
-// /listeners/<provider>/status, and the activity route reads it from there, the daemon holds no provider
-// connection of its own to probe. The body IS the ActivityStatus the /activity/status probe used to build from
-// in-process discord singletons, plus the per-gateway extras that ride the same channel: whether whisper is
-// present (discord's voice-pending signal) and each unpaired capability's ceremony by id (whatsapp's
-// link-a-device flow, the capability card renders it as the step the owner is standing in front of).
-export const ListenerStatusSchema = ActivityStatusSchema.extend({
-    whisperReady: z.boolean().optional(),
-    pairing: z.record(z.string(), ListenerPairingSchema).optional(),
-});
-export type ListenerStatus = z.infer<typeof ListenerStatusSchema>;
-
-// A connection's place in the reconcile lifecycle, as the status snapshot reports it: `idle` = up but holding
-// nothing on purpose (no enabled listener automation to connect for), `pairing` = the socket is up but the
-// credential is a ceremony nobody has completed yet (whatsapp), the rest are the connect loop.
-export type ListenerGatewayPhase = "idle" | "ready" | "pairing" | "connecting" | "disconnected";

package/src/mentions.ts

@@ -1,25 +0,0 @@
-/* @-FILE MENTIONS, the two readers of the same text: the composer, which sends every path a message names as
- * an attachment (the daemon resolves workspace-relative paths and folds them into the prompt as a Read-tool
- * note, no upload involved), and the fold, which draws a message's UPLOADED files as chips and its inline
- * mentions as nothing at all, because they are already visible in the words. One tokenizer, so what the
- * composer counts as a mention is what the transcript declines to redraw. */
-
-// Every path-looking @ token in text, including tokens that are not valid composer mentions. Broad on purpose:
-// old turns persisted these candidates in the shared attachment field, and the fold needs the broad set to
-// recognise and hide those inline paths rather than redraw them as file chips.
-export const mentionedPathTokens = (text: string): string[] => {
-    const paths = new Set<string>();
-    for (const match of text.matchAll(/(?:^|\s)@([^\s@]+)/g)) {
-        const token = (match[1] as string).replace(/[.,;:!?)]+$/, ``);
-        if (token.includes(`/`) || token.includes(`.`)) {
-            paths.add(token);
-        }
-    }
-    return [...paths];
-};
-
-// Workspace paths referenced as @-mentions in a prompt, deduped. A scoped package script prefix from copied
-// pnpm output has the same opening shape (`@scope/package:test:`) but is not a file; accepting it hands the
-// daemon a phantom attachment which only becomes visible when a transcript redraws the wire fields.
-const PACKAGE_SCRIPT = /^[^/]+\/[^/]+:[^/]+$/u;
-export const mentionPaths = (text: string): string[] => mentionedPathTokens(text).filter((token) => !PACKAGE_SCRIPT.test(token));

package/src/model-order.ts

@@ -1,262 +0,0 @@
-/* HOW A MODEL CATALOG IS ORDERED, one rule for every provider, because only one provider publishes an order
- * worth keeping.
- *
- * Anthropic's REST /v1/models answers newest-first: that IS a provider opinion, and Claude's catalog rides it
- * (claude-models.ts). Every other provider here is read through an OpenAI-compatible /v1/models. Codex and
- * Gemini and Kimi via the bundled translator, or out of xAI's "Did you mean" rejection, and those
- * endpoints publish a SET, not a ranking: they hand the ids back in whatever order their registry iterates,
- * which in practice is alphabetical. Reading that as a preference is what put "GPT 5.4 Mini" at the head of the
- * Codex group with GPT 5.6 below it, and what made a fresh Codex conversation start on whichever id happened to
- * sort first, models[0] is the provider default.
- *
- * So for those providers the order is DERIVED from the id, out of the only two facts an id reliably carries:
- * which TIER the model is (the adjective) and which RELEASE it is (the numbers). Both are provider-agnostic,
- * every vendor names its models the same way, which is what lets the daemon's four catalog services and the
- * web's picker share one rule instead of each inventing a local one. */
-
-// A version-ish segment: digits and dots, optionally prefixed by the vendor's version marker (`4`, `5.1`, `v2`,
-// `k3`, `k2.7`, `20251001`). Kimi is the one provider that fuses the marker with the generation; treating `k3`
-// as a name made the current flagship look unversioned, so K2.x sorted above it. Everything else is a NAME
-// segment and belongs to the family, which is what makes the split below exhaustive.
-const VERSION_SEGMENT = /^(?:v|k)?[\d.]+$/i;
-
-// A date stamp rather than a version component: six digits or more (20251001, 250514). The distinction is not
-// cosmetic, claude-opus-4-1-20250805 (Opus 4.1) and claude-opus-4-20250514 (Opus 4.0) compare as (4,1) vs (4)
-// with the stamps held apart, and as (4,1,20250805) vs (4,20250514), the OLDER model winning, without.
-const DATE_SEGMENT = /^\d{6,}$/;
-
-const segmentsOf = (id: string): string[] => id.split(/[-_]/);
-
-// A model's FAMILY, its id with every version-ish segment dropped, so claude-opus-5 and claude-opus-4-8 land
-// together (as do gpt-5.1/gpt-5, and claude-haiku-4-5-20251001 with its date suffix). Derived, never listed: a
-// family that ships tomorrow groups itself. The id is the stable key here, labels get renamed, ids don't.
-export const familyOf = (id: string): string => {
-    const stem = segmentsOf(id)
-        .filter((segment) => !VERSION_SEGMENT.test(segment))
-        .join("-");
-    // An all-numeric id (and an ACP row's empty one) has no stem to speak of; it stands as its own family.
-    return stem === "" ? id : stem;
-};
-
-export interface ModelRelease {
-    // The version components in id order: gpt-5.1 → [5, 1], claude-opus-4-8 → [4, 8]. EMPTY for an unversioned
-    // id (kimi-latest, gemini-pro-agent), which therefore reads as the oldest of its tier: a rolling alias names
-    // no release, and inventing one for it would outrank the models that do name theirs.
-    readonly version: readonly number[];
-    // The id's date stamp, 0 for none, the tiebreak between two builds of the SAME version.
-    readonly date: number;
-}
-
-export const releaseOf = (id: string): ModelRelease => {
-    const numeric = segmentsOf(id)
-        .filter((segment) => VERSION_SEGMENT.test(segment))
-        .map((segment) => segment.replace(/^[vk]/i, ""));
-    const stamps = numeric.filter((segment) => DATE_SEGMENT.test(segment)).map(Number);
-    return {
-        version: numeric
-            .filter((segment) => !DATE_SEGMENT.test(segment))
-            .flatMap((segment) => segment.split(".").map(Number))
-            .filter((component) => Number.isFinite(component)),
-        date: Math.max(0, ...stamps),
-    };
-};
-
-// Newest first. A missing component reads as -1, so gpt-5 sorts under gpt-5.1 and an unversioned id sorts under
-// every versioned one; the date stamp breaks what is left.
-const compareRelease = (left: ModelRelease, right: ModelRelease): number => {
-    for (let index = 0; index < Math.max(left.version.length, right.version.length); index += 1) {
-        const diff = (right.version[index] ?? -1) - (left.version[index] ?? -1);
-        if (diff !== 0) {
-            return diff;
-        }
-    }
-    return right.date - left.date;
-};
-
-/* THE ONE CURATED FACT in this file, and the only one the providers publish nowhere the app can read: which tier
- * is the frontier and which is the cheap one. It ranks FAMILIES, never models, and it is a vocabulary of tier
- * ADJECTIVES rather than a table of ids, that scoping is the whole point, because a per-model ranking table
- * failed here once already. The words are the ones every vendor reaches for, so a release that ships tomorrow
- * ranks itself as long as it is named like its predecessors, and a release named some other way ranks as unknown.
- *
- * An UNKNOWN family LEADS rather than sinks, and that direction is the point: the ranking this replaced sank
- * unrecognized ids to a floor below the everyday tier, so a brand-new flagship sorted beneath the model it
- * replaced. An id carrying no tier word at all is the provider's BASE line (gpt-5.6, grok-4, kimi-k2), which is
- * exactly the line a user reaches for, and a family nobody here has heard of is far likelier to be the next
- * flagship than the next budget tier. Being wrong costs one row's position; being wrong the other way hides a
- * launch. */
-const TIER_RANK: Readonly<Record<string, number>> = {
-    // Frontier: the tier a vendor ships last and charges most for.
-    opus: 0,
-    fable: 0,
-    pro: 0,
-    max: 0,
-    ultra: 0,
-    heavy: 0,
-    // Everyday: the workhorse a step below the frontier.
-    sonnet: 1,
-    flash: 1,
-    mini: 1,
-    // Efficient: the cheap/fast end, the rung whose whole purpose is to cost less than the one above it.
-    haiku: 2,
-    // An open-weights model a vendor re-serves beside its own (gpt-oss-120b on Google's channel) is that rung by
-    // construction: it is there to be the free/cheap option next to the frontier line, never the flagship. Without
-    // it the id carries no tier word at all and would LEAD the section it sits in.
-    oss: 2,
-    lite: 2,
-    nano: 2,
-    fast: 2,
-    small: 2,
-};
-
-const UNRANKED = -1;
-
-/* Some providers name a capability ladder INSIDE one release instead of using the cross-release adjectives
- * above. Codex 5.6's Sol/Terra/Luna rows are that shape: they must remain together ahead of the older 5.5 line,
- * but their order is not an arbitrary id tiebreak. Sol is the strongest, followed by Terra, then Luna. Keeping
- * this as a separate rank lets release recency still win across generations (a future GPT 5.7 base model must
- * not be buried under a recognized 5.6 suffix), while the three siblings sort by their real tier. */
-const RELEASE_TIER_RANK: Readonly<Record<string, number>> = {
-    sol: 0,
-    terra: 1,
-    luna: 2,
-};
-
-const lastRankOf = (family: string, ranks: Readonly<Record<string, number>>): number => {
-    let rank = UNRANKED;
-    for (const segment of family.split("-")) {
-        const found = ranks[segment];
-        if (found !== undefined) {
-            rank = found;
-        }
-    }
-    return rank;
-};
-
-const releaseTierRankOf = (family: string): number => lastRankOf(family, RELEASE_TIER_RANK);
-
-/* HOW HARD AN ID SAYS IT WILL THINK. A routed catalog does not publish one row per model, it publishes one row
- * per model PER THINKING LEVEL, spelling the level into the id: `gemini-3.6-flash-high` and
- * `gemini-3.5-flash-extra-low` are the same Flash at opposite ends of its reasoning budget.
- *
- * Which the ranking above cannot see at all, and that blind spot has a direction: `high` and `low` are both
- * unrecognized words, so two variants of one model tie on tier and the RELEASE tiebreak settles them, and the
- * newest variant a channel publishes is routinely the high one. The quick model, whose entire job is to be the
- * cheap rung, would therefore reach for the most expensive reading of the cheapest model it can find.
- *
- * That is not a small mis-sort. Thinking is the difference between a commit message that is in the box before
- * the user has finished reading the file list and one that arrives half a minute later, measured at ~2s versus
- * ~27s on the same model and the same diff (claude/claude-one-shot.ts, which disables thinking for the rungs where a
- * request parameter can). For a routed rung there is no such parameter: the id IS the setting, so this ranking
- * is the only place the choice can be made.
- *
- * Read ONLY by the cheap-end order. A picker orders a catalog by what a person reaches for, and a person
- * pinning `-high` on purpose means it, see compareCheapestFirst for the seam this belongs to. */
-const THINKING_RANK: Readonly<Record<string, number>> = {
-    minimal: 0,
-    none: 0,
-    low: 1,
-    medium: 3,
-    high: 4,
-    max: 4,
-    // Not a level but a switch, and the loudest statement an id can make about this: a channel that vends
-    // `kimi-k2` beside `kimi-k2-thinking` is naming the same model with its reasoning turned on.
-    thinking: 4,
-};
-
-/* An id naming NO level sits between the two ends rather than at either, the provider's own default, which for
- * a model that can think is usually some thinking. Ranking it cheapest would seat a silent default ahead of an
- * id that explicitly says `minimal`, and ranking it dearest would bury every model whose channel publishes no
- * variants at all (Anthropic's, Kimi's) beneath one that does. Neither is what the id claims. */
-const UNSTATED_THINKING = 2;
-
-const thinkingRankOf = (family: string): number => {
-    const rank = lastRankOf(family, THINKING_RANK);
-    return rank === UNRANKED ? UNSTATED_THINKING : rank;
-};
-
-// The LAST recognized word wins, because tier words compose and the rightmost is the most specific one:
-// gemini-flash-lite is the cheap end of Flash, gpt-codex-max the frontier end of Codex.
-export const tierRankOf = (family: string): number => lastRankOf(family, TIER_RANK);
-
-// The canonical order of two model ids: broad tier first, then release, then a tier declared within that release.
-// Hand it straight to Array#toSorted, that sort is stable, so two ids this rule cannot separate keep the order
-// they arrived in (for Claude, the provider's own).
-export const compareModelIds = (left: string, right: string): number => {
-    const leftFamily = familyOf(left);
-    const rightFamily = familyOf(right);
-    return (
-        tierRankOf(leftFamily) - tierRankOf(rightFamily) ||
-        compareRelease(releaseOf(left), releaseOf(right)) ||
-        releaseTierRankOf(leftFamily) - releaseTierRankOf(rightFamily)
-    );
-};
-
-/* The order for a catalog its endpoint published as a SET. Codex, Gemini, Kimi and Grok, i.e. everything but
- * Anthropic's ranked list. Falling back on arrival order is what the rule above does with a tie, and for a RANKED
- * catalog that is exactly right: the tie is the provider's own opinion, so claude-opus-5 stays ahead of
- * claude-fable-5. For a set there is no opinion to keep, and the header of this file assumed the leftover order
- * was at least alphabetical, it is not. A subscription can hand tied rows back in whatever order its registry
- * iterated THIS request, so the tie decides which model a fresh conversation opens on and can flip between
- * catalog refreshes.
- *
- * So a set breaks its own ties on the id. Which sibling that seats first is arbitrary, but it is the same
- * arbitrary answer every refresh, which is the property `default` actually needs. */
-export const compareUnrankedModelIds = (left: string, right: string): number => compareModelIds(left, right) || left.localeCompare(right);
-
-/* THE SAME TIER SCALE READ FROM THE OTHER END, for the one caller that wants the WEAKEST model rather than the
- * strongest: the quick model behind an automatic helper (the commit message written at land time). A picker
- * orders a catalog by what a user reaches for; this orders it by what a helper should spend, and the two are
- * exact opposites, so they share TIER_RANK rather than each naming its own list of cheap ids.
- *
- * The direction of UNRANKED is the reason this can't just be compareModelIds reversed. There, an unrecognized
- * family LEADS, because an id carrying no tier word is the provider's base line and a family nobody here has
- * heard of is likelier the next flagship than the next budget tier. Reversing would therefore seat exactly that
- * unknown-probably-flagship id as the cheap pick. So unknown sinks to LAST here too, both orders agree it is
- * not the efficient rung, and the cheap end is only ever a family whose tier word is actually recognized.
- * Falling off the end of a catalog with no efficient tier at all (Kimi publishes none) is then honest: the
- * newest of what it does publish, chosen by the release tiebreak below. */
-export const compareCheapestFirst = (left: string, right: string): number => {
-    const leftFamily = familyOf(left);
-    const rightFamily = familyOf(right);
-    return (
-        tierRankOf(rightFamily) - tierRankOf(leftFamily) ||
-        // BEFORE release, and that placement is the point: two rows of one model differing only in thinking
-        // level are the same model, so recency has nothing to say between them, and letting it speak is what
-        // seated the high variant. Tier still wins over both, a thinking Haiku is cheaper than a silent Opus.
-        thinkingRankOf(leftFamily) - thinkingRankOf(rightFamily) ||
-        compareRelease(releaseOf(left), releaseOf(right)) ||
-        releaseTierRankOf(rightFamily) - releaseTierRankOf(leftFamily)
-    );
-};
-
-/* IS `candidate` A STRICTLY CHEAPER RUNG THAN `pick`, on the tier ladder alone. The predicate automatic tier
- * selection runs on (prompt-complexity.ts judges the turn, fast-tier.ts spends this to find something cheaper
- * to run it on), and it lives here because it is a question about the tier vocabulary, which is this file's
- * one curated fact.
- *
- * TIER ONLY, deliberately: not release, not thinking level. A downgrade has to be legible as a downgrade, and
- * "the same model one release older" or "the same model with less thinking" are not the saving this mechanism
- * promises, they are a different turn wearing the user's model name. Haiku under Sonnet is; Sonnet 4 under
- * Sonnet 5 is not.
- *
- * AN UNRANKED FAMILY IS FALSE ON EITHER SIDE, and both directions matter. A candidate carrying no tier word is
- * a provider's base line or a family nobody here has heard of, so calling it the budget option is a guess, and
- * the scale already says the likelier reading is "next flagship". The PICK being unranked is the subtler half:
- * the safety argument for automatic tier selection is that it can only ever route DOWN, and against an id whose
- * tier is unknown nothing can be shown to be down. So an unrecognised pick is left alone rather than swapped
- * for something merely known to be cheap, which is how a saving turns into a bill. */
-export const isCheaperRung = (candidate: string, pick: string): boolean => {
-    const candidateRank = tierRankOf(familyOf(candidate));
-    const pickRank = tierRankOf(familyOf(pick));
-    return candidateRank !== UNRANKED && pickRank !== UNRANKED && candidateRank > pickRank;
-};
-
-/* WOULD RUNNING THIS ID MAKE THE MODEL THINK, as far as its name admits, which for a routed catalog is as far
- * as anyone can tell without running it. True only for an id that spells out a level ABOVE the quiet end, so an
- * ordinary id nobody has annotated (claude-haiku-4-5, kimi-k2) is never accused of it.
- *
- * Exported for one job: a settings row that lets someone pin the quick model has to be able to say that the row
- * they picked is the thinking one. The ordering above keeps Auto off these by construction; a PIN is a
- * deliberate choice and is honoured as written, which only works if the choice is legible when it is made. */
-export const namesThinking = (id: string): boolean => thinkingRankOf(familyOf(id)) > UNSTATED_THINKING;

package/src/model-pins.test.ts

@@ -1,202 +0,0 @@
-import { expect, test } from "vitest";
-import { type ModelSource, modelPinKey, parsePinned, resolveRoleModels } from "./model-pins.js";
-import type { ModelPin } from "./schemas/agent.js";
-
-/* Which models a job spends, and in which order. The rule answers two surfaces at once: the daemon walks it,
- * the browser names its head in that job's settings row, so what these tests pin is that a sandbox's
- * connections alone decide it, with no stored id to go stale, and that there is always a rung underneath the
- * first one whenever the sandbox has another account to reach for.
- *
- * `commit-message` and `pipeline-fix` stand in for the two KINDS of role here (model-roles.ts): the first is a
- * one-shot, whose empty list derives the Auto ladder, and the second is a whole session, whose empty list
- * resolves to nothing so the caller's own composer pick answers. Everything else about the two is identical,
- * which is why one resolver serves both. */
-
-const HELPER = `commit-message` as const;
-const RUN = `pipeline-fix` as const;
-
-// A pin as the settings rows store one. The tests are about ORDER, so most of them name only the pair; the
-// knobs an entry can carry ride through untouched and are asserted where that matters.
-const pin = (key: string): ModelPin => {
-    const at = key.indexOf(`:`);
-    return { provider: key.slice(0, at), model: key.slice(at + 1) };
-};
-
-// Catalogs as their providers actually publish them: Claude's ranked list, the rest in registry order.
-const CLAUDE: ModelSource = { provider: `claude`, ready: true, models: [`claude-opus-5`, `claude-sonnet-5`, `claude-haiku-4-5-20251001`] };
-const GOOGLE: ModelSource = { provider: `gemini`, ready: true, models: [`gemini-3-flash`, `gemini-3-flash-lite`, `gemini-3-pro`] };
-const CODEX: ModelSource = { provider: `codex`, ready: true, models: [`gpt-5.4-mini`, `gpt-5.6`] };
-const KIMI: ModelSource = { provider: `kimi`, ready: true, models: [`kimi-k2.6`, `kimi-k2.7-code`, `kimi-k3`] };
-
-const offline = (source: ModelSource): ModelSource => ({ ...source, ready: false });
-
-// The model that answers when nothing goes wrong: the head of the chain, which is what most of what follows is
-// about and what every surface naming the spend up front reads.
-const head = (sources: readonly ModelSource[], pinned: readonly string[]): ModelPin | undefined =>
-    resolveRoleModels(sources, pinned.map(pin), HELPER)[0];
-
-test("reaches for the efficient rung of the one connected provider, never its flagship", () => {
-    expect(head([CLAUDE], [])).toEqual({ provider: `claude`, model: `claude-haiku-4-5-20251001` });
-});
-
-test("spends the FREE channel over the subscription when both offer the same rung", () => {
-    // Both publish a cheap-tier row, so nothing separates them on capability, and one of them costs the user
-    // nothing while the other eats headroom they watch. A background helper should not quietly bill the Claude plan.
-    expect(head([CLAUDE, GOOGLE], [])).toEqual({ provider: `gemini`, model: `gemini-3-flash-lite` });
-});
-
-test("puts tier ahead of cost: a free frontier model is still the wrong tool for a commit message", () => {
-    // Google connected but publishing only its Pro line. Ordering on price first would seat a flagship here,
-    // which is the exact outcome the feature exists to avoid.
-    const proOnly: ModelSource = { provider: `gemini`, ready: true, models: [`gemini-3-pro`] };
-
-    expect(head([CLAUDE, proOnly], [])).toEqual({ provider: `claude`, model: `claude-haiku-4-5-20251001` });
-});
-
-test("uses stable provider order when two subscriptions offer the same tier", () => {
-    const kimiCheap: ModelSource = { provider: `kimi`, ready: true, models: [`kimi-k2-mini`] };
-    const claudeCheap: ModelSource = { provider: `claude`, ready: true, models: [`claude-haiku-4-5`] };
-
-    expect(head([kimiCheap, claudeCheap], [])?.provider).toBe(`claude`);
-});
-
-test("answers the same thing however the connected providers happen to be listed", () => {
-    // The daemon assembles these from live stores and the browser from its own refs; neither order is a fact.
-    const answers = [head([CLAUDE, GOOGLE, CODEX], []), head([CODEX, CLAUDE, GOOGLE], []), head([GOOGLE, CODEX, CLAUDE], [])];
-
-    expect(new Set(answers.map((answer) => modelPinKey(answer!))).size).toBe(1);
-});
-
-test("honours a pinned model verbatim, including an id no catalog lists yet", () => {
-    expect(head([CLAUDE, GOOGLE], [`claude:claude-opus-5`])).toEqual({ provider: `claude`, model: `claude-opus-5` });
-    // The picker's custom-id escape hatch reaches here too: a catalog can lag a release, and running something
-    // other than what the settings row names would be the worse failure.
-    expect(head([CLAUDE], [`claude:claude-haiku-9`])).toEqual({ provider: `claude`, model: `claude-haiku-9` });
-});
-
-test("falls back to Auto when the pinned provider is no longer connected", () => {
-    // Rather than failing every click with a credential error while the sandbox can plainly still answer.
-    expect(head([offline(CLAUDE), GOOGLE], [`claude:claude-haiku-4-5-20251001`])).toEqual({
-        provider: `gemini`,
-        model: `gemini-3-flash-lite`,
-    });
-});
-
-/* A MALFORMED KEY IS REFUSED WHERE KEYS STILL EXIST. A role's list holds PINS, whose two halves are separate
- * fields the schema requires (ModelPinSchema), so "claude with an empty model" is no longer a shape the
- * resolver can be handed — it is rejected at the settings boundary instead. What still travels as a key is
- * `autoFastModels`, so the rule lives with the parser that reads one, and this is where it is pinned. */
-test("refuses a malformed key rather than reading half a pin out of it", () => {
-    for (const key of [`claude`, `claude:`, `:claude-haiku-4-5`, ` `]) {
-        expect(parsePinned(key)).toBeUndefined();
-    }
-    expect(parsePinned(`claude:claude-haiku-4-5`)).toEqual({ provider: `claude`, model: `claude-haiku-4-5` });
-});
-
-/* THE TWO KINDS OF ROLE DIFFER ON EXACTLY ONE THING: what an empty list means. It is the whole reason the
- * resolver takes a role rather than a boolean, and the reason the two used to be separate files. */
-test("derives a ladder for an unpinned one-shot and nothing at all for an unpinned session", () => {
-    // A commit message exists to stay off the frontier tier, so working it out from what is connected is a good
-    // answer and gets better as accounts are added.
-    expect(resolveRoleModels([CLAUDE, GOOGLE], [], HELPER)).toEqual([
-        { provider: `gemini`, model: `gemini-3-flash-lite` },
-        { provider: `claude`, model: `claude-haiku-4-5-20251001` },
-    ]);
-    // A pipeline fix is a whole session billed whole, and nothing here can judge what one is worth — so the
-    // caller's own floor (the owner's composer pick) answers instead of a ladder this file invented.
-    expect(resolveRoleModels([CLAUDE, GOOGLE], [], RUN)).toEqual([]);
-});
-
-test("carries an entry's run settings through untouched, on either kind of role", () => {
-    // The resolver picks WHICH entry; how that entry runs is the entry's own business and rides along whole,
-    // because the turn (or the one-shot) is composed from all of it.
-    const configured: ModelPin = { provider: `claude`, model: `claude-opus-5`, effort: `max`, thinking: true, harness: `claude-code` };
-
-    expect(resolveRoleModels([CLAUDE], [configured], RUN)).toEqual([configured]);
-    expect(resolveRoleModels([CLAUDE], [configured], HELPER)).toEqual([configured]);
-});
-
-test("serves the newest of a catalog that publishes no cheap tier at all", () => {
-    // Kimi names no tier word anywhere. There is no cheaper rung to find, so the newest row is the honest answer.
-    expect(head([KIMI], [])).toEqual({ provider: `kimi`, model: `kimi-k3` });
-});
-
-test("reports nothing when no account is connected, so the button can say so instead of failing on click", () => {
-    expect(head([offline(CLAUDE), offline(GOOGLE)], [])).toBeUndefined();
-    expect(resolveRoleModels([offline(CLAUDE), offline(GOOGLE)], [], HELPER)).toEqual([]);
-    expect(head([], [`claude:claude-haiku-4-5`])).toBeUndefined();
-});
-
-test("skips a connected provider whose catalog has not loaded yet", () => {
-    const unloaded: ModelSource = { provider: `grok`, ready: true, models: [] };
-
-    expect(head([unloaded, CLAUDE], [])).toEqual({ provider: `claude`, model: `claude-haiku-4-5-20251001` });
-    expect(head([unloaded], [])).toBeUndefined();
-});
-
-/* THE CHAIN: what the daemon walks when the model at the top of it refuses. A spent allowance is the ordinary
- * case, not the exotic one: the account a helper shares with the chat runs out mid-afternoon, and the whole
- * point of the list is that the click still lands on the next rung down. */
-
-test("keeps the pinned models in the order they were written", () => {
-    expect(resolveRoleModels([CLAUDE, GOOGLE, CODEX], [`codex:gpt-5.6`, `gemini:gemini-3-flash`, `claude:claude-haiku-4-5-20251001`].map(pin), HELPER)).toEqual([
-        { provider: `codex`, model: `gpt-5.6` },
-        { provider: `gemini`, model: `gemini-3-flash` },
-        { provider: `claude`, model: `claude-haiku-4-5-20251001` },
-    ]);
-});
-
-test("drops a pin whose provider went away and keeps the rest of the order intact", () => {
-    expect(resolveRoleModels([CLAUDE, offline(GOOGLE), CODEX], [`codex:gpt-5.6`, `gemini:gemini-3-flash`, `claude:claude-haiku-4-5`].map(pin), HELPER)).toEqual([
-        { provider: `codex`, model: `gpt-5.6` },
-        { provider: `claude`, model: `claude-haiku-4-5` },
-    ]);
-});
-
-test("stops at the end of a pinned list rather than reaching for an account the user left out", () => {
-    // Google and Kimi are connected and cheaper. The user wrote down one model, so one model is what this may
-    // spend: a pin exists precisely to keep a helper off the accounts it does not name.
-    expect(resolveRoleModels([CLAUDE, GOOGLE, KIMI], [`claude:claude-haiku-4-5`].map(pin), HELPER)).toEqual([{ provider: `claude`, model: `claude-haiku-4-5` }]);
-});
-
-test("names each model once, however many times the list repeats it", () => {
-    // The list is edited by hand; a duplicate would spend a second attempt proving the same account is out.
-    expect(resolveRoleModels([CLAUDE], [`claude:claude-haiku-4-5`, `claude:claude-haiku-4-5`].map(pin), HELPER)).toEqual([
-        { provider: `claude`, model: `claude-haiku-4-5` },
-    ]);
-});
-
-test("Auto is a ladder too, every connected provider's cheap rung, best first", () => {
-    expect(resolveRoleModels([CLAUDE, GOOGLE, KIMI], [], HELPER)).toEqual([
-        { provider: `gemini`, model: `gemini-3-flash-lite` },
-        { provider: `claude`, model: `claude-haiku-4-5-20251001` },
-        { provider: `kimi`, model: `kimi-k3` },
-    ]);
-});
-
-/* A MODEL ENDPOINT the user configured is a provider like any other here, and the reason it has to be is the
- * settings row: its options are built from the same picker catalog, so a pin naming one that this resolver
- * dropped would print one model's name in the settings row and spend a different account entirely. */
-const OLLAMA: ModelSource = { provider: `endpoint/ollama`, ready: true, models: [`qwen3-coder`, `gemma3-27b`] };
-
-test("honours a pin on a configured endpoint: the whole id, not the half before its slash", () => {
-    expect(head([CLAUDE, OLLAMA], [`endpoint/ollama:qwen3-coder`])).toEqual({ provider: `endpoint/ollama`, model: `qwen3-coder` });
-    // And it round-trips through the key shape the picker mints, which is where the slash-not-colon rule earns
-    // itself: parsePinned splits on the FIRST colon, so an `endpoint:ollama` id would have parsed the provider
-    // as "endpoint" and the model as "ollama:qwen3-coder": a pin that silently resolves to nothing.
-    expect(modelPinKey({ provider: `endpoint/ollama`, model: `qwen3-coder` })).toBe(`endpoint/ollama:qwen3-coder`);
-});
-
-test("leaves Auto to the providers whose price is known, rather than reaching for someone's own server", () => {
-    // Claude publishes a Haiku-class row; the endpoint's ids carry no tier word at all, so they are UNRANKED and
-    // lose on tier. What a turn on a user's own model API costs is not a fact this repo holds, and Auto should
-    // not be asserting one.
-    expect(head([CLAUDE, OLLAMA], [])).toEqual({ provider: `claude`, model: `claude-haiku-4-5-20251001` });
-});
-
-test("still answers from an endpoint when it is the only thing configured", () => {
-    // No tier word in either id, so the shared id-derived ordering decides between them exactly as it does for
-    // Kimi above: the point here is that a sandbox whose only model API is its owner's still gets an answer
-    // rather than the disabled "nothing connected" button.
-    expect(head([offline(CLAUDE), OLLAMA], [])).toEqual({ provider: `endpoint/ollama`, model: `qwen3-coder` });
-});