@anchrd/intel-contract 0.12.0 → 0.14.0

package/dist/contract/contract.js

@@ -1,6 +1,18 @@
 import { z } from "zod";
 export const IntelId = z.string().min(1).max(128);
 export const IsoDateTime = z.iso.datetime({ offset: true });
+// ⚠️ One described primitive rather than the same sentence on twenty-odd fields (#398). The word
+// `idempotencyKey` means exactly the same thing everywhere it appears, and a reader who learns it
+// once at `node_create` should not have to re-read it at `flow_publish`. Twenty copies of one
+// sentence is also twenty places for it to drift, and `tools/list` would carry every copy.
+//
+// The description says what the caller has to DO, because that is the part a model gets wrong: it
+// invents a fresh key on the retry and creates the thing twice.
+export const IdempotencyKey = z
+    .string()
+    .min(8)
+    .max(200)
+    .describe("A caller-chosen key that makes this call safe to retry: repeating the same key returns the first result instead of doing the work twice. Reuse the SAME key when retrying one attempt, and a new one for a genuinely new call.");
 // The languages whose UI catalog ships inside intel-ui. They live here rather than only in the UI
 // because `intel build` has to know them: a built-in language may be chosen as `ui.defaultLanguage`
 // without the customer listing a copy under `ui.languages` that would rot at every UI update.
@@ -17,1810 +29,25 @@ export const ProblemDetails = z.strictObject({
     instance: z.string().optional(),
     code: z.string().optional(),
 });
-// Who the caller is, as Gate resolved it from the bearer. Deliberately identity only: no
-// capabilities, no token, nothing a surface could mistake for a permission.
+// Who the caller is, as Gate resolved it from the bearer: no token, and no capability list.
+//
+// ⚠️ `isAdmin` is the one exception, and it is a DRAWING instruction rather than a permission
+// (#416). MCP hides what a caller may not do by never registering the tool, so a model never sees a
+// door it cannot open; the browser has no equivalent and would have to offer an admin action to
+// everybody and answer with a 403. One boolean is what the shell needs to not do that.
+//
+// Two things keep it from becoming a capability list by degrees: it says what the shell may DRAW,
+// never what the server may do — every door still asks Gate itself — and it is one field with one
+// consumer. A second one is a second reason, written down when it exists.
 export const SessionUser = z.strictObject({
     id: IntelId,
     email: z.email(),
     name: z.string().min(1).max(240).nullable(),
+    isAdmin: z.boolean(),
 });
