@intentic/sandbox-contract 1.248.0 → 1.249.0

package/src/arrival.ts

@@ -1,160 +0,0 @@
-import { z } from "zod";
-import { NeedsActionSchema } from "./needs-action.js";
-
-/* AN ARRIVAL: something coming INTO this sandbox, whatever it came from and whatever it is made of.
- *
- * There used to be three of these, each with its own schemas, its own routes and its own card, and the split
- * was by ARTIFACT: a `sandbox.toml` had one surface, an environment bundle a second, a foreign assistant's
- * home directory a third. That is the wrong axis. The owner's question is never "which of your three import
- * features is this" — it is "I have a thing, take what is safe from it" — and the three artifacts answer it
- * with the same four moves: read the thing, show what would land, take the ticked rows, say what is left.
- *
- * So there is ONE pipeline, and the artifact is a parser:
- *
- *   source  →  plan   (items the owner ticks, refused lines, needsAction said BEFORE anything writes)
- *           →  apply  (the ticked ids, against a plan RE-DERIVED from the held bytes)
- *           →  report (what landed, what did not and why, what still needs a person)
- *
- * WHAT THE MERGE FIXED, beyond three of everything: the bundle door was the only one that WROTE ON FILE PICK.
- * It is also the most destructive of the three — a bundle lands over a workspace rather than beside it — so
- * the one arrival most deserving of a preview was the one without it. Sharing the pipeline is what gave it
- * one, and what makes "untick the 6 GB monorepo" a thing an owner can say to a bundle at all.
- *
- * THE OUTBOUND HALF IS NOT HERE. Deriving a definition, packing a bundle and publishing the workspace repo
- * live on definition.ts and schemas/environment.ts, because they answer the opposite question and share no
- * shape with this one. */
-
-// Which of the four things this is. The two assistants are separate members rather than one "foreign": the
-// checklist badges the source by name, and an owner who packed a Hermes folder should read the word Hermes.
-export const ArrivalSourceSchema = z.enum(["definition", "bundle", "hermes", "openclaw"]);
-export type ArrivalSource = z.infer<typeof ArrivalSourceSchema>;
-
-// The subset a foreign assistant's home directory can be. Narrower than ArrivalSource on purpose: a connected
-// device is scanned for these two and never for a bundle, which is a file, not a setup.
-export const AssistantSourceSchema = z.enum(["hermes", "openclaw"]);
-export type AssistantSource = z.infer<typeof AssistantSourceSchema>;
-
-/* WHAT AN ITEM BECOMES HERE, not what it was there. The apply loop dispatches on this and the checklist
- * groups by it, so an owner reads "3 skills, 2 connections" rather than a foreign directory listing or a tar
- * table of contents. One enum across all four sources, which is what makes the union honest: a repository is
- * a `repo` whether it arrived as a remote to clone (definition) or as a git dir in a tar (bundle), and the
- * owner ticking it means the same thing either way. */
-export const ArrivalGroupSchema = z.enum([
-    // The /work tree as a whole, cloned from the remote a definition's `[workspace]` names.
-    "workspace",
-    // One repository: cloned from its remote, or unpacked with its real git dir from a bundle.
-    "repo",
-    // Loose files landing in /work: a bundle's workspace bytes, an assistant's notes folder.
-    "files",
-    // Transcripts, checkpoint timelines, ledgers. Bundle-only — nothing else can reference them.
-    "history",
-    // The overlay Dockerfile.
-    "environment",
-    // One connection, landing unauthenticated unless its secret travelled.
-    "capability",
-    // The agent settings that differ from their defaults.
-    "settings",
-    // A merge into CLAUDE.md / AGENTS.md.
-    "memory",
-    "skill",
-    "automation",
-    // One credential VALUE, and the only group gated behind the apply's second consent.
-    "secret",
-]);
-export type ArrivalGroup = z.infer<typeof ArrivalGroupSchema>;
-
-/* ONE ROW OF THE CHECKLIST. Two flags rather than one, because the four sources fail an item for two
- * genuinely different reasons and collapsing them would lose the one the owner can act on:
- *
- *   `applicable: false`  the target already holds this, so it CANNOT be ticked. A definition and a bundle
- *                        land beside what is there, never over it, so an existing repo directory or
- *                        capability id greys its row and prints the reason.
- *   `recommended: false` it can be ticked and the reader should look first. An adapter's judgment about a
- *                        server URL pointing at the old machine, or an env key that reads as tuning.
- *
- * A source that has no use for one of them fills it constantly: a definition recommends everything it can
- * apply, an assistant adapter refuses inside its own walk rather than emitting inapplicable rows. */
-export const ArrivalItemSchema = z.object({
-    /* Deterministic and derived from the artifact ("repo:intentic", "skill:weather", "bundle:history"), which
-     * is the whole reason the apply may re-derive: the ids the owner ticked name the same items in the
-     * second derivation as in the one the browser rendered. */
-    id: z.string(),
-    group: ArrivalGroupSchema,
-    // The checklist line, in plain words: "Repository intentic", "Skill, weather", "Workspace files".
-    label: z.string(),
-    detail: z.string().optional(),
-    applicable: z.boolean(),
-    // Why it cannot be ticked. Present exactly when `applicable` is false.
-    reason: z.string().optional(),
-    recommended: z.boolean(),
-    /* Names of the secrets this row would store — never values. Non-empty rows only move when the apply
-     * carries `includeSecrets`; the report names what stayed behind rather than pretending it landed. */
-    secrets: z.array(z.string()),
-});
-export type ArrivalItem = z.infer<typeof ArrivalItemSchema>;
-
-export const ArrivalPlanSchema = z.object({
-    source: ArrivalSourceSchema,
-    /* Names the held artifact for the apply call. Minted per plan; a new plan replaces the held one, because
-     * an owner changing their mind is the ordinary case and not a conflict. */
-    token: z.string(),
-    // What the artifact calls itself: a definition's `name`, a bundle's source sandbox. For the reader only.
-    name: z.string().optional(),
-    items: z.array(ArrivalItemSchema),
-    /* Whether this artifact holds credential VALUES at all, which is what decides whether the apply's second
-     * consent is even a question. A definition is false by construction (it carries names, never values); a
-     * bundle is whatever its owner chose at export; an assistant's home directory is true whenever any row
-     * names a secret. The card asks with a toggle only when this is true, so the ordinary arrival is not made
-     * to answer a question about credentials that do not exist. */
-    carriesSecrets: z.boolean(),
-    // What the reader saw and will not offer at all: sessions, logs, pairing state, a tar entry this daemon
-    // refuses to write. Listed rather than silent.
-    refused: z.array(z.string()),
-    // What is already known not to move mechanically, surfaced at PREVIEW time so the owner ticks with open
-    // eyes and again on the report.
-    needsAction: z.array(NeedsActionSchema),
-});
-export type ArrivalPlan = z.infer<typeof ArrivalPlanSchema>;
-
-export const ArrivalApplySchema = z.object({
-    token: z.string(),
-    // The ticked ids. Ids the re-derived plan does not contain are ignored rather than erroring: the artifact
-    // is the truth, and a stale checklist must not block the items that still exist.
-    items: z.array(z.string()),
-    /* The owner's explicit consent to move credential VALUES, asked once, on the inbound side, for every
-     * source. It used to be asked at EXPORT time for a bundle and at APPLY time for an assistant, which is
-     * the same question in two places with two different answers about who is consenting to what. */
-    includeSecrets: z.boolean(),
-});
-export type ArrivalApply = z.infer<typeof ArrivalApplySchema>;
-
-export const ArrivalReportSchema = z.object({
-    applied: z.array(z.object({ id: z.string(), group: ArrivalGroupSchema, label: z.string() })),
-    // Ticked and did not land, each with its reason. Distinct from `refused` and from inapplicable rows,
-    // which were never attempted.
-    failed: z.array(z.object({ id: z.string(), label: z.string(), error: z.string() })),
-    refused: z.array(z.string()),
-    needsAction: z.array(NeedsActionSchema),
-});
-export type ArrivalReport = z.infer<typeof ArrivalReportSchema>;
-
-/* ONE OF THE OWNER'S OWN DEVICES, as an arrival source that needs no packing at all: the daemon walks the
- * machine's home folder over the socket it already holds. Read on the card's first render for every enrolled
- * machine, so the offer appears before the owner has read a single instruction.
- *
- * `found` absent means "connected, and nothing to bring in from here", which is a real answer worth rendering
- * quietly rather than an error: the machine may simply not be the one the assistant runs on. */
-export const ArrivalHostSchema = z.object({
-    id: z.string(),
-    online: z.boolean(),
-    found: AssistantSourceSchema.optional(),
-    // Why this machine cannot be read right now, when it cannot: asleep, or its own refusal, in its words.
-    detail: z.string().optional(),
-});
-export type ArrivalHost = z.infer<typeof ArrivalHostSchema>;
-export const ArrivalHostsSchema = z.object({ hosts: z.array(ArrivalHostSchema) });
-
-// Read a setup off a connected device instead of an upload. Answers with a plan exactly as the upload door
-// does; everything after this point is identical whichever door the arrival came through.
-export const ArrivalScanSchema = z.object({ host: z.string().min(1) });
-export type ArrivalScan = z.infer<typeof ArrivalScanSchema>;

