@anchrd/intel-api 0.13.0 → 0.15.0

package/migrations/0009_no_context_policy.sql

@@ -1,5 +1,13 @@
 -- #76. `context_policy` leaves the contract, the UI and every MCP answer. The COLUMN stays.
 --
+-- ⚠️ HISTORY, and no longer an explanation of what is possible. The column was finally dropped by
+-- `0018_no_context_policy_at_last.sql` (#86), through an ordinary migration file — the very thing
+-- the conclusion at the bottom of this file says cannot be done. What changed is not D1 but the
+-- recipe: `0005`, `0013` and `0016` worked out that the new table has to be created under the FINAL
+-- name instead of renamed into place, and that `node_links` has to be carried out of the way
+-- because it is the one child declared ON DELETE CASCADE. Read on for the three failures that
+-- produced the lessons; read `0018` for the shape that works.
+--
 -- ⚠️ That is not the intent, it is what D1 permits. SQLite cannot drop a column a CHECK names, and
 -- this one names itself. The way around it is a table rebuild, and `knowledge_nodes` carries six
 -- foreign keys, one of them from itself.
@@ -22,6 +30,13 @@
 -- A table rebuild with foreign keys is therefore not possible inside a migration file. It needs a
 -- session that drives the transaction itself.
 --
+-- ⚠️ THAT CONCLUSION WAS WRONG, and the way it was wrong is worth more than the conclusion. The
+-- three lessons above are all correct; what they did not contain was the fourth — do not RENAME at
+-- all. Create the new table under the final name and insert the rows back under the name the
+-- children have referenced the whole time, and there is nothing left for a deferred check to
+-- complain about at COMMIT. `0005` found it, `0013` and `0016` repeated it, and `0018` used it to
+-- drop this column at last (#86).
+--
 -- What holds instead: the column sits in D1, nothing reads it, and `db.ts` writes a fixed value on
 -- insert because it is NOT NULL without a DEFAULT. The contract does not know it — for every
 -- consumer it is gone. What remains is one dead column, and that is the price of Intel running.

package/migrations/0017_a_vector_per_card.sql

@@ -0,0 +1,38 @@
+-- anchrd/intel#301: one vector per board card, and the record of which vectors a node has.
+--
+-- Vectorize is keyed by node id (`adapters/semantic-index`), so a board was ONE vector holding the
+-- whole document while the full-text half had held one row per card since #285. "Where do I stand
+-- with X" is the question a board exists to answer and it is an imprecise one: lexically it reaches
+-- a card only where the searched word is written on it verbatim. A vector id therefore becomes
+-- `<node id>#<task id>` for a board card and stays the bare node id for every other kind — no
+-- existing vector changes its name, so no installation re-embeds its whole tree to get this.
+--
+-- This table is the D1 side of that index and nothing more: which vectors a node has, what text
+-- each one was made from, and the passage a searcher is shown when that vector is the hit. It is
+-- DERIVED like `node_fts` beside it, and `reindex` empties it so that a rebuild really rebuilds.
+--
+-- ⚠️ `fingerprint` is what keeps a board of three hundred cards from costing three hundred
+-- embeddings per save. The indexing pass compares it against the text it is about to embed and
+-- upserts only what changed; a row is written ONLY AFTER the upsert it describes succeeded. That is
+-- why a fingerprint is stored rather than a timestamp: a pass that dies between the two leaves a
+-- row missing, never a row claiming a vector that was never written, so the next pass repairs
+-- itself instead of trusting a lie.
+--
+-- ⚠️ `chunk_key` is `''` for a node that has exactly one vector — every kind but `board`. NULL
+-- would be the honest spelling and is the wrong one: NULLs are distinct from one another inside a
+-- SQLite primary key, so two rows for the same node could both exist and neither would be found by
+-- the other's write.
+--
+-- ⚠️ No foreign key on `node_id`, deliberately, and for the same reason `node_fts` has none: a
+-- derived index must not be able to make a write to `nodes` fail, and every rebuild of `nodes`
+-- (0005, 0013, 0016, 0018) has to carry each declared child through the detour those files describe.
+-- A row that outlives its node is invisible anyway — hydration joins `nodes` and drops what is
+-- archived or gone, exactly as it does for `node_fts`.
+CREATE TABLE node_vectors (
+  node_id TEXT NOT NULL,
+  chunk_key TEXT NOT NULL,
+  version_id TEXT NOT NULL,
+  fingerprint TEXT NOT NULL,
+  passage TEXT NOT NULL,
+  PRIMARY KEY (node_id, chunk_key)
+);

package/migrations/0018_no_context_policy_at_last.sql

@@ -0,0 +1,97 @@
+-- #86: `context_policy` leaves `nodes` for good.
+--
+-- #76 removed it from the contract, the UI and every MCP answer — for every consumer it has been
+-- gone since. The COLUMN stayed because SQLite cannot drop one a CHECK names, and `db.ts` has been
+-- writing the fixed value `'relevant'` into it ever since so that inserting a node works at all.
+-- A dead column plus a line of code serving it: harmless, and ballast the next reader has to be
+-- told about.
+--
+-- ⚠️ THE reason this ticket sat open for weeks is that three earlier attempts failed against
+-- `--remote` while passing locally, and the file that recorded them (`0009_no_context_policy.sql`)
+-- concluded that a table rebuild with foreign keys needs "a session that runs the transaction
+-- itself, not a migration file". That conclusion is out of date: `0005`, `0013` and `0016` each
+-- rebuilt this very table through an ordinary migration file, and `0016` did it against the live
+-- database on 2026-08-08 with 120 nodes, every referencing table coming out with the count it went
+-- in with.
+--
+-- ⚠️ `0013` and `0016` are GONE since #392 — they were the Agent and Board rebuilds, and the
+-- feature was parked (#385). What they worked out is not gone with them: the recipe is in
+-- `packages/api/CLAUDE.md`, which is where the next rebuild reads it, and the three points below
+-- are this file's own copy of it.
+--
+-- ⚠️ One thing about that run is worth knowing before it is quoted as a precedent: the installation
+-- held ZERO `node_links` rows, so the rescue below would have had nothing to rescue and the run
+-- would have passed without exercising it at all. The one row it did carry was created for the
+-- purpose, minutes before, by linking two throwaway documents. The proof was arranged, not found —
+-- and the next person rebuilding this table has to arrange it again, because the installation still
+-- has almost no links.
+--
+-- What the three of them worked out, and what this file copies rather than rediscovers:
+--
+--   1. `PRAGMA foreign_keys = OFF` is IGNORED by D1 over the HTTP API. Locally miniflare obeys it,
+--      so the integration test was green while the real database answered `FOREIGN KEY constraint
+--      failed`. That is why the proof of a migration here is a run against `--remote`.
+--   2. The new table is created under the FINAL name rather than built beside the old one and
+--      renamed over it. `ALTER TABLE ... RENAME` makes references FOLLOW the rename, so renaming
+--      the old table out of the way quietly re-points every other table at a table about to be
+--      dropped. Inserting the rows again under the name the children have referenced all along is
+--      what settles them.
+--   3. `DROP TABLE` on a parent runs an implicit `DELETE FROM` first, and `node_links` is the one
+--      child declared ON DELETE CASCADE — so that delete does not merely flag its rows, it REMOVES
+--      them. They are carried out of the way and put back. That is a rescue, not a decision about
+--      the data. ⚠️ The list of children is in `packages/api/CLAUDE.md` and is READ FROM THE
+--      DATABASE, not from these files: `0011` renamed the tree and SQLite rewrote the `REFERENCES`
+--      clauses of tables older than it, so their current shape is written down nowhere here.
+--
+-- ⚠️ On an empty database neither detour is visible, because nothing points at anything. That is
+-- 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.
+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;
+
+-- The same table as `0016` left it, minus one column. Nothing else about it changes: same keys,
+-- same CHECKs, same six kinds — a rebuild is the only way to drop the column, not an invitation to
+-- change anything else while the table is open.
+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')),
+  title TEXT NOT NULL CHECK (length(title) BETWEEN 1 AND 240),
+  description TEXT CHECK (description IS NULL OR length(description) <= 2000),
+  owner_id TEXT NOT NULL,
+  current_version_id TEXT,
+  created_at TEXT NOT NULL,
+  updated_at TEXT NOT NULL,
+  archived_at TEXT
+);
+
+-- Columns named on both sides rather than `SELECT *`: the holding table still HAS `context_policy`,
+-- and a positional insert would either fail or, worse, shift every value one place to the left.
+INSERT INTO nodes (
+  id, parent_id, kind, title, description, owner_id,
+  current_version_id, created_at, updated_at, archived_at
+)
+SELECT
+  id, parent_id, kind, title, description, 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/0019_one_name_for_the_grants.sql

@@ -0,0 +1,52 @@
+-- #392: the grant table takes the tree's name, and the table nobody reads goes.
+--
+-- Two changes to the same subject, in one file because they are one subject. After Agents and Board
+-- were parked (#385) `tree_grants` is the ONLY grant table left, and it stands beside
+-- `node_versions`, `node_links`, `node_vectors` and `node_index_state` under a name from a different
+-- vocabulary. `node_grants` is the name somebody would guess without looking.
+--
+-- ⚠️ It also closes a split that ran through four layers. D1 said `grants`, the contract says
+-- `ListGrantsInput`/`RevokeGrantInput`, HTTP says `/nodes/:nodeId/grants` — and the MCP surface
+-- alone said `share`. anchrd/intel#396 pulls the tools onto `grant`; this is the other half of the
+-- same move, and afterwards the same thing has the same name everywhere.
+--
+-- ⚠️ A rename is safe HERE and would not be one table up. `ALTER TABLE ... RENAME` makes every
+-- `REFERENCES` clause pointing AT the renamed table follow it — which is the trap the `nodes`
+-- rebuild exists to avoid (see `packages/api/CLAUDE.md`). `tree_grants` is a child: nothing points
+-- at it, so nothing can follow it anywhere. The direction is what makes the difference, not the
+-- statement.
+--
+-- ⚠️ Indexes do NOT follow a rename. They keep working — an index is bound to its table, not to its
+-- table's name — but they keep the old name in `sqlite_master` and would be the last place
+-- `tree_` survives. That is the lesson `0011` wrote down, and dropping and recreating one is free:
+-- an index holds no rows of its own and nothing points at it.
+ALTER TABLE tree_grants RENAME TO node_grants;
+
+DROP INDEX tree_grants_principal_idx;
+DROP INDEX tree_grants_node_idx;
+
+CREATE INDEX node_grants_principal_idx ON node_grants(
+  principal_type,
+  principal_id,
+  verb,
+  expires_at
+);
+
+CREATE INDEX node_grants_node_idx ON node_grants(node_id, verb);
+
+-- `resource_grants` has been dead since `0003`, which said so in its own header:
+--
+--   > `resource_grants` is deliberately left in place and untouched. The previous version of the
+--   > Worker reads it and keeps answering correctly until it is replaced; nothing in this version
+--   > reads it any more. Once no old Worker is left, the table holds only history and can be
+--   > dropped.
+--
+-- There is no old Worker. The condition has been met for five migrations and nobody announced the
+-- moment, because nothing forced one — and a customer should not receive a schema carrying a table
+-- no code has read since `0003`.
+--
+-- ⚠️ Dropped here rather than removed from `0000`, and that is deliberate. `0003` reads it: it is
+-- the source every `tree_grants` row was migrated FROM. Taking it out of `0000` would leave `0003`
+-- selecting from a table that never existed, so the history has to keep it and the end of the chain
+-- is where it can go. `0001` also deletes rows from it — same reason, same answer.
+DROP TABLE resource_grants;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anchrd/intel-api",
-  "version": "0.13.0",
+  "version": "0.15.0",
   "type": "module",
   "license": "UNLICENSED",
   "repository": {
@@ -43,7 +43,7 @@
   },
   "dependencies": {
     "@anchrd/gate-sdk": "^0.7.0",
-    "@anchrd/intel-contract": "^0.11.0",
+    "@anchrd/intel-contract": "^0.13.0",
     "@cfworker/json-schema": "^4.1.1",
     "@modelcontextprotocol/sdk": "^1.30.0",
     "fflate": "^0.8.3",

package/dist/adapters/cloudflare-api/cloudflare-api.d.ts

@@ -1,22 +0,0 @@
-import type { CloudflareAccountApi } from "./cloudflare-api.types.js";
-/**
- * ⚠️ `Authorization: Bearer`, and NOT `cf-aig-authorization`. The two hosts take different headers
- * and the agent runtime uses the other one: `gateway.ai.cloudflare.com` reads
- * `cf-aig-authorization`, this REST host reads the plain header. Swapping them produces a 401 that
- * says nothing about which of the two was wrong.
- */
-export interface CloudflareApiDeps {
-    accountId: string;
-    gatewayId: string;
-    /**
-     * A Cloudflare API token, read-only by intent.
-     *
-     * ⚠️ It is NOT the `AI_GATEWAY_TOKEN` the agent runtime holds. That one carries
-     * `AI Gateway: Run` and buys inference; this one carries `AI Gateway: Read` (and, for the model
-     * catalog, `Workers AI: Read`) and buys nothing at all. One credential for both would put a
-     * spending permission into the Worker that only ever reads.
-     */
-    token: string;
-    fetch: typeof fetch;
-}
-export declare function createCloudflareApi(deps: CloudflareApiDeps): CloudflareAccountApi;

package/dist/adapters/cloudflare-api/cloudflare-api.js

@@ -1,214 +0,0 @@
-import { z } from "zod";
-import { IntelError } from "../../shared/intel-error/intel-error.js";
-const ApiOrigin = "https://api.cloudflare.com/client/v4";
-/**
- * How many pages of gateway log are read before the answer is declared a floor.
- *
- * A run is several model turns and a five-minute schedule is 8 640 runs a month, so "read
- * everything" is not on the table. Twenty pages of fifty is the last thirty days of a busy agent
- * or the last few days of a very busy one; past that the screen says "at least this much" rather
- * than a number nobody can check.
- *
- * ⚠️ `PerPage` is Cloudflare's ceiling, not a chosen number. The endpoint answers `per_page=100`
- * with `HTTP 400` and `Number must be less than or equal to 50`, the adapter turns that into
- * `cloudflare_api_refused`, and the screen says `unreadable` — so the whole cost view read nothing,
- * ever, and looked like an outage while doing it (#294). Raising it back is not an optimisation;
- * it switches the feature off. `MaxPages` carries the reach instead: the product of the two is what
- * "the last thousand calls" means, and lowering one without raising the other halves the window
- * silently.
- */
-const MaxPages = 20;
-const PerPage = 50;
-/**
- * ⚠️ Cloudflare's ceiling on `/ai/models/search`, and a DIFFERENT number from `PerPage` above —
- * the limit belongs to the endpoint, not to the account. Neither may be copied onto the other's
- * call: 50 on the model catalog halves it, 100 on the log is refused outright.
- *
- * And the two fail in opposite ways, of which this is the worse one. The log endpoint REFUSES with
- * `HTTP 400 Number must be less than or equal to 50` — loud, and found in a day (#294). This one
- * IGNORES: measured against the live account (#297), `per_page=200` and `per_page=1000` both answer
- * `HTTP 200` with no error and `result_info.per_page: 100`.
- *
- * ⚠️ `result_info.total_count` cannot be used to notice a short answer either. The same account
- * reports `total_count: 286` and returns 61 entries on page 1, with page 2 empty — a reader that
- * paginated on that figure would loop over empty pages and call the result partial. The truthful
- * signal is a page that came back FULL, which the log reader already uses and this one does not
- * yet (anchrd/intel#330).
- */
-const ModelPerPage = 100;
-/**
- * The gateway's log entry, read tolerantly.
- *
- * ⚠️ `metadata` arrives as an object on some responses and as a JSON string on others, and neither
- * is documented as the one shape. Both are accepted; anything else means the call is unattributed,
- * which is a state the caller can see rather than a parse failure that blanks the whole window.
- */
-const LogEntry = z.object({
-    cost: z.number().nullish(),
-    model: z.string().nullish(),
-    created_at: z.string().nullish(),
-    metadata: z.union([z.string(), z.record(z.string(), z.unknown())]).nullish(),
-});
-/**
- * ⚠️ `result` is required, only its contents may be null. An optional field would let ANY JSON body
- * parse as an empty page — and an empty page reads as "this agent cost nothing", which is the one
- * answer this whole path exists to avoid giving by accident.
- */
-const LogResponse = z.object({
-    success: z.boolean().nullish(),
-    result: z.array(LogEntry).nullable(),
-});
-function readMetadata(raw) {
-    if (typeof raw === "string") {
-        try {
-            const parsed = JSON.parse(raw);
-            return parsed && typeof parsed === "object" && !Array.isArray(parsed)
-                ? parsed
-                : {};
-        }
-        catch {
-            return {};
-        }
-    }
-    return raw && typeof raw === "object" && !Array.isArray(raw)
-        ? raw
-        : {};
-}
-/**
- * ⚠️ Cloudflare's `properties` are a list of `{property_id, value}` pairs, not fields, and `value`
- * is a string for the scalars and an array of `{unit, price, currency}` for the price. The units are
- * the provider's own wording — "per M input tokens" — so they are matched loosely and never parsed
- * as a contract: an unrecognised unit costs a missing price, and a missing price shows nothing,
- * which is the behaviour #257 asks for anyway.
- */
-const PriceEntry = z.object({
-    unit: z.string(),
-    price: z.union([z.number(), z.string()]),
-    currency: z.string().nullish(),
-});
-const ModelProperty = z.object({
-    property_id: z.string(),
-    value: z.union([z.string(), z.number(), z.boolean(), z.array(PriceEntry)]),
-});
-const ModelEntry = z.object({
-    name: z.string(),
-    properties: z.array(ModelProperty).nullish(),
-});
-// Required for the same reason `LogResponse.result` is: a body this reader does not recognise must
-// not come out as "the account offers no models".
-const ModelResponse = z.object({
-    success: z.boolean().nullish(),
-    result: z.array(ModelEntry).nullable(),
-});
-function propertyOf(properties, id) {
-    return properties.find((property) => property.property_id === id)?.value;
-}
-function priceFor(entries, side) {
-    const found = entries.find((entry) => {
-        const unit = entry.unit.toLowerCase();
-        return unit.includes(side) && unit.includes("token") && /\bm\b|million/.test(unit);
-    });
-    if (!found)
-        return undefined;
-    const value = typeof found.price === "string" ? Number(found.price) : found.price;
-    return Number.isFinite(value) ? value : undefined;
-}
-function readModel(entry) {
-    const properties = entry.properties ?? [];
-    const context = Number(propertyOf(properties, "context_window"));
-    const rawPrice = propertyOf(properties, "price");
-    const prices = Array.isArray(rawPrice) ? rawPrice : [];
-    const input = priceFor(prices, "input");
-    const output = priceFor(prices, "output");
-    return {
-        name: entry.name,
-        contextTokens: Number.isFinite(context) && context > 0 ? context : null,
-        // ⚠️ Both halves or neither. A model shown with an input price and no output price reads as if
-        // its answers were free, which is a worse statement than saying nothing.
-        price: input !== undefined && output !== undefined
-            ? { inputPerMillion: input, outputPerMillion: output }
-            : null,
-        functionCalling: String(propertyOf(properties, "function_calling") ?? "") === "true",
-    };
-}
-export function createCloudflareApi(deps) {
-    /**
-     * ⚠️ Neither the URL nor the body of a refusal is quoted onward. The URL carries the account id
-     * and the body carries whatever Cloudflare wrote about a token; this message is read by a person
-     * on a screen and by a model through the MCP surface alike. The status is kept, because it is the
-     * whole of what an operator can act on: 401/403 is the token's permissions, 404 is the gateway id,
-     * 429 is a limit.
-     */
-    async function get(path, query) {
-        const url = new URL(`${ApiOrigin}${path}`);
-        for (const [key, value] of Object.entries(query))
-            url.searchParams.set(key, value);
-        let response;
-        try {
-            response = await deps.fetch(url, {
-                headers: { authorization: `Bearer ${deps.token}`, accept: "application/json" },
-            });
-        }
-        catch {
-            throw new IntelError(502, "cloudflare_api_unreachable", "The Cloudflare API did not answer");
-        }
-        if (!response.ok) {
-            throw new IntelError(502, "cloudflare_api_refused", `The Cloudflare API refused this read (HTTP ${response.status})`);
-        }
-        return await response.json().catch(() => null);
-    }
-    return {
-        async gatewayCalls(query) {
-            const calls = [];
-            let partial = false;
-            for (let page = 1; page <= MaxPages; page += 1) {
-                const body = await get(`/accounts/${encodeURIComponent(deps.accountId)}/ai-gateway/gateways/${encodeURIComponent(deps.gatewayId)}/logs`, {
-                    page: String(page),
-                    per_page: String(PerPage),
-                    start_date: query.since.toISOString(),
-                    end_date: query.until.toISOString(),
-                    order_by: "created_at",
-                    order_by_direction: "desc",
-                    // ⚠️ Only documented scalar parameters travel. The endpoint also takes a `filters` array
-                    // whose query encoding Cloudflare documents nowhere — neither the reference nor the
-                    // curl example shows it — so a guess at it would either be ignored (a slow read) or
-                    // rejected (no read at all), and there is no way to tell those apart from the status.
-                    // The agent is therefore picked out below, from the metadata the runtime stamped.
-                });
-                const parsed = LogResponse.safeParse(body);
-                // A shape this reader cannot make sense of is a failure, not an empty window: an empty
-                // window reads as "this agent cost nothing".
-                if (!parsed.success) {
-                    throw new IntelError(502, "cloudflare_api_unreadable", "The Cloudflare API answered in a shape this version does not understand");
-                }
-                const entries = parsed.data.result ?? [];
-                for (const entry of entries) {
-                    const metadata = readMetadata(entry.metadata);
-                    if (metadata.agentId !== query.agentId)
-                        continue;
-                    calls.push({
-                        runId: typeof metadata.runId === "string" ? metadata.runId : null,
-                        model: entry.model ?? "",
-                        cost: entry.cost ?? 0,
-                        at: entry.created_at ?? query.until.toISOString(),
-                    });
-                }
-                if (entries.length < PerPage)
-                    return { calls, partial: false };
-                partial = page === MaxPages;
-            }
-            return { calls, partial };
-        },
-        async workersAiModels() {
-            const body = await get(`/accounts/${encodeURIComponent(deps.accountId)}/ai/models/search`, {
-                per_page: String(ModelPerPage),
-                hide_experimental: "true",
-            });
-            const parsed = ModelResponse.safeParse(body);
-            if (!parsed.success) {
-                throw new IntelError(502, "cloudflare_api_unreadable", "The Cloudflare API answered in a shape this version does not understand");
-            }
-            return (parsed.data.result ?? []).map(readModel);
-        },
-    };
-}

package/dist/adapters/cloudflare-api/cloudflare-api.types.d.ts

@@ -1,64 +0,0 @@
-/**
- * The two things Intel reads out of the Cloudflare account, and nothing else.
- *
- * ⚠️ Both are READS, and the port says so by having no other verb. The token behind it is
- * account-wide — Cloudflare offers no per-gateway scope for `AI Gateway: Read`, the same limitation
- * `AI Gateway: Run` already had in #239 — so the narrowness has to come from what this interface
- * can express rather than from what the credential allows.
- */
-export interface CloudflareAccountApi {
-    /**
-     * The gateway's own log lines for one agent, within a window.
-     *
-     * ⚠️ `cost` here is the **debit from the Cloudflare balance**, 1:1 — measured on 2026-08-07
-     * against the running installation: balance $19.77 + spend $0.23 = the $20.00 that was loaded.
-     * Cloudflare takes its 5 % when the balance is topped up and passes inference through without a
-     * markup, so this number means "what this costs us" and needs no conversion. A reader who
-     * multiplied it by anything would be inventing a second, wrong price.
-     */
-    gatewayCalls(query: GatewayCallQuery): Promise<GatewayCallPage>;
-    /**
-     * What Cloudflare currently charges for the models it serves itself (#257).
-     *
-     * ⚠️ Workers AI only. Cloudflare publishes no price list for the Anthropic models it resells
-     * through Unified Billing, so those figures have no live source and stay a table — which is the
-     * whole reason the catalog says, per entry, where its numbers came from.
-     */
-    workersAiModels(): Promise<WorkersAiModel[]>;
-}
-export interface GatewayCallQuery {
-    /** The value stamped as `cf-aig-metadata.agentId` by the agent runtime. */
-    agentId: string;
-    since: Date;
-    until: Date;
-}
-export interface GatewayCall {
-    /** From `cf-aig-metadata.runId`. `null` for a call made before the stamp existed. */
-    runId: string | null;
-    model: string;
-    /** US dollars, as billed. */
-    cost: number;
-    at: string;
-}
-export interface GatewayCallPage {
-    calls: GatewayCall[];
-    /**
-     * The window was cut off at the page cap, so every total built from it is a floor rather than a
-     * total.
-     *
-     * ⚠️ It exists so the screen can say "at least". A sum that silently stopped counting is the same
-     * failure as a missing number pretending to be zero, only harder to notice.
-     */
-    partial: boolean;
-}
-export interface WorkersAiModel {
-    /** The full `@cf/...` id, exactly as a definition names it. */
-    name: string;
-    contextTokens: number | null;
-    price: {
-        inputPerMillion: number;
-        outputPerMillion: number;
-    } | null;
-    /** Whether this model can call a tool at all. An agent is a tool loop; one that cannot is useless. */
-    functionCalling: boolean;
-}

package/dist/adapters/cloudflare-api/cloudflare-api.types.js

@@ -1 +0,0 @@
-export {};

package/dist/adapters/gate-applications/gate-applications.d.ts

@@ -1,23 +0,0 @@
-import type { AgentApplications } from "../../nodes/nodes.types.js";
-/**
- * Intel's door to Gate's Applications surface (`anchrd/gate#223`/`#224`, Gate 0.10.x).
- *
- * ⚠️ This is the one Gate call Intel makes with the CALLER's bearer instead of its service key, and
- * that is not a shortcut — the service key does not open this door. A Gate service key authorizes
- * `/api/v1/authorization` and `/api/v1/schema` and nothing else (Gate's two-token rule); the
- * Applications routes are admin-gated and resolve a real principal, so the person creating an agent
- * needs `applications:write` in Gate and their act is audited in Gate under their own name. A
- * service key here would have made Intel the author of every machine principal an installation ever
- * grew, which is the opposite of what an audit trail is for.
- *
- * ⚠️ Nothing this module receives from Gate is logged, wrapped into a message, or returned other
- * than through the one typed answer below. `create` is handed a plain-text key, and the shortest
- * path from here to a leak is an error that quotes the response body — so no refusal names anything
- * but the status Gate answered with.
- */
-export interface GateApplicationsDeps {
-    fetch: (url: string, init?: RequestInit) => Promise<Response>;
-    gateUrl: string;
-    timeoutMs?: number;
-}
-export declare function createGateApplications(deps: GateApplicationsDeps): AgentApplications;

package/dist/adapters/gate-applications/gate-applications.js

@@ -1,88 +0,0 @@
-import { z } from "zod";
-import { IntelError } from "../../shared/intel-error/intel-error.js";
-// Tolerant on purpose, unlike Intel's own contracts: this is somebody else's wire format, and a
-// field Gate adds tomorrow must not stop an installation from creating an agent. Only what Intel
-// actually reads is named.
-const CreatedApplication = z.object({ id: z.string().min(1), key: z.string().min(1) });
-// The same tolerance, for the same reason. Only the key is read: the ID is the one Intel asked with.
-const RotatedApplication = z.object({ key: z.string().min(1) });
-const DefaultTimeoutMs = 10_000;
-export function createGateApplications(deps) {
-    const base = deps.gateUrl.replace(/\/+$/, "");
-    const timeoutMs = deps.timeoutMs ?? DefaultTimeoutMs;
-    // Gate's refusals, translated once. A 401/403 is the caller's missing `applications:write` and is
-    // permanent until somebody acts in Gate, so it is answered as a refusal rather than as an outage;
-    // everything else — a 5xx, a timeout, a DNS failure — is "Gate did not answer", and the caller is
-    // told that no agent was created rather than left to guess.
-    function refusal(status) {
-        if (status === 401 || status === 403) {
-            return new IntelError(403, "agent_application_forbidden", "Gate refused this account the management of applications — creating an agent needs the applications permission in Gate");
-        }
-        return new IntelError(502, "agent_application_unavailable", `Gate could not manage this agent's application (${status})`);
-    }
-    async function call(path, token, body) {
-        try {
-            return await deps.fetch(`${base}/api/v1/applications${path}`, {
-                method: "POST",
-                headers: {
-                    "content-type": "application/json",
-                    authorization: `Bearer ${token}`,
-                },
-                body: JSON.stringify(body),
-                signal: AbortSignal.timeout(timeoutMs),
-            });
-        }
-        catch {
-            // ⚠️ The caught error is dropped rather than described. A fetch failure carries the URL, and
-            // the URL is the one place the bearer could still be if a caller ever put it in a query.
-            throw new IntelError(502, "agent_application_unavailable", "Gate did not answer, so no agent application was created or changed");
-        }
-    }
-    return {
-        async create(input) {
-            const response = await call("", input.token, { name: input.name });
-            if (!response.ok)
-                throw refusal(response.status);
-            const parsed = CreatedApplication.safeParse(await response.json().catch(() => null));
-            if (!parsed.success) {
-                // ⚠️ A 2xx Intel cannot read means a principal MAY exist in Gate that Intel cannot record.
-                // Nothing has been written on this side yet, so the agent does not come into being; the
-                // operator finds an unused application in Gate's list rather than an agent that half works.
-                throw new IntelError(502, "agent_application_unavailable", "Gate answered the application creation in a shape Intel cannot read");
-            }
-            return { id: parsed.data.id, key: parsed.data.key };
-        },
-        async rotateKey(input) {
-            // Gate issues the replacement FIRST and only then revokes what was there, so a rotation that
-            // fails leaves the old key working rather than locking the agent out (`applications.ts` in
-            // `anchrd/gate`). Intel relies on that: the handover to the runtime happens after this call,
-            // and until it succeeds the agent keeps running on the key it had.
-            const response = await call(`/${encodeURIComponent(input.applicationId)}/rotate-key`, input.token, {});
-            if (response.status === 404) {
-                throw new IntelError(502, "agent_application_missing", "Gate does not know this agent's application any more");
-            }
-            if (!response.ok)
-                throw refusal(response.status);
-            const parsed = RotatedApplication.safeParse(await response.json().catch(() => null));
-            if (!parsed.success) {
-                // ⚠️ A 2xx Intel cannot read means the OLD key is already revoked in Gate and the new one is
-                // lost. The agent is broken either way, so the caller is told the rotation failed and rotates
-                // again — which is safe, because rotating twice is just another new key.
-                throw new IntelError(502, "agent_application_unavailable", "Gate answered the key rotation in a shape Intel cannot read");
-            }
-            return { key: parsed.data.key };
-        },
-        async setEnabled(input) {
-            // Both routes are idempotent in Gate, which is what lets a retried archive heal a run that
-            // failed between the two writes instead of needing a repair path of its own.
-            const response = await call(`/${encodeURIComponent(input.applicationId)}/${input.enabled ? "enable" : "disable"}`, input.token, {});
-            // A 404 is the one status worth separating: the Application behind this agent is gone from
-            // Gate, and telling the operator that is more use than a generic outage they would retry.
-            if (response.status === 404) {
-                throw new IntelError(502, "agent_application_missing", "Gate does not know this agent's application any more");
-            }
-            if (!response.ok)
-                throw refusal(response.status);
-        },
-    };
-}