@intentic/sandbox-contract 1.156.0 → 1.158.0

package/src/model-order.ts

@@ -0,0 +1,124 @@
+/* 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 via the bundled translator, Kimi via Moonshot — 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 v-prefixed (`4`, `5.1`, `v2`, `20251001`). Everything else
+// is a NAME segment and belongs to the family — which is what makes the split below exhaustive.
+const VERSION_SEGMENT = /^v?[\d.]+$/;
+
+// 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(/^v/, ""));
+    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,
+    lite: 2,
+    nano: 2,
+    fast: 2,
+    small: 2,
+};
+
+const UNRANKED = -1;
+
+// 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 => {
+    let rank = UNRANKED;
+    for (const segment of family.split("-")) {
+        const found = TIER_RANK[segment];
+        if (found !== undefined) {
+            rank = found;
+        }
+    }
+    return rank;
+};
+
+// The canonical order of two model ids: tier first, then 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 =>
+    tierRankOf(familyOf(left)) - tierRankOf(familyOf(right)) || compareRelease(releaseOf(left), releaseOf(right));

package/src/schemas.ts

@@ -206,10 +206,13 @@ export const AgentIdSchema = z.object({ id: z.string().min(1) });
 // right now (the lane header's "Clear"); unarchive always names its ids (a restore, or a bulk archive's undo).
 export const AgentArchiveSchema = z.object({ ids: z.array(z.string().min(1)).max(500).optional() });
 export const AgentIdsSchema = z.object({ ids: z.array(z.string().min(1)).min(1).max(500) });
-// The roster after the change PLUS the ids that actually moved — the board needs those to offer "Undo",
-// since "archive everything finished" can't be inverted by re-reading the list afterwards.
-export const AgentArchiveResultSchema = z.object({ agents: z.array(AgentSummarySchema), archived: z.array(z.string()) });
-export type AgentArchiveResult = z.infer<typeof AgentArchiveResultSchema>;
+// What actually MOVED, and deliberately NOT the roster afterwards. Two archives in flight at once each finish
+// holding a full-roster snapshot from a different instant, so a client that swapped one in wholesale would let
+// the slower response resurrect what the faster one just filed away — a delta composes where a snapshot races.
+// Whole summaries rather than ids because the receiving side has to SHOW them (the archive list, and the agent
+// detail page addressed by id); the ids "Undo" needs come off them for free.
+export const AgentsMovedSchema = z.object({ moved: z.array(AgentSummarySchema) });
+export type AgentsMoved = z.infer<typeof AgentsMovedSchema>;
 // rename's input: the user-chosen display title (bounded like sanitizeTitle's cap).
 export const AgentRenameSchema = z.object({ id: z.string().min(1), title: z.string().trim().min(1).max(80) });
 export const AgentFileDiffQuerySchema = z.object({ id: z.string().min(1), repo: z.string().min(1), path: z.string().min(1) });
@@ -273,8 +276,20 @@ export const AgentReplySchema = z.discriminatedUnion("kind", [
 export type AgentReply = z.infer<typeof AgentReplySchema>;
 // Steering: a user message delivered INTO the running turn (injected between tool calls, Claude Code style),
 // keyed by the conversation whose turn is in flight. NOT_FOUND when no steerable turn is running — the client
-// then falls back to a fresh send.
-export const SteerSchema = z.object({ conversationId: z.string().min(1), text: z.string().min(1).max(20_000) });
+// then holds the message in its queue and sends it as the next turn instead. Carries everything a turn's own
+// prompt can carry (files, the editor-context chip), because "add more while it works" is worth nothing if it
+// only takes bare text: the daemon folds the same notes into the injected message that a fresh turn gets.
+export const SteerSchema = z
+    .object({
+        conversationId: z.string().min(1),
+        text: z.string().max(20_000),
+        attachments: z.array(z.string().min(1)).max(20).optional(),
+        editorContext: EditorContextSchema.optional(),
+    })
+    // An attachment-only steer (a screenshot dropped in mid-turn) is legal; an entirely empty one is not.
+    .refine((steer) => steer.text.trim().length > 0 || (steer.attachments?.length ?? 0) > 0, {
+        message: "text or attachments required",
+    });
 // True cancel for the conversation's in-flight turn — aborts the agent daemon-side, unlike closing the
 // /agent fetch (which sends no cancel frame).
 export const StopTurnSchema = z.object({ conversationId: z.string().min(1) });
@@ -1447,6 +1462,42 @@ export type ExtensionProcessStatus = z.infer<typeof ExtensionProcessStatusSchema
 // /webchat/<id>/message and the agent's reply streams back over SSE. Its address is the public automation id, so
 // allowedOrigins (the widget's embed sites) + a per-conversation rate limit are its abuse boundary — no secret
 // token can live in a browser.
+// `workspace` fires from the sandbox's OWN codebase instead of the outside world — see WorkspaceEventKindSchema.
+
+// What the daemon emits as the fleet works, and what a `workspace` trigger names. These are the events a code
+// CHORE runs on (continuous review, post-land checks): the daemon is both producer and consumer, so unlike
+// `event` there is no token and no route — nothing outside the sandbox can reach them.
+//
+// The two OVERLAP on the common path: a clean turn auto-lands, firing both. A chore should name exactly one.
+// `turn.settled` fires once per isolated turn whatever its outcome, so it also covers the errored and
+// conflicted turns most worth a second pair of eyes, and it fires while the user is still looking at the diff —
+// before they decide to land. `agent.landed` fires only when work actually reached the main tree, including an
+// explicit Land from the review panel long after the turn ended.
+export const WorkspaceEventKindSchema = z.enum(["turn.settled", "agent.landed"]);
+export type WorkspaceEventKind = z.infer<typeof WorkspaceEventKindSchema>;
+
+// The payload a workspace-triggered wake carries: one JSON object, in $AUTOMATION_PAYLOAD for the guard and
+// appended to the prompt for the turn.
+//
+// `repos` names the change to look at as an OPEN span — `git -C <dir> diff <from>`, with no upper bound. Each
+// `from` is where that repo stood before the turn (its last landed tip, or the base it branched from); the
+// other end is deliberately the working tree rather than a sha, because a turn that ERRORED left its work
+// uncommitted in the worktree and a commit-to-commit span would report it as nothing at all. `dir` is that
+// repo's dir inside the agent's own checkout, so a chore reads the agent's work without touching /work.
+//
+// No diffstat rides along on purpose: the registry's counts are refreshed at land, so an errored or conflicted
+// turn would carry stale numbers, and a guard that wants a size threshold gets the true one from
+// `git -C <dir> diff --numstat <from>` for the price of one spawn.
+export const WorkspaceEventSchema = z.object({
+    event: WorkspaceEventKindSchema,
+    agentId: z.string(),
+    title: z.string().optional(),
+    branch: z.string(),
+    outcome: z.enum(["landed", "conflict", "idle", "error"]),
+    repos: z.array(z.object({ repo: z.string(), from: z.string(), dir: z.string() })),
+});
+export type WorkspaceEvent = z.infer<typeof WorkspaceEventSchema>;
+
 export const TriggerSchema = z.discriminatedUnion("kind", [
     z.object({ kind: z.literal("schedule"), cron: z.string().min(1) }),
     z.object({ kind: z.literal("event"), token: z.string().min(1).optional() }),
@@ -1459,6 +1510,8 @@ export const TriggerSchema = z.discriminatedUnion("kind", [
         // webchat only: the website origins allowed to POST to the widget endpoint. Absent/empty ⇒ none admitted.
         allowedOrigins: z.array(z.string()).optional(),
     }),
+    // `repo` narrows to events whose span touches one workspace repo ("root" or a repo id); absent ⇒ any.
+    z.object({ kind: z.literal("workspace"), event: WorkspaceEventKindSchema, repo: z.string().min(1).optional() }),
 ]);
 export type Trigger = z.infer<typeof TriggerSchema>;
 
@@ -1476,6 +1529,11 @@ export const AutomationSchema = z.object({
     model: z.string().optional(),
     // When true, a fire doesn't wake the agent — it's held in the approvals queue until the owner approves.
     requireApproval: z.boolean().optional(),
+    // A code CHORE: maintenance of THIS codebase rather than a reaction to the outside world. Purely a
+    // classification — the daemon fires a chore exactly like any other automation — but it cannot be derived
+    // from the trigger, which is why it is stored: a nightly `pnpm audit` sweep and a nightly Stripe poll are
+    // both `schedule`, and belong on different shelves. Absent ⇒ an ordinary automation.
+    chore: z.boolean().optional(),
     enabled: z.boolean(),
 });
 export type Automation = z.infer<typeof AutomationSchema>;