package/src/batch-runs.ts

@@ -1,188 +0,0 @@
-import { STATE_DIR } from "@intentic/constants";
-import type { ModelRole } from "./model-roles.js";
-
-/* ONE BATCH RUN ENGINE, for every surface that fans an ISOLATED AGENT TURN out over a set of items and reads
- * the answers back off disk.
- *
- * Three packs had written this separately — acceptance (a run per story), maintenance (a run per chore, per
- * repository) and documentation (a run per package) — and the three copies agreed on every decision that
- * matters and drifted on every detail that does not: `SCAN_RUNS` was 10 in one and 30 in another, one minted
- * run ids with a per-process counter and one without (the one without could collide, and did, the moment a
- * surface started several runs inside a millisecond), and each spelled the reporting clause its own way, so an
- * agent's instructions for where to leave its answer depended on which screen started it.
- *
- * WHY THE CORE OWNS IT rather than one of them exporting it. A substrate is what other packs fire into, and a
- * pack can be switched off: a run engine that stops existing because somebody hid a screen is not an engine.
- * The reverse — a substrate living in one pack — is what produced the three copies, because reaching into
- * `acceptance` for a run id is a dependency no other pack wants and reinventing it is one afternoon.
- * `_extensions/README.md` states the rule; this is the second of the four substrates named there.
- *
- * WHAT A RUN IS, and the part that is load-bearing rather than incidental:
- *
- *  • IT IS BACKED BY FILES, never by a store a pack owns. `run.json` is written before the first turn starts
- *    and each agent writes its own result beside it. So a run survives archiving the fleet agents, discarding
- *    them, closing the browser and rebuilding the image, and a browser that was shut when a turn finished picks
- *    the answer up the next time it opens.
- *  • ITS CONVERSATION IDS ARE DERIVED, so joining a run to the fleet is a filter over `GET /agents` rather than
- *    bookkeeping that can drift. This is why none of these surfaces owns session machinery: the worktree, the
- *    live status, the cost, the transcript and the `/agents/<id>` page all already exist.
- *  • IT LIVES UNDER `.intentic`, which is outside every repo (the root repo excludes it) and is bound back in
- *    SHARED for isolated turns, so an agent writing its result from inside its own worktree writes into the
- *    same tree the browser reads: nothing to land, no git noise.
- *
- * The manifest and result SHAPES stay with the packs. A chore's outcome vocabulary and a story's criteria have
- * nothing to say to each other, and a substrate that tried to own both would be a union that grows a field per
- * screen. What is here is what all three do identically: where the files go, how the ids are made, how a
- * half-written file is survived, and what the agent is told about where to leave its answer. */
-
-/* WHERE ONE KIND OF RUN KEEPS ITS DIRECTORIES. Taken as the tail rather than composed from a pack id, because
- * the three existing layouts are not uniform and rewriting them would orphan every run already on disk:
- * acceptance keeps runs under `records/artifacts/acceptance`, maintenance under `records/chores/runs`. A path
- * is a fact about a tree that exists, not a naming opportunity. */
-export interface BatchRunKind {
-    /* The directory holding this kind's run directories, workspace-relative, under the state dir. */
-    readonly runsDir: string;
-    /* The conversation-id prefix, two or three characters. Every conversation this kind starts carries it, so a
-     * prefix filter over `GET /agents` is the join key and not merely a naming convention. */
-    readonly prefix: string;
-    /* How many runs deep anything that READS RESULTS goes. A bound on the walk, not on what can be run: only
-     * recent runs carry news, and a workspace with hundreds of run directories must not spend a request per
-     * item to render a list or light a badge. One number per kind, shared by every reader of that kind, so a
-     * badge's idea of "recent" and a list's can never disagree. */
-    readonly scanRuns: number;
-}
-
-/* The conversation id's own regex is `^[a-zA-Z0-9][a-zA-Z0-9_-]{0,63}$` — it lands in branch names and in
- * paths — so this is a hard ceiling rather than a style choice. */
-const CONVERSATION_ID_MAX = 64;
-
-/* `r` + a base-36 millisecond, zero-padded, + a per-process counter: sortable, ~10 characters, and readable
- * enough to match a directory to a moment. The clock is taken from the caller so this stays pure and testable.
- *
- * THE PADDING IS WHAT MAKES "SORTABLE" TRUE. Both copies this replaces claimed it and neither had it: a base-36
- * number is shorter when it is smaller, so a plain `toString(36)` sorts `r1a` after `rzz` the moment two ids
- * straddle a digit boundary. Today's milliseconds are all eight digits so nothing has gone wrong yet, and
- * nothing will until 2059 — which is exactly the kind of latent boundary that is cheap to remove now and
- * expensive to find later. Padded to the same width, the ids on disk are the length they already were.
- *
- * THE COUNTER IS NOT OPTIONAL, the other drift worth naming. A surface that fans out over items can get away
- * without one, because its ids differ by item; a surface where one run IS one item cannot, and "run this chore
- * in every repository" starts several inside the same millisecond. Both kinds share this function, so the
- * safe answer is the only answer, and it costs the id one character. */
-const TIME_DIGITS = 8;
-let sequence = 0;
-export const batchRunIdAt = (epochMs: number): string => `r${epochMs.toString(36).padStart(TIME_DIGITS, `0`)}${(sequence++).toString(36)}`;
-
-/* The fleet conversation id for one item of one run, or for a run that is a single item (omit `item`).
- *
- * THE RUN ID SURVIVES TRUNCATION and the item is what gets cut, because the run id is how a card is attributed
- * back to its run: lose that and a finished turn belongs to nothing. Callers that fan out must already have
- * made their item slugs unique by suffixing, and the suffix sits at the end — exactly where the cut lands — so
- * uniqueness holds only while the cut leaves it. In practice nothing is close: slugs are capped at 40 and run
- * ids are ~10, well inside 64. A trailing separator left by the cut is trimmed, because `xt-r5k2-` is a
- * conversation id the regex above would refuse. */
-export const batchConversationId = (kind: BatchRunKind, runId: string, item?: string): string =>
-    `${kind.prefix}-${runId}${item === undefined ? `` : `-${item}`}`.slice(0, CONVERSATION_ID_MAX).replace(/[-_]+$/u, ``);
-
-// Every conversation one kind starts, for the prefix filter over `GET /agents` that joins a run to the fleet.
-export const batchRunPrefix = (kind: BatchRunKind): string => `${kind.prefix}-`;
-
-// The directory holding one kind's run directories, workspace-relative. What a listing is asked for.
-export const batchRunsDir = (kind: BatchRunKind): string => `${STATE_DIR}/${kind.runsDir}`;
-export const batchRunDir = (kind: BatchRunKind, runId: string): string => `${batchRunsDir(kind)}/${runId}`;
-export const batchRunManifestPath = (kind: BatchRunKind, runId: string): string => `${batchRunDir(kind, runId)}/run.json`;
-
-/* Where one item of a run leaves its files. A run whose items are the run itself (`item` omitted) writes
- * straight into the run directory, which is what maintenance already does and what keeps its `result.json`
- * beside its `run.json` rather than one pointless level down. */
-export const batchItemDir = (kind: BatchRunKind, runId: string, item?: string): string =>
-    item === undefined ? batchRunDir(kind, runId) : `${batchRunDir(kind, runId)}/${item}`;
-export const batchResultPath = (kind: BatchRunKind, runId: string, item?: string): string => `${batchItemDir(kind, runId, item)}/result.json`;
-
-/* A FILE THAT IS HALF-WRITTEN, or written by a build whose shape has since changed, IS SKIPPED rather than
- * thrown on. One bad directory must not blank a whole history, and a run directory is written by an agent
- * mid-turn, so reading one that is not finished being written is ordinary rather than exceptional.
- *
- * The caller supplies the shape check, because the shape is the pack's. This owns only the two failure modes
- * every reader shares: text that is not JSON, and JSON that is not an object. */
-export const parseBatchFile = <T>(text: string, shape: (value: Record<string, unknown>) => T | undefined): T | undefined => {
-    try {
-        const parsed: unknown = JSON.parse(text);
-        return typeof parsed !== `object` || parsed === null ? undefined : shape(parsed as Record<string, unknown>);
-    } catch {
-        return undefined;
-    }
-};
-
-/* WHAT THE AGENT IS TOLD ABOUT WHERE TO LEAVE ITS ANSWER, appended to whatever prompt the pack composed.
- *
- * WHY THE AGENT WRITES A FILE AND NOT A ROUTE. A ledger is a daemon route, and reaching it from a turn would
- * mean handing the agent a token and a client it needs for nothing else. Writing one small JSON file is
- * something every agent can already do, and the surface promotes finished runs when it next sees them. The
- * promotion is idempotent and re-runs on every poll, so nothing is lost by not being watched.
- *
- * `outcomes` is the pack's vocabulary and is spelled out in full, because a closed set is what lets a surface
- * debounce without hiding anything: an agent that verified some findings and concluded they were false
- * positives has to be able to SAY so, or the next poll starts the same turn again forever. Pass the
- * explanations with the words — a model that reads an outcome as an admission of having done nothing useful
- * will avoid it and report something else, and the surface never goes quiet.
- *
- * The closing line is not decoration. A turn that concludes there was nothing to do and writes no file is
- * indistinguishable from a turn that died, and the surface has to show the second as an unknown. */
-export const batchReportingClause = (params: {
-    readonly path: string;
-    readonly fields: string;
-    readonly outcomes?: string | undefined;
-}): string =>
-    [
-        `When you are finished, write your conclusion to ${params.path} as JSON:`,
-        params.fields,
-        ...(params.outcomes === undefined ? [] : [params.outcomes]),
-        `Write that file even if you conclude there was nothing to do.`,
-    ].join(`\n\n`);
-
-/* THE BODY OF THE `POST /agent` THAT STARTS ONE ITEM, so the flag combination that makes a run a run is decided
- * once. `isolated: true` with a conversationId is the shape (and the only shape) that registers a fleet entry,
- * which is why none of these packs owns session machinery; `unattended: true` is what the turn IS — started by
- * a row rather than by a person at a composer — and `runRole` is which of those rows, so the daemon answers
- * with the owner's list FOR THAT JOB (model-roles.ts) unless the caller pinned a model on the row's caret, in
- * which case the pick rides along and the daemon's fill step leaves it alone.
- *
- * PERMISSIONS AND ISOLATION ARE THE CALLER'S, deliberately. They are the two decisions that differ by kind and
- * both are about safety rather than plumbing: an acceptance test that parks on a permission card is a test that
- * never finishes, so that surface trades the prompt away; a maintenance chore is different in kind — nobody is
- * waiting on it, it may take until tomorrow, and a sweep that can answer its own permission prompts is exactly
- * the thing an owner would want to have been asked about. A default here would decide that for both. */
-export interface BatchTurnPick {
-    readonly provider: string;
-    readonly model?: string | undefined;
-    readonly effort?: string | undefined;
-}
-
-export const batchTurnBody = (params: {
-    readonly prompt: string;
-    readonly title: string;
-    readonly conversationId: string;
-    /* WHICH JOB THIS IS, and therefore which of the owner's model lists pays for it (model-roles.ts). Required
-     * rather than optional, because every pack that reaches this function is one of the named roles and a
-     * default here would silently hand a new one somebody else's budget — which is exactly how one "agent runs"
-     * tier came to cover a documentation sweep and a red production pipeline. */
-    readonly role: ModelRole;
-    readonly pick?: BatchTurnPick | undefined;
-    readonly extra?: Readonly<Record<string, unknown>> | undefined;
-}): Record<string, unknown> => ({
-    prompt: params.prompt,
-    title: params.title.slice(0, 80),
-    conversationId: params.conversationId,
-    isolated: true,
-    unattended: true,
-    runRole: params.role,
-    ...(params.pick === undefined
-        ? {}
-        : {
-              agent: params.pick.provider,
-              ...(params.pick.model === undefined ? {} : { model: params.pick.model }),
-              ...(params.pick.effort === undefined ? {} : { effort: params.pick.effort }),
-          }),
-    ...params.extra,
-});

