@anchrd/intel-api 0.14.0 → 0.16.0

package/dist/nodes/board/board.types.d.ts

@@ -1,38 +0,0 @@
-import type { AddBoardTaskInput, BoardDocument, BoardStatusInput, BoardTask, MoveBoardTaskInput, UpdateBoardTaskInput } from "@anchrd/intel-contract";
-export interface BoardDeps {
-    id(): string;
-}
-export interface BoardPlacement {
-    status: string;
-    parentId: string | null;
-    afterTaskId: string | null;
-    beforeTaskId: string | null;
-}
-export interface BoardOperations {
-    defaultBoard(): BoardDocument;
-    configure(board: BoardDocument, statuses: BoardStatusInput[]): BoardDocument;
-    addTask(board: BoardDocument, input: AddBoardTaskInput): {
-        board: BoardDocument;
-        task: BoardTask;
-    };
-    updateTask(board: BoardDocument, input: UpdateBoardTaskInput): {
-        board: BoardDocument;
-        task: BoardTask;
-    };
-    moveTask(board: BoardDocument, input: MoveBoardTaskInput): {
-        board: BoardDocument;
-        task: BoardTask;
-    };
-    deleteTask(board: BoardDocument, taskId: string): {
-        board: BoardDocument;
-        deleted: number;
-    };
-    repairTaskIds(board: BoardDocument): {
-        board: BoardDocument;
-        renumbered: {
-            previousId: string;
-            task: BoardTask;
-        }[];
-    };
-    sorted(tasks: readonly BoardTask[]): BoardTask[];
-}

package/dist/nodes/board/board.types.js

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

package/migrations/0013_agents_in_the_tree.sql

@@ -1,76 +0,0 @@
--- #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

@@ -1,25 +0,0 @@
--- #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

@@ -1,15 +0,0 @@
--- #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/migrations/0016_boards_in_the_tree.sql

@@ -1,80 +0,0 @@
--- #285: a sixth kind in the shared tree — `board`. It is a node like the other five: same
--- `parent_id`, same folder grants, same immutable `node_versions` rows, same R2 body (ADR-0004 §1).
--- Its body happens to be a JSON project board 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.
---
--- A board's tasks live INSIDE that one body and get no table of their own. That is the decision the
--- ticket makes: a board with three hundred tasks is one node in the tree, not three hundred, and
--- nothing about the tree has to behave differently because a board is filed in it.
---
--- SQLite cannot alter a CHECK constraint, so the table is rebuilt — the same rebuild 0005 and 0013
--- performed for `table` and `agent`, 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', 'board')),
-  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);