@anchrd/intel 0.59.0

package/migrations/0008_three_layers.sql

@@ -0,0 +1,130 @@
+-- #74. Three kinds change shape at once, so the stored graphs are rewritten before the schema that
+-- reads them changes. Without this they stop parsing in `db-flows.ts` and the flows become
+-- unopenable — the trap 0007 was written for, at a larger scale.
+--
+-- ⚠️ A `knowledge` node was BOTH a step and its material. Under D25 those are two layers, so it
+-- becomes two nodes: the step stays exactly where it stood in the chain and turns into an
+-- `instruction`, and each reference it held becomes a link hanging off it on a context edge.
+--
+--     ▶ ── knowledge[a,b] ── ▶        becomes        ▶ ── instruction ── ▶
+--                                                          │      │
+--                                                       link a   link b
+--
+-- Splitting this way rather than turning the node itself into a link is what keeps every existing
+-- edge valid: nothing is re-pointed, nothing is deleted, and a knowledge node sitting directly
+-- after the start still works — as a link it would have had to attach to the start, which is a
+-- marker and holds nothing. It is also the honest reading. The old node WAS a step; what it lacked
+-- was anything saying what to do with the material, which is exactly what the instruction now says.
+--
+-- ⚠️ The kind a reference points at was never stored in the graph — the node only held ids. The
+-- knowledge tree knows, so the rewrite reads it there. A reference whose target is gone becomes
+-- `document`, which is what the old node treated everything as.
+
+-- ── The edges: every old edge, plus one context edge per reference ───────────────────────────────
+-- ⚠️ Runs BEFORE the node rewrite, and that order is the whole reason it is readable: while the
+-- knowledge nodes are still knowledge nodes, the id of the step and the list of references sit in
+-- the same row, so the new edge can name both without taking anybody's id apart.
+UPDATE flow_versions
+SET graph_json = json_set(
+  graph_json,
+  '$.edges',
+  (
+    SELECT json_group_array(json(value)) FROM (
+      SELECT edge.key AS position, 0 AS tier, edge.value AS value
+      FROM json_each(flow_versions.graph_json, '$.edges') AS edge
+
+      UNION ALL
+
+      SELECT 1000000 + node.key AS position, reference.key + 1 AS tier,
+        json_object(
+          'id', json_extract(node.value, '$.id') || '-link-' || reference.key || '-context',
+          'source', json_extract(node.value, '$.id'),
+          'target', json_extract(node.value, '$.id') || '-link-' || reference.key,
+          'kind', 'context',
+          'label', NULL,
+          'sourceHandle', NULL
+        ) AS value
+      FROM json_each(flow_versions.graph_json, '$.nodes') AS node,
+           json_each(json_extract(node.value, '$.configuration.resourceIds')) AS reference
+      WHERE json_extract(node.value, '$.kind') = 'knowledge'
+      ORDER BY position, tier
+    )
+  )
+)
+WHERE EXISTS (
+  SELECT 1 FROM json_each(flow_versions.graph_json, '$.nodes') AS node
+  WHERE json_extract(node.value, '$.kind') = 'knowledge'
+);
+
+-- ── The nodes: every old node, plus one link per reference ───────────────────────────────────────
+UPDATE flow_versions
+SET graph_json = json_set(
+  graph_json,
+  '$.nodes',
+  (
+    SELECT json_group_array(json(value)) FROM (
+      -- The old nodes, in place and in order. A knowledge node becomes the instruction it always
+      -- half was; its retrieval hint becomes the prompt, because that is the only sentence the
+      -- author ever wrote about what should happen with the material.
+      SELECT node.key AS position, 0 AS tier,
+        CASE
+          WHEN json_extract(node.value, '$.kind') = 'knowledge'
+          THEN json_set(
+            json_set(node.value, '$.kind', 'instruction'),
+            '$.configuration',
+            json_object(
+              'prompt',
+              COALESCE(
+                NULLIF(json_extract(node.value, '$.configuration.query'), ''),
+                'Work with the attached material.'
+              )
+            )
+          )
+          -- The end marks and no longer makes: `template` was never read by anything.
+          WHEN json_extract(node.value, '$.kind') = 'output'
+          THEN json_set(node.value, '$.configuration', json_object())
+          ELSE node.value
+        END AS value
+      FROM json_each(flow_versions.graph_json, '$.nodes') AS node
+
+      UNION ALL
+
+      -- One link per reference, laid out below its step so the graph opens readable rather than
+      -- stacked. The id is derived from the node it came from, which keeps the rewrite idempotent:
+      -- running it twice produces the same ids, and there is no second knowledge node to expand.
+      SELECT node.key AS position, 1 AS tier,
+        json_object(
+          'id', json_extract(node.value, '$.id') || '-link-' || reference.key,
+          'kind', COALESCE(
+            (
+              SELECT CASE knowledge_nodes.kind
+                WHEN 'folder' THEN 'folder'
+                WHEN 'attachment' THEN 'upload'
+                WHEN 'table' THEN 'table'
+                ELSE 'document'
+              END
+              FROM knowledge_nodes WHERE knowledge_nodes.id = reference.value
+            ),
+            'document'
+          ),
+          'label', COALESCE(
+            (SELECT knowledge_nodes.title FROM knowledge_nodes WHERE knowledge_nodes.id = reference.value),
+            'Missing reference'
+          ),
+          'position', json_object(
+            'x', json_extract(node.value, '$.position.x') + (reference.key * 200),
+            'y', json_extract(node.value, '$.position.y') + 160
+          ),
+          'configuration', json_object('resourceId', reference.value)
+        ) AS value
+      FROM json_each(flow_versions.graph_json, '$.nodes') AS node,
+           json_each(json_extract(node.value, '$.configuration.resourceIds')) AS reference
+      WHERE json_extract(node.value, '$.kind') = 'knowledge'
+      ORDER BY position, tier
+    )
+  )
+)
+WHERE EXISTS (
+  SELECT 1 FROM json_each(flow_versions.graph_json, '$.nodes') AS node
+  WHERE json_extract(node.value, '$.kind') IN ('knowledge', 'output')
+);