package/src/capability-ledger.test.ts

@@ -1,140 +0,0 @@
-import { describe, expect, it } from "vitest";
-import { capabilitiesOf, limitationsOf } from "./agent-catalog.js";
-import type { AgentCapabilities } from "./agent-runtimes.js";
-
-/* THE CAPABILITY LEDGER, which claims in the record are backed by machinery, and which by prose.
- *
- * agent-catalog.test.ts asks two other questions: does every provider/harness pair HAVE a row, and does every
- * axis a record can lack have words for it. A row can pass both and still be a lie. The ability is declared,
- * the sentence renders in the picker's footer, and nothing anywhere behaves differently, so the day the
- * runtime gains the ability (or loses it), the declaration keeps its old value and the footer keeps telling the
- * user something that stopped being true. Over-promising is the direction that hurts: told a runtime can be
- * steered, someone types a mid-turn correction into a queue that does not exist.
- *
- * The record's header already states the rule: "a capability is listed here only if something READS it". This
- * is the rule with teeth. Every field is ENFORCED (a seam opens or closes on it, and the entry cites where) or
- * DESCRIPTIVE (it gates nothing; its whole job is that one sentence). `Record<keyof AgentCapabilities, …>`
- * makes the split exhaustive at COMPILE time: a field added to the interface without an entry here does not
- * typecheck, and neither does an entry for a field that no longer exists. There is no way to add an ability and
- * leave the question of what backs it unanswered.
- *
- * WHAT THIS DOES NOT DO, deliberately: prove an ENFORCED gate exists. Those gates live in the daemon and the
- * web, which sit ABOVE this package and must not be imported back into it. So an enforced entry's citation is a
- * comment a reader checks, and the honest reading is "someone verified this once", not "CI verifies it". The
- * descriptive half IS machine-checked below, because it can be: those claims reach the user through
- * `limitationsOf`, which is right here.
- *
- * Moving a field between the two sets belongs in the same change that adds or removes its gate. */
-
-type Backing = "enforced" | "descriptive";
-
-const LEDGER: Record<keyof AgentCapabilities, Backing> = {
-    // adapter-registry.ts maps runtime → the adapter that serves the turn; getting it wrong runs the turn on
-    // the wrong loop entirely. Also keys the daemon's per-runtime health probes (useSandboxVersion.ts).
-    runtime: "enforced",
-    // conversation.ts's `steerable`: the composer offers mid-turn injection only where there is a queue.
-    steering: "enforced",
-    // turn-plan.ts forwards `permissionMode` only under "modes" (bar plan); modesFor/clampMode build the
-    // composer's mode list from it, so a plan-only runtime is offered two postures rather than four names.
-    permissions: "enforced",
-    // turn-plan.ts opens the tool seam on "full" and attaches the setup notice when it is anything less.
-    mcp: "enforced",
-    // turn-plan.ts drops `effort` unless the runtime takes it; ComposerEffort.vue renders no scale without it.
-    effort: "enforced",
-    // turn-plan.ts drops `fast` unless the loop can ask for it. The one axis with no sentence of its own: a
-    // record alone cannot tell the truth about it (a translator-routed turn reads true and still cannot go
-    // fast), so the user-facing answer comes from fastAllowed instead.
-    fastMode: "enforced",
-    // turn-plan.ts tells a "cwd" turn where its worktree is, because an absolute /work path still reaches the
-    // shared checkout there. Under "namespace" the mount does it and the note would be noise.
-    isolation: "enforced",
-    /* system-prompt.ts composes a turn's standing instructions AGAINST this value: a replacement where one may
-     * be sent, an addition where only that is possible, and the user-message door for the persona note where
-     * there is no system seam at all, and each adapter reads the field the composition set (codex-agent.ts's
-     * two config keys, grok-agent.ts's per-message `system`). It is also the one axis whose absence was the bug
-     * that produced it: before the field existed, every runtime was composed for as though it were the Claude
-     * Code loop, and five of the six silently dropped the owner's prompt. */
-    instructions: "enforced",
-    // turn-plan.ts reads this before an opening turn: a "prompt" runtime receives the generated catalogue as
-    // a typed note, while a "native" runtime is left to its own loader so the same list never arrives twice.
-    skillDiscovery: "enforced",
-    // turn-plan.ts (honoured) plans the JS backend only where "js" is declared, so a runtime without it is
-    // handed no `jsExecution` and mounts no Code tool: the same drop-what-you-can't-honour rule as `effort`.
-    execution: "enforced",
-    /* turn-plan.ts (honoured) carries this onto every request and guard/turn-gate.ts DERIVES the gate's shape
-     * from it: "none" gets no consult and a permanently-set taint bit, "refuse-only" cannot park so a hold
-     * refuses, the other two park on a card. So a row that lies about itself changes how its turns behave.
-     * It also decides whether Codex is asked to raise approvals at all (codex-agent.ts threadOptions). */
-    rulebook: "enforced",
-
-    /* DESCRIPTIVE: true of the runtime, and nothing consults them. Each describes behaviour that is emergent
-     * rather than gated: an agent that never emits `question` frames simply never asks, one that publishes no
-     * commands leaves the `/` popover empty. Nothing has to switch off, which is why nothing does. That also
-     * means the declaration and the behaviour are two independent facts, and only the reader below keeps them
-     * from disagreeing in the one place a user can see. Wiring one up (hiding the terminal tab, skipping
-     * auto-resume) moves it to ENFORCED: in the change that wires it. */
-    questions: "descriptive",
-    commands: "descriptive",
-    terminals: "descriptive",
-    recovery: "descriptive",
-    /* DESCRIPTIVE, and the one entry here whose gap cannot be closed by wiring. Masking a stored credential in
-     * what the model READS needs a seam that edits a tool result before the model sees it, and only the Claude
-     * Code loop has one (a PostToolUse hook). Every other runtime runs its tools inside the VENDOR'S loop: the
-     * model has read the result before the daemon sees any frame about it. So nothing consults this field, and
-     * nothing can: it exists so limitationsOf can say out loud what is true, instead of letting an owner who
-     * stored a credential assume it is hidden everywhere. Moving it to ENFORCED would take a runtime that
-     * publishes a result-rewriting seam, not a change here. */
-    secrets: "descriptive",
-};
-
-// The full ceiling: every ability real, so `limitationsOf` has nothing to say about it. Read from the catalog
-// rather than written out, so this is the record the product actually ships.
-const CEILING = capabilitiesOf("claude", "native");
-
-const fieldsWhere = (backing: Backing): (keyof AgentCapabilities)[] =>
-    (Object.keys(LEDGER) as (keyof AgentCapabilities)[]).filter((field) => LEDGER[field] === backing);
-
-/* The compiler pins the ledger against the INTERFACE. This pins it against a live record, which is not the same
- * claim: an optional field, or one a record leaves off, typechecks and then is not there to gate anything. */
-it("classifies exactly the fields a live record carries", () => {
-    expect(Object.keys(LEDGER).toSorted()).toEqual(Object.keys(CEILING).toSorted());
-});
-
-/* A DESCRIPTIVE field earns its place by reaching the user, since by definition it does nothing else. Checked
- * per field rather than by counting sentences: an aggregate is satisfied by one axis contributing two lines
- * while another contributes none, which is exactly the case worth catching. Anything that survives here without
- * a sentence is decoration, and the fix is to delete the field or wire it up, not to add an exemption. */
-describe("a descriptive claim reaches the user", () => {
-    it("has something to disclose against: the ceiling discloses nothing", () => {
-        expect(limitationsOf(CEILING)).toEqual([]);
-    });
-
-    /* What "lacking this axis" MEANS for a field that is not a boolean. A boolean diminishes to false; anything
-     * else has to name its own floor here, because only the axis knows which of its values is the weak one.
-     * Adding a non-boolean descriptive field without an entry fails below rather than silently testing nothing. */
-    const DIMINISHED: Partial<Record<keyof AgentCapabilities, unknown>> = { secrets: "none" };
-
-    it.each(fieldsWhere("descriptive"))("%s puts its own sentence in the picker when the runtime lacks it", (field) => {
-        const boolean = typeof CEILING[field] === "boolean";
-        // A boolean's floor is `false` and needs no entry; every other descriptive field has to name its own.
-        // Asserted against the KEYS of DIMINISHED so the failure prints the floors that do exist, which is what
-        // tells "this field was never added" apart from "this field was renamed and its entry left behind".
-        expect(
-            boolean ? [field] : Object.keys(DIMINISHED),
-            `${field} is descriptive and not a boolean: add its weakest value to DIMINISHED above`,
-        ).toContain(field);
-        const floor = boolean ? false : DIMINISHED[field];
-
-        const lacking: AgentCapabilities = { ...CEILING, [field]: floor };
-
-        expect(limitationsOf(lacking)).toHaveLength(1);
-    });
-});
-
-/* The ledger is a split, not a label: a set that swallowed everything would typecheck and prove nothing. Both
- * sides being occupied is what makes reading an entry informative, and if the descriptive side ever empties
- * because every axis got wired up, that is a real event, and deleting this file is the right response to it. */
-it("is a real split: neither side is empty", () => {
-    expect(fieldsWhere("enforced").length).toBeGreaterThan(0);
-    expect(fieldsWhere("descriptive").length).toBeGreaterThan(0);
-});

