@anchrd/intel-api 0.35.0 → 0.37.0

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-feed.d.ts

@@ -1,23 +1,5 @@
 import type { FeedRepository } from "../../feed/feed.types.js";
 import type { D1Database } from "./db.types.js";
-/**
- * One page of the journal, newest first, cut down to the rows this actor may see.
- *
- * ⚠️ **The visibility check is the same JOIN against `allowed` that `audit_list` uses**, which is
- * the same tree walk `nodes` reads through (`db-grants.ts`). An event about a node is visible
- * exactly when the node is. A second, similar-looking query beside the first is the drift that
- * `anchrd/intel#457` was built out of: two queries with similar names are two different questions.
- *
- * ⚠️ **`ORDER BY` and the cursor comparison name BOTH columns, in the same direction.** Two events
- * in the same millisecond are the normal case inside a batch, not the exception; on `occurred_at`
- * alone the second one is skipped in silence. SQLite has no row-value comparison here, so the
- * tuple comparison is written out: "earlier timestamp, OR same timestamp and smaller id".
- *
- * ⚠️ **Both columns descend, and that is what lets the index carry this.** `audit_events_feed_idx`
- * is `(resource_type, occurred_at, id)` ascending; SQLite reads an index backwards only when every
- * sort column is reversed together. Reversing one would cost a sort over the whole table, and that
- * is invisible on the first pages and only hurts far down.
- */
 export declare const feedPageQuery: string;
 /**
  * The folders above each of a page's nodes, and only the ones the actor may open.
@@ -32,6 +14,14 @@ export declare const feedPageQuery: string;
  * and `UNION` ends the walk because the row repeats — a depth counter would make every row unique
  * and turn the same cycle into a query that never returns. The order is rebuilt in TypeScript from
  * `parent_id`, where a visited-set makes the cycle harmless.
+ *
+ * ⚠️ **The seeds are the PARENTS, not the nodes** (#645). Starting at the node and stepping up to
+ * its parent works only while the node exists, and the one event that most needs a trail is the one
+ * whose node is gone. Starting a level higher costs nothing for the ordinary case — the parent is
+ * where the walk went anyway — and it is the only anchor a deletion has left.
+ *
+ * There is no `seed` column: ids are unique, so one flat set of visible ancestors serves every card
+ * on the page, and each trail is rebuilt from its own `parentId` through that set.
  */
 export declare const feedAncestorsQuery: (seeds: number) => string;
 export declare function createFeedRepository(deps: {

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

@@ -1,9 +1,12 @@
-import { FeedAction } from "@anchrd/intel-contract/feed";
-import { subtreeBindings, subtreeCte } from "./db-grants.js";
-// Built once from the contract enum rather than written out here: two lists of actions that have to
-// agree would eventually stop agreeing, and the one that silently wins is the SQL.
-const ACTIONS = FeedAction.options;
-const ACTION_PLACEHOLDERS = ACTIONS.map(() => "?").join(", ");
+import { FeedAction, feedKindOf, } from "@anchrd/intel-contract/feed";
+import { flowInSubtreeBindings, flowInSubtreeOver, subtreeBindings, subtreeCte, } from "./db-grants.js";
+// The two kinds of resource the feed reads, split out of the one action list so the SQL can name
+// each side by itself. Derived from the contract rather than written again here: one list that has
+// to agree with another is one list too many.
+const NODE_ACTIONS = FeedAction.options.filter((action) => feedKindOf(action) === "node");
+const FLOW_ACTIONS = FeedAction.options.filter((action) => feedKindOf(action) === "flow");
+const NODE_PLACEHOLDERS = NODE_ACTIONS.map(() => "?").join(", ");
+const FLOW_PLACEHOLDERS = FLOW_ACTIONS.map(() => "?").join(", ");
 function parseMetadata(raw) {
     // The column is `NOT NULL DEFAULT '{}'` but it is written by eleven call sites over
     // `JSON.stringify` on whatever each had at hand. A row that cannot be parsed must not take the
@@ -29,24 +32,72 @@ function parseMetadata(raw) {
  * exactly when the node is. A second, similar-looking query beside the first is the drift that
  * `anchrd/intel#457` was built out of: two queries with similar names are two different questions.
  *
+ * ⚠️ **Two events have no row left to check, and that is why the join reads `COALESCE`** (#645 for
+ * `node.purge`, #763 for `flows.purge`).
+ * After `node.purge` the row is gone, so `JOIN nodes` dropped the event for everybody — creation,
+ * change and archiving arrived, final deletion never did. It now falls back to the `parentId` the
+ * purge wrote into its own metadata, and the check runs against that surviving FOLDER.
+ *
+ * The fallback is deliberately narrow: `COALESCE(n.id, …)` prefers the node whenever it exists, so
+ * for every other event nothing changes at all. It is not "or the parent is allowed" — that would
+ * hand out every event in a readable folder about nodes inside it that are NOT readable.
+ *
+ * ⚠️ **The title comes from the metadata for the same reason** — there is no row to read it from —
+ * and events written before #645 carry no `parentId`, so they stay unreachable. That cannot be
+ * repaired: at a deleted row there is nothing left to look up where it hung.
+ *
  * ⚠️ **`ORDER BY` and the cursor comparison name BOTH columns, in the same direction.** Two events
  * in the same millisecond are the normal case inside a batch, not the exception; on `occurred_at`
  * alone the second one is skipped in silence. SQLite has no row-value comparison here, so the
  * tuple comparison is written out: "earlier timestamp, OR same timestamp and smaller id".
  *
- * ⚠️ **Both columns descend, and that is what lets the index carry this.** `audit_events_feed_idx`
- * is `(resource_type, occurred_at, id)` ascending; SQLite reads an index backwards only when every
- * sort column is reversed together. Reversing one would cost a sort over the whole table, and that
- * is invisible on the first pages and only hurts far down.
+ * ⚠️ **Both columns descend, and that is what lets an index carry this.** SQLite reads an index
+ * backwards only when every sort column is reversed together. Reversing one would cost a sort over
+ * the whole table, and that is invisible on the first pages and only hurts far down.
+ *
+ * ⚠️ **The index that carries it is `audit_events_time_idx`, NOT `audit_events_feed_idx`** (#763).
+ * The feed reads two kinds at once, and the older index leads with `resource_type`; under
+ * `IN ('node', 'flow')` — or, as written here, under two branches joined by `OR` — that column
+ * stops being an equality prefix, and the ordering falls off it. Measured before `0026` existed:
+ * `SEARCH e USING INDEX audit_events_feed_idx (resource_type=?)` followed by
+ * `USE TEMP B-TREE FOR ORDER BY`. The older index stays for `audit_list`, which names one kind.
+ *
+ * ⚠️ **The unary `+` in front of each `resource_type` is load-bearing, not a typo.** It tells SQLite
+ * the term may not drive an index. Without it the planner sees two indexable `OR` branches, picks
+ * `MULTI-INDEX OR` over the OLD index — one search per branch, both on `resource_type=?` — and buys
+ * the filtering back at the price of the ordering: `USE TEMP B-TREE FOR ORDER BY` returns, over the
+ * whole table. Measured both ways. Filtering on kind is cheap here (two values out of three);
+ * sorting the journal is not.
+ *
+ * ⚠️ **The two halves ask two DIFFERENT authorization questions, and neither may stand in for the
+ * other.** A node is visible when the node itself is in `allowed`; a flow when its FOLDER is, or
+ * when it carries a grant of its own — flows hang in the tree but have nothing beneath them, so
+ * `flowInSubtree` is the rule and `allowed.id = flow.id` would answer about a node that does not
+ * exist. Both halves fall back on the metadata `parentId` for the one event whose row is gone.
  */
+const FLOW_PARENT = "COALESCE(flow.parent_id, json_extract(e.metadata_json, '$.parentId'))";
+const NODE_PARENT = "COALESCE(n.id, json_extract(e.metadata_json, '$.parentId'))";
 export const feedPageQuery = `${subtreeCte}
-    SELECT e.id, e.actor_id, e.action, e.resource_id, n.title AS node_title,
-           n.parent_id AS node_parent_id, e.metadata_json, e.occurred_at
+    SELECT e.id, e.actor_id, e.action, e.resource_id,
+           COALESCE(n.title, flow.title, json_extract(e.metadata_json, '$.title')) AS resource_title,
+           COALESCE(n.parent_id, flow.parent_id, json_extract(e.metadata_json, '$.parentId'))
+             AS resource_parent_id,
+           e.metadata_json, e.occurred_at
     FROM audit_events e
-    JOIN allowed ON allowed.id = e.resource_id
-    JOIN nodes n ON n.id = e.resource_id
-    WHERE e.resource_type = 'node'
-      AND e.action IN (${ACTION_PLACEHOLDERS})
+    LEFT JOIN nodes n ON n.id = e.resource_id AND e.resource_type = 'node'
+    LEFT JOIN flows flow ON flow.id = e.resource_id AND e.resource_type = 'flow'
+    WHERE (
+        (
+          +e.resource_type = 'node'
+          AND e.action IN (${NODE_PLACEHOLDERS})
+          AND ${NODE_PARENT} IN (SELECT id FROM allowed)
+        )
+        OR (
+          +e.resource_type = 'flow'
+          AND e.action IN (${FLOW_PLACEHOLDERS})
+          AND ${flowInSubtreeOver(FLOW_PARENT)}
+        )
+      )
       AND (? IS NULL OR e.actor_id = ?)
       AND (
         ? IS NULL
@@ -68,19 +119,26 @@ export const feedPageQuery = `${subtreeCte}
  * and `UNION` ends the walk because the row repeats — a depth counter would make every row unique
  * and turn the same cycle into a query that never returns. The order is rebuilt in TypeScript from
  * `parent_id`, where a visited-set makes the cycle harmless.
+ *
+ * ⚠️ **The seeds are the PARENTS, not the nodes** (#645). Starting at the node and stepping up to
+ * its parent works only while the node exists, and the one event that most needs a trail is the one
+ * whose node is gone. Starting a level higher costs nothing for the ordinary case — the parent is
+ * where the walk went anyway — and it is the only anchor a deletion has left.
+ *
+ * There is no `seed` column: ids are unique, so one flat set of visible ancestors serves every card
+ * on the page, and each trail is rebuilt from its own `parentId` through that set.
  */
 export const feedAncestorsQuery = (seeds) => `${subtreeCte},
-  ancestry(seed, id, parent_id, title) AS (
-    SELECT child.id, parent.id, parent.parent_id, parent.title
-    FROM nodes child
-    JOIN nodes parent ON parent.id = child.parent_id
-    WHERE child.id IN (${Array.from({ length: seeds }, () => "?").join(", ")})
+  ancestry(id, parent_id, title) AS (
+    SELECT parent.id, parent.parent_id, parent.title
+    FROM nodes parent
+    WHERE parent.id IN (${Array.from({ length: seeds }, () => "?").join(", ")})
     UNION
-    SELECT a.seed, grandparent.id, grandparent.parent_id, grandparent.title
+    SELECT grandparent.id, grandparent.parent_id, grandparent.title
     FROM nodes grandparent
     JOIN ancestry a ON a.parent_id = grandparent.id
   )
-  SELECT a.seed, a.id, a.parent_id, a.title
+  SELECT a.id, a.parent_id, a.title
   FROM ancestry a
   JOIN allowed ON allowed.id = a.id`;
 /**
@@ -115,36 +173,40 @@ export function createFeedRepository(deps) {
     return {
         async listEvents(actor, query) {
             const before = query.before ?? null;
+            // One reading of the clock for the whole call. Both guards measure grant expiry against it,
+            // and two `now()` calls could straddle the moment a grant runs out — a page whose flow half
+            // answers about a permission its node half no longer has.
+            const now = deps.now().toISOString();
             const page = await deps.db
                 .prepare(feedPageQuery)
-                .bind(...subtreeBindings(actor, "read", deps.now().toISOString()), ...ACTIONS, query.actor, query.actor, before === null ? null : before.occurredAt, before === null ? null : before.occurredAt, before === null ? null : before.occurredAt, before === null ? null : before.id, query.limit)
+                .bind(...subtreeBindings(actor, "read", now), ...NODE_ACTIONS, ...FLOW_ACTIONS, ...flowInSubtreeBindings(actor, "read", now), query.actor, query.actor, before === null ? null : before.occurredAt, before === null ? null : before.occurredAt, before === null ? null : before.occurredAt, before === null ? null : before.id, query.limit)
                 .all();
             const rows = page.results ?? [];
             if (rows.length === 0)
                 return { events: [] };
             // One walk for the whole page rather than one per row. The set is at most the page size, and
             // it is deduplicated because a busy morning on one document is exactly the case the feed
-            // shows unsummarised today.
-            const nodeIds = [...new Set(rows.map((row) => row.resource_id))];
-            const ancestors = await deps.db
-                .prepare(feedAncestorsQuery(nodeIds.length))
-                .bind(...subtreeBindings(actor, "read", deps.now().toISOString()), ...nodeIds)
-                .all();
-            const ancestorRows = ancestors.results ?? [];
-            const parentOf = new Map(rows.map((row) => [row.resource_id, row.node_parent_id]));
-            const trails = new Map(nodeIds.map((id) => [
-                id,
-                trailFor(parentOf.get(id) ?? null, ancestorRows.filter((row) => row.seed === id)),
-            ]));
+            // shows unsummarised today. The trail is keyed by EVENT rather than by node: two events about
+            // one node share a trail, but a deleted node and a live one can carry the same parent.
+            const parentIds = [
+                ...new Set(rows.map((row) => row.resource_parent_id).filter((id) => id !== null)),
+            ];
+            const ancestorRows = parentIds.length === 0
+                ? []
+                : ((await deps.db
+                    .prepare(feedAncestorsQuery(parentIds.length))
+                    .bind(...subtreeBindings(actor, "read", now), ...parentIds)
+                    .all()).results ?? []);
+            const trails = new Map(rows.map((row) => [row.id, trailFor(row.resource_parent_id, ancestorRows)]));
             const events = rows.map((row) => ({
                 id: row.id,
                 actorId: row.actor_id,
                 // Narrowed at the door by the SQL `IN`, so the cast names what the query already
                 // guarantees rather than trusting the column.
                 action: row.action,
-                nodeId: row.resource_id,
-                nodeTitle: row.node_title,
-                path: trails.get(row.resource_id) ?? [],
+                resourceId: row.resource_id,
+                resourceTitle: row.resource_title,
+                path: trails.get(row.id) ?? [],
                 metadata: parseMetadata(row.metadata_json),
                 occurredAt: row.occurred_at,
             }));

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

@@ -532,7 +532,8 @@ export function createFlowRepository(deps) {
                 deps.db
                     .prepare(`INSERT INTO audit_events (
             id, actor_id, action, resource_type, resource_id, metadata_json, occurred_at
-          ) SELECT ?, ?, 'flows.purge', 'flow', f.id, json_object('title', f.title), ?
+          ) SELECT ?, ?, 'flows.purge', 'flow', f.id,
+              json_object('title', f.title, 'parentId', f.parent_id), ?
             FROM flows f WHERE f.id = ? AND f.archived_at IS NOT NULL`)
                     .bind(input.auditId, input.actorId, input.occurredAt, input.flowId),
                 // The runs are this flow's history: the steps hang off the runs, the runs off the flow.

package/dist/adapters/db/db-grants.d.ts

@@ -106,5 +106,15 @@ export declare function flowVerbBindings(flowId: string, actor: GrantActor, verb
  * different verbs would produce a predicate that is neither, and it is the kind of mismatch nothing
  * fails on: the query still runs and quietly hands out the wrong list.
  */
+/**
+ * ⚠️ The parent is a PARAMETER for exactly one caller, and giving it one was cheaper than the
+ * alternative. The feed reads events about flows that no longer exist: after `flows.purge` the row
+ * is gone, so `flow.parent_id`, `flow.owner_id` and every `flow_grants` row are gone with it, and
+ * the only anchor left is the `parentId` the purge wrote into its own metadata (#763, D73). A
+ * second, similar-looking predicate beside this one is the drift `destructive.md` warns about: two
+ * expressions with similar names are two different questions, and the one that goes stale is the
+ * copy.
+ */
+export declare function flowInSubtreeOver(parentExpression: string): string;
 export declare const flowInSubtree: string;
 export declare function flowInSubtreeBindings(actor: GrantActor, verb: ResourceVerb, now: string): unknown[];

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

@@ -233,12 +233,24 @@ export function flowVerbBindings(flowId, actor, verb, now) {
  * different verbs would produce a predicate that is neither, and it is the kind of mismatch nothing
  * fails on: the query still runs and quietly hands out the wrong list.
  */
-export const flowInSubtree = `(
+/**
+ * ⚠️ The parent is a PARAMETER for exactly one caller, and giving it one was cheaper than the
+ * alternative. The feed reads events about flows that no longer exist: after `flows.purge` the row
+ * is gone, so `flow.parent_id`, `flow.owner_id` and every `flow_grants` row are gone with it, and
+ * the only anchor left is the `parentId` the purge wrote into its own metadata (#763, D73). A
+ * second, similar-looking predicate beside this one is the drift `destructive.md` warns about: two
+ * expressions with similar names are two different questions, and the one that goes stale is the
+ * copy.
+ */
+export function flowInSubtreeOver(parentExpression) {
+    return `(
   ? = 1
   OR flow.owner_id = ?
-  OR flow.parent_id IN (SELECT id FROM allowed)
+  OR ${parentExpression} IN (SELECT id FROM allowed)
   OR ${flowGrantExists("flow.id")}
 )`;
+}
+export const flowInSubtree = flowInSubtreeOver("flow.parent_id");
 export function flowInSubtreeBindings(actor, verb, now) {
     return [actor.isAdmin ? 1 : 0, actor.id, ...grantBindings(actor, verb, now)];
 }

package/dist/adapters/db/db.js

@@ -904,11 +904,18 @@ export function createNodeRepository(deps) {
                 // ⚠️ FIRST, and reading the title out of the row that falls at the end of this batch. Its
                 // `WHERE EXISTS` is what makes it honest: no row, no entry — a purge that hit nothing does
                 // not book one.
+                //
+                // ⚠️ **`parentId` travels beside the title, and it is what makes this row READABLE
+                // afterwards** (#645). Visibility everywhere else walks `nodes` from the row itself, and
+                // after this batch that row is gone — so until now the event was unreachable for everybody,
+                // admin included. The surviving FOLDER answers instead. It is written here rather than
+                // derived later for the same reason the title is: after the delete there is nothing left to
+                // look either of them up from (`destructive.md`).
                 deps.db
                     .prepare(`INSERT INTO audit_events (
             id, actor_id, action, resource_type, resource_id, metadata_json, occurred_at
           ) SELECT ?, ?, 'node.purge', 'node', n.id,
-              json_patch(?, json_object('title', n.title, 'kind', n.kind)), ?
+              json_patch(?, json_object('title', n.title, 'kind', n.kind, 'parentId', n.parent_id)), ?
             FROM nodes n WHERE n.id = ? AND n.archived_at IS NOT NULL`)
                     .bind(input.auditId, input.actorId, JSON.stringify(input.metadata), input.occurredAt, input.nodeId),
                 deps.db

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);
@@ -308,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
@@ -317,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/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",

package/migrations/0026_one_feed_over_two_kinds.sql

@@ -0,0 +1,23 @@
+-- The feed reads both kinds at once — nodes and flows — and `audit_events_feed_idx` cannot serve
+-- that. It leads with `resource_type` because every reader until now named exactly one kind, so for
+-- a query saying `resource_type IN ('node', 'flow')` that column is no longer an equality prefix but
+-- an ordinary filter, and the ordering falls off the index.
+--
+-- ⚠️ Measured against the real `feedPageQuery` before this file existed, not assumed
+-- (anchrd/intel#763):
+--
+--     SEARCH e USING INDEX audit_events_feed_idx (resource_type=?)
+--     … | USE TEMP B-TREE FOR ORDER BY
+--
+-- That last line is a sorting pass over the whole table. It costs nothing on the first page and
+-- everything far down — which is exactly where an endless scroll goes.
+--
+-- ⚠️ Both columns, in the order the cursor compares them, for the reason `0022` gives: two events
+-- written in the same millisecond are the normal case inside one batch, and without the tie-break
+-- on `id` a reader skips the second one with no error and no log.
+--
+-- ⚠️ This does NOT replace `audit_events_feed_idx`. That one still serves `audit_list`, which names
+-- one kind and is the contract `anchrd/signals` builds on; dropping it would put a sorting pass into
+-- the reader that has none today. Two readers, two shapes, two indexes.
+CREATE INDEX audit_events_time_idx
+  ON audit_events(occurred_at, id);

package/package.json

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