-// What this installation is equipped to do — deployment facts, never the caller's permissions
-// (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
-// (ADR-0004 §1, ADR-0005 §1). Only the media type and the operations below differ.
-//
-// ⚠️ `agent` being optional is load-bearing (ADR-0005 §1): an installation without a single agent
-// node is complete, not unfinished, and nothing here asks anyone to classify a document as a skill
-// 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"]);
-// ⚠️ 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
-// fetches what it needs (D24), so nothing here could ever have read it, and nothing did.
-//
-// Semantic search stays: as an MCP tool the agent calls, over everything or over one area.
-// One verb per grant, granted independently (ADR-0004 §2). Not a ladder: seeing a process must be
-// separable from being allowed to start it, and `execute` is meaningful only where a flow can live.
-export const ResourceVerb = z.enum(["read", "write", "execute", "share"]);
-export const SharePrincipal = z.discriminatedUnion("type", [
-    z.strictObject({ type: z.literal("user"), id: IntelId }),
-    z.strictObject({ type: z.literal("email"), email: z.email() }),
-    z.strictObject({ type: z.literal("organization") }),
-]);
-export const Node = z.strictObject({
-    id: IntelId,
-    parentId: IntelId.nullable(),
-    kind: NodeKind,
-    title: z.string().min(1).max(240),
-    description: z.string().max(2_000).nullable(),
-    ownerId: IntelId,
-    currentVersionId: IntelId.nullable(),
-    createdAt: IsoDateTime,
-    updatedAt: IsoDateTime,
-    archivedAt: IsoDateTime.nullable(),
-});
-// What one table version carries (#135). An `append` holds only the rows one write added; a
-// `snapshot` holds the complete table — header and every row — so reading starts at the newest
-// snapshot and everything before it is history rather than content. Defining a table writes the
-// first snapshot; updating, deleting, and redefining write the later ones. Documents and
-// attachments carry `null`: each of their versions is complete by construction, and the word would
-// say nothing about them.
-export const NodeVersionSegment = z.enum(["append", "snapshot"]);
-export const NodeVersion = z.strictObject({
-    id: IntelId,
-    nodeId: IntelId,
-    sequence: z.number().int().positive(),
-    contentKey: z.string().min(1),
-    mediaType: z.string().min(1).max(160),
-    contentHash: z.string().regex(/^[a-f0-9]{64}$/),
-    size: z.number().int().nonnegative(),
-    segment: NodeVersionSegment.nullable(),
-    createdBy: IntelId,
-    createdAt: IsoDateTime,
-});
-export const ListNodesInput = z.strictObject({
-    parentId: IntelId.nullable().default(null),
-    includeArchived: z.boolean().default(false),
-    // ⚠️ Overrides `parentId` rather than narrowing beside it: what is archived is asked for across
-    // the whole tree, because that is the only useful question. Somebody looking for what they threw
-    // away does not know which folder it was in — if they did, they would not be looking (#113).
-    // A separate flag rather than a third state on `includeArchived`, so no existing caller changes
-    // meaning — and `.optional()` rather than `.default(false)` for the same reason `ListFlowsInput`
-    // carries it that way: a default makes the field required in the PARSED type, and every existing
-    // caller would have to answer a question it is not asking.
-    archivedOnly: z.boolean().optional(),
-});
-export const GetNodeInput = z.strictObject({ nodeId: IntelId });
-// One pinned version of one node (#147). Both IDs, always: a version ID alone would let anyone
-// holding an ID read content whose node-level ACL they never passed, and a citation names both.
-export const GetNodeVersionInput = z.strictObject({ nodeId: IntelId, versionId: IntelId });
-export const ListGrantsInput = z.strictObject({ resourceId: IntelId });
-export const CreateNodeInput = z.strictObject({
-    parentId: IntelId.nullable().default(null),
-    kind: NodeKind,
-    title: z.string().trim().min(1).max(240),
-    description: z.string().trim().max(2_000).nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const SaveNodeVersionInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId.nullable(),
-    content: z.string().max(10_000_000),
-    mediaType: z.string().min(1).max(160).default("text/markdown"),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const SaveAttachmentInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId.nullable(),
-    contentBase64: z.string().min(1).max(20_000_000),
-    mediaType: z.string().min(1).max(160),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const UpdateNodeInput = z
-    .strictObject({
-    nodeId: IntelId,
-    baseUpdatedAt: IsoDateTime,
-    title: z.string().trim().min(1).max(240).optional(),
-    description: z.string().trim().max(2_000).nullable().optional(),
-    parentId: IntelId.nullable().optional(),
-    idempotencyKey: z.string().min(8).max(200),
-})
-    .refine((input) => input.title !== undefined || input.description !== undefined || input.parentId !== undefined, { message: "At least one change is required" });
-export const ArchiveNodeInput = z.strictObject({
-    nodeId: IntelId,
-    baseUpdatedAt: IsoDateTime,
-    archived: z.boolean(),
-    idempotencyKey: z.string().min(8).max(200),
-});
-// ⚠️ `withChildren` belongs to the LEVEL, not to the node (#59). Whether something has children
-// THIS reader may see is not a property of the thing — two readers get different answers. As a
-// field on the node, every other place that returns a node would have to compute it as well or
-// lie; as a list beside the entries it costs only the one answer that needs it.
-export const NodeList = z.strictObject({
-    items: z.array(Node),
-    withChildren: z.array(IntelId).default([]),
-});
-export const NodeVersionList = z.strictObject({ items: z.array(NodeVersion) });
-export const NodeDocument = z.strictObject({
-    node: Node,
-    version: NodeVersion.nullable(),
-    content: z.string().nullable(),
-});
-export const NodeAttachment = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    resourceUri: z.string().regex(/^intel:\/\/nodes\/[^/]+\/attachment$/),
-});
-// A table is CSV, and CSV is the whole format: it is what is stored, what is downloaded and what a
-// machine reads. There is no second representation to keep in step with it (#40).
-export const TableMediaType = "text/csv";
-// A column name is the contract between the table and everyone who appends to it, so it is trimmed,
-// non-empty and bounded like a title. Cells are not: a cell is text, and text is what CSV carries.
-export const TableColumn = z.string().trim().min(1).max(120);
-export const TableCell = z.string().max(4_000);
-export const TableRow = z.array(TableCell).min(1).max(64);
-// Writing the header, once. The columns are the contract (#40's comment), which is why this refuses
-// on a table that already has one: changing the header would silently reinterpret every row that
-// was appended under the old one.
-export const DefineTableInput = z.strictObject({
-    nodeId: IntelId,
-    columns: z
-        .array(TableColumn)
-        .min(1)
-        .max(64)
-        .refine((columns) => new Set(columns.map((column) => column.toLowerCase())).size === columns.length, { error: "Column names must be distinct" }),
-    idempotencyKey: z.string().min(8).max(200),
-});
-// ⚠️ No `baseVersionId`, and that absence is the feature. A document replaces its content and needs
-// to know which content it replaces; an append adds to the end and cannot collide with a second
-// append, so demanding a base version would invent a conflict that does not exist and force the
-// caller to read the whole table first — the exact cost #40 exists to remove.
-export const AppendTableRowsInput = z.strictObject({
-    nodeId: IntelId,
-    rows: z.array(TableRow).min(1).max(1_000),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const GetTableInput = z.strictObject({ nodeId: IntelId });
-// The table as a grid rather than as text: the server owns the one CSV reader, so no surface has to
-// grow a second one that would disagree with it about quoting.
-export const NodeTable = z.strictObject({
-    node: Node,
-    columns: z.array(z.string()),
-    rows: z.array(z.array(z.string())),
-    // The newest append, or `null` while the table has no header yet.
-    versionId: IntelId.nullable(),
-});
-export const AppendTableRowsResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    appended: z.number().int().positive(),
-});
-// A row's address is its position among the table's current rows, counted from zero and without the
-// header. Deliberately not an ID: rows carry no identity of their own (#135, and the same decision
-// the grid documents), so every mutation instead pins the state its positions refer to.
-export const TableRowPosition = z.number().int().nonnegative();
-const distinctPositions = { error: "Row positions must be distinct" };
-// Replacing rows in place (#135). `baseVersionId` is the version the caller read the positions
-// from — required, never nullable, because a position into a table one has not read is a guess.
-// A table that moved on since answers `version_conflict` rather than editing the wrong rows; that
-// is the same optimistic concurrency the document save uses, and the deliberate opposite of
-// `append`, which needs no base because it collides with nothing.
-export const UpdateTableRowsInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId,
-    updates: z
-        .array(z.strictObject({ position: TableRowPosition, row: TableRow }))
-        .min(1)
-        .max(1_000)
-        .refine((updates) => new Set(updates.map((update) => update.position)).size === updates.length, distinctPositions),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const UpdateTableRowsResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    updated: z.number().int().positive(),
-});
-export const DeleteTableRowsInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId,
-    positions: z
-        .array(TableRowPosition)
-        .min(1)
-        .max(1_000)
-        .refine((positions) => new Set(positions).size === positions.length, distinctPositions),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const DeleteTableRowsResult = z.strictObject({
-    node: Node,
-    version: NodeVersion,
-    deleted: z.number().int().positive(),
-});
-// One entry per column the table will have afterwards, in order. `source` names the current column
-// whose cells fill it; `null` adds an empty column, and a current column no entry names is removed
-// together with its cells. Renaming is naming a source under a new name.
-export const RedefineTableColumn = z.strictObject({
-    name: TableColumn,
-    source: TableColumn.nullable().default(null),
-});
-// Changing the header of a table that has one (#135). The mapping is explicit because it is the
-// whole difference to the blind re-definition `defineTable` keeps refusing: without it a new header
-// would silently reinterpret every stored row under names nobody matched to the old ones.
-export const RedefineTableInput = z.strictObject({
-    nodeId: IntelId,
-    baseVersionId: IntelId,
-    columns: z
-        .array(RedefineTableColumn)
-        .min(1)
-        .max(64)
-        .refine((columns) => new Set(columns.map((column) => column.name.toLowerCase())).size === columns.length, { error: "Column names must be distinct" })
-        .refine((columns) => {
-        const sources = columns.map((column) => column.source).filter((source) => source !== null);
-        return new Set(sources).size === sources.length;
-    }, { 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
- * Intel can both store and recognise again in a live `tools/list`.
- *
- * ⚠️ A handle is never invented from a tool name. Which servers exist is the portal's answer
- * (`portal_list_servers`), and the prefix is only used to attribute a tool to a server that answer
- * already named — see `packages/api/src/tools/tool-servers` for why splitting on the underscore
- * alone would be ambiguous.
- */
-export const ToolServerHandle = z
-    .string()
-    .trim()
-    .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.
-//
-// ⚠️ This is provenance, never a second sort of relationship. Nothing offers the reader a choice
-// between them, and nothing may start writing `manual` again — that would be the two ways of saying
-// one thing that #41 exists to end. It exists so that saving a document cannot delete a link
-// somebody made before there was another way to make one.
-export const NodeLinkOrigin = z.enum(["text", "manual"]);
-export const NodeLink = z.strictObject({
-    id: IntelId,
-    sourceNodeId: IntelId,
-    targetNodeId: IntelId,
-    relation: NodeLinkRelation,
-    origin: NodeLinkOrigin,
-    label: z.string().trim().min(1).max(120).nullable(),
-    createdBy: IntelId,
-    createdAt: IsoDateTime,
-});
-export const NodeLinkList = z.strictObject({ items: z.array(NodeLink) });
-// The inline element a document link is, inside a BlockNote document (#41).
-//
-// ⚠️ The ID and nothing else. No title and no path travel with it: a stored title would go stale
-// the moment the target is renamed, a stored path the moment it is moved — and either one would
-// put a name the reader may not see into a document they may.
-export const DocumentLinkInlineType = "documentLink";
-export const ResolveNodeLinksInput = z.strictObject({
-    nodeIds: z.array(IntelId).min(1).max(200),
-});
-export const ResolvedNodeLink = z.strictObject({
-    nodeId: IntelId,
-    title: z.string().min(1).max(240),
-});
-// ⚠️ Only what the asking reader may see is in here, and an unreachable target is simply absent —
-// never a row with an empty title, never a count, never a "restricted" marker. The list is what one
-// side of a document link is drawn from, and an entry that says "something is here" is exactly the
-// leak this schema has to make impossible to write by accident. Deleted and unreadable therefore
-// look identical from the outside, which is the point.
-export const ResolveNodeLinksResult = z.strictObject({
-    items: z.array(ResolvedNodeLink),
-});
-export const NodeGraphInput = z.strictObject({
-    limit: z.number().int().min(1).max(500).default(250),
-});
-export const NodeGraph = z.strictObject({
-    nodes: z.array(Node),
-    links: z.array(NodeLink),
-});
-export const BlockNoteMediaType = "application/vnd.anchrd.intel.blocknote+json";
-export const BlockNoteDocument = z.strictObject({
-    format: z.literal("blocknote"),
-    schemaVersion: z.literal(1),
-    blocks: z.array(z.record(z.string(), z.unknown())),
-    markdown: z.string(),
-});
-export const ResourceGrant = z.strictObject({
-    id: IntelId,
-    resourceId: IntelId,
-    principal: SharePrincipal,
-    verb: ResourceVerb,
-    expiresAt: IsoDateTime.nullable(),
-    createdBy: IntelId,
-    createdAt: IsoDateTime,
-});
-export const ShareInput = z.strictObject({
-    resourceId: IntelId,
-    principal: SharePrincipal,
-    verb: ResourceVerb,
-    expiresAt: IsoDateTime.nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const RevokeGrantInput = z.strictObject({
-    resourceId: IntelId,
-    grantId: IntelId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-// What a grant does not cover, reported to whoever just made it. A flow in the shared folder may
-// read a document outside it, and the run is re-authorized against the person running it — so the
-// grant can be complete and the flow still stop for them (ADR-0004 §4).
-//
-// ⚠️ `titles` holds only the documents the sharer may see; everything else is in `hidden` as a
-// number. A warning must not become a way of reading titles out of the tree.
-export const UnreadableNodes = z.strictObject({
-    titles: z.array(z.string().min(1).max(240)),
-    hidden: z.number().int().nonnegative(),
-});
-// The grant is in the answer, so the warning cannot be mistaken for a refusal: it is written first
-// and described afterwards. Blocking would force everyone who uses a central policy document to
-// duplicate it, which is the opposite of what one tree is for (ADR-0004 §4).
-export const ShareResult = z.strictObject({
-    grant: ResourceGrant,
-    unreadable: UnreadableNodes,
-});
-// `applicableVerbs` travels with the list because the answer is the business layer's, not the
-// screen's: a document has nothing to execute, so `execute` is not offered on one (ADR-0004 §2).
-export const ResourceGrantList = z.strictObject({
-    resourceId: IntelId,
-    applicableVerbs: z.array(ResourceVerb).min(1),
-    items: z.array(ResourceGrant),
-});
-// `scopeId` is a cut, never a grant (#126): it narrows an answer the actor is already entitled to
-// and can only ever remove rows. Without it the search stays global over everything visible, which
-// is why it is optional rather than nullable — an absent field and `null` would otherwise be two
-// spellings of the same request.
-export const SearchInput = z.strictObject({
-    query: z.string().trim().min(1).max(500),
-    limit: z.number().int().min(1).max(50).default(10),
-    scopeId: IntelId.optional().describe("Optional folder node id. When given, only nodes filed in that folder or beneath it are searched."),
-});
-export const NodeCitation = z.strictObject({
-    nodeId: IntelId,
-    versionId: IntelId,
-    title: z.string(),
-    passage: z.string(),
-    source: z.string(),
-    freshness: IsoDateTime,
-    score: z.number().min(0).max(1),
-    match: z.enum(["lexical", "semantic", "hybrid"]),
-});
-export const SearchResult = z.strictObject({
-    items: z.array(NodeCitation),
-});
-export const ReindexResult = z.strictObject({ queued: z.number().int().nonnegative() });
-export const RevokeGrantResult = z.strictObject({ revoked: z.boolean() });
-function isPrivateIpv4(hostname) {
-    const parts = hostname.split(".").map(Number);
-    if (parts.length !== 4 ||
-        parts.some((part) => !Number.isInteger(part) || part < 0 || part > 255)) {
-        return false;
-    }
-    const [first = 0, second = 0] = parts;
-    return (first === 0 ||
-        first === 10 ||
-        first === 127 ||
-        (first === 100 && second >= 64 && second <= 127) ||
-        (first === 169 && second === 254) ||
-        (first === 172 && second >= 16 && second <= 31) ||
-        (first === 192 && second === 168) ||
-        (first === 198 && (second === 18 || second === 19)) ||
-        first >= 224);
-}
-function normalizedHostname(url) {
-    return url.hostname.toLowerCase().replace(/^\[|\]$/g, "");
-}
-function isPublicToolHost(url) {
-    const hostname = normalizedHostname(url);
-    if (hostname === "localhost" || hostname === "127.0.0.1" || hostname === "::1") {
-        return url.protocol === "http:";
-    }
-    if (!hostname.includes(".") ||
-        hostname.endsWith(".local") ||
-        hostname.endsWith(".localhost") ||
-        hostname.endsWith(".internal") ||
-        isPrivateIpv4(hostname) ||
-        hostname.includes(":")) {
-        return false;
-    }
-    return url.protocol === "https:";
-}
-export const ToolSourceUrl = z.url().refine((value) => {
-    try {
-        const url = new URL(value);
-        return !url.username && !url.password && isPublicToolHost(url);
-    }
-    catch {
-        return false;
-    }
-}, "The portal must use an approved public HTTPS host without embedded credentials");
-// The portal namespaces every upstream tool, so the name alone identifies the target server. The
-// portal is still the one that resolves it and attaches the credentials — Intel never holds an
-// upstream credential. Since D30 Intel does read the namespace for one purpose: attributing a tool
-// to a server the portal's own `portal_list_servers` already named, so a delegation can be cut to
-// whole servers. That is attribution, not routing.
-export const ToolName = z.string().min(1).max(240);
-export const ToolAnnotations = z.strictObject({
-    title: z.string().max(240).optional(),
-    readOnlyHint: z.boolean().optional(),
-    destructiveHint: z.boolean().optional(),
-    idempotentHint: z.boolean().optional(),
-    openWorldHint: z.boolean().optional(),
-});
-export const ToolCapability = z.strictObject({
-    name: ToolName,
-    title: z.string().max(240).nullable(),
-    description: z.string().max(10_000).nullable(),
-    inputSchema: z.record(z.string(), z.unknown()),
-    outputSchema: z.record(z.string(), z.unknown()).nullable(),
-    annotations: ToolAnnotations,
-    fingerprint: z.string().regex(/^[a-f0-9]{64}$/),
-});
-// The catalog reflects one live tools/list for the requesting user. It is never stored as a
-// permission mirror, so there is no per-source state and no Intel-owned connection status.
-export const ToolCatalog = z.strictObject({
-    portalConnected: z.boolean(),
-    items: z.array(ToolCapability),
-    /**
-     * Which delegated servers actually contributed a tool to this catalog (#289).
-     *
-     * ⚠️ Present only where the attribution was actually made — a delegated caller whose catalog was
-     * read. It is absent for an ordinary user, and absent as well when the answer comes from one of
-     * the short paths that never reach the portal (nothing delegated, no portal sign-in, connection
-     * dropped). Absent therefore means "not stated", never "nothing arrived"; `[]` is the second one.
-     *
-     * That it is missing rather than empty on those paths is deliberate rather than half-finished:
-     * the attribution already happens for a delegation — `capabilities` has to make it to cut the
-     * list — so naming it costs nothing there, while computing the same thing for an ordinary user
-     * would mean a second portal request per call, for a question their screen does not ask.
-     *
-     * ⚠️ It is the answer to "what arrived", never to "what was granted". A server missing here has
-     * been switched off, revoked, or is failing right now; the delegation in the definition is
-     * unchanged. Reading it the other way round would turn an outage into a permission change.
-     */
-    reached: z.array(ToolServerHandle).optional(),
-});
-/**
- * One MCP server the asking user reaches right now, as the portal itself names it (D30).
- *
- * ⚠️ `toolCount` is a fact about this moment and this user, not a size. It exists so a picker can
- * say "9 tools" instead of showing a handle alone, and it must never be read as what an agent will
- * get: the delegated run asks the portal again, with the delegator's token.
- */
-export const ToolServer = z.strictObject({
-    handle: ToolServerHandle,
-    name: z.string().min(1).max(240),
-    toolCount: z.number().int().min(0),
-});
-// The same live-query rule as the tool catalog, one level up. `portalConnected: false` is the state
-// of somebody who has not signed into the portal yet, and it is not an error.
-export const ToolServerCatalog = z.strictObject({
-    portalConnected: z.boolean(),
-    items: z.array(ToolServer),
-});
-/**
- * Which of the named servers a tool belongs to, or `null` for none of them.
- *
- * ⚠️ THE TRAP: a tool name does not say where its server name ends.
- *
- * The portal writes `<server>_<tool>`, and both halves may contain underscores — `intel_flow_get`
- * reads equally well as server `intel` with tool `flow_get` and as a server called `intel_flow`
- * with tool `get`. Splitting on the first underscore is therefore a guess that is wrong the day
- * somebody adds a server whose name contains one, and on the API side being wrong means an agent
- * delegated server A quietly reaching server B.
- *
- * So the prefix is never split. It is only ever MATCHED against handles the portal itself named,
- * and the longest match wins: with `intel` and `intel_flow` both declared, `intel_flow_get` belongs
- * to `intel_flow`, which is the only reading in which both declarations stay true.
- *
- * ⚠️ This lives in the contract because HOW A NAME IS READ is a property of the wire, and both
- * surfaces read the same wire: `packages/api` cuts a delegation with it, `packages/ui` groups the
- * tools screen with it (#212). A second implementation in the browser would be the third answer to
- * one question — the underscore rule has already been answered differently in two places once
- * (#106, #107), and the copies disagreed. What deliberately stays OUT of here is everything about
- * reach: which handles are declared, which are enabled, which may be delegated and which one owns
- * the portal's own management tools are decisions with consequences, and they belong to
- * `packages/api/src/tools/tool-servers`. This function only reads a name.
- */
-export function serverOf(toolName, handles) {
-    let best = null;
-    for (const handle of handles) {
-        if (!toolName.startsWith(`${handle}_`))
-            continue;
-        if (best === null || handle.length > best.length)
-            best = handle;
-    }
-    return best;
-}
-export const TestToolInput = z.strictObject({
-    name: ToolName,
-    arguments: z.record(z.string(), z.unknown()).default({}),
-});
-export const ExecuteToolInput = TestToolInput;
-export const ToolTestResult = z.strictObject({
-    isError: z.boolean(),
-    content: z.array(z.unknown()),
-    structuredContent: z.unknown().optional(),
-});
-export const FlowNodeId = z.string().regex(/^[A-Za-z0-9][A-Za-z0-9_-]{0,99}$/);
-export const FlowPosition = z.strictObject({ x: z.number().finite(), y: z.number().finite() });
-// A node has a title and nothing else to write in prose (#39). A second free text beside it was
-// kept half up to date on both sides, and for an instruction the same sentence already belongs in
-// the instruction itself.
-const FlowNodeBase = {
-    id: FlowNodeId,
-    position: FlowPosition,
-    label: z.string().trim().min(1).max(160),
-};
-// Which version of the callee a sub-flow call takes (ADR-0004 §5). Three states rather than an
-// optional identifier, because the difference between them is a decision and has to be readable:
-//
-// - `latest`   the draft default. Nobody should have to version things while building, and
-//              publishing turns this into `pinned` — visibly, before the author publishes.
-// - `follows`  "always latest", chosen on purpose. The call rides along with the callee, so a
-//              change to the building block changes this flow too. Publishing leaves it alone.
-// - `pinned`   one immutable version, whatever is published elsewhere.
-//
-// ⚠️ Without the freeze a change to a building block would silently change the behavior of every
-// published flow using it, which contradicts the immutable versions and pinned schema fingerprints
-// Intel otherwise guarantees. That is why `latest` cannot survive publishing.
-export const SubflowVersionMode = z.enum(["latest", "follows", "pinned"]);
-export const SubflowVersion = z.discriminatedUnion("mode", [
-    z.strictObject({ mode: z.literal("latest") }),
-    z.strictObject({ mode: z.literal("follows") }),
-    z.strictObject({ mode: z.literal("pinned"), versionId: IntelId }),
-]);
-// The three layers a node can belong to (D25). Which one a kind is in decides what it may carry and
-// where it may sit, and both rules are enforced in `compileFlow` rather than only drawn in the
-// editor — a graph arrives over MCP as readily as from the canvas.
-//
-// ⚠️ A LINK never stands in the chain. It hangs off a step on a `context` edge, and that is the
-// distinction the graph has drawn since #37 without anyone enforcing it — which is exactly how a
-// start with an attachment once began its run at the attachment (the "flow edges only" comments in
-// `flows.ts`). Marker and step keep the chain; a link is what a step works with.
-export const FlowNodeLayer = z.enum(["marker", "step", "link"]);
-export const flowNodeLayer = {
-    trigger: "marker",
-    output: "marker",
-    instruction: "step",
-    condition: "step",
-    subflow: "step",
-    folder: "link",
-    document: "link",
-    upload: "link",
-    table: "link",
-    tool: "link",
-};
 // One reference, never a list. The old `knowledge` node carried up to a hundred, plus a retrieval
 // mode and a query that nothing read — three things in one, and the last two describing a retrieval
 // Intel does not perform (D24: the agent fetches, Intel does not put anything into a context).
 // Splitting by kind is what makes "exactly one" sayable at all, and it lets the editor filter the
 // picker by what the node is for.
-const LinkConfiguration = z.strictObject({ resourceId: IntelId });
-export const FlowNode = z.discriminatedUnion("kind", [
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("trigger"),
-        // ⚠️ `manual` is the only mode there is. `webhook` and `schedule` stood here and fired nothing:
-        // a flow is carried out by an external agent that brings its own schedule, which is what the
-        // code does rather than what it intends — `step()` hands back the current node, `completeStep`
-        // takes the result from outside, and the Cloudflare workflow waits rather than drives. #32 was
-        // closed on that basis, and a mode nothing triggers is a promise nobody keeps.
-        configuration: z.strictObject({ mode: z.literal("manual") }),
-    }),
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("instruction"),
-        configuration: z.strictObject({ prompt: z.string().min(1).max(50_000) }),
-    }),
-    // The four link kinds that name something in the shared tree. They are separate kinds rather than
-    // one with a `kind` field so the canvas, the palette and the picker can each say what they mean
-    // without reading into a configuration — and so a stored graph says it too.
-    z.strictObject({ ...FlowNodeBase, kind: z.literal("folder"), configuration: LinkConfiguration }),
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("document"),
-        configuration: LinkConfiguration,
-    }),
-    z.strictObject({ ...FlowNodeBase, kind: z.literal("upload"), configuration: LinkConfiguration }),
-    z.strictObject({ ...FlowNodeBase, kind: z.literal("table"), configuration: LinkConfiguration }),
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("tool"),
-        configuration: z.strictObject({
-            toolName: ToolName,
-            fingerprint: z
-                .string()
-                .regex(/^[a-f0-9]{64}$/)
-                .nullable()
-                .default(null),
-            arguments: z.record(z.string(), z.unknown()).default({}),
-        }),
-    }),
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("condition"),
-        configuration: z.strictObject({
-            mode: z.literal("semantic"),
-            instruction: z.string().min(1).max(10_000),
-        }),
-    }),
-    // ⚠️ There is no `approval` kind, and adding one back is a product decision rather than a schema
-    // addition (#73). It waited on a named person with a deadline, which needs a queue, a
-    // notification, a stand-in and an answer to "the deadline passed" — none of which exist. Without
-    // it, D24 holds without exception: nothing in Intel waits. A stored graph that still carries one
-    // is rewritten to a `condition` by migration 0007, because the question it asked is one the agent
-    // can answer.
-    //
-    // The seventh kind: one flow calls another (ADR-0004 §3). A schema addition, not hidden behavior
-    // in a generic code node — which flow is called has to be readable from the graph, or neither the
-    // publish-time call rule nor the sidebar could see it.
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("subflow"),
-        // What the called flow is given travels through `StartFlowRunInput.input` — the schema every run
-        // already uses. A second, static input here would be a promise the execution does not keep.
-        configuration: z.strictObject({
-            flowId: IntelId,
-            version: SubflowVersion.default({ mode: "latest" }),
-        }),
-    }),
-    // ⚠️ The end marks, it does not make. It used to carry a `template` that nothing ever read, and a
-    // node called "Result" that appeared to produce one is what everybody read it as. The result of a
-    // run is what the last step before it hands in (D25) — `completeStep` carries that forward.
-    z.strictObject({
-        ...FlowNodeBase,
-        kind: z.literal("output"),
-        configuration: z.strictObject({}),
-    }),
-]);
-// The two things an edge can mean (#37). `flow` is the order of work — "and then". `context` is what
-// a step works with: a document consulted in exactly this step, an approval obtained in exactly this
-// step, or, at the output, the table a result is written to.
-//
-// ⚠️ `flow` is the default, and that is the whole of the migration: every edge stored before this
-// existed parses into the meaning it already had. Nothing about saved graphs has to be rewritten.
-export const FlowEdgeKind = z.enum(["flow", "context"]);
-export const FlowEdge = z.strictObject({
-    id: FlowNodeId,
-    source: FlowNodeId,
-    target: FlowNodeId,
-    kind: FlowEdgeKind.default("flow"),
-    label: z.string().trim().min(1).max(120).nullable().default(null),
-    sourceHandle: z.string().trim().min(1).max(120).nullable().default(null),
-});
-export const FlowGraph = z.strictObject({
-    nodes: z.array(FlowNode).min(2).max(200),
-    edges: z.array(FlowEdge).min(1).max(500),
-});
-export const Flow = z.strictObject({
-    id: IntelId,
-    // The one thing a Flow shares with a document: its place in the shared folder tree (ADR-0004).
-    // Everything else stays apart — versions, R2 body and Vectorize belong to the document, the graph,
-    // runs and approvals to the flow. `null` is the root of that same tree.
-    parentId: IntelId.nullable(),
-    title: z.string().min(1).max(240),
-    description: z.string().max(2_000).nullable(),
-    ownerId: IntelId,
-    currentVersionId: IntelId.nullable(),
-    publishedVersionId: IntelId.nullable(),
-    createdAt: IsoDateTime,
-    updatedAt: IsoDateTime,
-    archivedAt: IsoDateTime.nullable(),
-});
-export const FlowVersion = z.strictObject({
-    id: IntelId,
-    flowId: IntelId,
-    sequence: z.number().int().positive(),
-    graph: FlowGraph,
-    createdBy: IntelId,
-    createdAt: IsoDateTime,
-});
-export const FlowDocument = z.strictObject({
-    flow: Flow,
-    version: FlowVersion.nullable(),
-});
-// One version as the history shows it: the metadata without the graph it carries. A flow's history
-// is as long as its edits, and a list that shipped every graph would pay for drawings nobody asked
-// for — whoever needs one asks for that one version.
-export const FlowVersionSummary = z.strictObject({
-    id: IntelId,
-    flowId: IntelId,
-    sequence: z.number().int().positive(),
-    createdBy: IntelId,
-    createdAt: IsoDateTime,
-    // Whether this is the version the flow currently publishes. Derived from the flow row when the
-    // list is read, never stored on the version: a version is immutable and "published" is not a
-    // property of it — it is the flow's choice, revocable without touching the version.
-    published: z.boolean(),
-});
-export const FlowVersionList = z.strictObject({
-    flowId: IntelId,
-    items: z.array(FlowVersionSummary),
-});
-// Both identifiers, deliberately: a version ID alone would resolve whatever version carries it,
-// whichever flow it belongs to, and the ACL is answered on the flow. The pair makes a foreign
-// version a 404 rather than a read.
-export const GetFlowVersionInput = z.strictObject({ flowId: IntelId, versionId: IntelId });
-// The same for flows: which of them call another flow that this reader may also see (#59). An
-// expand arrow on a flow whose calls are all hidden promises content that expanding it cannot
-// deliver.
-export const FlowList = z.strictObject({
-    items: z.array(Flow),
-    withCalls: z.array(IntelId).default([]),
-});
-export const ReferencedNode = z.strictObject({
-    id: IntelId,
-    title: z.string().min(1).max(240),
-});
-// What a flow touches: the documents its tree links name and the tools its Tool steps call,
-// read straight out of the graph. Deliberately not a conflict report — there is no arithmetic here
-// and nothing that can go stale, because the graph is the answer. Whether a given person may reach
-// any of it is decided where it can be decided honestly: when the folder is shared, and at runtime
-// (ADR-0004 §4). For tools it can only ever be the latter, because the catalog is a live query with
-// the requesting user's own token (ADR-0003).
-//
-// ⚠️ `nodes` names only what the asking user may see. The rest is `hiddenNodes`, a count.
-export const FlowRequirements = z.strictObject({
-    flowId: IntelId,
-    versionId: IntelId.nullable(),
-    nodes: z.array(ReferencedNode),
-    hiddenNodes: z.number().int().nonnegative(),
-    tools: z.array(ToolName),
-});
-// What stands between this flow and a run, asked on demand and answered for the person asking.
-//
-// ⚠️ A snapshot, and it says so. The tool catalog is a live query with the requesting user's own
-// token (ADR-0003), so what is reachable now can be different tomorrow, and the same flow answers
-// differently for two people. That is why this is a question one asks rather than a badge on the
-// flow: a standing "this flow has conflicts" would be wrong for tools by construction (#72, D24).
-export const FlowValidation = z.strictObject({
-    flowId: IntelId,
-    versionId: IntelId.nullable(),
-    // Empty means it would start now — for this person, at this moment.
-    problems: z.array(z.strictObject({
-        code: z.string().min(1).max(80),
-        detail: z.string().min(1).max(2_000),
-    })),
-    checkedAt: IsoDateTime,
-});
-export const CreateFlowInput = 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),
-    idempotencyKey: z.string().min(8).max(200),
-});
-// Renaming and moving a flow. Both are organization and nothing else: they touch no version, no
-// published graph and no run, because organization has to stay free of consequence or nobody dares
-// to reorganize (ADR-0004).
-export const UpdateFlowInput = z
-    .strictObject({
-    flowId: IntelId,
-    baseUpdatedAt: IsoDateTime,
-    title: z.string().trim().min(1).max(240).optional(),
-    description: z.string().trim().max(2_000).nullable().optional(),
-    parentId: IntelId.nullable().optional(),
-    idempotencyKey: z.string().min(8).max(200),
-})
-    .refine((input) => input.title !== undefined || input.description !== undefined || input.parentId !== undefined, { error: "At least one change is required" });
-// Archiving a flow is the same shape as archiving a document, deliberately: `archived` is a boolean
-// rather than a one-way verb, because an archive nothing returns from is a delete under a friendlier
-// name. Restoring is the same call with `false`.
-export const ArchiveFlowInput = z.strictObject({
-    flowId: IntelId,
-    baseUpdatedAt: IsoDateTime,
-    archived: z.boolean(),
-    idempotencyKey: z.string().min(8).max(200),
-});
-// Three answers, not two: an absent `parentId` lists every visible flow (the search dialog asks
-// that), `null` lists the root of the shared tree and an ID lists one folder (the sidebar tree asks
-// per level, which is what keeps the tree off the N+1 it used to load with).
-export const ListFlowsInput = z.strictObject({
-    parentId: IntelId.nullable().optional(),
-    // The only way back to an archived flow, and the only place that asks for one: the bounded read
-    // behind the relation graph has no such flag on purpose (#30). A drawing that includes what was
-    // archived says the tidying up never happened.
-    //
-    // ⚠️ `.optional()` rather than `.default(false)`, unlike `ListNodesInput`. This schema is
-    // the argument type of `listFlows` on three layers, and a default makes the field required in the
-    // *parsed* type — every existing caller that lists a folder would have to spell out the answer to
-    // a question it is not asking. Absent means "without the archive" everywhere it is read.
-    includeArchived: z.boolean().optional(),
-    // The same question for flows, and the same override of `parentId` — see `ListNodesInput`.
-    archivedOnly: z.boolean().optional(),
-});
-export const GetFlowInput = z.strictObject({ flowId: IntelId });
-export const SaveFlowVersionInput = z.strictObject({
-    flowId: IntelId,
-    baseVersionId: IntelId.nullable(),
-    graph: FlowGraph,
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const PublishFlowInput = z.strictObject({
-    flowId: IntelId,
-    versionId: IntelId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-// The way back out of a publication (#146). No versionId: what is withdrawn is whatever is
-// published now, and naming one would invite a race between reading it and revoking it. Versions
-// are untouched — republishing any of them is one `publish` away.
-export const UnpublishFlowInput = z.strictObject({
-    flowId: IntelId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const PreviewFlowPublishInput = z.strictObject({ flowId: IntelId, versionId: IntelId });
-// One sub-flow call as publishing will leave it (ADR-0004 §5). `freezes` is the whole point of the
-// preview: it marks the calls whose `latest` publishing turns into `versionId`, so the author reads
-// the decision before making it rather than after.
-//
-// ⚠️ Only callees the asking actor may reach are listed at all. A call whose callee they cannot see
-// is left out rather than named, because a title is the thing an unreachable flow must not hand out.
-export const FlowPublishCall = z.strictObject({
-    nodeId: FlowNodeId,
-    nodeLabel: z.string().min(1).max(160),
-    calleeId: IntelId,
-    calleeTitle: z.string().min(1).max(240),
-    mode: SubflowVersionMode,
-    // The version this call will take once published. `null` when it follows the callee, which is the
-    // one case where the answer is only known at run time.
-    versionId: IntelId.nullable(),
-    versionSequence: z.number().int().positive().nullable(),
-    freezes: z.boolean(),
-    // The callee has a published version to be called at all. `false` is what publishing will refuse.
-    available: z.boolean(),
-});
-export const FlowPublishPreview = z.strictObject({
-    flowId: IntelId,
-    versionId: IntelId,
-    calls: z.array(FlowPublishCall),
-});
-// A flow has no share schema of its own. A grant sits on the folder a flow is filed in and inherits
-// down from there (ADR-0004 §2); a narrower grant beside it would destroy the subtree guarantee
-// section 3 rests on, so per-flow grants were removed rather than deprecated.
-// 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 RelationNode = z.strictObject({
-    id: IntelId,
-    kind: RelationNodeKind,
-    title: z.string().min(1).max(240),
-    // Inside the level being shown, rather than something it reaches out to. A flow reading a policy
-    // document from another folder pulls that document in, and the difference should be legible.
-    inScope: z.boolean(),
-});
-export const RelationEdge = z.strictObject({
-    id: z.string().min(1).max(400),
-    source: IntelId,
-    target: IntelId,
-    relation: z.enum(["reads", "calls"]),
-});
-export const RelationGraphScope = z.discriminatedUnion("of", [
-    z.strictObject({ of: z.literal("folder"), folderId: IntelId.nullable() }),
-    z.strictObject({ of: z.literal("flow"), flowId: IntelId }),
-]);
-export const RelationGraphInput = z.strictObject({
-    scope: RelationGraphScope,
-    // How much is drawn before the answer is summarized instead. A big folder has to stay usable, and
-    // the cut-off is reported rather than swallowed.
-    limit: z.number().int().min(1).max(300).default(60),
-});
-// ⚠️ Only what the asking user may see is in here. A node they may not reach is absent, not greyed
-// out and not counted: an edge to a placeholder would already tell them the thing exists, which is
-// the leak this schema has to make impossible to write by accident. `omitted` is about the size
-// limit alone, never about permissions.
-export const RelationGraph = z.strictObject({
-    scope: RelationGraphScope,
-    nodes: z.array(RelationNode),
-    edges: z.array(RelationEdge),
-    omitted: z.number().int().nonnegative(),
-    limit: z.number().int().positive(),
-});
-// ⚠️ No `waiting`. It was written for the approval node and never set by anything — the two places
-// that tested for it only ever saw `running` (#73). The column's CHECK constraint still allows the
-// value, deliberately: rewriting it means rebuilding the table in D1 for a value nothing writes,
-// and migration 0007 turns any row that somehow carries it into `failed` rather than leave a status
-// the contract cannot parse.
-export const FlowRunStatus = z.enum(["queued", "running", "completed", "failed", "cancelled"]);
-export const FlowRun = z.strictObject({
-    id: IntelId,
-    flowId: IntelId,
-    versionId: IntelId,
-    status: FlowRunStatus,
-    currentNodeId: FlowNodeId.nullable(),
-    input: z.record(z.string(), z.unknown()),
-    output: z.unknown().nullable(),
-    error: z.string().max(2_000).nullable(),
-    initiatedBy: IntelId,
-    // The subflow node this run was called from, and the run that node belongs to. A called run is a
-    // run of its own: it has its own version, its own steps and its own authorization, and only these
-    // two fields say where its result goes back to.
-    parentRunId: IntelId.nullable().default(null),
-    parentNodeId: FlowNodeId.nullable().default(null),
-    createdAt: IsoDateTime,
-    updatedAt: IsoDateTime,
-    completedAt: IsoDateTime.nullable(),
-});
-// Which step of which flow is running, outermost caller first. Readable rather than reconstructed
-// from `parentRunId` by whoever is looking (#17).
-export const FlowRunTrailEntry = z.strictObject({
-    runId: IntelId,
-    flowId: IntelId,
-    flowTitle: z.string().min(1).max(240),
-    nodeId: FlowNodeId.nullable(),
-    nodeLabel: z.string().max(160).nullable(),
-});
-export const FlowRunStep = z.strictObject({
-    run: FlowRun,
-    node: FlowNode.nullable(),
-    trail: z.array(FlowRunTrailEntry).default([]),
-});
-export const StartFlowRunInput = z.strictObject({
-    flowId: IntelId,
-    input: z.record(z.string(), z.unknown()).default({}),
-    // Present when this run is the call a subflow node makes. It names a place, never a permission:
-    // the callee's `execute` is asked of the user exactly as it is for a run they start themselves,
-    // and the parent run must be the caller's own and standing on that very node.
-    parent: z.strictObject({ runId: IntelId, nodeId: FlowNodeId }).nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const GetFlowRunInput = z.strictObject({ runId: IntelId });
-// Ending a run on purpose (#145). Until this existed the only way off a parked manual step was
-// `completeStep` with `outcome: "failed"` — which recorded a step failure that never happened.
-// Cancelling records nothing into the step history: the run ends, the history stays true.
-export const CancelFlowRunInput = z.strictObject({
-    runId: IntelId,
-    idempotencyKey: z.string().min(8).max(200),
-});
-export const CompleteFlowRunStepInput = z.strictObject({
-    runId: IntelId,
-    nodeId: FlowNodeId,
-    outcome: z.enum(["completed", "failed"]),
-    branch: z.string().min(1).max(120).nullable().default(null),
-    output: z.unknown().nullable().default(null),
-    error: z.string().max(2_000).nullable().default(null),
-    idempotencyKey: z.string().min(8).max(200),
-});
-// Why a run started. Derived when it is read and deliberately not a column: `subflow` when the run
-// is the call another run made, otherwise the mode of the trigger node in the immutable version the
-// run took. A stored copy would be a second answer that could disagree with the graph that ran.
-//
-// ⚠️ `webhook` and `schedule` stood here until #39 took them out of the trigger node. Being derived
-// rather than stored is exactly what makes that safe: no run carries a trigger of its own, so once
-// the 0005 migration has rewritten every stored trigger to `manual`, there is nowhere left for the
-// old values to come from. Had this been a column, the enum would have had to keep reading them or
-// every old run would have failed to parse the moment somebody opened the list.
-export const FlowRunTrigger = z.enum(["manual", "subflow"]);
-// Which step ended a run, and why, in the words the failure already used (#20).
-//
-// ⚠️ A call that failed carries its reason in the *called* run, and that run is a run of its own
-// with its own authorization. `calledRunId` is therefore filled only when the asking user may see
-// that run through the very rule every other run answer uses; otherwise the failure is named by the
-// calling step alone — the caller's own label — and `detail` says no more than that it did not
-// finish. Naming a callee's step or document here would be the leak #17, #19 and #20 each closed.
-export const FlowRunFailure = z.strictObject({
-    nodeId: FlowNodeId,
-    nodeLabel: z.string().max(160),
-    detail: z.string().max(2_000),
-    calledRunId: IntelId.nullable(),
-});
-// One run as a list shows it: what it did, never what it produced.
-//
-// ⚠️ Neither `input` nor `output` is in here, on purpose. A run reaches its nodes and its tools
-// with the rights of whoever started it, so its result is a way to content the next reader of this
-// list may have no claim to. Whoever wants a result asks for the run itself, where the same rule
-// decides again.
-export const FlowRunSummary = z.strictObject({
-    id: IntelId,
-    flowId: IntelId,
-    // The version the run took. Together with the run's stored input it is what a later "run this
-    // again with the old data" would need; replaying is a separate ticket, this only keeps it possible.
-    versionId: IntelId,
-    status: FlowRunStatus,
-    trigger: FlowRunTrigger,
-    startedAt: IsoDateTime,
-    completedAt: IsoDateTime.nullable(),
-    durationMs: z.number().int().nonnegative().nullable(),
-    initiatedBy: IntelId,
-    parentRunId: IntelId.nullable(),
-    failure: FlowRunFailure.nullable(),
-});
-// One filter and nothing else: "only the failed ones" is the question asked in almost every case,
-// and every further facet is a report rather than a search for a fault.
-export const ListFlowRunsInput = z.strictObject({
-    flowId: IntelId,
-    failedOnly: z.boolean().default(false),
-    limit: z.number().int().min(1).max(50).default(20),
-    // The `nextCursor` of the previous page. Keyset rather than an offset, because runs arrive while
-    // someone reads and an offset would skip or repeat rows exactly when a flow is busy.
-    cursor: z.string().min(1).max(400).nullable().default(null),
-});
-export const FlowRunList = z.strictObject({
-    items: z.array(FlowRunSummary),
-    nextCursor: z.string().max(400).nullable(),
-});
-// One completed step of one run. `detail` is the step's own error text; an output is absent for the
-// same reason it is absent from the summary.
-export const FlowRunStepRecord = z.strictObject({
-    nodeId: FlowNodeId,
-    nodeLabel: z.string().max(160),
-    outcome: z.enum(["completed", "failed"]),
-    branch: z.string().max(120).nullable(),
-    detail: z.string().max(2_000).nullable(),
-    calledRunId: IntelId.nullable(),
-    completedAt: IsoDateTime,
-});
-// What one run did, step by step, oldest first, with the call chain it belongs to (#17). The trail
-// is what makes a nested run readable: which step of which flow this run is.
-export const FlowRunHistory = z.strictObject({
-    runId: IntelId,
-    flowId: IntelId,
-    status: FlowRunStatus,
-    steps: z.array(FlowRunStepRecord),
-    trail: z.array(FlowRunTrailEntry),
-});
-// ── Bundle export (#136) ────────────────────────────────────────────────────────────────────────
-// 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.
-export const BundleEntryKind = z.enum([
-    "folder",
-    "document",
-    "table",
-    "attachment",
-    "agent",
-    "board",
-    "flow",
-]);
-// One entry of the manifest: the identity a re-import needs, next to the relative path where the
-// bytes sit in the zip. A folder carries no media type — it has no bytes.
-export const BundleManifestEntry = z.strictObject({
-    id: IntelId,
-    kind: BundleEntryKind,
-    title: z.string().min(1).max(240),
-    description: z.string().max(2_000).nullable(),
-    mediaType: z.string().min(1).max(160).nullable(),
-    // Relative to the zip root, forward slashes, no leading slash. Folders end with a slash so an
-    // empty folder still has an address.
-    path: z.string().min(1).max(4_000),
-});
-// What an export leaves out on purpose, named so a bundle says it rather than a reader guessing:
-// version history, grants/shares, flow runs, and archived nodes are not in any bundle (#136).
-export const BundleExclusion = z.enum(["version-history", "grants", "flow-runs", "archived-nodes"]);
-export const BundleManifest = z.strictObject({
-    version: z.literal(1),
-    exportedAt: IsoDateTime,
-    // The node the export started at; `null` is the root of the tree — the whole installation as the
-    // exporting caller may read it.
-    rootId: IntelId.nullable(),
-    entries: z.array(BundleManifestEntry),
-    excluded: z.array(BundleExclusion),
-});
-// ── Bundle import (#137) ────────────────────────────────────────────────────────────────────────
-// What one import made. Import always creates new nodes — no merge, no overwrite, no restored IDs
-// (#137, phase 1) — so the answer is counts and the new roots, never a diff. `replayed` marks the
-// idempotent second answer to the same key: nothing was created twice.
-export const BundleImportResult = z.strictObject({
-    nodes: z.number().int().nonnegative(),
-    flows: z.number().int().nonnegative(),
-    rootNodeIds: z.array(IntelId),
-    replayed: z.boolean(),
-});
+export const LinkConfiguration = z.strictObject({ resourceId: IntelId });