@anchrd/intel-contract 0.12.0 → 0.13.0

package/dist/contract/contract.js

@@ -28,9 +28,6 @@ export const SessionUser = z.strictObject({
 // (those stay behind each door, where `/session` deliberately does not carry them). `agentRuntime`
 // says whether an agent Worker is bound at all (#190): without it the UI offers no "New agent" and
 // an agent node explains itself instead of rendering views that could only end in a 503.
-export const IntelCapabilities = z.strictObject({
-    agentRuntime: z.boolean(),
-});
 // The fourth kind is `table` (#40), the fifth is `agent` (#139) and the sixth is `board` (#285).
 // Each is a kind of node, not a kind of thing: it hangs in the same folder tree, inherits the same
 // folder grants, carries the same immutable versions and the same R2 body as a document
@@ -41,7 +38,7 @@ export const IntelCapabilities = z.strictObject({
 // or a policy in order to file it. The same holds for `board`: it is a file somebody may make, not
 // a place the tree grows a special corner for — which is exactly why a board is one node carrying
 // its tasks and not a folder that only tasks may live in (#285).
-export const NodeKind = z.enum(["folder", "document", "attachment", "table", "agent", "board"]);
+export const NodeKind = z.enum(["folder", "document", "attachment", "table"]);
 // ⚠️ There is no `ContextPolicy`, and it is not coming back in this shape (#76). It said whether a
 // document should be pinned into a context, be found by relevance, or be named explicitly — an
 // instruction to a retrieval Intel does not perform. Intel hands out references and the agent
@@ -268,469 +265,6 @@ export const RedefineTableInput = z.strictObject({
     }, { error: "A current column can fill only one new column" }),
     idempotencyKey: z.string().min(8).max(200),
 });
-// ── The board (#285) ─────────────────────────────────────────────────────────────────────────────
-//
-// A board's body is a whole project board — the status list and every task — stored as one
-// validated JSON version in R2, exactly the way an agent's definition is. It is a kind of node and
-// not a kind of thing (see `NodeKind`): it hangs in a folder, inherits that folder's grants, has
-// versions and is exported like everything else. Its own media type exists so a reader can tell a
-// board from prose without parsing it.
-export const BoardMediaType = "application/vnd.anchrd.board+json";
-// ⚠️ `archived` belongs to EVERY status list and cannot be configured away (#285). It is the shelf
-// tasks are swept onto, so that being finished with a task never has to mean deleting it — and
-// getting one back is an explicit move to another status, never an undelete.
-export const ArchivedBoardStatusId = "archived";
-// A status id is referenced by every task that sits in that column, so it is machine-shaped and
-// bounded rather than free text. Renaming a column changes its LABEL; the id stays, and no task has
-// to be rewritten to follow it.
-export const BoardStatusId = z.string().regex(/^[a-z0-9][a-z0-9_]{0,39}$/);
-export const BoardStatus = z.strictObject({
-    id: BoardStatusId,
-    label: z.string().trim().min(1).max(60),
-    // ⚠️ Server-assigned from the position in `ConfigureBoardInput.statuses`, never sent. Two columns
-    // both claiming position 3 is a board no surface could draw, and it is a state nobody has to be
-    // able to reason about if it cannot be expressed.
-    order: z.number().int().nonnegative(),
-    /**
-     * Whether standing in this column means the work is finished (anchrd/intel#311).
-     *
-     * It answers the one question #285 left open — when a `dependsOn` is satisfied — and it is the
-     * ONLY answer to it. There is deliberately no second reading anywhere: a surface that decided
-     * "done" for itself would decide it differently the first time somebody reconfigured a board.
-     *
-     * ⚠️ It is a property of the status, not a position in the list, and that distinction is the
-     * whole ticket. #286 first read "the last column before `archived`" as done, reasoning by symmetry
-     * with the server's rule that a new task lands in the first column that is not `archived`. But a
-     * status list is configurable on purpose, so `… done → blocked → archived` makes "blocked" mean
-     * finished — silently, with a wrong blocked marker as the only symptom.
-     *
-     * ⚠️ Several columns may carry it. "Done" and a cancelled-like column are both ends of the work,
-     * and nothing waiting on a cancelled task is still blocked by it.
-     */
-    terminal: z.boolean(),
-});
-// What a board starts out with. Five columns, of which the last one is the fixed `archived` shelf.
-// `done` and the shelf are where work ends; the three before them are not (anchrd/intel#311).
-export const BoardDefaultStatuses = [
-    { id: "backlog", label: "Backlog", order: 0, terminal: false },
-    { id: "in_progress", label: "In progress", order: 1, terminal: false },
-    { id: "review", label: "Review", order: 2, terminal: false },
-    { id: "done", label: "Done", order: 3, terminal: true },
-    { id: ArchivedBoardStatusId, label: "Archived", order: 4, terminal: true },
-];
-/**
- * Who a task is on: a person Gate knows, or an agent node in this installation (#285).
- *
- * ⚠️ A `user` id is deliberately NOT validated against Intel's own id shape. Identity is Gate's
- * (see the product boundary), so a rule here would be Intel inventing one about somebody else's
- * identifier — the same reason `GateApplicationId` is a plain bounded string.
- */
-export const BoardAssignee = z.discriminatedUnion("type", [
-    z.strictObject({ type: z.literal("user"), id: z.string().min(1).max(255) }),
-    z.strictObject({ type: z.literal("agent"), nodeId: IntelId }),
-]);
-/**
- * A task's place among the others, as a fractional index (#285).
- *
- * ⚠️ Server-assigned, and a caller can never send one. A move names its NEIGHBOURS and the server
- * mints a key between theirs, so moving one task writes one task and renumbers nothing — the whole
- * reason a board is not addressed by position the way a table's rows are (`TableRowPosition`).
- * A hand-written key could collide, and two tasks sharing a key have no defined order at all.
- *
- * ⚠️ This CHARACTER CLASS is the truth about a stored key, not `fractional-indexing`, and the two
- * are deliberately not the same set (anchrd/intel#359). A board that arrived through a bundle may
- * spell `"0"`, `"a00"`, `"zzz"` or `"A"` — all of them legal here, none of them readable by that
- * library. Narrowing the regex to what it reads would be a rule on the STORED document, so a board
- * carrying one would stop parsing in all four places a board body is read (the board read, the
- * indexer, the link reader, the bundle import) — unreadable, unsearchable and unmovable at once,
- * over a value its owner never wrote. That is the trap #311, #318 and #321 each walked into from a
- * different side.
- *
- * ⚠️ What every consumer may therefore rely on is exactly what stands here: keys are non-empty
- * strings over `[0-9A-Za-z]` and are ORDERED BY STRING COMPARISON. Nothing may assume more — and
- * `packages/api`'s `orderBetween` is the one place that asks `fractional-indexing` for a key and
- * carries on without it when it refuses a bound.
- */
-// ⚠️ Named because a consumer has to be able to stay inside it. The repair of a repeated task id
-// (anchrd/intel#341) mints a key beside an existing one, and a key one character too long would be
-// written and then refused by the very next read — the whole board lost over a repair.
-export const MaxBoardTaskOrderLength = 64;
-export const BoardTaskOrder = z
-    .string()
-    .regex(new RegExp(`^[0-9A-Za-z]{1,${MaxBoardTaskOrderLength}}$`));
-export const BoardTaskId = IntelId;
-export const BoardTaskLabel = z.string().trim().min(1).max(60);
-// A day, not an instant. A task is due on a date; giving it a time zone would make the same task
-// due on two different days depending on who is looking at it.
-export const BoardTaskDate = z.iso.date();
-// Markdown, and capped: a task's description is a card, and what needs more than this is a document
-// the task can point at through `references`.
-export const BoardTaskDescription = z.string().max(20_000);
-/**
- * The tasks one task waits for (#285), each of them at most once (anchrd/intel#318).
- *
- * ⚠️ Board-internal only, enforced on the write path: a dependency on a task in another board would
- * hang this node on a file that can change without anyone here noticing. Across boards the link is
- * `references`, which points at the board NODE and lands in the link graph.
- *
- * ⚠️ Refused rather than folded together, the same shape as the status ids in `ConfigureBoardInput`.
- * A repeat carries no information — but that is a fact about the value, not about the answer: a
- * caller handed back a shorter list than it sent is told nothing, and composes the same one again.
- * The refusal names the mistake once, and the caller is holding the list it has to fix. (The one
- * place a repeat is folded instead is `upgradeStoredBoard`, where there is no caller to tell.)
- *
- * ⚠️ It sits on the STORED task as well as on the two inputs, so a consumer may rely on it rather
- * than defend against it — `createBoardGraph` mints one edge key per pair, and a second one threw
- * the whole graph view off the screen for everybody looking at that board.
- */
-export const BoardTaskDependsOn = z
-    .array(BoardTaskId)
-    .max(64)
-    .refine((ids) => new Set(ids).size === ids.length, {
-    error: "A task can be named only once in dependsOn",
-});
-/**
- * A task's labels, each of them at most once (anchrd/intel#318).
- *
- * ⚠️ The same rule the detail panel has always applied to what a person types — it refuses to add a
- * label the task already carries — stated where every surface meets it, because the MCP write path
- * did not. A repeated label draws the same chip twice on the card, with two remove buttons of which
- * either takes both away, and weights that word higher in the search text (`indexing.ts`).
- */
-export const BoardTaskLabels = z
-    .array(BoardTaskLabel)
-    .max(32)
-    .refine((labels) => new Set(labels).size === labels.length, {
-    error: "A label can be named only once",
-});
-/**
- * The Intel nodes a task points at, each of them at most once (anchrd/intel#318).
- *
- * They land in the link graph as `text` links, the same way a document's inline links do, so what a
- * board points at is visible from the other side too.
- *
- * ⚠️ Distinct for the same reason as `labels`: the picker in the detail panel already refuses one
- * the task holds, and the link graph counts a repeat once anyway (`ON CONFLICT DO NOTHING`), so a
- * duplicate is a second row in the panel and nothing else — which is exactly the kind of value that
- * has no reading and should not be storable.
- */
-export const BoardTaskReferences = z
-    .array(IntelId)
-    .max(64)
-    .refine((ids) => new Set(ids).size === ids.length, {
-    error: "A node can be referenced only once",
-});
-export const BoardTask = z.strictObject({
-    id: BoardTaskId,
-    title: z.string().trim().min(1).max(240),
-    status: BoardStatusId,
-    assignee: BoardAssignee.nullable(),
-    labels: BoardTaskLabels,
-    startDate: BoardTaskDate.nullable(),
-    dueDate: BoardTaskDate.nullable(),
-    // ⚠️ The whole hierarchy in one field, deliberately: epic, task and subtask are a DEPTH and not a
-    // type (#285). A `kind` beside it would allow a subtask under nothing and an epic under an epic,
-    // and every surface would then need its own opinion about which combinations mean anything.
-    parentId: BoardTaskId.nullable(),
-    dependsOn: BoardTaskDependsOn,
-    order: BoardTaskOrder,
-    description: BoardTaskDescription,
-    references: BoardTaskReferences,
-});
-// The whole board, as it is stored and as it is read. There is no second representation to keep in
-// step with it — this document is the file.
-export const BoardDocument = z.strictObject({
-    statuses: z.array(BoardStatus).min(1).max(32),
-    tasks: z.array(BoardTask).max(5_000),
-});
-// How deep `parentId` may nest. Five is epic → task → subtask with room left over; without a bound
-// a chain of a thousand tasks would be a valid board that no view can draw and no walk can afford.
-export const BoardMaxTaskDepth = 5;
-export const GetBoardInput = z.strictObject({ nodeId: IntelId });
-// A board as it is read. `versionId` is `null` while nothing has been written yet — the same answer
-// a table gives before its header exists — and the document is then the defaults.
-export const NodeBoard = z.strictObject({
-    node: Node,
-    board: BoardDocument,
-    versionId: IntelId.nullable(),
-});
-export const BoardStatusInput = z.strictObject({
-    id: BoardStatusId,
-    label: z.string().trim().min(1).max(60),
-    /**
-     * Whether this column means finished (anchrd/intel#311).
-     *
-     * ⚠️ Optional, and the absence is not the same as `false`. A caller who says nothing gets the
-     * server's answer — `false` for an ordinary column, `true` for the shelf, which cannot be
-     * anything else. Making it a required boolean would force every caller that only wanted to rename
-     * a column to restate the whole board's notion of done, and getting one entry wrong there is a
-     * silent change to what counts as blocked.
-     */
-    terminal: z.boolean().optional(),
-});
-// The status list, written whole and in the order it should be drawn — never a patch. Adding,
-// renaming and reordering are all this one call, and `archived` has to be in what it is given.
-export const ConfigureBoardInput = z.strictObject({
-    nodeId: IntelId,
-    statuses: z
-        .array(BoardStatusInput)
-        .min(1)
-        .max(32)
-        .refine((statuses) => new Set(statuses.map((status) => status.id)).size === statuses.length, {
-        error: "Status ids must be distinct",
-    })
-        .refine((statuses) => statuses.some((status) => status.id === ArchivedBoardStatusId), {
-        error: `The "${ArchivedBoardStatusId}" status cannot be removed`,
-    })
-        // ⚠️ Refused rather than corrected, the same way removing the shelf is refused. A task swept
-        // onto `archived` is finished with, and a board that could declare the shelf non-terminal would
-        // hold every archived task open as a blocker forever. Only an EXPLICIT `false` is refused —
-        // saying nothing is fine and means the server's `true` (anchrd/intel#311).
-        .refine((statuses) => statuses.find((status) => status.id === ArchivedBoardStatusId)?.terminal !== false, { error: `The "${ArchivedBoardStatusId}" status is always terminal` }),
-    idempotencyKey: z.string().min(8).max(200),
-});
-/**
- * A new task (#285).
- *
- * ⚠️ No `baseVersionId`, on this and on every other task operation, and that absence is the
- * feature. A board is addressed by stable task id and never by position, so two agents touching two
- * different tasks cannot collide — demanding a base version would invent the `version_conflict`
- * that #285 exists to remove, and force every caller to read the whole board first.
- */
-export const AddBoardTaskInput = z.strictObject({
-    nodeId: IntelId,
-    title: z.string().trim().min(1).max(240),
-    // Omitted means the first status that is not `archived`: a new task belongs on the board, not on
-    // the shelf.
-    status: BoardStatusId.optional(),
-    assignee: BoardAssignee.nullable().default(null),
-    labels: BoardTaskLabels.default([]),
-    startDate: BoardTaskDate.nullable().default(null),
-    dueDate: BoardTaskDate.nullable().default(null),
-    parentId: BoardTaskId.nullable().default(null),
-    dependsOn: BoardTaskDependsOn.default([]),
-    description: BoardTaskDescription.default(""),
-    references: BoardTaskReferences.default([]),
-    // Where among its neighbours it goes. Both absent puts it last in its column.
-    afterTaskId: BoardTaskId.nullable().default(null),
-    beforeTaskId: BoardTaskId.nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-});
-/**
- * What a task says about itself.
- *
- * ⚠️ Deliberately no `status`, no `parentId` and no `order`: where a task SITS is a move, and a
- * move is the operation that has to mint an order key and re-check the two cycle rules. Folding
- * both into one call would mean every field edit pays for those checks and every move could quietly
- * rewrite a description.
- */
-export const UpdateBoardTaskInput = z
-    .strictObject({
-    nodeId: IntelId,
-    taskId: BoardTaskId,
-    title: z.string().trim().min(1).max(240).optional(),
-    assignee: BoardAssignee.nullable().optional(),
-    labels: BoardTaskLabels.optional(),
-    startDate: BoardTaskDate.nullable().optional(),
-    dueDate: BoardTaskDate.nullable().optional(),
-    dependsOn: BoardTaskDependsOn.optional(),
-    description: BoardTaskDescription.optional(),
-    references: BoardTaskReferences.optional(),
-    idempotencyKey: z.string().min(8).max(200),
-})
-    .refine((input) => input.title !== undefined ||
-    input.assignee !== undefined ||
-    input.labels !== undefined ||
-    input.startDate !== undefined ||
-    input.dueDate !== undefined ||
-    input.dependsOn !== undefined ||
-    input.description !== undefined ||
-    input.references !== undefined, { error: "At least one change is required" });
-// Where a task sits: its column, its parent, its place among its neighbours. Archiving is this call
-// with `status: "archived"` — there is no separate verb, because it is not a separate act.
-export const MoveBoardTaskInput = z
-    .strictObject({
-    nodeId: IntelId,
-    taskId: BoardTaskId,
-    status: BoardStatusId.optional(),
-    parentId: BoardTaskId.nullable().optional(),
-    afterTaskId: BoardTaskId.nullable().default(null),
-    beforeTaskId: BoardTaskId.nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-})
-    .refine((input) => input.status !== undefined ||
-    input.parentId !== undefined ||
-    input.afterTaskId !== null ||
-    input.beforeTaskId !== null, { error: "A move needs a status, a parent or a neighbour" });
-// ⚠️ Deleting cascades to every descendant, and the count comes back so a surface can warn BEFORE
-// asking. See `DeleteBoardTaskResult`.
-export const DeleteBoardTaskInput = z.strictObject({
-    nodeId: IntelId,
-    taskId: BoardTaskId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-/**
- * The way out of a board whose `tasks[]` names one id twice (anchrd/intel#341).
- *
- * ⚠️ It names no task, and that is not an oversight. Such a board holds a pair the caller cannot
- * tell apart — every other operation here addresses a task BY id (#285), so the one thing nobody
- * can say is "the second of the two". The board is what is named, and the server does the one thing
- * that removes the ambiguity: the first entry under an id keeps it, every later one gets a freshly
- * minted id and keeps everything else it carries.
- *
- * ⚠️ It exists because the pair is deliberately NOT folded away on read (`upgradeStoredBoard`,
- * `repeatedBoardId`): two tasks under one id are two whole tasks, and a fold on the read is written
- * back by the next save of any kind. So somebody has to ask for the repair, and this is the asking.
- */
-export const RepairBoardTaskIdsInput = z.strictObject({
-    nodeId: IntelId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-// The one task that was written, not the whole board: a board can hold thousands of tasks, and
-// answering a one-card edit with all of them would make every write pay for the read.
-export const BoardTaskResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    task: BoardTask,
-});
-// `deleted` counts the task AND every descendant that went with it, so a caller can say what
-// happened rather than "done".
-export const DeleteBoardTaskResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    deleted: z.number().int().positive(),
-});
-export const ConfigureBoardResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    statuses: z.array(BoardStatus),
-});
-/**
- * What the repair did, task by task (anchrd/intel#341).
- *
- * ⚠️ `previousId` is the id the entry shared, and it still names a task on this board — the FIRST
- * entry under it, the one that kept it. That is what makes the repair readable: nothing that
- * pointed at that id moved, so a caller can see which of the two the board's `parentId` and
- * `dependsOn` edges have been meaning all along, and move them with `board_task_move` and
- * `board_task_update` if they meant the other one.
- *
- * ⚠️ At least one entry, because a board with nothing to repair is refused rather than answered
- * with an empty list and a new version that changed nothing.
- */
-export const RepairBoardTaskIdsResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    renumbered: z
-        .array(z.strictObject({ previousId: BoardTaskId, task: BoardTask }))
-        .min(1)
-        .max(5_000),
-});
-// ── The agent definition (#139, ADR-0005 §4) ─────────────────────────────────────────────────────
-//
-// An agent's body is a definition, stored as an immutable version in R2 exactly like a document's.
-// Its own media type exists so a reader can tell a definition from prose without parsing it.
-export const AgentMediaType = "application/vnd.anchrd.agent+json";
-// ⚠️ The role lives on the AGENT, never on the node it names, and that is the whole difference to
-// the removed `context_policy` (ADR-0005 §2, #76). The same folder can be the system message for
-// one agent and nothing but search space for another; a node has no opinion about how it is used.
-// Any future field on a node saying how it should be loaded is `context_policy` under a new name.
-//
-//   system-message    prepended verbatim by the runtime
-//   semantic-context  search space; the agent searches it when it decides to
-//   memory            write target — ordinary Knowledge, versioned and readable like everything else
-export const AgentReferenceRole = z.enum(["system-message", "semantic-context", "memory"]);
-export const AgentReference = z.strictObject({ nodeId: IntelId, role: AgentReferenceRole });
-/**
- * Which kinds of node each role can actually be given (#255).
- *
- * ⚠️ Not every role takes every kind, and the reasons are about what the runtime DOES with a
- * reference rather than about tidiness:
- *
- *   `memory` is a folder because the agent WRITES there — `agent_remember` creates a note inside
- *   it. A single document as memory would mean the agent overwrites the document it was given.
- *
- *   `semantic-context` is a folder because it is a search SPACE, searched per folder by
- *   `loop/scoped-search`. A single document is not a narrower search space; reading it whole is a
- *   different behaviour, and one that gets named before it is introduced, not slipped in.
- *
- *   `system-message` reads single nodes already and takes a document or a table as well as a
- *   folder. A document is the natural case — a skill somebody wrote as ordinary text — and a table
- *   is the same read: the runtime asks intel for the node and prepends its content, which for a
- *   table is its CSV.
- *
- * ⚠️ `folder` stays on `system-message` although a folder carries no content of its own. Every
- * definition written before #255 could only name folders, and taking the combination away here
- * would refuse the next save of an agent that has been working for months — "existing definitions
- * stay valid" is not only about reading them.
- *
- * ⚠️ This is the ONE place the rule lives. The screen offers what it says and the write path
- * refuses what it forbids; a surface that made its own list would eventually disagree with the
- * other, and the one that matters is whichever runs last.
- */
-export const AgentReferenceKinds = {
-    "system-message": ["folder", "document", "table"],
-    "semantic-context": ["folder"],
-    memory: ["folder"],
-};
-export function agentReferenceAccepts(role, kind) {
-    return AgentReferenceKinds[role].includes(kind);
-}
-/** The roles a node of this kind may be given — the same rule, read from the other side. */
-export function agentReferenceRolesFor(kind) {
-    return AgentReferenceRole.options.filter((role) => agentReferenceAccepts(role, kind));
-}
-// A `document` target means the content of that document is the instruction — a "skill" somebody
-// wrote as ordinary text; a `flow` target means a run is started through Intel MCP and worked step
-// by step. Both are references, so nothing in here goes stale (ADR-0005 §4).
-//
-// ⚠️ Intel stores a schedule as a declared fact and never fires it. The alarm lives in the runtime
-// (ADR-0005 §3); Intel gains no scheduler, which is D24 confirmed rather than bent.
-export const AgentScheduleTarget = z.strictObject({
-    kind: z.enum(["document", "flow"]),
-    id: IntelId,
-});
-/**
- * ⚠️ `timezone` is what the cron expression is READ IN, and it belongs to the schedule rather than
- * to whoever is looking at it (#228). "Every morning at eight" means eight o'clock where the person
- * who wrote it sits — in Berlin that is 06:00 UTC in summer and 07:00 in winter, and a field that
- * does not carry the zone cannot express that difference. A UTC cron is an hour wrong twice a year
- * and nobody sees why.
- *
- * The UI suggests the reader's own zone when a schedule is created, but it is not a per-user
- * setting: an agent's schedule would otherwise move whenever its owner travelled, and it would mean
- * different times to two people reading the same definition. What is stored is the answer.
- *
- * ⚠️ The default is `"UTC"`, and it is load-bearing rather than tidy: every definition written
- * before this field parses to it and therefore keeps firing exactly when it did. A default of
- * "whatever the writer's browser says" would silently move every existing schedule at the next save.
- *
- * The name is validated against this runtime's own tz database rather than a pattern. A regular
- * expression would accept `Mars/Olympus`, and the failure would surface inside a Durable Object
- * alarm — the place where nobody is watching.
- */
-const IanaTimezone = z
-    .string()
-    .trim()
-    .min(1)
-    .max(64)
-    .refine((zone) => {
-    try {
-        new Intl.DateTimeFormat("en-US", { timeZone: zone });
-        return true;
-    }
-    catch {
-        return false;
-    }
-}, { message: "must be an IANA timezone name this runtime knows, for example Europe/Berlin" });
-export const AgentSchedule = z.strictObject({
-    cron: z.string().trim().min(1).max(120),
-    timezone: IanaTimezone.default("UTC"),
-    target: AgentScheduleTarget,
-});
-export const AgentModel = z.strictObject({
-    provider: z.enum(["workers-ai", "anthropic"]),
-    model: z.string().trim().min(1).max(120),
-});
 /**
  * One MCP server as the portal names it. The handle is what the portal puts in front of every tool
  * that server offers (`notion_notion-search` belongs to `notion`), and it is the only identifier
@@ -747,233 +281,6 @@ export const ToolServerHandle = z
     .min(1)
     .max(120)
     .regex(/^[A-Za-z0-9][A-Za-z0-9._-]*$/, "A server handle is the portal's own identifier");
-const ToolServerHandles = z.array(ToolServerHandle).max(32).default([]);
-/**
- * What a caller may ASK for: whole MCP servers, and nothing about who delegates them (D30).
- *
- * ⚠️ The absence of `delegatedBy` is the point, and it is why the write shape differs from the read
- * shape at all. Intel writes that field from the session it authorized; a caller who could name
- * somebody else would be handing an agent a portal connection they do not have, and the agent would
- * act on it unattended. Leaving the field out of the input makes that structural instead of a
- * runtime overwrite: a body carrying it is a parse error at the boundary, on every surface, and no
- * screen ever has to invent a value it has no business knowing.
- */
-export const AgentToolSelection = z.strictObject({ servers: ToolServerHandles });
-/**
- * What is STORED and read back: the selection plus whose portal connection it came from (D30).
- *
- * ⚠️ This is a selection, not a permission. Nothing here grants anything: whether a server is
- * reachable is still decided by one live `tools/list` with `delegatedBy`'s own portal token, so a
- * delegator who loses the server or the connection takes it away from the agent at the next run
- * with no edit to this document.
- *
- * ⚠️ Read shape only. It appears in `AgentDefinition` and never in an input — see
- * `AgentToolSelection` for why the two are deliberately different documents rather than one schema
- * with an optional field.
- */
-export const AgentToolDelegation = z.strictObject({
-    delegatedBy: IntelId,
-    servers: ToolServerHandles,
-});
-/**
- * ⚠️ No accounts, no secrets and no channels — and the reason is mechanical rather than tidy
- * (ADR-0005 §4): this body is read, shared, exported and put into model context, so a secret in it
- * is a secret in a citation. Identity is Gate's, accounts are the portal's, channels are runtime
- * configuration.
- *
- * ⚠️ `tools` is the one correction to that list (D30), and it is narrower than it looks. What is
- * stored is a **selection of whole servers plus who delegated them**, never a mirrored permission
- * and never a catalog: the catalog stays a live `tools/list` made with the delegator's token at the
- * moment the agent runs. ADR-0005 §4's "no tools in the definition" forbade the mirror, and the
- * mirror is still forbidden — a tool name, a schema or an account in here would be the thing that
- * line was written against.
- *
- * ⚠️ Strict on purpose, and deliberately stricter than the runtime's own reader
- * (`packages/agent/src/definition/definition.ts`, which is `z.object`). Intel is the writer: an
- * unknown field here is a caller's mistake and is refused at the boundary. The runtime is the
- * reader and released separately, so it must keep starting agents when Intel adds a field
- * tomorrow. The asymmetry is the point, not an oversight.
- */
-const AgentBody = {
-    references: z.array(AgentReference).max(200).default([]),
-    schedules: z.array(AgentSchedule).max(50).default([]),
-    model: AgentModel,
-};
-export const AgentDefinition = z.strictObject({
-    ...AgentBody,
-    // `null` is "this agent has no tools", and it is also what every definition written before D30
-    // parses to. An empty `servers` list means the same thing and is kept as its own state so
-    // removing the last server does not have to erase who was delegating.
-    tools: AgentToolDelegation.nullable().default(null),
-});
-/**
- * The same document as `AgentDefinition`, minus the one field a caller may not write.
- *
- * ⚠️ Two schemas rather than one, and the split is load-bearing (#208, D30). Everything an agent IS
- * comes from whoever edits it; **whose portal connection it acts on** does not, because that is an
- * authority the editor would be granting to themselves. So the write shape simply has no place to
- * put it: `{ tools: { servers: [...] } }` is what a screen or an MCP client sends, Intel adds
- * `delegatedBy` from the session, and a body that tries to name one is refused by the strict object
- * before any of it is read. The reading shape keeps the field because a reader must be able to see
- * whose connection an agent runs on.
- */
-export const AgentDefinitionInput = z.strictObject({
-    ...AgentBody,
-    tools: AgentToolSelection.nullable().default(null),
-});
-export const SaveAgentDefinitionInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId.nullable(),
-    definition: AgentDefinitionInput,
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const GetAgentInput = z.strictObject({ nodeId: IntelId });
-// Switching an agent off and on again, and starting one run by hand. All three name only the agent
-// and — for a run — which of the targets it already schedules.
-//
-// ⚠️ Intel holds none of this. Whether an agent is paused is state of its Durable Object, not a
-// field of the definition: a definition is versioned, shared and read into model context (ADR-0005
-// §4), so every pause would otherwise be a new version and would tell the agent it is switched off.
-// These inputs are what Intel accepts and passes on, nothing that Intel stores.
-export const PauseAgentInput = z.strictObject({ nodeId: IntelId });
-export const RunAgentNowInput = z.strictObject({
-    nodeId: IntelId,
-    target: AgentScheduleTarget,
-});
-/**
- * What one agent has actually cost, read out of Cloudflare's AI Gateway log (#251).
- *
- * ⚠️ Intel computes none of this from tokens and a price table. The gateway publishes the billed
- * figure per call, and that figure is the debit from the Cloudflare balance 1:1 — Cloudflare takes
- * its 5 % when the balance is loaded and passes inference through unchanged (measured 2026-08-07).
- * A second, self-maintained answer beside it would be wrong on the day the two disagreed, and the
- * wrong one would be the one on screen.
- *
- * ⚠️ `status` travels with the numbers and may never be dropped. `runs: []` means "cost nothing"
- * only when `status` is `read`; under `not_configured` or `unreadable` it means "not known", and a
- * screen that renders the two alike reports an outage as a saving.
- */
-export const AgentCostStatus = z.enum(["read", "not_configured", "unreadable"]);
-export const AgentRunCost = z.strictObject({
-    runId: z.string(),
-    cost: z.number(),
-    calls: z.number(),
-});
-export const AgentCostWindow = z.strictObject({
-    days: z.number(),
-    cost: z.number(),
-    calls: z.number(),
-    // Which models produced this figure. It is here so the model select can say the number is about
-    // the PAST (#257) — a reader who switched model would otherwise take it for a forecast.
-    models: z.array(z.string()),
-});
-export const AgentCosts = z.strictObject({
-    status: AgentCostStatus,
-    currency: z.literal("USD"),
-    runs: z.array(AgentRunCost),
-    windows: z.array(AgentCostWindow),
-    // The read hit its page limit, so every total above is a floor rather than a total.
-    partial: z.boolean(),
-});
-/**
- * What the models on offer cost and how much they hold (#257).
- *
- * ⚠️ `source` is per ENTRY and not per response, and that is not over-engineering. Cloudflare
- * publishes figures for the models it serves itself and none at all for the Anthropic models it
- * resells through Unified Billing — so a perfectly healthy read still leaves half the list on a
- * written-out table, and one flag for the whole answer would call either the read stale or the
- * table live.
- */
-export const ModelPrice = z.strictObject({
-    inputPerMillion: z.number(),
-    outputPerMillion: z.number(),
-});
-export const ModelCatalogEntry = z.strictObject({
-    provider: z.enum(["workers-ai", "anthropic"]),
-    model: z.string(),
-    name: z.string(),
-    contextTokens: z.number().nullable(),
-    // `null` where this installation has no figure. Never zero and never a guess — an invented number
-    // is a false statement about money.
-    price: ModelPrice.nullable(),
-    source: z.enum(["cloudflare", "builtin"]),
-});
-export const ModelCatalog = z.strictObject({
-    entries: z.array(ModelCatalogEntry),
-    liveStatus: z.enum(["read", "not_configured", "unreadable"]),
-});
-// ⚠️ Three states, not two, and the same three the flow list makes: omitted is the whole tree,
-// `null` is the root level, an ID is that folder. "Which agents may I use" is a question about the
-// tree rather than about one folder, so the useful answer has to be reachable without knowing where
-// somebody filed them.
-export const ListAgentsInput = z.strictObject({
-    parentId: IntelId.nullable().optional(),
-    includeArchived: z.boolean().default(false),
-});
-export const CreateAgentInput = z.strictObject({
-    parentId: IntelId.nullable().default(null),
-    title: z.string().trim().min(1).max(240),
-    description: z.string().trim().max(2_000).nullable().default(null),
-    definition: AgentDefinitionInput,
-    idempotencyKey: z.string().min(8).max(200),
-});
-// The ID of the Gate Application an agent runs as. Deliberately NOT an `IntelId`: it is Better
-// Auth's user ID, minted in Gate and only ever handed back to Gate, so validating it against
-// Intel's own ID shape would be Intel inventing a rule about somebody else's identifier.
-export const GateApplicationId = z.string().min(1).max(255);
-// The definition is `null` exactly while the node exists and no version has been written yet — the
-// same window in which a document's content is `null`.
-//
-// ⚠️ `applicationId` names the machine principal, it does not authenticate it (#182, D27). That is
-// why the ID may be stored, listed and drawn while the key may not: one is a name, the other is the
-// credential, and Gate hands the credential out exactly once and keeps only its hash. `null` means
-// this agent has no Application — an agent node written before #182, restored from a bundle, or
-// imported from another installation. Such an agent is not switched with its node, and giving it a
-// principal is an operator's act in Gate.
-export const NodeAgent = z.strictObject({
-    node: Node,
-    version: NodeVersion.nullable(),
-    definition: AgentDefinition.nullable(),
-    applicationId: GateApplicationId.nullable(),
-});
-/**
- * ⚠️ There is NO key field in this file, and adding one back would be the regression (D29, #207).
- *
- * Until #207 the create answer carried the Application key in plain text, once, and a person had to
- * carry it into a Worker secret by hand — which is why an agent created through the screen could
- * never run (#200). The key now goes from Gate straight into the agent runtime over Intel's service
- * binding and is encrypted into that agent's Durable Object; it reaches no browser, no MCP tool
- * result and no response body at all. `NodeAgent` is a `z.strictObject`, so a field named `key`
- * added anywhere in this file is a parse error at the boundary rather than a leak somebody has to
- * spot in review.
- *
- * What `POST /nodes/agents` and `agent_create` answer is therefore exactly what every read answers:
- * the node, its first definition, and the `applicationId` that NAMES the principal without
- * authenticating it.
- */
-export const CreatedAgent = NodeAgent;
-// Which agent's key is being replaced. `nodeId` and not the Application ID: this addresses an agent
-// in Intel's tree, and the Application behind it is Intel's to look up — a caller naming the
-// principal directly would be rotating a key for an agent nobody checked they may edit.
-export const RotateAgentKeyInput = z.strictObject({ nodeId: IntelId });
-/**
- * What replacing an agent's key answers.
- *
- * ⚠️ No key, and that is the whole shape of D29: Intel asks Gate for a new one, hands it to the
- * runtime over the service binding, and forgets it inside the same call. What the caller gets is
- * the fact that it happened, so a screen can say so — `applicationId` names the principal whose key
- * was replaced, which is a name and not a credential.
- */
-export const AgentKeyRotated = z.strictObject({
-    nodeId: IntelId,
-    applicationId: GateApplicationId,
-    rotatedAt: IsoDateTime,
-});
-export const AgentList = z.strictObject({ items: z.array(Node) });
-// ⚠️ Kept for what is already stored, not for what is written. Relations were picked in a dialog
-// until #41; a link is now made where it is meant — in the text — and every link written from now
-// on is a `references`. Rewriting the old rows would destroy a distinction somebody chose on
-// purpose, and dropping the column would destroy it with them, so both stay readable.
 export const NodeLinkRelation = z.enum(["references", "related", "depends_on", "implements"]);
 // Where the link came from. `text` links are derived from a document's content and are rewritten
 // whenever it is saved; `manual` links were made in the dialog #41 removed and are now history.
