@anchrd/intel-api 0.34.0 → 0.36.0

package/dist/adapters/cloudflare/cloudflare.js

@@ -192,6 +192,10 @@ export default {
             id: ulid,
             now,
             folderAccess: async (actor, folderId) => await nodes.folderAccess(actor, folderId),
+            // ⚠️ Straight to the repository, past the node service: this one question is asked WITHOUT the
+            // visibility predicate on purpose (#733), and a service method taking an actor would invite
+            // somebody to hand one in.
+            parentArchivedAt: async (folderId) => await nodeRepository.parentArchivedAt(folderId),
             nodeChildren: async (actor, folderId, limit) => await nodes.childrenBounded(actor, { parentId: folderId, limit }),
             // The tree's own visibility lookup, unchanged on the way through: the relation graph, the
             // requirements list and every tree link of every run read this one answer, so none of

package/dist/adapters/db/db-boards.js

@@ -247,6 +247,18 @@ export function createBoardRepository(deps) {
          * membership to anyone who can read it; what leaves this method cannot be turned back into who
          * granted what to whom.
          *
+         * ⚠️ **A grant can name an EMAIL instead of a user id, and both are real access** (#757). The
+         * first version of this counted only `principal_type = 'user'` and therefore showed nobody on a
+         * board shared by address. Measured on the installation on 2026-08-23: four of nine grants were
+         * `email` ones.
+         *
+         * ⚠️ **Not lowercased here, and that is measured rather than assumed.** The write path already
+         * normalises an address twice (`nodes.ts` before the write, `db-grants.ts` at the boundary), and
+         * the installation confirms it: every stored `email` grant is lowercase. A `lower()` here would
+         * be defence against data that cannot exist, and no test could tell it from a no-op. The side
+         * that DOES need folding is the directory hit, because gate stores what somebody typed at
+         * signup and its casing is not this repository's to decide.
+         *
          * ⚠️ `verb = 'read'`, and that is not a detail. The verbs here are granted INDEPENDENTLY
          * (ADR-0004 §2): `write` does not follow from `read` and `read` does not follow from `write`.
          * Counting any verb would offer somebody who holds only `write` or `share` as an assignee for a
@@ -279,17 +291,32 @@ export function createBoardRepository(deps) {
                  AND grant_row.verb = 'read'
                  AND ${grantInForce}
              )) AS principal_ids_json,
+            (SELECT json_group_array(principal_id)
+             FROM (
+               SELECT DISTINCT grant_row.principal_id
+               FROM node_grants grant_row
+               JOIN ancestors ON ancestors.id = grant_row.node_id
+               WHERE grant_row.principal_type = 'email'
+                 AND grant_row.principal_id IS NOT NULL
+                 AND grant_row.verb = 'read'
+                 AND ${grantInForce}
+             )) AS principal_emails_json,
             (SELECT COUNT(*)
              FROM node_grants grant_row
              JOIN ancestors ON ancestors.id = grant_row.node_id
              WHERE grant_row.principal_type = 'organization'
                AND grant_row.verb = 'read'
                AND ${grantInForce}) AS organization_grants`)
-                .bind(boardId, deps.now().toISOString(), deps.now().toISOString())
+                // ⚠️ ONE `now` per `grantInForce`, and there are three of them since #757: the user
+                // grants, the email grants and the organization count. A missing binding is not a wrong
+                // answer here, it is `D1_ERROR: Wrong number of parameter bindings` — loud, which is the
+                // good case. Read the count off the statement, never off memory.
+                .bind(boardId, deps.now().toISOString(), deps.now().toISOString(), deps.now().toISOString())
                 .first();
             return {
                 ownerIds: JSON.parse(row?.owner_ids_json ?? "[]"),
                 principalIds: JSON.parse(row?.principal_ids_json ?? "[]"),
+                principalEmails: JSON.parse(row?.principal_emails_json ?? "[]"),
                 organizationWide: (row?.organization_grants ?? 0) > 0,
             };
         },

package/dist/adapters/db/db-flows.js

@@ -739,8 +739,19 @@ export function createFlowRepository(deps) {
         async archiveFlow(input) {
             try {
                 await deps.db.batch([
+                    /**
+                     * ⚠️ **`archived_with` is CLEARED here, in both directions** (D71, #733, found in review
+                     * of #738). A flow that travels through this door travels alone, so it belongs to no
+                     * group: archiving it on its own must not leave it looking like part of one, and a row
+                     * that still pointed at a group it no longer belongs to would come back with that group's
+                     * next restore.
+                     *
+                     * The group itself is written by ONE place, the cascade in `archiveNode`. Minting an
+                     * operation here as well would be a second writer for one column, and it would have no
+                     * reader: for a restore, "no group" and "somebody else's group" are the same answer.
+                     */
                     deps.db
-                        .prepare(`UPDATE flows SET archived_at = ?, updated_at = ?
+                        .prepare(`UPDATE flows SET archived_at = ?, archived_with = NULL, updated_at = ?
               WHERE id = ? AND updated_at = ?`)
                         .bind(input.archivedAt, input.updatedAt, input.flowId, input.baseUpdatedAt),
                     deps.db

package/dist/adapters/db/db.js

@@ -176,22 +176,6 @@ export function createNodeRepository(deps) {
                 withChildren: rows.filter((row) => row.has_children === 1).map((row) => row.id),
             };
         },
-        /**
-         * ⚠️ Deliberately NOT `visibleChildren`: that builder cuts tasks out of every level, so it
-         * answers `0` for a task with any number of subtasks. This one asks the question the guard
-         * actually has — "is anything still hanging under this node".
-         */
-        async countLiveChildren(nodeId) {
-            // ⚠️ No `allowed` join, deliberately: a grant can sit on a single node, so a child may be
-            // invisible to whoever archives its parent. Filtered by visibility this answers `0`, the
-            // refusal does not fire, and the child is later purged without being named. A count leaks a
-            // number and nothing else; the alternative leaks the child itself, permanently.
-            const result = await deps.db
-                .prepare("SELECT COUNT(*) AS total FROM nodes WHERE parent_id = ? AND archived_at IS NULL")
-                .bind(nodeId)
-                .first();
-            return result?.total ?? 0;
-        },
         async listVisibleBounded(actor, input) {
             const result = await deps.db
                 .prepare(visibleChildren(true))
@@ -580,13 +564,114 @@ export function createNodeRepository(deps) {
             return "conflict";
         },
         async archiveNode(input) {
+            const archiving = input.archivedAt !== null;
+            /**
+             * ⚠️ **The operation a node falls with, read BEFORE anything moves** (D71, #733).
+             *
+             * Archiving takes the whole subtree, so a restore needs to know which nodes fell TOGETHER —
+             * anything already archived before keeps its own older operation and stays archived. On the
+             * way in that is the new id; on the way back it is the one the root already carries, and it
+             * has to be read here because the first statement below clears it.
+             *
+             * ⚠️ `NULL` is not a group. A node archived before this migration carries `NULL`, and
+             * restoring it must bring back that node alone — matching on `NULL` would revive every node
+             * ever archived before the migration ran.
+             */
+            const group = archiving
+                ? input.operationId
+                : ((await deps.db
+                    .prepare("SELECT archived_with FROM nodes WHERE id = ?")
+                    .bind(input.nodeId)
+                    .first())?.archived_with ?? null);
+            const subtree = `WITH RECURSIVE tree(id) AS (
+        SELECT id FROM nodes WHERE id = ?
+        UNION SELECT child.id FROM nodes child JOIN tree parent ON child.parent_id = parent.id
+      )`;
+            /**
+             * ⚠️ **Every cascading statement carries the same guard, not just the first** (#457). A
+             * `D1.batch` is one transaction, but a statement matching zero rows is not an error — so
+             * without `EXISTS` on the root the children would fall while the root stayed put, taken out
+             * by the `updated_at` guard on statement one, and the caller would be told about a conflict
+             * that had already half happened.
+             */
+            const rootMoved = archiving
+                ? "EXISTS (SELECT 1 FROM nodes WHERE id = ? AND archived_at = ? AND archived_with = ?)"
+                : "EXISTS (SELECT 1 FROM nodes WHERE id = ? AND archived_at IS NULL)";
+            const cascade = archiving
+                ? [
+                    // The subtree, minus what was already archived: those keep their own operation.
+                    deps.db
+                        .prepare(`${subtree}
+                UPDATE nodes SET archived_at = ?, archived_with = ?, updated_at = ?
+                WHERE id IN (SELECT id FROM tree) AND id != ? AND archived_at IS NULL
+                  AND ${rootMoved}`)
+                        .bind(input.nodeId, input.archivedAt, input.operationId, input.updatedAt, input.nodeId, input.nodeId, input.archivedAt, input.operationId),
+                    // Flows hang in the same tree by `parent_id` and carry their own `archived_at`.
+                    deps.db
+                        .prepare(`${subtree}
+                UPDATE flows SET archived_at = ?, archived_with = ?, updated_at = ?
+                WHERE parent_id IN (SELECT id FROM tree) AND archived_at IS NULL
+                  AND ${rootMoved}`)
+                        .bind(input.nodeId, input.archivedAt, input.operationId, input.updatedAt, input.nodeId, input.archivedAt, input.operationId),
+                ]
+                : group === null
+                    ? []
+                    : [
+                        /**
+                         * ⚠️ **The group AND the subtree, not the group alone** (found in review of #738).
+                         * Matching on the operation by itself made restoring a leaf bring back its former
+                         * parent and every sibling that fell with it: one card pulled out of a board's
+                         * archive column put the whole card tree back. The walk starts at the node being
+                         * restored, so a leaf restores itself and a folder restores what hangs under it.
+                         */
+                        deps.db
+                            .prepare(`${subtree}
+                  UPDATE nodes SET archived_at = NULL, archived_with = NULL, updated_at = ?
+                  WHERE id IN (SELECT id FROM tree) AND id != ? AND archived_with = ?
+                    AND ${rootMoved}`)
+                            .bind(input.nodeId, input.updatedAt, input.nodeId, group, input.nodeId),
+                        deps.db
+                            .prepare(`${subtree}
+                  UPDATE flows SET archived_at = NULL, archived_with = NULL, updated_at = ?
+                  WHERE parent_id IN (SELECT id FROM tree) AND archived_with = ?
+                    AND ${rootMoved}`)
+                            .bind(input.nodeId, input.updatedAt, group, input.nodeId),
+                    ];
+            // How many rows this operation moves besides the root, read before it moves them: the journal
+            // line is written inside the same batch and cannot count what it is doing.
+            const cascadeSize = archiving
+                ? ((await deps.db
+                    .prepare(`WITH RECURSIVE tree(id) AS (
+                SELECT id FROM nodes WHERE id = ?
+                UNION SELECT child.id FROM nodes child JOIN tree parent ON child.parent_id = parent.id
+              )
+              SELECT (SELECT COUNT(*) FROM nodes WHERE id IN (SELECT id FROM tree) AND id != ?
+                        AND archived_at IS NULL)
+                   + (SELECT COUNT(*) FROM flows WHERE parent_id IN (SELECT id FROM tree)
+                        AND archived_at IS NULL) AS total`)
+                    .bind(input.nodeId, input.nodeId)
+                    .first())?.total ?? 0)
+                : group === null
+                    ? 0
+                    : ((await deps.db
+                        .prepare(`WITH RECURSIVE tree(id) AS (
+                  SELECT id FROM nodes WHERE id = ?
+                  UNION SELECT child.id FROM nodes child JOIN tree parent ON child.parent_id = parent.id
+                )
+                SELECT (SELECT COUNT(*) FROM nodes WHERE id IN (SELECT id FROM tree) AND id != ?
+                          AND archived_with = ?)
+                     + (SELECT COUNT(*) FROM flows WHERE parent_id IN (SELECT id FROM tree)
+                          AND archived_with = ?) AS total`)
+                        .bind(input.nodeId, input.nodeId, group, group)
+                        .first())?.total ?? 0);
             try {
                 await deps.db.batch([
                     deps.db
                         .prepare(`UPDATE nodes
-              SET archived_at = ?, updated_at = ?
+              SET archived_at = ?, archived_with = ?, updated_at = ?
               WHERE id = ? AND updated_at = ?`)
-                        .bind(input.archivedAt, input.updatedAt, input.nodeId, input.baseUpdatedAt),
+                        .bind(input.archivedAt, archiving ? input.operationId : null, input.updatedAt, input.nodeId, input.baseUpdatedAt),
+                    ...cascade,
                     deps.db
                         .prepare(`INSERT INTO idempotency_keys (
               actor_id, operation, idempotency_key, resource_id, created_at
@@ -605,7 +690,22 @@ export function createNodeRepository(deps) {
               WHERE actor_id = ? AND operation = 'node.archive'
                 AND idempotency_key = ? AND resource_id = ?
             )`)
-                        .bind(input.auditId, input.actorId, input.nodeId, JSON.stringify({ archived: input.archivedAt !== null }), input.updatedAt, input.actorId, input.idempotencyKey, input.nodeId),
+                        .bind(input.auditId, input.actorId, input.nodeId, 
+                    /**
+                     * ⚠️ **The operation and the SIZE of what moved** (D71, #733). One `node.archive` now
+                     * moves a whole subtree, and the change journal (#747) reads this table: without the
+                     * count, archiving a folder makes N documents disappear from every list behind a
+                     * single line that names only the folder.
+                     *
+                     * ⚠️ What this row does NOT carry is WHICH nodes fell. After a restore the column is
+                     * cleared, so that list is gone; if it is ever needed, it needs its own row per node
+                     * and that is a decision, not a detail.
+                     */
+                    JSON.stringify({
+                        archived: input.archivedAt !== null,
+                        operation: group,
+                        cascaded: cascadeSize,
+                    }), input.updatedAt, input.actorId, input.idempotencyKey, input.nodeId),
                 ]);
             }
             catch (error) {
@@ -630,6 +730,38 @@ export function createNodeRepository(deps) {
                 .first();
             return row ? mapNode(row) : "conflict";
         },
+        async parentArchivedAt(nodeId) {
+            // ⚠️ **No visibility predicate, and that is the whole point of this query** (found in review
+            // of #738). A grant can sit on a single node (ADR-0004 §2), so whoever may restore a child may
+            // well not see the folder above it. Asked through `getVisible`, that folder answers `null`,
+            // the guard reads "not archived", and a live node ends up under an archived one — where the
+            // purge takes it unnamed. It is the same lesson `countLiveChildren` carried before D71
+            // replaced it, and the same mistake was made again in its place.
+            //
+            // It leaks one timestamp about a node the caller cannot open. The alternative leaks the node
+            // itself, permanently.
+            const row = await deps.db
+                .prepare("SELECT archived_at, kind FROM nodes WHERE id = ?")
+                .bind(nodeId)
+                .first();
+            return row ? { archivedAt: row.archived_at, kind: row.kind } : null;
+        },
+        async versionIdsInSubtree(nodeId) {
+            // ⚠️ No visibility predicate and no archived filter, for the reason `hasAnyChild` gives: this
+            // answers what the INDEX has to be told about, not what somebody may look at. A node whose
+            // vectors stay behind pays for itself out of everybody else's search results (#348).
+            const rows = await deps.db
+                .prepare(`WITH RECURSIVE tree(id) AS (
+          SELECT id FROM nodes WHERE id = ?
+          UNION SELECT child.id FROM nodes child JOIN tree parent ON child.parent_id = parent.id
+        )
+        SELECT n.current_version_id AS version_id FROM nodes n
+        JOIN tree ON tree.id = n.id
+        WHERE n.current_version_id IS NOT NULL`)
+                .bind(nodeId)
+                .all();
+            return (rows.results ?? []).map((row) => row.version_id);
+        },
         async hasAnyChild(nodeId) {
             // ⚠️ Without a visibility predicate and without an archived filter, both on purpose: this
             // answers whether the row can be deleted at all, not what somebody may look at (#457).
@@ -675,12 +807,12 @@ export function createNodeRepository(deps) {
         UNION ALL SELECT child.id FROM nodes child JOIN tree parent ON child.parent_id = parent.id
       )`;
             const nodes = await deps.db
-                .prepare(`${tree} SELECT n.id, n.kind FROM nodes n JOIN tree ON tree.id = n.id`)
+                .prepare(`${tree} SELECT n.id, n.kind, n.title FROM nodes n JOIN tree ON tree.id = n.id`)
                 .bind(nodeId)
                 .all();
             const nodeIds = (nodes.results ?? []).map((row) => row.id);
             const flows = await deps.db
-                .prepare(`${tree} SELECT f.id FROM flows f WHERE f.parent_id IN (SELECT id FROM tree)`)
+                .prepare(`${tree} SELECT f.id, f.title FROM flows f WHERE f.parent_id IN (SELECT id FROM tree)`)
                 .bind(nodeId)
                 .all();
             const keys = await deps.db
@@ -702,6 +834,26 @@ export function createNodeRepository(deps) {
                 counts[row.kind] = (counts[row.kind] ?? 0) + 1;
             return {
                 nodeIds,
+                // The names the preview shows, capped there rather than here: a caller that wants the whole
+                // tree has `nodeIds`, and the cap belongs where the sentence is written (#733).
+                /**
+                 * ⚠️ **Flows FIRST, and the order is the finding rather than a preference** (second review
+                 * of #738). The preview names the first fifty, so with flows appended a folder holding
+                 * fifty documents and one flow named every document and hid the flow — the one thing the
+                 * cascade had to be widened for, and the one a reader is least likely to expect in there.
+                 */
+                named: [
+                    ...(flows.results ?? []).map((row) => ({
+                        id: row.id,
+                        kind: "flow",
+                        title: row.title,
+                    })),
+                    ...(nodes.results ?? []).map((row) => ({
+                        id: row.id,
+                        kind: row.kind,
+                        title: row.title,
+                    })),
+                ],
                 flowIds: (flows.results ?? []).map((row) => row.id),
                 contentKeys: [...new Set((keys.results ?? []).map((row) => row.content_key))],
                 vectorKeys: nodeIds.map((id) => ({ nodeId: id, keys: grouped.get(id) ?? [] })),

package/dist/boards/boards.d.ts

@@ -9,22 +9,36 @@ import type { BoardDeps, BoardService } from "./boards.types.js";
  * and from then on they are data anybody can rename. This list only answers for a board nobody
  * configured — one made over MCP, or one whose seeding did not land.
  */
+/**
+ * ⚠️ **The four start coloured, and the colours mean something** (Jack's decision 2026-08-22): grey
+ * for what is only lying there, yellow for what is ready, orange for what is being worked on, green
+ * for what is done. That order is the one people already read without a legend, which is the whole
+ * reason a default is worth having — a board that starts grey teaches nothing, and one that starts
+ * in arbitrary colours teaches something false.
+ *
+ * They are a suggestion, not a setting: every one of them can be overwritten, and a board that has
+ * been recoloured keeps its own values.
+ */
 export declare const DEFAULT_COLUMNS: readonly [{
     readonly id: "backlog";
     readonly title: "Backlog";
     readonly terminal: false;
+    readonly color: "#9ca3af";
 }, {
     readonly id: "todo";
     readonly title: "Offen";
     readonly terminal: false;
+    readonly color: "#eab308";
 }, {
     readonly id: "doing";
     readonly title: "Läuft";
     readonly terminal: false;
+    readonly color: "#f97316";
 }, {
     readonly id: "done";
     readonly title: "Fertig";
     readonly terminal: true;
+    readonly color: "#22c55e";
 }];
 export declare const FIRST_DEFAULT_COLUMN: "backlog";
 export declare function createBoards(deps: BoardDeps): BoardService;

package/dist/boards/boards.js

@@ -1,4 +1,4 @@
-import { ARCHIVE_COLUMN_ID } from "@anchrd/intel-contract/board";
+import { ARCHIVE_COLUMN_ID, DEFAULT_COLUMN_COLOR } from "@anchrd/intel-contract/board";
 import { IntelError } from "../shared/intel-error/intel-error.js";
 /**
  * What a board with no configuration answers with. A board is usable the moment it is created, and
@@ -10,11 +10,21 @@ import { IntelError } from "../shared/intel-error/intel-error.js";
  * and from then on they are data anybody can rename. This list only answers for a board nobody
  * configured — one made over MCP, or one whose seeding did not land.
  */
+/**
+ * ⚠️ **The four start coloured, and the colours mean something** (Jack's decision 2026-08-22): grey
+ * for what is only lying there, yellow for what is ready, orange for what is being worked on, green
+ * for what is done. That order is the one people already read without a legend, which is the whole
+ * reason a default is worth having — a board that starts grey teaches nothing, and one that starts
+ * in arbitrary colours teaches something false.
+ *
+ * They are a suggestion, not a setting: every one of them can be overwritten, and a board that has
+ * been recoloured keeps its own values.
+ */
 export const DEFAULT_COLUMNS = [
-    { id: "backlog", title: "Backlog", terminal: false },
-    { id: "todo", title: "Offen", terminal: false },
-    { id: "doing", title: "Läuft", terminal: false },
-    { id: "done", title: "Fertig", terminal: true },
+    { id: "backlog", title: "Backlog", terminal: false, color: DEFAULT_COLUMN_COLOR },
+    { id: "todo", title: "Offen", terminal: false, color: "#eab308" },
+    { id: "doing", title: "Läuft", terminal: false, color: "#f97316" },
+    { id: "done", title: "Fertig", terminal: true, color: "#22c55e" },
 ];
 // The column a card lands in when nobody said and the board has none configured. One export rather
 // than the literal `"todo"` in three places: the fallback exists FOR the unconfigured board, so a
@@ -24,6 +34,26 @@ export const FIRST_DEFAULT_COLUMN = DEFAULT_COLUMNS[0].id;
 // is a listing under a different name — the same floor gate holds at its own door, stated here so
 // this surface keeps its own promise (#700).
 const MINIMUM_QUERY = 2;
+// How many people a picker offers before anybody types. Three is a suggestion, not a directory: a
+// longer list is one somebody reads instead of typing the name they already know (#757).
+const SUGGESTIONS = 3;
+/**
+ * Whether one person from the directory reaches this board (#700, #757).
+ *
+ * ⚠️ **Two ways in, and the second one cost a release to notice.** A grant names either a user id or
+ * an EMAIL, and both are real access. Counting only ids showed nobody on a board shared by address,
+ * which is how four of the nine grants on the reference installation are written.
+ *
+ * The address is compared lowercased on both sides: a grant written `Anton@…` and a directory hit
+ * that says `anton@…` are the same person, and a case-sensitive compare would quietly disagree.
+ */
+function reachedBy(access, person) {
+    if (access.ownerIds.includes(person.id))
+        return true;
+    if (access.principalIds.includes(person.id))
+        return true;
+    return access.principalEmails.includes(person.email.toLowerCase());
+}
 export function createBoards(deps) {
     /**
      * ⚠️ The one place "which board, and may this actor DO THIS to it" is answered — and the verb is
@@ -84,6 +114,61 @@ export function createBoards(deps) {
             return;
         throw new IntelError(400, "unknown_column", `This board has no column \`${status}\`. Its columns are: ${columns.join(", ")}.`);
     };
+    /**
+     * The people this board can be handed to, without a search term (#757).
+     *
+     * ⚠️ **Named, not enumerated.** Gate's directory answers searches, not listings, so what can be
+     * offered here is exactly the set this repository already knows by name: the owners, the user
+     * grants, and the addresses of the email grants. An organization-wide board therefore suggests
+     * whatever explicit grants it also has and nothing more — "everybody" is not a list anyone can
+     * produce, and pretending otherwise would mean asking gate to hand over its directory.
+     *
+     * ⚠️ **The cap is visible.** `more` says how many are left over, so the picker can say "and 4
+     * more" instead of quietly showing three and looking complete.
+     */
+    const suggest = async (boardId) => {
+        if (!deps.directory)
+            return { items: [], more: 0 };
+        const access = await deps.boards.effectiveAccess(boardId);
+        const ids = [...new Set([...access.ownerIds, ...access.principalIds])];
+        // One call for every id at once. The addresses need one lookup each, because gate resolves ids
+        // and searches text and there is no third door — so only as many as it takes to FILL the cap.
+        const byId = ids.length === 0 ? [] : await deps.directory.resolve(ids);
+        const knownEmails = new Set(byId.map((person) => person.email.toLowerCase()));
+        /**
+         * ⚠️ **The count and the list are two different things, and the count comes FIRST.**
+         *
+         * An earlier version stopped looking after the cap and then reported the leftovers it happened
+         * to have — so a board with ten address grants said "and 1 more" instead of "and 7 more". The
+         * cap was visible and its number was wrong, which is worse than no number: it is a number
+         * somebody believes.
+         *
+         * Counted here without naming anybody: every address that is not already one of the resolved
+         * people is one more person who reaches this board. Whether gate can name them does not change
+         * how many there are.
+         */
+        const unnamedAddresses = access.principalEmails.filter((address) => !knownEmails.has(address));
+        const total = byId.length + unnamedAddresses.length;
+        /**
+         * ⚠️ **The cap counts LOOKUPS, not names found**, and the difference is a real hole. An address
+         * gate cannot name never grows `named`, so a bound on the names would never trigger: a board
+         * with a hundred address grants and no matching accounts would fire a hundred sequential calls
+         * to gate to open one menu. The test that sets six unnameable addresses walks exactly that path.
+         */
+        const named = [...byId];
+        let lookups = 0;
+        for (const address of unnamedAddresses) {
+            if (named.length >= SUGGESTIONS || lookups >= SUGGESTIONS)
+                break;
+            lookups += 1;
+            const found = await deps.directory.search(address);
+            const exact = found.find((person) => person.email.toLowerCase() === address);
+            if (exact !== undefined)
+                named.push(exact);
+        }
+        const items = named.slice(0, SUGGESTIONS);
+        return { items, more: Math.max(0, total - items.length) };
+    };
     return {
         async get(actor, input) {
             return await viewOrRefuse(actor, input);
@@ -216,7 +301,10 @@ export function createBoards(deps) {
              * design exists against.
              *
              * `nodes.archive` is the same door `node_archive` uses — one path, one audit row, one set of
-             * refusals (a card with live subtasks is still refused, #669).
+             * refusals. ⚠️ Since D71 (#733) that door CASCADES: dropping a card with subtasks on the
+             * archive column takes them with it, where #669 used to refuse the drop. Pulling the card back
+             * out brings exactly those back, and pulling a SUBTASK out while its parent card is archived
+             * is refused instead — a live card under an archived one is what the purge reaches.
              */
             const intoArchive = input.status === ARCHIVE_COLUMN_ID;
             const outOfArchive = input.status !== undefined && !intoArchive && row.archivedAt !== null;
@@ -305,7 +393,7 @@ export function createBoards(deps) {
             // read gives, so a board one may not see stays indistinguishable from one that is not there.
             await columnsOrRefuse(actor, input.boardId, "read");
             if (!deps.directory)
-                return { items: [] };
+                return { items: [], more: 0 };
             /**
              * ⚠️ ENFORCED HERE, not only described. The contract's `query` says a single character
              * answers empty, and until this line that sentence was true only because gate happens to
@@ -314,19 +402,31 @@ export function createBoards(deps) {
              * It is also the cheaper answer: a letter that can only ever produce a listing does not
              * need to travel to gate first to be refused there.
              */
-            if (input.query.trim().length < MINIMUM_QUERY)
-                return { items: [] };
-            const hits = await deps.directory.search(input.query);
+            const query = input.query.trim();
+            /**
+             * ⚠️ **Nothing typed is a QUESTION, not a refusal** (#757). The set of people who reach this
+             * board is short and known, so it can be named without a search term — and a picker that
+             * opens empty teaches the reader that there is nobody, which is the opposite of what it
+             * means.
+             *
+             * A single character stays refused, and the reason is unchanged: a letter is not a search, it
+             * is a listing under a different name. The two cases differ because one names a bounded set
+             * and the other asks the directory to filter one.
+             */
+            if (query.length === 0)
+                return await suggest(input.boardId);
+            if (query.length < MINIMUM_QUERY)
+                return { items: [], more: 0 };
+            const hits = await deps.directory.search(query);
             if (hits.length === 0)
-                return { items: [] };
+                return { items: [], more: 0 };
             const access = await deps.boards.effectiveAccess(input.boardId);
             // A grant to the organization means everybody reaches the board, so there is nothing left to
             // narrow — and narrowing anyway would produce an empty picker on exactly the boards that are
             // shared with everyone, which is most of them.
             if (access.organizationWide)
-                return { items: hits };
-            const reaches = new Set([...access.ownerIds, ...access.principalIds]);
-            return { items: hits.filter((hit) => reaches.has(hit.id)) };
+                return { items: hits, more: 0 };
+            return { items: hits.filter((hit) => reachedBy(access, hit)), more: 0 };
         },
         /**
          * What the people already recorded on cards are called (#258, #700).

package/dist/boards/boards.types.d.ts

@@ -56,6 +56,7 @@ export interface BoardRepository {
     effectiveAccess(boardId: string): Promise<{
         ownerIds: string[];
         principalIds: string[];
+        principalEmails: string[];
         organizationWide: boolean;
     }>;
 }
@@ -101,8 +102,14 @@ export interface BoardService {
     update(actor: Actor, input: BoardUpdateInput): Promise<BoardView>;
     createTask(actor: Actor, input: BoardTaskCreateInput): Promise<BoardView>;
     updateTask(actor: Actor, input: BoardTaskUpdateInput): Promise<BoardView>;
+    /**
+     * ⚠️ `more` says how many people reach this board beyond the ones named, so a capped list can say
+     * so instead of looking complete (#757). It is `0` on a search answer, where the cap belongs to
+     * gate and not to this door.
+     */
     searchAssignees(actor: Actor, input: BoardAssigneeSearchInput): Promise<{
         items: BoardAssignee[];
+        more: number;
     }>;
     resolveAssignees(actor: Actor, input: BoardAssigneeResolveInput): Promise<{
         items: BoardAssignee[];

package/dist/flows/flows.js

@@ -1446,6 +1446,23 @@ export function createFlows(deps) {
                     throw new IntelError(404, "flow_not_found", "Flow was not found");
                 return flow;
             }
+            /**
+             * ⚠️ **A flow cannot be restored on its own into an archived folder** (D71, #733, found in
+             * review of #738). The same refusal `nodes.archive` carries, and for the same reason: a live
+             * flow under an archived folder is reached by a purge of that folder, which checks
+             * `archived_at` on its root alone and walks the whole subtree.
+             */
+            if (!input.archived && current.parentId !== null) {
+                // ⚠️ Asked WITHOUT the visibility predicate, and that is the difference between a guard and
+                // a decoration: a flow is reachable through `flow_grants` on its own, so its grantee may not
+                // see the folder it is filed in. `folderAccess` answers `missing` for such a folder, the
+                // guard would not fire, and a live flow would hang under an archived one — where the purge
+                // of that folder takes it through `parent_id IN tree`.
+                const folder = await deps.parentArchivedAt(current.parentId);
+                if (folder?.archivedAt) {
+                    throw new IntelError(409, "parent_archived", "The folder this flow is filed in is archived, so it cannot be restored on its own. Restore the folder first, and this comes back with it.");
+                }
+            }
             const updatedAt = deps.now().toISOString();
             const updated = await deps.repository.archiveFlow({
                 flowId: current.id,

package/dist/flows/flows.types.d.ts

@@ -224,6 +224,10 @@ export interface FlowDeps {
     id(): string;
     now(): Date;
     folderAccess(actor: FlowActor, folderId: string): Promise<FolderAccess>;
+    parentArchivedAt(folderId: string): Promise<{
+        archivedAt: string | null;
+        kind: string;
+    } | null>;
     /**
      * The children of one folder of the shared tree as this actor may see them, without their bodies.
      * `null` is the root. The node service answers, for the same reason `folderAccess` does.

package/dist/mcp/mcp.js

@@ -192,7 +192,7 @@ export async function handleMcp(request, deps) {
         // `list`, and a filter does not change which verb a call is.
         server.registerTool("board_assignee_list", {
             title: "Who a card on this board can be given to",
-            description: "Find the people you may set as assignee on a card of this board, by typing part of a name or an address. Only people who can actually open THIS board are offered, so the same query against two boards can give two different answers. Under two characters the answer is empty rather than everybody. Use board_assignee_resolve to name somebody already on a card.",
+            description: "Find the people you may set as assignee on a card of this board. Only people who can actually open THIS board are offered, so the same query against two boards can give two different answers. Leave the query EMPTY to get up to three of them without searching, plus a count of how many more there are. One character answers empty rather than everybody; from two on it filters. Use board_assignee_resolve to name somebody already on a card.",
             inputSchema: BoardAssigneeSearchInput,
             annotations: {
                 title: "Who a card on this board can be given to",
@@ -640,7 +640,7 @@ export async function handleMcp(request, deps) {
          */
         server.registerTool("node_purge_preview", {
             title: "Preview a permanent deletion",
-            description: "Count what deleting one ARCHIVED node for good would take with it: every item in its subtree, documents and flows alike, and how many documents elsewhere link to it. It changes nothing. Ask before node_purge — afterwards there is no row left to count, and the links that break are not refused, only reported.",
+            description: "Ask before node_purge, afterwards there is no row left to count. Names and counts what deleting one ARCHIVED node for good would take with it: the nodes and flows in its subtree with their titles, capped at fifty with the total beside it, plus how many documents link to it from outside. Changes nothing.",
             inputSchema: PurgeNodePreviewInput,
             annotations: {
                 title: "Preview a permanent deletion",

package/dist/nodes/nodes.js

@@ -87,14 +87,14 @@ function decodeBase64(value) {
  * ⚠️ **Nothing may be filed under an ARCHIVED node**, and this is not tidiness — it is what keeps
  * the purge honest.
  *
- * A parent may be archived while it is empty; `task_has_subtasks` only refuses one that still has
- * live children. Without this rule it could then GAIN a live child afterwards, and `purge` — which
- * asks only whether the node itself is archived — walks the whole subtree and takes that child
- * with it. It would disappear for good without ever being named in the confirmation.
+ * Archiving takes the whole subtree since D71 (#733), so an archived node holds nothing live at the
+ * moment it is archived. Without this rule it could GAIN one afterwards, and `purge` — which asks
+ * only whether the node itself is archived — walks the whole subtree and takes that child with it.
+ * It would disappear for good without ever being named in the confirmation.
  *
  * Found in review of #669, against my own sentence claiming purge needed no rule of its own. That
- * sentence was true only as long as an archived node could never gain a live child, and nothing
- * made it true.
+ * sentence was true only as long as an archived node could never gain a live child, and until #679
+ * and D71 nothing made it true: the guard covered tasks alone, and archiving covered one row.
  */
 /**
  * The board a node would be filed on: the board itself, or the board of the task it hangs under
@@ -120,17 +120,19 @@ async function boardFor(deps, actor, parent) {
         return null;
     return (await deps.boardOfTask?.(actor, parent.id)) ?? null;
 }
+// How many of the nodes a purge would take are named in the preview. High enough that an ordinary
+// folder is listed in full, low enough that a tree nobody can render is not built (#733).
+const PURGE_PREVIEW_NAMES = 50;
 function refuseArchivedParent(parent) {
     // ⚠️ EVERY kind, not just tasks (#679). It was narrowed to tasks in #677 because widening it out
     // of a board ticket would have changed the whole tree with no test outside `boards.int.ts`; the
     // hole it left is older than that ticket and is what this one closes.
     //
-    // ⚠️ **This asks the DIRECT parent only, and the hole one level up stays open** (#733). Archiving a
-    // folder that still holds something live is allowed for every kind but `task`, so `Aussen`
-    // archived over a live `Innen` still takes anything filed under `Innen` when it is purged:
-    // `inspectPurgeTree` walks the whole subtree and `purge` checks `archived_at` on the root alone.
-    // Closing that needs a decision (refuse the archive, cascade it, refuse the purge, or name the
-    // live nodes in the preview) and #733 carries it with the count of what already exists.
+    // ⚠️ **The DIRECT parent is enough since D71 (#733), and only since then.** Archiving cascades, so
+    // an archived node holds nothing live at the moment it is archived, and a restore under an
+    // archived parent is refused: there is no live node under an archived one for something to be
+    // filed beneath. Before that, this guard closed one level while `Aussen` archived over a live
+    // `Innen` still handed anything filed under `Innen` to the purge.
     if (parent === null || parent.archivedAt === null)
         return;
     throw new IntelError(409, "parent_archived", `This ${parent.kind} is archived, so nothing new can be filed under it. Restore it first.`);
@@ -516,6 +518,19 @@ export function createNodes(deps) {
             return {
                 inboundLinks: await deps.repository.countInboundLinks(node.id),
                 totalItems: tree.nodeIds.length + tree.flowIds.length,
+                /**
+                 * ⚠️ **Named, not just counted** (D71, #733), and the cap is stated rather than silent:
+                 * `totalItems` keeps counting past it, so a surface can always say "and 40 more". Whoever
+                 * confirms a purge is deciding about things, and "82 items" is not a thing.
+                 *
+                 * The node itself is in here too. It is the one the caller named, so it is the one they can
+                 * check the list against.
+                 */
+                items: tree.named.slice(0, PURGE_PREVIEW_NAMES).map((entry) => ({
+                    id: entry.id,
+                    kind: entry.kind,
+                    title: entry.title,
+                })),
             };
         },
         /**
@@ -552,6 +567,10 @@ export function createNodes(deps) {
         // its ACLs, rather than being reimplemented on the flow side.
         async folderAccess(actor, folderId) {
             const folder = await deps.repository.getVisible(actor, folderId);
+            // ⚠️ An archived folder answers `missing` rather than a state of its own: filing into one is
+            // refused exactly like filing into one that is not there. The question "is the folder above
+            // archived" is asked by `parentArchivedAt` instead, because it must not run through the
+            // visibility predicate at all (#733).
             if (!folder || folder.archivedAt)
                 return "missing";
             if (folder.kind !== "folder")
@@ -1033,24 +1052,50 @@ export function createNodes(deps) {
             if (replayedId)
                 return await requireVisible(actor, replayedId);
             /**
-             * ⚠️ **A task with live subtasks is refused, not archived with them** (#669).
-             * `destructive.md`: *verweigern schlägt kaskadieren* — a cascade turns one confirmed click
-             * into an unknown number of disappearances, and the question that was asked ("archive this
-             * card") cannot then name what actually vanishes.
+             * ⚠️ **Archiving takes the whole subtree, flows included** (D71, #733), and the refusal that
+             * used to stand here is gone with it. `task_has_subtasks` (#669) refused a card with live
+             * subtasks, on the reasoning that a cascade turns one confirmed click into an unknown number
+             * of disappearances.
+             *
+             * That reasoning holds for `purge` and not for this call. The two steps are not symmetric:
+             * archiving is REVERSIBLE, so cascading it costs nothing that cannot be undone, while `purge`
+             * has cascaded over the subtree since #492 and cannot be undone at all. With the cascade on
+             * this side, nothing live sits under an archived node any more — which is precisely what
+             * makes the purge honest, and what `refuseArchivedParent` below keeps true afterwards.
+             *
+             * ⚠️ The counterpart is the restore, and it is the part that can quietly do too much or too
+             * little. It brings back what fell with THIS operation **and hangs under the node being
+             * restored** — a child archived earlier keeps its own operation and stays archived, and
+             * restoring a leaf does not drag its whole former tree back with it.
+             */
+            /**
+             * ⚠️ **Archiving something that is already archived changes nothing, deliberately** (found in
+             * review of #738). Without this it mints a NEW operation on the root while the cascade skips
+             * every child (`archived_at IS NULL`), so the children keep the old one — and a later restore
+             * hands back an empty folder while its contents stay archived, with nothing saying so.
              *
-             * ⚠️ It is refused only ON THE WAY IN. Restoring a parent must stay possible, or a card
-             * archived together with its children by an older path could never come back.
+             * The likeliest way there is not misuse but a retry after a timeout with a fresh idempotency
+             * key: the key does not catch it, and the operation is re-minted.
+             */
+            if (input.archived && current.archivedAt !== null)
+                return current;
+            /**
+             * ⚠️ **A restore under an archived parent is refused, and this is the other half of
+             * `refuseArchivedParent`** (found in review of #738). Without it the cascade closes nothing:
+             * archive a child alone, archive the folder over it, restore the child, and a LIVE node hangs
+             * under an archived one again — where `purge` reaches it, because it checks `archived_at` on
+             * the root alone and walks the whole subtree.
              *
-             * The other half — `purge` — needs no rule of its own, but ONLY together with
-             * `refuseArchivedParent` below: only an archived node may be purged, a parent cannot reach
-             * that state while a child is live, and nothing new may be filed under it afterwards. Take
-             * any one of the three away and a live card can be deleted for good without being named —
-             * which is what the review of #669 found in the first version of this sentence.
+             * The refusal names the way out rather than the rule: whoever wants this child back wants the
+             * folder back first, and then the child comes with it.
              */
-            if (input.archived && current.kind === "task") {
-                const children = await deps.repository.countLiveChildren(current.id);
-                if (children > 0) {
-                    throw new IntelError(409, "task_has_subtasks", `This card still has ${children} subtask(s). Archive them first, or move them somewhere else — archiving a card does not archive what hangs under it.`);
+            if (!input.archived && current.parentId !== null) {
+                // ⚠️ Read WITHOUT the visibility predicate, see `parentArchivedAt`: asked through
+                // `getVisible` this guard misses exactly the actor it exists for, the one holding a grant on
+                // the child alone.
+                const parent = await deps.repository.parentArchivedAt(current.parentId);
+                if (parent?.archivedAt) {
+                    throw new IntelError(409, "parent_archived", `This ${parent.kind} is archived, so nothing under it can be restored on its own. Restore it first, and this comes back with it.`);
                 }
             }
             const updatedAt = deps.now().toISOString();
@@ -1058,6 +1103,7 @@ export function createNodes(deps) {
                 nodeId: current.id,
                 baseUpdatedAt: input.baseUpdatedAt,
                 archivedAt: input.archived ? updatedAt : null,
+                operationId: deps.id(),
                 updatedAt,
                 actorId: actor.id,
                 idempotencyKey: input.idempotencyKey,
@@ -1083,9 +1129,21 @@ export function createNodes(deps) {
              *
              * A replayed archive never reaches this line — it returned above, on the idempotency key — so
              * repeating the same call does not ask the index to forget the same names twice.
+             *
+             * ⚠️ **The whole subtree, not the root** (D71, #733, found in review of #738). Since archiving
+             * cascades, a folder with fifty documents takes fifty nodes out of sight — and every one of
+             * them would keep its place in the candidate list if only the root were enqueued. The pass
+             * reads each node's state, so a node that was already archived costs one no-op rather than a
+             * wrong answer.
+             *
+             * ⚠️ It is one enqueue per versioned node in the subtree, sequentially, and each one is a
+             * subrequest. A tree large enough runs into the Workers limit AFTER the batch has committed:
+             * archived tree, error to the caller, index half followed. That is #754, and it needs
+             * `sendBatch` or a sweeper rather than a cap here — a cap would be the silent kind.
              */
-            if (updated.currentVersionId)
-                await deps.indexing.enqueue(updated.currentVersionId);
+            for (const versionId of await deps.repository.versionIdsInSubtree(updated.id)) {
+                await deps.indexing.enqueue(versionId);
+            }
             return updated;
         },
         /**

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

@@ -55,23 +55,6 @@ export interface NodeRepository {
         limit: number;
     }): Promise<BoundedChildren>;
     getVisible(actor: Actor, nodeId: string): Promise<Node | null>;
-    /**
-     * How many live children this node has — **every kind, tasks included** (#669).
-     *
-     * ⚠️ **`listVisibleBounded` cannot answer this**, and the difference is invisible at the call
-     * site: that query runs through `visibleChildren`, which cuts `kind = 'task'` out of every level
-     * so a board shows no cards in the tree (D66). Asked about a task, it therefore answers `0` for
-     * every task that ever existed — a guard built on it would never fire once, and nothing would
-     * report that. Two queries with similar names are two different questions
-     * (`destructive.md`, `anchrd/intel#457`).
-     *
-     * ⚠️ **It takes no actor, and that is the second half of the same lesson.** A grant can sit on a
-     * single node (ADR-0004 §2), so a child may be invisible to whoever archives its parent. Counted
-     * through the visibility predicate, such a child reads as `0`, the refusal does not fire, the
-     * parent becomes purgeable — and the child is deleted for good without ever being named. The
-     * question here is "is anything still hanging under this node", not "what may this actor see".
-     */
-    countLiveChildren(nodeId: string): Promise<number>;
     listVisibleSubtree(actor: Actor, rootId: string | null): Promise<SubtreeNode[]>;
     can(actor: Actor, nodeId: string, verb: ResourceVerb): Promise<boolean>;
     findIdempotentNode(actorId: string, operation: "node.create" | "node.save" | "node.append" | "node.update" | "node.archive" | "node.share" | "node.revoke" | SnapshotOperation, idempotencyKey: string): Promise<string | null>;
@@ -96,16 +79,27 @@ export interface NodeRepository {
         nodeId: string;
         baseUpdatedAt: string;
         archivedAt: string | null;
+        operationId: string;
         updatedAt: string;
         actorId: string;
         idempotencyKey: string;
         auditId: string;
     }): Promise<"conflict" | Node>;
+    versionIdsInSubtree(nodeId: string): Promise<string[]>;
+    parentArchivedAt(nodeId: string): Promise<{
+        archivedAt: string | null;
+        kind: string;
+    } | null>;
     hasAnyChild(nodeId: string): Promise<boolean>;
     listVectorKeys(nodeId: string): Promise<string[]>;
     countInboundLinks(nodeId: string): Promise<number>;
     inspectPurgeTree(nodeId: string): Promise<{
         nodeIds: string[];
+        named: Array<{
+            id: string;
+            kind: string;
+            title: string;
+        }>;
         flowIds: string[];
         contentKeys: string[];
         vectorKeys: Array<{
@@ -356,6 +350,11 @@ export interface NodeService {
     }): Promise<{
         inboundLinks: number;
         totalItems: number;
+        items: Array<{
+            id: string;
+            kind: NodeKind;
+            title: string;
+        }>;
     }>;
     listGrants(actor: Actor, resourceId: string): Promise<ResourceGrantList>;
     listEffectiveAccess(actor: Actor, resourceId: string): Promise<import("@anchrd/intel-contract/share").ResourceAccessList>;

package/migrations/0025_archiving_takes_the_subtree.sql

@@ -0,0 +1,29 @@
+-- Archiving takes the whole subtree, and this column is what lets it come back (D71, #733).
+--
+-- ⚠️ **The two steps were the wrong way round.** `purge` cascaded over the subtree since #492 while
+-- `archive` touched a single row, so a folder archived over live children handed those children to
+-- the one step that cannot be undone. Cascading the REVERSIBLE step instead closes the whole chain:
+-- nothing live sits under an archived node any more, so the purge can keep cascading without ever
+-- reaching something alive.
+--
+-- What this column holds is the OPERATION a node fell with, not a flag. A restore brings back
+-- exactly the nodes that fell together, and a child that was already archived before keeps its own
+-- older operation id — and stays archived.
+--
+-- ⚠️ **Existing data keeps `NULL` here**, and that is not the same as "fell alone": it means
+-- "archived before this migration, and nobody recorded what it fell with". A restore therefore
+-- treats `NULL` as itself only, never as a group — otherwise restoring one old node would revive
+-- every node ever archived before today.
+ALTER TABLE nodes ADD COLUMN archived_with TEXT;
+
+-- The restore reads this column for one node and then finds its siblings by it. Without the index
+-- that is a scan of the whole table on every restore of a large folder.
+CREATE INDEX IF NOT EXISTS nodes_archived_with ON nodes (archived_with) WHERE archived_with IS NOT NULL;
+
+-- ⚠️ **Flows fall with the tree, so they need the same column.** They hang in the folder tree by
+-- `parent_id` and carry their own `archived_at`, and `inspectPurgeTree` collects them by that same
+-- parent. A cascade that took only `nodes` would leave exactly one kind of live thing under an
+-- archived folder — the kind this repository's own flows are filed as.
+ALTER TABLE flows ADD COLUMN archived_with TEXT;
+
+CREATE INDEX IF NOT EXISTS flows_archived_with ON flows (archived_with) WHERE archived_with IS NOT NULL;

package/package.json

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