package/src/capability-secrets.ts

@@ -1,20 +0,0 @@
-/* THE ONE VALUE THAT MEANS "WHATEVER IS ALREADY STORED", the rule both ends of the capability wire apply.
- *
- * A capability's credentials never reach a browser: the list route echoes the shape of a connection and drops
- * every secret in it, and the manifest on disk holds this marker where each value used to be (the vault keeps
- * the value itself). That is what makes a connection EDITABLE without being re-typed: a form that wants to
- * change a tunnel's routed networks sends this back in place of the pre-shared key it was never shown, and both
- * the write path and the storage layer read it as "leave that one alone".
- *
- * Deliberately not an empty string and not a dropped key. The entry still has to satisfy CapabilitySchema, a
- * connector's required token, an ssh key, and a reader that somehow bypasses rehydration must fail LOUDLY: a
- * service refusing this string is a clear auth error, where an empty value reads as "not configured yet" and a
- * missing key as a shape change.
- *
- * It lives in the contract rather than in the daemon's store because it is now spoken on the wire. The browser
- * has to be able to say it, the add route has to resolve it before a handler ever sees it, and the store has to
- * refuse to write it over a real value, three places, one spelling. */
-export const VAULTED = "__intentic_vaulted__";
-
-/** Whether a config value is the marker rather than a credential, the check, so the string is typed once. */
-export const isVaulted = (value: unknown): boolean => value === VAULTED;