@@ -1588,15 +895,7 @@ export const FlowPublishPreview = z.strictObject({
 // What accesses what, for one level of the shared tree (#19). A folder answers it for its contents,
 // a single flow for itself. Documents and flows are two kinds of thing that share one tree
 // (ADR-0004 §1), so the graph carries both and says which of them it is.
-export const RelationNodeKind = z.enum([
-    "folder",
-    "document",
-    "attachment",
-    "table",
-    "agent",
-    "board",
-    "flow",
-]);
+export const RelationNodeKind = z.enum(["folder", "document", "attachment", "table", "flow"]);
 export const RelationNode = z.strictObject({
     id: IntelId,
     kind: RelationNodeKind,
@@ -1779,8 +1078,20 @@ export const FlowRunHistory = z.strictObject({
 // The one name the importer looks for at the zip root. A different spelling would make a bundle a
 // naked folder, so the constant lives in the contract rather than in each surface.
 export const BundleManifestFilename = "manifest.json";
-// What a bundle entry can be. `flow` joins the six node kinds because a flow shares the folder
-// tree without being a node (ADR-0004), and the bundle mirrors the tree, not the tables.
+/**
+ * What a bundle entry can be. `flow` joins the node kinds because a flow shares the folder tree
+ * without being a node (ADR-0004), and the bundle mirrors the tree, not the tables.
+ *
+ * ⚠️ `agent` and `board` are STILL HERE, and that is the one place in this file where a value
+ * survives its feature (#390). A bundle is somebody else's file: an export written before Agents
+ * and Board were parked (#385) is a correct export, and it has to PARSE so the import can refuse it
+ * by name — with the entry, the kind and the branch the code is on. Take them out and the same
+ * bundle fails as `unexpected enum value`, which sends its holder looking for a broken file that is
+ * not broken.
+ *
+ * They belong to the wire format of a file that already exists, not to the product. Nothing may
+ * create either kind; `NodeKind` is the enum that says so.
+ */
 export const BundleEntryKind = z.enum([
     "folder",
     "document",