@intentic/sandbox-contract 1.248.0 → 1.250.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.ts

@@ -1,132 +0,0 @@
-import { modelsFor } from "./agent-catalog.js";
-import type { AgentProvider, ModelPin } from "./schemas/agent.js";
-
-/* WHICH MODELS A ROLE MAY RUN, IN THE ORDER TO TRY THEM. One resolver over every list in
- * settings.modelRoles, and the browser and the daemon both read it.
- *
- * IT IS AN ORDER, NOT A MODEL, and that is the shape of every list this file answers for. A single pick is a
- * single point of failure: the account it names spends its allowance on the chat all morning, and the role
- * fails on a limit for the rest of the day while three other connected providers sit idle. So a setting is a
- * LIST read top to bottom, this hands back the whole ladder, and the caller walks it until one answers. Nothing
- * here decides WHICH failures are worth stepping over — only the runner has made the call and seen it fail —
- * this side says what the running order is.
- *
- * THE RULE LIVES IN THE CONTRACT because both sides need the same answer for different jobs: the daemon runs
- * the model, and the browser has to NAME it, in that job's settings row, before anything has run. Two
- * implementations would drift precisely where it matters most, since a row promising Haiku while the daemon
- * bills Opus is worse than no row at all.
- *
- * AN EMPTY LIST RESOLVES TO NOTHING, FOR EVERY ROLE, and this file no longer derives a floor for any of them.
- * It used to: a `helper` role with no list got an "Auto ladder" worked out from whatever was connected —
- * every provider's cheapest row, best-first — so an owner who had never opened the settings page still got
- * commit messages, session titles and safety verdicts from a model this file picked. That was the wrong
- * default, and the settings row saying "Auto: Gemini 3 Flash Lite, then Claude Haiku 4.5, then …" was the
- * tell: a recommendation nobody asked for, over accounts they had connected for something else, changing
- * under them whenever an account was added. NOT SET NOW MEANS NOT SET. Nothing is auto-selected and nothing
- * is recommended: the owner names the models for a job or the job does not run, which is a state they can
- * read off the row and a bill they cannot be surprised by.
- *
- * The two kinds of role (model-roles.ts) still differ in what the CALLER does with an empty answer — a
- * `helper` is simply off, a `run` falls to the model the owner picked for their own chat — but that is the
- * caller's business, and nothing here has to know which kind it is holding. */
-
-/* One provider's standing in the decision: whether a turn on it can be sent at all, and what its catalog holds.
- *
- * ACP agents are deliberately not expressible here — an ACP row's model id is empty because the agent owns its
- * own model, so there is no rung to point it at. `endpoint/<id>` providers ARE, and have to be: their models
- * appear in the same picker the settings rows build their options from, so a pin naming one has to hold rather
- * than drop out and leave the job running on an account the user was deliberately steering away from. */
-export interface ModelSource {
-    // AgentProvider, not NativeProvider: an endpoint's id is user-created and cannot be in a fixed union, and
-    // what a turn on somebody's own model server costs is not a fact this repo can know — which is fine here,
-    // because nothing on this side ranks anything. A pin either names a provider that can run it or it does not.
-    readonly provider: AgentProvider;
-    // The same connection predicate every other surface gates on (access.ts web-side, the daemon's own account
-    // stores daemon-side). A catalog is never empty by construction, so "has rows" says nothing about "can send".
-    readonly ready: boolean;
-    // What the provider publishes. NOTHING IN THIS FILE READS IT any more: it was the input to the derived Auto
-    // ladder, and a pin is taken verbatim. Kept because it is what a source IS, and the daemon's helper walk
-    // still gathers it (role-model.ts); a caller with no catalog to hand passes an empty list and loses nothing.
-    readonly models: readonly string[];
-}
-
-export interface ModelChoice {
-    readonly provider: AgentProvider;
-    readonly model: string;
-}
-
-// A (provider, model) pair on the wire: `${provider}:${modelId}`, the same key shape the model picker mints for
-// its entries (PickerEntry.key). Every role list stores PINS rather than these keys — an entry says how it runs
-// as well as which model it is — but the key is still how two entries are compared, how a role list dedupes,
-// and how `autoFastModels` (which pins no knobs, see its own note in settings.ts) is stored.
-export const modelPinKey = (choice: ModelChoice): string => `${choice.provider}:${choice.model}`;
-
-/* Split on the FIRST colon only: a provider id never contains one and a model id might. Exported because
- * `autoFastModels` stores these keys, and because a session composed from a pin travels as one
- * (composeSession). */
-export const parsePinned = (pinned: string): ModelChoice | undefined => {
-    const separator = pinned.indexOf(`:`);
-    if (separator <= 0 || separator === pinned.length - 1) {
-        return undefined;
-    }
-    return { provider: pinned.slice(0, separator), model: pinned.slice(separator + 1) };
-};
-
-/* A pin as a person reads it: the catalog's own label for the id, or the id itself for one the static catalog
- * has not caught up with (the picker offers a custom-id escape hatch, so this is a real case rather than a
- * defensive branch). Beside parsePinned because the two are always wanted together, by any surface that has to
- * name what a click is about to spend BEFORE it spends it, and the two loudest of those are extensions that
- * share no other code with each other. */
-export const pinnedModelLabel = (choice: ModelChoice): string =>
-    modelsFor(choice.provider).find((option) => option.value === choice.model)?.label ?? choice.model;
-
-/* WHICH MODELS THIS ROLE MAY RUN, IN THE ORDER TO TRY THEM, given what this sandbox has connected.
- * `pinned` is the stored setting: settings.modelRoles[role], an ordered list of pins.
- *
- * A pin only holds while its provider is READY: an account the user disconnected would otherwise sit at the
- * head of the chain failing on a credential error while the sandbox can plainly still answer from the rung
- * below. It stays on SCREEN, greyed — the settings row renders the stored list, not this one — because a
- * setting that vanished from view would look like the app had eaten it.
- *
- * THE PINNED LIST IS THE WHOLE ANSWER, and there is nothing underneath it. A user who writes down three models
- * has said which accounts this job may spend, and reaching for a fourth when all three are out is exactly the
- * "spend an account they were steering away from" failure a pin exists to prevent. A user who writes down none
- * has said the job picks no model at all.
- *
- * THE WHOLE PIN SURVIVES, not the pair inside it: an entry's effort, thinking, speed and harness are what the
- * work is composed from, so a resolver handing back a bare (provider, model) would silently run the head of the
- * list at the provider's defaults. Nothing here reads or judges those fields, which is the point of carrying
- * them whole.
- *
- * EMPTY OUT MEANS THE LIST HAS NOTHING IT MAY REACH, from two different causes the caller can tell apart by
- * looking at `pinned`: an empty list is an owner who set no model, and a full list that survives none of the
- * readiness filter is an owner whose accounts have gone. The first is the job being switched off, the second
- * is worth a sentence about the accounts.
- *
- * ONE FUNCTION FOR BOTH KINDS OF LADDER, and it is `resolveRoleModels` that stopped existing rather than this
- * one arriving to replace it. A role's list used to add the role's own floor beneath the ready chain, which is
- * the only thing it did that a persona card's list (schemas/personas.ts `personaModels`) did not — so the walk
- * was split out to be shared. With the floor gone there is no difference left to share around: a role's list
- * and a card's list are the same question over the same sources, and two names for it would be two places to
- * read before believing they agree. */
-export const readyChain = (sources: readonly ModelSource[], pinned: readonly ModelPin[]): readonly ModelPin[] => {
-    const ready = new Set(sources.filter((source) => source.ready).map((source) => source.provider));
-    // Taken verbatim, unvalidated against the catalog on purpose: the picker offers a custom-id escape hatch for
-    // a model a catalog hasn't caught up with, and second-guessing the user's own id here would silently run a
-    // different model than the settings row names.
-    const requested = pinned.filter((pin) => ready.has(pin.provider));
-    /* The same model twice would spend two attempts proving one account is out — a real state, since the list is
-     * hand-edited and the bulk editor writes one pin across many jobs.
-     *
-     * THE FIRST OF A PAIR WINS, WHOLE. Two entries can name one model and differ in their knobs (the same Sonnet
-     * at Max and again at Low, written while reordering the list), and the one the user reads first is the one
-     * they meant; keeping the earlier position with the later entry's effort would run a tier that appears
-     * nowhere the pin does. */
-    const chain: ModelPin[] = [];
-    for (const pin of requested) {
-        if (!chain.some((held) => modelPinKey(held) === modelPinKey(pin))) {
-            chain.push(pin);
-        }
-    }
-    return chain;
-};

