@anchrd/intel-api 0.13.0 → 0.15.0

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);