package/migrations/0009_no_context_policy.sql

@@ -0,0 +1,48 @@
+-- #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.
+--
+-- Three attempts against the real database, three failures, each with its own lesson:
+--
+--   1. `PRAGMA foreign_keys = OFF` — **ignored** by D1 over its HTTP API. It works locally, because
+--      miniflare honours it, so the integration test was green while production answered
+--      `FOREIGN KEY constraint failed` on the DROP. ⚠️ A green migration test does not prove a D1
+--      migration runs.
+--   2. `PRAGMA defer_foreign_keys = true` — it works, but the self-reference was written as
+--      `REFERENCES knowledge_nodes(id)` and therefore pointed at the table this same migration was
+--      about to drop. SQLite rewrites a self-reference along with the rename, so the temporary name
+--      belongs there.
+--   3. Self-reference fixed → green through `wrangler d1 migrations apply --local`, still red
+--      against `--remote`. The reason is the execution model: D1 commits the statements of a
+--      migration file one at a time, and the deferral only lasts until the next COMMIT. After the
+--      first statement the reprieve is gone and `DROP TABLE` runs unprotected.
+--
+-- 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.
+--
+-- How it disappears after all is anchrd/intel#86.
+--
+-- This file deliberately does nothing. It is where the above is written down; deleted, it would be
+-- a gap in the numbering that nobody explains.
+SELECT 1;

package/migrations/0010_no_run_waits_a_year.sql

