@anchrd/intel-api 0.6.7 → 0.9.0

package/dist/tools/tools.js

@@ -1,10 +1,24 @@
+import { serverOf } from "@anchrd/intel-contract";
 import { IntelError } from "../shared/intel-error/intel-error.js";
 import { reportUnexpectedError } from "../shared/report-unexpected-error/report-unexpected-error.js";
+import { ServerDirectoryTool, toolServersFrom, } from "./tool-servers/tool-servers.js";
 const CallTimeoutMs = 15_000;
 const MaxTools = 1_000;
 const MaxResultBytes = 1_000_000;
 // Refresh slightly early so a call cannot start with a token that expires mid-flight.
 const RefreshWindowMs = 30_000;
+/**
+ * An agent that delegates nothing — no servers, or no delegator to act for.
+ *
+ * ⚠️ It is answered without touching the token store at all. `delegatedBy` is empty for an archived
+ * agent, one whose definition Intel could not read, and one that was never given tools; asking the
+ * store for the connection of user "" would be a lookup that can only ever fail, on a path that has
+ * already decided the answer.
+ */
+function delegatesNothing(who) {
+    return (who.delegation !== null &&
+        (who.delegation.servers.length === 0 || who.delegation.delegatedBy.length === 0));
+}
 export function createTools(deps) {
     function portal() {
         if (!deps.portalUrl || !deps.sourceAllowed(deps.portalUrl)) {
@@ -12,12 +26,23 @@ export function createTools(deps) {
         }
         return deps.portalUrl;
     }
+    // One lookup per request, before anything else happens: everything below has to know whether it
+    // is answering a person or an agent, and a second lookup could answer differently mid-call.
+    async function acting(actor) {
+        const delegation = await deps.delegation(actor.id);
+        return {
+            actor,
+            connectionOf: delegation?.delegatedBy ?? actor.id,
+            delegation,
+        };
+    }
     // Authorization for tools lives entirely in the portal, so "may this user act" reduces to "does
     // this user have a usable portal token". ⚠️ The token is read per actor and never shared: one
     // operator token for everybody would make every catalog the same one and the portal's Access
-    // policies decorative (ADR-0003).
-    async function accessToken(actor) {
-        const stored = await deps.tokens.read(actor.id);
+    // policies decorative (ADR-0003). For an agent the actor IS somebody else — the delegator — which
+    // is the whole of D30 and the reason this takes an `Acting` rather than a `ToolActor`.
+    async function accessToken(who) {
+        const stored = await deps.tokens.read(who.connectionOf);
         if (!stored) {
             throw new IntelError(401, "portal_not_connected", "The portal has not signed this user in yet");
         }
@@ -33,20 +58,81 @@ export function createTools(deps) {
             // A token that cannot be renewed is dropped: leaving it would keep failing every call with a
             // stale credential. The browser answers this by signing in silently again (#60); an MCP
             // client sees the code and repeats its own authorization.
-            await deps.tokens.clear(actor.id);
+            await deps.tokens.clear(who.connectionOf);
             throw new IntelError(401, "portal_reconnect_required", "The portal sign-in for this user has expired");
         }
-        await deps.tokens.write(actor.id, refreshed);
+        await deps.tokens.write(who.connectionOf, refreshed);
         return refreshed.accessToken;
     }
-    // One live tools/list is both the catalog and the authorization answer: the portal only returns
-    // what this user may reach. Nothing here is cached as a permission.
-    async function capabilities(actor) {
-        const token = await accessToken(actor);
+    async function remoteTools(who) {
+        const token = await accessToken(who);
         const remote = await deps.remote.list(portal(), token, AbortSignal.timeout(CallTimeoutMs));
         if (remote.length > MaxTools) {
             throw new IntelError(502, "tool_catalog_too_large", "The portal returned too many tools");
         }
+        return remote;
+    }
+    /**
+     * The servers the portal says this connection reaches, confirmed against its live tool list.
+     *
+     * ⚠️ Fails rather than answering "none" when the portal keeps no directory. An empty list would
+     * be indistinguishable from "you have no servers", and the difference decides whether a screen
+     * says "connect something" or "this portal cannot be delegated from".
+     */
+    async function serverList(who, toolNames) {
+        if (!toolNames.includes(ServerDirectoryTool)) {
+            throw new IntelError(502, "tool_servers_unavailable", `The portal does not offer ${ServerDirectoryTool}, so its servers cannot be listed`);
+        }
+        const answer = await deps.remote.call({
+            url: portal(),
+            accessToken: await accessToken(who),
+            name: ServerDirectoryTool,
+            arguments: {},
+            signal: AbortSignal.timeout(CallTimeoutMs),
+        });
+        const directory = answer.isError ? null : toolServersFrom({ directory: answer, toolNames });
+        if (directory === null) {
+            throw new IntelError(502, "tool_servers_unavailable", "The portal did not answer with a server list this Intel can read");
+        }
+        return directory;
+    }
+    /**
+     * One live tools/list is both the catalog and the authorization answer: the portal only returns
+     * what this user may reach. Nothing here is cached as a permission.
+     *
+     * ⚠️ For an agent the list is cut to the delegated servers, and the cut is made against the
+     * portal's own directory rather than against the tool names — `tool-servers.ts` says why the
+     * namespace alone is not enough to attribute a tool. The second return value is the attribution
+     * itself, so the audit below names the server the cut actually used rather than guessing again.
+     */
+    async function capabilities(who) {
+        const delegated = who.delegation;
+        const serverOfTool = new Map();
+        if (delegatesNothing(who))
+            return { items: [], serverOfTool };
+        let remote = await remoteTools(who);
+        if (delegated) {
+            const directory = await serverList(who, remote.map((tool) => tool.name));
+            // ⚠️ Attributed against every identifier the portal DECLARED — including rows it marked
+            // disabled — and only then checked against the delegation. Attributing against the offerable
+            // subset (or against the delegation itself) would widen it: with `wiki` delegated and
+            // `wiki_extra` merely declared, `wiki_extra__read` starts with `wiki_` and would be handed
+            // over as a `wiki` tool. The longest match over the widest declared set is the only reading
+            // that no missing row can loosen.
+            const delegatedSet = new Set(delegated.servers);
+            // ⚠️ And the attribution is then required to land on a server that is still OFFERABLE — the
+            // narrow set, enabled and confirmed. Wide for attribution, narrow for permission: a portal
+            // that switches a server off takes it away from the agent here, which is revocation reaching
+            // an agent without anybody touching its definition (D30).
+            const offerable = new Set(directory.servers.map((server) => server.handle));
+            remote = remote.filter((tool) => {
+                const handle = serverOf(tool.name, directory.declared);
+                if (handle === null || !delegatedSet.has(handle) || !offerable.has(handle))
+                    return false;
+                serverOfTool.set(tool.name, handle);
+                return true;
+            });
+        }
         const items = [];
         for (const tool of remote) {
             items.push({
@@ -59,27 +145,63 @@ export function createTools(deps) {
                 }),
             });
         }
-        return items;
+        return { items, serverOfTool };
+    }
+    /**
+     * ⚠️ The refusal that costs nothing. A delegated caller naming a tool outside every delegated
+     * namespace is turned away here — before the token store, before `tools/list`, before the portal
+     * hears anything at all. The authoritative cut still happens in `capabilities`, against the
+     * portal's directory; this one exists so the portal is never touched on behalf of a call that was
+     * always going to be refused, and so the refusal can name the tool and the servers (D30).
+     */
+    function requireDelegated(who, name) {
+        const delegated = who.delegation;
+        if (!delegated)
+            return;
+        if (delegatesNothing(who)) {
+            throw new IntelError(403, "tool_not_delegated", `${name} is not available: this agent has no delegated MCP servers`);
+        }
+        if (serverOf(name, delegated.servers) === null) {
+            throw new IntelError(403, "tool_not_delegated", `${name} is not part of this agent's delegated servers (${delegated.servers.join(", ")})`);
+        }
     }
-    async function requireCapability(actor, name) {
-        const found = (await capabilities(actor)).find((capability) => capability.name === name);
+    async function requireCapability(who, name) {
+        const reachable = await capabilities(who);
+        const found = reachable.items.find((capability) => capability.name === name);
         if (!found) {
             throw new IntelError(404, "tool_not_available", `Tool ${name} is not available to you`);
         }
-        return found;
+        return { capability: found, server: reachable.serverOfTool.get(name) };
     }
-    async function call(actor, input) {
-        if (!actor.canExecute) {
+    async function call(who, input) {
+        if (!who.actor.canExecute) {
             throw new IntelError(403, "tool_execute_forbidden", "Tool execution permission is required");
         }
-        const capability = await requireCapability(actor, input.name);
+        requireDelegated(who, input.name);
+        const { capability, server } = await requireCapability(who, input.name);
         const validation = deps.validate(capability.inputSchema, input.arguments);
         if (!validation.valid) {
             throw new IntelError(400, "tool_arguments_invalid", validation.detail ?? "Invalid arguments");
         }
+        // ⚠️ Written before the call, not after it: an audit that only records what succeeded is a
+        // record of the harmless half. Both principals are named — the agent that acted and the person
+        // whose connection carried it (D30) — and no argument is.
+        //
+        // ⚠️ The server is the one the CUT used, carried out of `capabilities`, not a second guess made
+        // against the delegated handles. Re-deriving it here would name `wiki` for a tool the cut
+        // attributed to `wiki_extra`, and an audit row that names the wrong system is worse than none.
+        if (who.delegation) {
+            await deps.audit({
+                agentId: who.delegation.agentId,
+                applicationId: who.actor.id,
+                delegatedBy: who.delegation.delegatedBy,
+                server: server ?? "",
+                tool: capability.name,
+            });
+        }
         const result = await deps.remote.call({
             url: portal(),
-            accessToken: await accessToken(actor),
+            accessToken: await accessToken(who),
             name: capability.name,
             arguments: input.arguments,
             signal: AbortSignal.timeout(CallTimeoutMs),
@@ -89,41 +211,78 @@ export function createTools(deps) {
         }
         return result;
     }
+    // A token that is gone or beyond renewal is the same answer as never having signed in, so reading
+    // a catalog reports it as a state. Only a portal that does not answer stays an error — the view
+    // has to tell "sign in again" apart from "the portal failed", and a 401 here would otherwise look
+    // like an expired Intel session to the browser.
+    function disconnected(error) {
+        return (error instanceof IntelError &&
+            (error.code === "portal_not_connected" || error.code === "portal_reconnect_required"));
+    }
     return {
         async catalog(actor) {
-            const stored = await deps.tokens.read(actor.id);
+            const who = await acting(actor);
+            if (delegatesNothing(who))
+                return { portalConnected: true, items: [] };
+            const stored = await deps.tokens.read(who.connectionOf);
             // No portal sign-in yet is a normal state, not an error: the browser answers it by running
-            // the silent sign-in and asking again (#60).
+            // the silent sign-in and asking again (#60). For an agent it is the ordinary shape of
+            // revocation — the delegator disconnected, so the agent reaches nothing (D30).
+            if (!stored)
+                return { portalConnected: false, items: [] };
+            try {
+                return { portalConnected: true, items: (await capabilities(who)).items };
+            }
+            catch (error) {
+                if (disconnected(error))
+                    return { portalConnected: false, items: [] };
+                throw error;
+            }
+        },
+        async servers(actor) {
+            const who = await acting(actor);
+            if (delegatesNothing(who))
+                return { portalConnected: true, items: [] };
+            const stored = await deps.tokens.read(who.connectionOf);
             if (!stored)
                 return { portalConnected: false, items: [] };
             try {
-                return { portalConnected: true, items: await capabilities(actor) };
+                const remote = await remoteTools(who);
+                const { servers } = await serverList(who, remote.map((tool) => tool.name));
+                // ⚠️ An agent sees its own delegation, never the delegator's whole shelf. Its catalog is cut
+                // anyway, so the uncut list would grant nothing — it would only tell an agent, and through
+                // it a model, which other systems the person it acts for is connected to.
+                const delegated = who.delegation;
+                return {
+                    portalConnected: true,
+                    items: delegated
+                        ? servers.filter((server) => delegated.servers.includes(server.handle))
+                        : servers,
+                };
             }
             catch (error) {
-                // A token that is gone or beyond renewal is the same answer as never having signed in, so
-                // reading the catalog reports it as a state. Only a portal that does not answer stays an
-                // error — the view has to tell "sign in again" apart from "the portal failed", and a 401
-                // here would otherwise look like an expired Intel session to the browser.
-                if (error instanceof IntelError &&
-                    (error.code === "portal_not_connected" || error.code === "portal_reconnect_required")) {
+                if (disconnected(error))
                     return { portalConnected: false, items: [] };
-                }
                 throw error;
             }
         },
-        execute: async (actor, input) => await call(actor, input),
+        execute: async (actor, input) => await call(await acting(actor), input),
         async test(actor, input) {
-            const capability = await requireCapability(actor, input.name);
+            const who = await acting(actor);
+            requireDelegated(who, input.name);
+            const { capability } = await requireCapability(who, input.name);
             if (capability.annotations.readOnlyHint !== true ||
                 capability.annotations.destructiveHint === true) {
                 throw new IntelError(409, "tool_test_unsafe", "Only explicitly read-only, non-destructive tools can run in the test surface");
             }
-            return await call(actor, input);
+            return await call(who, input);
         },
         async unavailable(actor, names) {
             if (names.length === 0)
                 return [];
-            const available = new Set((await capabilities(actor)).map((capability) => capability.name));
+            const who = await acting(actor);
+            const reachable = await capabilities(who);
+            const available = new Set(reachable.items.map((capability) => capability.name));
             return names.filter((name) => !available.has(name));
         },
     };

package/dist/tools/tools.types.d.ts

@@ -1,4 +1,4 @@
-import type { ExecuteToolInput, TestToolInput, ToolCapability, ToolCatalog, ToolTestResult } from "@anchrd/intel-contract";
+import type { ExecuteToolInput, TestToolInput, ToolCapability, ToolCatalog, ToolServerCatalog, ToolTestResult } from "@anchrd/intel-contract";
 export interface ToolActor {
     id: string;
     email: string;
@@ -35,6 +35,25 @@ export interface RemoteTools {
         signal: AbortSignal;
     }): Promise<ToolTestResult>;
 }
+/**
+ * What an agent's definition delegates, resolved from the Gate Application the caller authenticated
+ * as (D30). `null` from the port means "this caller is not an agent" — the ordinary user path.
+ *
+ * ⚠️ Read fresh on every call and never cached as a permission. It is the same rule the catalog
+ * follows: the answer has to be able to change between two runs without anybody editing anything.
+ */
+export interface ToolDelegation {
+    agentId: string;
+    delegatedBy: string;
+    servers: string[];
+}
+export interface ToolAuditEvent {
+    agentId: string;
+    applicationId: string;
+    delegatedBy: string;
+    server: string;
+    tool: string;
+}
 export interface ToolDeps {
     portalUrl: string | null;
     remote: RemoteTools;
@@ -47,9 +66,12 @@ export interface ToolDeps {
         valid: boolean;
         detail?: string;
     };
+    delegation(applicationId: string): Promise<ToolDelegation | null>;
+    audit(event: ToolAuditEvent): Promise<void>;
 }
 export interface ToolService {
     catalog(actor: ToolActor): Promise<ToolCatalog>;
+    servers(actor: ToolActor): Promise<ToolServerCatalog>;
     execute(actor: ToolActor, input: ExecuteToolInput): Promise<ToolTestResult>;
     test(actor: ToolActor, input: TestToolInput): Promise<ToolTestResult>;
     unavailable(actor: ToolActor, names: string[]): Promise<string[]>;

package/migrations/0011_one_name_for_the_tree.sql

@@ -0,0 +1,53 @@
+-- #125: `knowledge` was the first draft's word for the shared tree. The product is called intel,
+-- and a second name for one concept costs a translation in every session. The prefix goes: the tree
+-- is `nodes`, and the four tables around it are named after the node they belong to.
+--
+-- Nothing is rebuilt here, and that is the whole point of the file. `ALTER TABLE ... RENAME TO` is
+-- the one way to change a table's name without a `DROP TABLE`, and `DROP TABLE` is what made the
+-- two migrations that touched this table difficult:
+--
+--   - 0005 had to carry `knowledge_links` out of the way and put it back afterwards, because the
+--     implicit `DELETE FROM` behind `DROP TABLE` fires the ON DELETE CASCADE those rows hang on.
+--     Without the rescue the migration would have committed with every relationship between two
+--     documents quietly gone.
+--   - 0009 gave up on a rebuild altogether. D1 commits the statements of a migration file one at a
+--     time, so `PRAGMA defer_foreign_keys` is spent before the DROP arrives, and
+--     `PRAGMA foreign_keys = OFF` is ignored by D1 over its HTTP API while miniflare honours it —
+--     which is how a green local test can accompany a red remote migration.
+--
+-- A rename touches no row, so neither trap is reachable from here. SQLite rewrites the REFERENCES
+-- clauses of every table pointing at the renamed one — `node_versions`, `node_links` (twice),
+-- `tree_grants`, `flows`, and the tree's reference to itself — so all six foreign keys survive under
+-- the new name and no cascade has anything to fire on. That rewriting is conditional on foreign keys
+-- being enabled, which is exactly what 0005 established the hard way when the cascade took its link
+-- rows: D1 has them on.
+--
+-- ⚠️ Indexes do not follow a rename. They keep working, because an index is bound to its table
+-- rather than to its table's name, but they keep the old name in `sqlite_master` and would be the
+-- last place `knowledge` survives. Dropping and recreating one is free of everything above: an
+-- index holds no rows of its own, and no foreign key points at it.
+--
+-- `node_fts` is a derived FTS5 index and is renamed along with the rest rather than rebuilt; FTS5
+-- renames its own shadow tables. If it ever did come out empty, `intel reindex` builds it back from
+-- D1 and R2 — but nothing here asks it to.
+ALTER TABLE knowledge_nodes RENAME TO nodes;
+ALTER TABLE knowledge_versions RENAME TO node_versions;
+ALTER TABLE knowledge_links RENAME TO node_links;
+ALTER TABLE knowledge_index_state RENAME TO node_index_state;
+ALTER TABLE knowledge_fts RENAME TO node_fts;
+
+DROP INDEX knowledge_nodes_parent_idx;
+DROP INDEX knowledge_nodes_owner_idx;
+DROP INDEX knowledge_versions_node_idx;
+DROP INDEX knowledge_links_source_idx;
+DROP INDEX knowledge_links_target_idx;
+DROP INDEX knowledge_links_origin_idx;
+DROP INDEX knowledge_index_state_status_idx;
+
+CREATE INDEX nodes_parent_idx ON nodes(parent_id, archived_at, title);
+CREATE INDEX nodes_owner_idx ON nodes(owner_id, archived_at);
+CREATE INDEX node_versions_node_idx ON node_versions(node_id, sequence DESC);
+CREATE INDEX node_links_source_idx ON node_links(source_node_id, created_at);
+CREATE INDEX node_links_target_idx ON node_links(target_node_id, created_at);
+CREATE INDEX node_links_origin_idx ON node_links(source_node_id, origin);
+CREATE INDEX node_index_state_status_idx ON node_index_state(status, updated_at);

package/migrations/0012_table_snapshots.sql

@@ -0,0 +1,29 @@
+-- #135: a table version says what it carries. 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 stays history. Update, delete, and redefine write snapshots;
+-- append keeps writing appends; documents and attachments stay NULL because each of their versions
+-- is complete by construction and the word would say nothing about them.
+--
+-- A plain ADD COLUMN, deliberately: unlike 0005 this touches no CHECK an existing column carries,
+-- so nothing has to be rebuilt and no foreign key is ever in flight.
+ALTER TABLE node_versions ADD COLUMN segment TEXT
+  CHECK (segment IS NULL OR segment IN ('append', 'snapshot'));
+
+-- Every table that exists was defined through `defineTable`, so its first version is the header
+-- segment — the complete state of the moment it was written, which is exactly what a snapshot is.
+-- Marking it so is what lets "read from the newest snapshot" answer for old tables without a
+-- special case for "no snapshot yet". Every later segment of an existing table is an append.
+UPDATE node_versions
+SET segment = CASE
+  WHEN sequence = (
+    SELECT MIN(inner_version.sequence) FROM node_versions inner_version
+    WHERE inner_version.node_id = node_versions.node_id
+  ) THEN 'snapshot'
+  ELSE 'append'
+END
+WHERE node_id IN (SELECT id FROM nodes WHERE kind = 'table');
+
+-- The two questions every table read asks — "where is the newest snapshot" and "which segments
+-- follow it" — must not scan the whole history to be answered (#30).
+CREATE INDEX node_versions_segment_idx
+  ON node_versions(node_id, segment, sequence DESC);

package/migrations/0013_agents_in_the_tree.sql

@@ -0,0 +1,76 @@
+-- #139: a fifth kind in the shared tree — `agent`. It is a node like the other four: same
+-- `parent_id`, same folder grants, same immutable `node_versions` rows, same R2 body (ADR-0005 §1).
+-- Its body happens to be a JSON definition rather than prose, which the schema neither knows nor
+-- needs to: nothing here creates a second content model, only the CHECK has to learn the word.
+--
+-- SQLite cannot alter a CHECK constraint, so the table is rebuilt — the same rebuild 0005 performed
+-- for `table`, written the same long way round for the same two reasons. Both detours below are
+-- copied from a file that earned them against a real database, not from caution.
+--
+-- ⚠️ First detour: the new table is created under the final name rather than built beside the old
+-- one and renamed over it. `DROP TABLE` on a parent runs an implicit `DELETE FROM` first, so the
+-- moment the old `nodes` goes, every row of `node_versions`, `tree_grants` and `flows` pointing at a
+-- node is a foreign-key violation. `defer_foreign_keys` postpones the complaint to COMMIT but does
+-- not withdraw it, and `ALTER TABLE ... RENAME` does not settle it either: a rename puts the name
+-- back, not the rows. Only inserting the nodes again, under the name the children have referenced
+-- all along, does. This is also why the self-reference below reads `REFERENCES nodes(id)` — the
+-- final name — which is lesson 2 of the three recorded in `0009_no_context_policy.sql`.
+--
+-- ⚠️ Second detour: `node_links` is the only child of `nodes` declared ON DELETE CASCADE, so that
+-- same implicit delete does not merely flag its rows, it removes them — the migration would commit
+-- with every relationship between two documents quietly gone. The rows are carried out of the way
+-- first and put back afterwards. That is a rescue, not a decision about the data: nothing is
+-- dropped, rewritten or reinterpreted here.
+--
+-- ⚠️ On an empty database neither detour is visible, because nothing points at anything. That is
+-- exactly how 0005's first version passed a green suite and then failed against the first database
+-- with content in it, and why the proof for this file is a row count of every referencing table
+-- before and after rather than a migration that merely ran.
+--
+-- `context_policy` is carried over unchanged and still NOT NULL. It is dead for every consumer
+-- (#76) and only D1's refusal to drop a column a CHECK names keeps it here; removing it is #86 and
+-- deliberately not smuggled into this rebuild.
+PRAGMA defer_foreign_keys = TRUE;
+
+-- Plain holding tables on purpose: no keys, no CHECKs, no foreign keys, and the column set taken
+-- from whatever the live table has. Anything enforced here would only be enforced a second time on
+-- the way back in, and a holding table that can reject a row is a holding table that can lose one.
+CREATE TABLE nodes_carry AS SELECT * FROM nodes;
+CREATE TABLE node_links_carry AS SELECT * FROM node_links;
+
+DROP TABLE nodes;
+
+CREATE TABLE nodes (
+  id TEXT PRIMARY KEY NOT NULL,
+  parent_id TEXT REFERENCES nodes(id),
+  kind TEXT NOT NULL CHECK (kind IN ('folder', 'document', 'attachment', 'table', 'agent')),
+  title TEXT NOT NULL CHECK (length(title) BETWEEN 1 AND 240),
+  description TEXT CHECK (description IS NULL OR length(description) <= 2000),
+  context_policy TEXT NOT NULL CHECK (context_policy IN ('pinned', 'relevant', 'explicit')),
+  owner_id TEXT NOT NULL,
+  current_version_id TEXT,
+  created_at TEXT NOT NULL,
+  updated_at TEXT NOT NULL,
+  archived_at TEXT
+);
+
+INSERT INTO nodes (
+  id, parent_id, kind, title, description, context_policy, owner_id,
+  current_version_id, created_at, updated_at, archived_at
+)
+SELECT
+  id, parent_id, kind, title, description, context_policy, owner_id,
+  current_version_id, created_at, updated_at, archived_at
+FROM nodes_carry;
+
+-- `OR IGNORE` because whether the cascade above actually fired is SQLite's business, not this
+-- migration's: if it did, this puts the rows back; if it did not, each one is already present under
+-- the same primary key and this is a no-op. Either way `node_links` ends up holding exactly what it
+-- held before, which is the only outcome this statement is permitted to have.
+INSERT OR IGNORE INTO node_links SELECT * FROM node_links_carry;
+
+DROP TABLE nodes_carry;
+DROP TABLE node_links_carry;
+
+CREATE INDEX nodes_parent_idx ON nodes(parent_id, archived_at, title);
+CREATE INDEX nodes_owner_idx ON nodes(owner_id, archived_at);

package/migrations/0014_agent_applications.sql

@@ -0,0 +1,25 @@
+-- #182: which Gate Application an agent node runs as. One row per agent that has a principal, and
+-- nothing else — the row is a NAME, never a credential.
+--
+-- ⚠️ The Application KEY has no column here and must never get one (D27). Gate hands a key out once
+-- in plain text and keeps only its hash, so there is nothing to store even in principle; the key
+-- lives in the runtime's `AGENT_APPLICATION_KEYS` secret and reaches it through the one response
+-- that created the agent. A column for it would turn every backup of this database into a set of
+-- machine credentials.
+--
+-- ⚠️ A table rather than a column on `nodes`, for two reasons. The column would be NULL for every
+-- folder, document, attachment and table there will ever be, which is a shape that says nothing
+-- about four of the five kinds; and adding it would mean rebuilding `nodes` — SQLite cannot alter
+-- a table a CHECK constrains — with the two detours `0013_agents_in_the_tree.sql` records. This
+-- file writes one new table and touches nothing that exists.
+--
+-- ⚠️ Deliberately NOT `ON DELETE CASCADE`, unlike `node_links`. Migration 0013 explains what that
+-- one cascade cost the rebuild it had to survive: an implicit `DELETE FROM` on the parent removed
+-- its rows outright rather than merely flagging them, and they had to be carried out of the way and
+-- put back. A second cascading child would hand the next rebuild the same trap twice. Nodes are
+-- archived, never deleted, so nothing is being kept alive by leaving the cascade off.
+CREATE TABLE agent_applications (
+  node_id TEXT PRIMARY KEY NOT NULL REFERENCES nodes(id),
+  application_id TEXT NOT NULL,
+  created_at TEXT NOT NULL
+);

package/migrations/0015_tools_delegated_from_a_connection.sql

@@ -0,0 +1,15 @@
+-- #208 (D30): an agent's tools are whole MCP servers its owner delegated from the owner's own
+-- portal connection. Nothing about that selection is stored here — it lives in the agent's
+-- definition, versioned in R2 like the rest of the document.
+--
+-- What this file adds is the one lookup the run path needs and `0014` did not provide: a call
+-- arrives authenticated as a Gate Application, and Intel has to answer "which agent is that"
+-- before it may read anybody's portal token. `0014` indexed `node_id` only (it is the primary
+-- key), so the reverse question was a table scan on every delegated tool call.
+--
+-- ⚠️ UNIQUE, not just an index. Two agents sharing one Application would make the lookup ambiguous
+-- and would hand one agent the other's delegation — the same class of hole `AGENT_APPLICATION_KEYS`
+-- refuses a doubly listed id for (D27). The constraint is what makes "one Application per agent"
+-- a fact of the database rather than a promise of the code that writes it.
+CREATE UNIQUE INDEX agent_applications_application_idx
+  ON agent_applications(application_id);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anchrd/intel-api",
-  "version": "0.6.7",
+  "version": "0.9.0",
   "type": "module",
   "license": "UNLICENSED",
   "repository": {
@@ -43,9 +43,10 @@
   },
   "dependencies": {
     "@anchrd/gate-sdk": "^0.7.0",
-    "@anchrd/intel-contract": "^0.4.0",
+    "@anchrd/intel-contract": "^0.7.0",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "ajv": "^8.20.0",
+    "fflate": "^0.8.3",
     "hono": "^4.12.32",
     "openid-client": "^6.8.4",
     "ulid": "^3.0.2",

package/dist/knowledge/knowledge.d.ts

@@ -1,2 +0,0 @@
-import type { KnowledgeDeps, KnowledgeService } from "./knowledge.types.js";
-export declare function createKnowledge(deps: KnowledgeDeps): KnowledgeService;