package/src/model-roles.test.ts

@@ -1,52 +0,0 @@
-import { expect, test } from "vitest";
-import { MODEL_ROLE_BLOCKS, MODEL_ROLES, type ModelRoleSpec } from "./model-roles.js";
-
-/* THE CATALOG DRAWS THE SETTINGS PAGE, so the properties the page relies on have to be true of the TABLE rather
- * than remembered by whoever last added a row. Eighteen jobs in one unbroken list is what the blocks exist to
- * break up, and the failure they replace is a silent one: a role that belongs to no block is simply missing
- * from Sandbox ▸ Agent ▸ Models, with no error anywhere and a page that looks completely normal. */
-
-// The table at its declared width rather than as the literal tuple: `trigger` is absent from a helper's literal
-// type, and what is under test is exactly whether it is absent where it should be.
-const roles: readonly ModelRoleSpec[] = MODEL_ROLES;
-
-/* WHAT STARTS A RUN IS THE BLOCK IT IS READ IN, and asserting the two against each other is what stops them
- * drifting: a run whose trigger says one thing while the page draws it under the other heading is a row telling
- * an owner that a session nobody is watching is one they start. A helper answers with its own kind, because it
- * has no trigger and its block is the kind itself. */
-test("every whole session says what starts it, and it is the block it is drawn in", () => {
-    const blockOf = new Map(MODEL_ROLE_BLOCKS.flatMap((block) => block.roles.map((role) => [role.id, block.id] as const)));
-
-    for (const role of roles) {
-        expect(role.kind === `run` ? role.trigger : role.kind, role.id).toBe(blockOf.get(role.id));
-    }
-});
-
-test("a one-shot declares no trigger at all: nothing presses a commit subject into being", () => {
-    for (const helper of roles.filter((role) => role.kind === `helper`)) {
-        expect(Object.keys(helper), helper.id).not.toContain(`trigger`);
-    }
-});
-
-/* THE BLOCKS PARTITION THE TABLE: every role in exactly one, nothing invented. Asserted as a partition rather
- * than block by block, because the two ways to get this wrong are opposites and only one of them is visible —
- * a role in no block vanishes from the page, a role in two is drawn twice and would be caught by eye. */
-test("the blocks hold every role once, in the table's own order", () => {
-    const blocked = MODEL_ROLE_BLOCKS.flatMap((block) => block.roles.map((role) => role.id));
-
-    expect(blocked.toSorted()).toEqual(MODEL_ROLES.map((role) => role.id).toSorted());
-    /* AND THE ORDER SURVIVES THE SPLIT. Reading the blocks in order is reading the table in order: the table
-     * argues its sequence is REACH (jobs nobody picked a model for, then sessions a click starts, then sessions
-     * that start without one), and a block re-sorted here would leave that argument describing a page it no
-     * longer matches. */
-    expect(blocked).toEqual(MODEL_ROLES.map((role) => role.id));
-});
-
-test("each block says what it is, so the page keeps no headings of its own", () => {
-    for (const block of MODEL_ROLE_BLOCKS) {
-        expect(block.label, block.id).toMatch(/\S/);
-        expect(block.caption, block.id).toMatch(/\S/);
-        // A block with nothing in it would draw a heading over an empty surface.
-        expect(block.roles.length, block.id).toBeGreaterThan(0);
-    }
-});