@@ -0,0 +1,27 @@
+-- Runs that nobody is carrying forward, ended (#83).
+--
+-- The workflow used to wait `365 days` for the next step to be reported, so a run whose agent
+-- stopped — context full, tab closed, session over — stood as "running" for a year and was
+-- indistinguishable from one that really was running. The wait is now the stall timeout; this
+-- clears the ones that were left behind before it existed.
+--
+-- ⚠️ The cut-off is deliberately far past the new timeout rather than equal to it. This runs once,
+-- against rows whose `updated_at` is whatever it happened to be, and a run that is genuinely mid-
+-- step when the migration is applied must not be swept up. A day is long enough that anything
+-- older stopped for good; anything younger is left to the timeout, which measures properly.
+--
+-- ⚠️ `parent_run_id IS NULL OR the child is finished`: a caller standing on a sub-flow node looks
+-- exactly like a stalled run. Ending a caller whose child is still going is the one way this could
+-- destroy work, and it is the same rule the workflow applies at its timeout.
+UPDATE flow_runs
+SET status = 'failed',
+    error = 'Nothing has moved this run forward, so it was ended. Whatever was running it stopped without reporting a result — start it again if it is still needed.',
+    completed_at = datetime('now'),
+    updated_at = datetime('now')
+WHERE status IN ('queued', 'running')
+  AND updated_at < datetime('now', '-1 day')
+  AND NOT EXISTS (
+    SELECT 1 FROM flow_runs child
+    WHERE child.parent_run_id = flow_runs.id
+      AND child.status IN ('queued', 'running')
+  );

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/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/intel/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/intel/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/intel/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/migrations/0020_cascade_purge_replay.sql

@@ -0,0 +1,11 @@
+-- #492: D1 commits before irreversible R2 deletion. This receipt keeps every object key reachable
+-- when an R2 call fails, and also makes a repeated purge key return the original result.
+CREATE TABLE node_purge_receipts (
+  actor_id TEXT NOT NULL,
+  idempotency_key TEXT NOT NULL,
+  node_id TEXT NOT NULL,
+  title TEXT NOT NULL,
+  content_keys_json TEXT NOT NULL,
+  completed_at TEXT,
+  PRIMARY KEY (actor_id, idempotency_key)
+);

package/migrations/0021_a_flow_carries_its_own_grant.sql

@@ -0,0 +1,44 @@
+-- #530: a flow is shared on its own again, the way a document and a table are.
+--
+-- `0003` moved every per-flow grant onto a folder because ADR-0004 §3 promised something a narrower
+-- grant would have broken: "everything A calls is covered by the same grant — automatically, and
+-- for all time". The word that carried the promise was *automatically*. A grant on the flow alone
+-- does not reach the sub-flow filed beside it, and in 2026-08 the run would simply have stopped at
+-- that step, without anyone having been told beforehand.
+--
+-- Being told beforehand is what has been built since: `flow_validate` gathers everything standing
+-- between one person and one run — missing `execute`, an unreachable sub-flow, an unreachable tool,
+-- an unreadable tree link — and answers it per person and per moment, on all three surfaces. The
+-- promise is therefore not restored here; it is replaced by a question anybody can ask. ADR-0004 §2
+-- carries the dated amendment, D49 the reason.
+--
+-- ⚠️ A table of its own, not a widened `node_grants`. A flow is not a node — that is the one thing
+-- ADR-0004 §1 was most explicit about — and `node_grants.node_id` carries a REFERENCES clause into
+-- `nodes`. Making the column polymorphic would mean dropping that clause, and an ACL table whose
+-- rows can outlive their subject is precisely where a stale row keeps handing out access.
+--
+-- Everything else is deliberately identical to `node_grants`, down to the index shape: the two are
+-- read by one predicate builder (`db-grants.ts`), and a difference here would become a difference
+-- in the questions it can ask.
+CREATE TABLE flow_grants (
+  id TEXT PRIMARY KEY NOT NULL,
+  flow_id TEXT NOT NULL REFERENCES flows(id),
+  principal_type TEXT NOT NULL CHECK (principal_type IN ('user', 'email', 'organization')),
+  principal_id TEXT NOT NULL,
+  verb TEXT NOT NULL CHECK (verb IN ('read', 'write', 'execute', 'share')),
+  expires_at TEXT,
+  created_by TEXT NOT NULL,
+  created_at TEXT NOT NULL,
+  -- The verb belongs in the key, for the reason `0003` gives: without it one principal holds one
+  -- verb per flow, which is the ladder the four independent verbs exist instead of.
+  UNIQUE (flow_id, principal_type, principal_id, verb)
+);
+
+CREATE INDEX flow_grants_principal_idx ON flow_grants(
+  principal_type,
+  principal_id,
+  verb,
+  expires_at
+);
+
+CREATE INDEX flow_grants_flow_idx ON flow_grants(flow_id, verb);

package/migrations/0022_a_cursor_over_the_journal.sql

@@ -0,0 +1,14 @@
+-- A change feed reads the journal in the order it happened, not by resource. The two indexes from
+-- 0000 both lead with a resource or an actor, so neither can serve "everything since position X":
+-- SQLite would have to scan and sort the whole table on every poll.
+--
+-- ⚠️ Both columns, in the order the cursor compares them. `occurred_at` alone is not enough and the
+-- shortfall is invisible: two events written in the same millisecond — the normal case inside one
+-- batch, not the exception — are indistinguishable, and a reader continuing past the timestamp
+-- skips the second one with no error and no log. The tie-break on `id` is what makes the position
+-- stable, and the index has to carry it or the sort falls back to a scan (anchrd/intel#620).
+--
+-- `resource_type` leads because every query names exactly one kind: today only node events can be
+-- listed at all, and flow events need a different visibility check before they could be.
+CREATE INDEX audit_events_feed_idx
+  ON audit_events(resource_type, occurred_at, id);