limn-review 0.1.123

package/dist/db/daily-brief.js

@@ -0,0 +1,406 @@
+// ── The daily brief (plan P3.1 / N1): ONE deterministic "what needs me" fold per workspace ──
+//
+// Computed on read, stored nowhere (D5 — zero core migrations). Every line REUSES the exact fold
+// of the surface its strip line deep-links to, so a number and the view it opens cannot disagree
+// (the plan's ⚠: "never a re-derivation that can disagree with the surface it links to"):
+//
+//   myTurn /
+//   ciFailing /
+//   security /
+//   stalled /
+//   untouchedThreads /
+//   needsReviewer    → getWorkspaceInsights card counts — the same cards GET /api/attention
+//                      serves (one my_turn card = one thing on your plate; one security card =
+//                      one PR with a known-advisory fix or alert; one stalled_review card = one
+//                      PR; one untouched_thread card = one thread; one reviewer_routing card =
+//                      one PR needing a reviewer).
+//                      ⚠ `myTurn` USED TO be getConsolidatedFeed(...).counts.myTurn — a count of
+//                      feed EVENTS in a rolling 14 days, which corresponded to no clickable list
+//                      ("54 items" the user could not open). It is now literally the number of
+//                      my_turn cards the board emitted, which are in turn one-per-row of the
+//                      `getMyTurn(accountId, scope)` fold GET /api/my-turn serves — so the strip's
+//                      number, the board's list and the My Turn view are one population.
+//                      ⚠ Those cards are CAPPED (MY_TURN_CARD_CAP = 50) and the cap is DISCLOSED,
+//                      not hidden: `myTurnTotal` carries the uncapped population so the line can
+//                      read "50 of 148". The displayed figure stays `myTurn` — the card count —
+//                      because that is the list the click opens. See the shared type's doc.
+//   resolveBacklog   → getResolvableBotThreadPrs(...).totalThreads — the review-&-resolve tab's
+//                      own number (same predicate the resolve route re-derives).
+//   trunkRed         → the repos DEFAULT-BRANCH head snapshot columns (branch-status's source of
+//                      truth) — red = 'failure' | 'error'; pending/unknown are not red.
+//                      ⚠ NOT the same population as `ciFailing` above, and neither replaces the
+//                      other: this names EVERY red trunk in the workspace and opens that repo's
+//                      console; `ciFailing` counts the ones you MAINTAIN plus your own red PRs and
+//                      opens the attention board. Two figures, two lists, two destinations.
+//   botAnomalies     → a NARROW volume-only self-baseline (below) — deliberately NOT the full
+//                      getBotBehaviourAnalytics compute (trends+heatmaps+overlap+ML fold over
+//                      every bot), which is priced for an explicit Pro tab open, not an
+//                      every-morning free strip.
+//
+// ── The anomaly slice (the cost decision, spelled out) ──
+// Weekly bot-activity counts (review_comment | pr_comment | review_submitted events) per
+// role-'review' automated reviewer over the last 84 days — one indexed scan of `events`, no
+// thread/ML/heatmap work — folded through the SAME exported `weeklyAnomalies` (median ± MAD,
+// z ≥ 3) the behaviour tab uses, with the SAME volume discipline: zero weeks are null (a
+// "typical volume" means "how much when it's working"; going dark is the silence detector's
+// question and this slice deliberately does not ask it), direction 'both', minScale 2. A bot is
+// flagged when its CURRENT trailing-7-day bucket is the anomalous one — the brief is about this
+// week, not history.
+//
+// ── TWO caches, and the line between them (⚠ do not merge them back into one) ──
+// The brief USED to sit behind a single 5-minute per-(accountId, workspaceId) TTL covering every
+// slice. That made the strip's headline a snapshot of a fold whose LIST is live: `myTurn` is the
+// my_turn card count, the click opens GET /api/attention, and that route recomputes the very same
+// getWorkspaceInsights fold on every request with no cache at all. Dismiss two cards (or open two
+// of your PRs — `pr_views` moves the fold too) and the strip kept saying 5 over a board of 3 for
+// up to five more minutes. A count that a single click disproves is not "≤5 min stale", it is
+// wrong; disclosing the staleness would not have made it right.
+//
+// So the split is by WHETHER THE NUMBER SITS ABOVE A LIVE LIST:
+//
+//   COUNTS (the four card counts + resolveBacklog + trunkRed) — computed FRESH on every read of
+//     `getDailyBriefEntry`, the ACTIVE workspace's line. Each one is the same fold the surface it
+//     deep-links to serves on demand, so it must be evaluated at the same moment the user looks
+//     at it. This is affordable precisely BECAUSE the anomaly slice below is not in it.
+//   botAnomalies — keeps its OWN 5-min TTL (`anomalyCache`). It is an 84-day `events` scan, and
+//     it backs NO clickable list: its line reads "unusual volume this week" and opens a bot tab,
+//     so nothing a click renders can contradict a five-minute-old flag.
+//   The ROLL-UP + the Pro narration inputs — keep a whole-counts TTL (`countsCache`, reached
+//     through `getDailyBriefCounts`). The "Elsewhere" lines describe OTHER workspaces: clicking
+//     one switches workspace, which then fetches that workspace's own FRESH brief, so the number
+//     is re-derived before any list can disagree with it. Freshening the loop instead would
+//     multiply getWorkspaceInsights by workspace count on every Feed mount — the cost this route
+//     is on the `search` tier for. A My Turn settings save drops the account's entries
+//     (`clearDailyBriefCountsFor`), because it changes WHICH cards exist, not just how many.
+//     So does the SPA change signal (sync/pr-change-signal.ts `onPrChanged`, registered below):
+//     every write route, settle re-read, webhook sync and liveness sweep that moves a
+//     board-visible column raises it, and the SPA refetches the strip on it — a roll-up line
+//     still answering from before the change would then disagree with the Pending tabs it
+//     counts for up to COUNTS_TTL_MS. It drops the whole ACCOUNT (the signal names a repo, and
+//     mapping it to its workspace would be a query inside a synchronous listener). ⚠ This does
+//     NOT weaken the narration's cost gate below: the TTL still absorbs READ churn, and a
+//     narration regenerates only on a click (POST /api/pro/synthesis) whose payload hash really
+//     did move — a figure that changed is exactly what a regeneration is for.
+//
+// ⚠ THEREFORE `generatedAt` DESCRIBES TWO COMPUTATION TIMES, and the honest one is the tighter:
+// it stamps the COUNTS (now == the request), while `botAnomalies` inside the same object may be
+// up to ANOMALY_TTL_MS older. That asymmetry is the feature, not an oversight — collapsing it
+// back into one cache to make one timestamp true again reintroduces the bug above.
+//
+// Both caches coalesce concurrent computes by storing the promise, and evict a REJECTED one so an
+// error never sticks for the whole window.
+import { and, eq, gte, inArray } from 'drizzle-orm';
+import { PENDING_LIMITS } from '../shared/index.js';
+import { db, schema } from './client.js';
+import { onPrChanged } from '../sync/pr-change-signal.js';
+import { automatedReviewerUserIds, classificationKindForUser, classificationLabelMap, getResolvableBotThreadPrs, getWorkspaceInsights, resolveWorkspaceScope, weeklyAnomalies, } from './queries.js';
+const WEEK_MS = 7 * 86_400_000;
+const SPAN_WEEKS = 12; // 84 days — the behaviour tab's own baseline span
+/** Defensive caps: the strip is a one-line-per-item surface, not a listing. */
+const ANOMALY_CAP = 5;
+const TRUNK_CAP = 8;
+/** The 84-day anomaly scan's own window (see the header — it backs no clickable list). */
+const ANOMALY_TTL_MS = 5 * 60_000;
+/** The roll-up / narration window — OTHER workspaces' lines, never the active one's. */
+const COUNTS_TTL_MS = 5 * 60_000;
+const anomalyCache = new Map();
+const countsCache = new Map();
+/** The one TTL read both caches share, so their eviction rules cannot drift apart. */
+function cached(map, key, ttlMs, compute) {
+    const now = Date.now();
+    const hit = map.get(key);
+    if (hit && now - hit.at < ttlMs)
+        return hit.promise;
+    const promise = compute();
+    map.set(key, { at: now, promise });
+    // An errored compute must not stick for the whole window.
+    promise.catch(() => {
+        if (map.get(key)?.promise === promise)
+            map.delete(key);
+    });
+    return promise;
+}
+/** Test seam: drop every cached brief slice (the module-level-cache convention). */
+export function clearDailyBriefCache() {
+    anomalyCache.clear();
+    countsCache.clear();
+}
+/** Drop ONE account's roll-up counts, so a My Turn settings save cannot leave "Elsewhere" lines
+ *  counting a type the reader just switched off for the rest of the five-minute window. The anomaly
+ *  slice is untouched: settings do not move it. Called by PUT /api/me/my-turn-settings, and by
+ *  the PR change signal's listener below. */
+export function clearDailyBriefCountsFor(accountId) {
+    for (const k of [...countsCache.keys()]) {
+        if (k.startsWith(`${accountId}:`))
+            countsCache.delete(k);
+    }
+}
+// A board-visible PR change drops the account's roll-up counts too (see the header). Registered at
+// module load, so the cache and its invalidation exist together or not at all.
+onPrChanged((accountId) => clearDailyBriefCountsFor(accountId));
+// The narrow volume-only anomaly slice (see the module header for why it is NOT the behaviour
+// compute). Returns at most ANOMALY_CAP bots, most-anomalous first.
+async function briefBotAnomalies(accountId, scope) {
+    if (scope.repoIds.length === 0)
+        return [];
+    const botIds = await automatedReviewerUserIds(accountId, scope.workspaceId, 'review');
+    if (botIds.length === 0)
+        return [];
+    const { events } = schema;
+    const nowMs = Date.now();
+    const since = new Date(nowMs - SPAN_WEEKS * WEEK_MS);
+    const rows = await db
+        .select({ actorId: events.actorId, occurredAt: events.occurredAt })
+        .from(events)
+        .where(and(eq(events.accountId, accountId), inArray(events.repoId, scope.repoIds), inArray(events.actorId, botIds), inArray(events.type, ['review_comment', 'pr_comment', 'review_submitted']), gte(events.occurredAt, since)))
+        .execute();
+    if (rows.length === 0)
+        return [];
+    // Rolling 7-day buckets ENDING NOW, oldest first — index 11 is the trailing week the brief
+    // reports on. (Calendar weeks would make Monday mornings compare a 1-day bucket to full ones.)
+    const byBot = new Map();
+    for (const r of rows) {
+        if (r.actorId == null)
+            continue;
+        const age = nowMs - r.occurredAt.getTime();
+        const bucket = SPAN_WEEKS - 1 - Math.min(SPAN_WEEKS - 1, Math.floor(age / WEEK_MS));
+        let counts = byBot.get(r.actorId);
+        if (!counts) {
+            counts = Array.from({ length: SPAN_WEEKS }, () => 0);
+            byBot.set(r.actorId, counts);
+        }
+        counts[bucket] = (counts[bucket] ?? 0) + 1;
+    }
+    const flagged = [];
+    for (const [userId, counts] of byBot) {
+        // Active-weeks-only baseline (zero weeks → null), the behaviour tab's volume discipline.
+        const series = counts.map((v) => (v > 0 ? v : null));
+        const anoms = weeklyAnomalies(series, { direction: 'both', minScale: 2 });
+        const current = anoms[SPAN_WEEKS - 1];
+        if (current != null)
+            flagged.push({ userId, z: current.z });
+    }
+    if (flagged.length === 0)
+        return [];
+    flagged.sort((a, b) => b.z - a.z);
+    const top = flagged.slice(0, ANOMALY_CAP);
+    const [labels, kinds] = await Promise.all([
+        classificationLabelMap(accountId, scope.workspaceId),
+        classificationKindForUser(accountId, scope.workspaceId),
+    ]);
+    const { users } = schema;
+    const userRows = await db
+        .select({ id: users.id, login: users.githubLogin })
+        .from(users)
+        .where(inArray(users.id, top.map((f) => f.userId)))
+        .execute();
+    const loginById = new Map(userRows.map((u) => [u.id, u.login]));
+    return top.map((f) => {
+        const login = loginById.get(f.userId) ?? null;
+        return {
+            userId: f.userId,
+            label: labels.get(f.userId) ?? login ?? `#${f.userId}`,
+            login,
+            kind: kinds.get(f.userId) ?? null,
+        };
+    });
+}
+// Every red default branch in the workspace, sorted, UNCAPPED — `computeBriefCounts` removes the
+// ones the reader promoted into My Turn first and only then applies TRUNK_CAP, so a promoted trunk
+// never takes a slot on this line and is counted once, in My Turn.
+async function trunkRedRepos(accountId, scope) {
+    if (scope.repoIds.length === 0)
+        return [];
+    const { repos } = schema;
+    const rows = await db
+        .select({ id: repos.id, name: repos.name, ci: repos.defaultBranchCiStatus })
+        .from(repos)
+        .where(and(eq(repos.accountId, accountId), inArray(repos.id, scope.repoIds)))
+        .execute();
+    return rows
+        .filter((r) => r.ci === 'failure' || r.ci === 'error')
+        .sort((a, b) => a.name.localeCompare(b.name))
+        .map((r) => ({ repoId: r.id, name: r.name }));
+}
+async function computeBriefCounts(accountId, workspaceId) {
+    // Number in → the resolver still owns membership (a foreign/dead id degrades to Default,
+    // exactly the scoped-route posture; the caller already resolved real requests).
+    const scope = await resolveWorkspaceScope(accountId, workspaceId);
+    const [insights, backlog, botAnomalies, allRedTrunks] = await Promise.all([
+        // The /api/attention fold verbatim (getWorkspaceInsights with the default window); the two
+        // bot cards it filters out are not counted here either. ⚠ UNCACHED, and that is the point:
+        // /api/attention re-runs this exact call on every request, so a cached copy here is a number
+        // the very next click disproves.
+        getWorkspaceInsights(accountId, undefined, scope),
+        getResolvableBotThreadPrs(accountId, scope),
+        // The ONE cached slice — the 84-day scan, keyed on the RESOLVED workspace (the raw argument
+        // may have degraded to Default). Membership changes reach it within ANOMALY_TTL_MS, which is
+        // fine here and only here: no list contradicts a bot-volume flag.
+        cached(anomalyCache, `${accountId}:${scope.workspaceId}`, ANOMALY_TTL_MS, () => briefBotAnomalies(accountId, scope)),
+        trunkRedRepos(accountId, scope),
+    ]);
+    // ⚠ A RED TRUNK THE READER PROMOTED INTO MY TURN IS COUNTED THERE, NOT HERE — it is a my_turn
+    // card (and in `myTurn` below), so listing it on this line too would count one red branch twice.
+    // Filtered after the fold resolves, then capped.
+    const promotedTrunks = new Set(insights.myTurnTrunkRepoIds ?? []);
+    const trunkRed = allRedTrunks.filter((t) => !promotedTrunks.has(t.repoId)).slice(0, TRUNK_CAP);
+    let myTurn = 0;
+    // The `MyTurnCard.personal` subset of the same cards — the figure the NOTIFICATION surfaces
+    // display, where the board keeps displaying `myTurn`. Counted off the cards for exactly the
+    // reason `myTurn` is: it is the number of PERSONAL cards the board actually paints, so its
+    // total (`myTurnPersonalTotal`, the pre-cap fold) is the only thing that may qualify it.
+    let myTurnPersonal = 0;
+    // The THREE-WAY split of those same cards, by `MyTurnCard.relevance`. The brief renders two
+    // MUTUALLY EXCLUSIVE lines off them — "N need your attention" (direct + maintained, i.e.
+    // `myTurnPersonal`, unchanged) and "M need review or reply" (`myTurnOther`) — and each line
+    // opens a board filtered to its own number, so each needs its own count AND its own total.
+    //
+    // ⚠ `myTurnOther` IS NOT `myTurn - myTurnPersonal`. The arithmetic agrees; the disclosure does
+    // not. `capFor` prints "of N" only when the displayed figure equals the count it qualifies, so
+    // a subtracted figure has no total it may legally borrow and the "of N" vanishes on every
+    // capped workspace — the pair-narrow-with-narrow rule, one level down.
+    let myTurnDirect = 0;
+    let myTurnMaintained = 0;
+    let myTurnOther = 0;
+    // Red builds the viewer is on the hook for — their own open PR, or trunk in a repo they
+    // maintain. Counted off the CARDS like every figure above, so the line and the board agree.
+    //
+    // ⚠ IT OVERLAPS `trunkRed` BELOW WITHOUT REPLACING IT, and the two lines are not interchangeable:
+    // `trunkRed` names EVERY red trunk in the workspace (maintained or not) and each of its lines
+    // opens that repo's console; this counts the subset that is YOURS plus your own red PRs, and its
+    // line opens the attention board isolated to `ci_failing`. Folding either into the other hands
+    // one of them a list its number does not match — the defect this whole strip exists to prevent.
+    let ciFailing = 0;
+    let stalled = 0;
+    let untouchedThreads = 0;
+    let needsReviewer = 0;
+    // ⚠ FOUR KINDS REACH THIS LOOP AND ARE COUNTED BY NO LINE: `merge`, `update_branch`,
+    // `conflicts` and `dependency_bump`. The first two are opportunities and the strip counts what is
+    // WAITING ON YOU. The third is a genuine problem, but 3 of every 4 are somebody else's PR in a
+    // repo you can merely push to — a "waiting on you" number over that population would be a false
+    // claim, and it would stop the strip self-hiding on a workspace where nothing is actually owed.
+    // The fourth is housekeeping — an update, not something waiting on you. (`security` IS counted,
+    // below, off `kindTotals` like the other survey lines.) This allow-list and the route's deny-list
+    // are the two hand-maintained spellings of "which kinds count"; daily-brief.test.ts compares them
+    // per kind, so an omission here is a CI failure, not a silence.
+    for (const c of insights.cards) {
+        if (c.kind === 'ci_failing')
+            ciFailing += 1;
+        else if (c.kind === 'my_turn') {
+            myTurn += 1;
+            if (c.personal)
+                myTurnPersonal += 1;
+            // Absent ⇒ fall back to the boolean, which cannot express 'maintained' (see
+            // `MyTurnRelevance`). getWorkspaceInsights above always sets it; this is wire tolerance.
+            const rel = c.relevance ?? (c.personal ? 'direct' : 'none');
+            if (rel === 'direct')
+                myTurnDirect += 1;
+            else if (rel === 'maintained')
+                myTurnMaintained += 1;
+            else
+                myTurnOther += 1;
+        }
+        else if (c.kind === 'stalled_review')
+            stalled += 1;
+        else if (c.kind === 'untouched_thread')
+            untouchedThreads += 1;
+        else if (c.kind === 'reviewer_routing')
+            needsReviewer += 1;
+    }
+    // ⚠ THE DISPLAYED FIGURES ARE WHAT THE PENDING BOARD LISTS. The board ranks the UNCAPPED
+    // population by score and lists the top `boardListCap` of each view — My turn, "Only yours", its
+    // complement, CI failing — so each line's figure is min(its total, that cap), paired with the
+    // total for the "of N" disclosure. Counting the cards of THIS capped fold instead would count a
+    // different 50 (the newest, by colour) and could disagree with the list the line opens.
+    const listed = (total, fallback) => total == null ? fallback : Math.min(total, PENDING_LIMITS.boardListCap);
+    myTurn = listed(insights.myTurnTotal, myTurn);
+    myTurnPersonal = listed(insights.myTurnPersonalTotal, myTurnPersonal);
+    myTurnOther = listed(insights.myTurnOtherTotal, myTurnOther);
+    ciFailing = listed(insights.ciFailingTotal, ciFailing);
+    // ⚠ THE DIRECT / MAINTAINED HALVES MUST ADD UP TO `myTurnPersonal`, because the Workspace badges
+    // print them beside it. They do exactly when every personal item fits on the list — then the
+    // listed set IS the whole population and the halves are its two totals. Past the cap, which of
+    // the two the top-scoring items are is the board's call, not this fold's, so the halves are left
+    // OUT and the badge shows the total alone (its existing "both or neither" refusal).
+    const personalFits = insights.myTurnPersonalTotal == null ||
+        insights.myTurnPersonalTotal <= PENDING_LIMITS.boardListCap;
+    const split = personalFits
+        ? {
+            myTurnDirect: insights.myTurnDirectTotal ?? myTurnDirect,
+            myTurnMaintained: insights.myTurnMaintainedTotal ?? myTurnMaintained,
+        }
+        : {};
+    return {
+        myTurn,
+        // The cap DISCLOSURE, passed straight through from the same getWorkspaceInsights call above
+        // (same fold, same scope, same default window) — so the strip's "of N" and the board's "of N"
+        // are one number, not two derivations that can drift. ⚠ `myTurn` above stays the figure the
+        // strip DISPLAYS: it is the number of cards the board will paint, and a strip that announced
+        // 148 over a board of 50 is exactly the "number you can't open" this brief replaced.
+        myTurnTotal: insights.myTurnTotal,
+        myTurnPersonal,
+        // ⚠ THE MATCHED DENOMINATOR, and it is not optional in practice. `myTurnPersonal` paired with
+        // `myTurnTotal` would put two populations in one row, AND the cap disclosure only fires when
+        // the displayed figure equals the count it qualifies — so a narrow line borrowing the broad
+        // total would silently lose its "of N" on every capped workspace.
+        myTurnPersonalTotal: insights.myTurnPersonalTotal,
+        // The split, each count paired with the total folded off the SAME pre-cap array it came from
+        // (passed straight through — same fold, same scope, same window as `myTurnTotal`).
+        ...split,
+        myTurnDirectTotal: insights.myTurnDirectTotal,
+        myTurnMaintainedTotal: insights.myTurnMaintainedTotal,
+        myTurnOther,
+        myTurnOtherTotal: insights.myTurnOtherTotal,
+        ciFailing,
+        // The matched denominator, passed straight through from the same getWorkspaceInsights call —
+        // pair narrow with narrow, or the "of N" disclosure silently never fires.
+        ciFailingTotal: insights.ciFailingTotal,
+        // The Dependencies tab's SECURITY population — the figure its "Security" chip shows, uncapped
+        // (a survey line, so no `…Total` twin); the line opens the board isolated to `security`. ⚠ It
+        // is not in the Pro narration's inputs: it is templated, like `ciFailing`'s line, so adding it
+        // re-bills no stored brief.
+        security: insights.kindTotals?.security ?? 0,
+        // ⚠ THE THREE SURVEY LINES COUNT THE WHOLE POPULATION, not the cards this capped fold kept.
+        // Each line opens its Pending tab with its own kind chip selected, and the chip shows
+        // `kindTotals` — the uncapped figure — so the strip must say the same number or the reader
+        // clicks "15" and lands on "173". The card count stays the fallback for a fold predating it.
+        stalled: insights.kindTotals?.stalled_review ?? stalled,
+        untouchedThreads: insights.kindTotals?.untouched_thread ?? untouchedThreads,
+        needsReviewer: insights.kindTotals?.reviewer_routing ?? needsReviewer,
+        resolveBacklog: backlog.totalThreads,
+        botAnomalies,
+        trunkRed,
+    };
+}
+/**
+ * THE ACTIVE WORKSPACE'S BRIEF — the one whose numbers sit above lists the strip can open, so its
+ * counts are computed FRESH on every call and never served from a cache (only the anomaly slice
+ * inside them is TTL'd; see the header). `computedAt` therefore stamps THE COUNTS, not the object.
+ *
+ * ⚠ Do not "optimise" this into `getDailyBriefCounts` below. They differ in exactly one way and it
+ * is the whole fix: this one cannot lag GET /api/attention, that one may.
+ */
+export async function getDailyBriefEntry(accountId, workspaceId) {
+    // Stamped before the fold, so `generatedAt` can never claim to be newer than the read it describes.
+    const computedAt = new Date();
+    return { counts: await computeBriefCounts(accountId, workspaceId), computedAt };
+}
+/**
+ * The CACHED daily-brief fold (ProHostQueries.getDailyBriefCounts's real body — bind.ts swaps its
+ * declared-inert throw for this). Counts only, no cost fields, behind the module-level 5-min TTL.
+ *
+ * ⚠ Callers are the ones for whom a ≤5-min-old count cannot be contradicted by a click: the
+ * roll-up's OTHER-workspace lines (switching workspace re-derives them fresh) and the Pro
+ * narration's input assembly (whose phrasing is digit-free — the figures the strip paints always
+ * come from the counts response). The workspace the user is LOOKING at goes through
+ * `getDailyBriefEntry` above instead.
+ *
+ * ⚠ And the fresh path must NOT seed this cache with what it just computed, obvious as that looks:
+ * the narration's payload hash is read from here, so a counts vector that tracked every read would
+ * bill a regeneration for a count that ticked down and back up inside one window. The TTL is a
+ * cost gate on this path, not a performance one.
+ */
+export async function getDailyBriefCounts(accountId, workspaceId) {
+    return cached(countsCache, `${accountId}:${workspaceId}`, COUNTS_TTL_MS, () => computeBriefCounts(accountId, workspaceId));
+}
+//# sourceMappingURL=daily-brief.js.map

package/dist/db/dependency-cards.js

@@ -0,0 +1,145 @@
+import { DEPENDENCY_STATE_BASE, MERGE_QUEUE_CARD_DETAIL, REVIEW_BOT_KINDS } from '../shared/index.js';
+import { reviewBotKind, roleForBotLogin } from '../sync/bot-detection.js';
+import { canonicalAdvisoryId } from '../sync/security-detect.js';
+import { isConflicting, isRedCiStatus } from './pending-classify.js';
+/**
+ * WHO MADE THIS CHANGE, when it was automation. ONE function behind the card field, the lens side
+ * and the Dependencies-tab membership, so the three cannot disagree.
+ *
+ *   1. `dependencyVendor` set (a tool's own marker on the PR)  → { role:'dependency', kind: vendor,
+ *      source: author is automated ? 'account' : 'marker' }. The marker wins the ROLE even over an
+ *      automated author with another role (Socket Fix / Frogbot run as github-actions).
+ *   2. author null or not in `automatedIds`                     → null (a person; a manual "human"
+ *      already removed the actor from the set).
+ *   3. role = manualRoleOf ?? roleForBotLogin(login) ?? (reviewBotKind(login) ? 'review')
+ *            ?? (stored role ≠ 'review' ? stored) ?? (kind ∈ REVIEW_BOT_KINDS ? 'review')
+ *            ?? 'code_agent'
+ *      ⚠ The last resort is `code_agent`, NOT `resolveActorLanes`' `quality_gate`: an unknown
+ *      automation that OPENS a pull request writes code. Different question, deliberate divergence.
+ *      ⚠ A DERIVED 'review' is the default an unknown login gets, so it is not evidence — the
+ *      resolveActorLanes rule; every other stored role was positively concluded and wins.
+ *   4. kind = kindOf.get(id) ?? null; source 'account'.
+ */
+export function authorAutomationFor(authorId, dependencyVendor, x) {
+    const automated = authorId != null && x.automatedIds.has(authorId);
+    if (dependencyVendor != null) {
+        return { role: 'dependency', kind: dependencyVendor, source: automated ? 'account' : 'marker' };
+    }
+    if (!automated)
+        return null;
+    const login = x.loginOf.get(authorId) ?? null;
+    const stored = x.storedRoleOf.get(authorId);
+    const kind = x.kindOf.get(authorId) ?? null;
+    const role = x.manualRoleOf.get(authorId) ??
+        roleForBotLogin(login) ??
+        (reviewBotKind(login) != null ? 'review' : null) ??
+        (stored != null && stored !== 'review' ? stored : null) ??
+        (kind != null && REVIEW_BOT_KINDS.has(kind) ? 'review' : null) ??
+        'code_agent';
+    return { role, kind, source: 'account' };
+}
+/** A dependency PR's next step, folded from its synced columns. FIRST MATCH WINS, in this order:
+ *  conflicts (mergeStateStatus 'dirty' OR mergeable 'conflicting') → ci_red (ciStatus failure|error,
+ *  and GitHub would not merge it) → behind (mss 'behind') → ready (`readyToMerge`, i.e.
+ *  READY_MERGE_STATES.has(mss)) → needs_review (reviewDecision review_required|changes_requested) →
+ *  blocked (mss 'blocked') → unknown. ⚠ NULL columns are NOT OBSERVED and fall through to `unknown`,
+ *  never to `ready`.
+ *  ⚠ A RED BUILD GITHUB WOULD STILL MERGE IS `ready`: `unstable` means only NON-required checks are
+ *  red, and it is mergeable (`mergeVerdict()`, READY_MERGE_STATES). So this card and a person's
+ *  `merge` card say one thing about one state — "Can land now, but non-required checks are red". */
+export function dependencyPrState(p) {
+    if (isConflicting(p))
+        return 'conflicts';
+    if (isRedCiStatus(p.ciStatus) && !p.readyToMerge)
+        return 'ci_red';
+    if (p.mergeStateStatus === 'behind')
+        return 'behind';
+    if (p.readyToMerge)
+        return 'ready';
+    if (p.reviewDecision === 'review_required' || p.reviewDecision === 'changes_requested') {
+        return 'needs_review';
+    }
+    if (p.mergeStateStatus === 'blocked')
+        return 'blocked';
+    return 'unknown';
+}
+// THE ONE SENTENCE a Pending card says while GitHub's merge queue holds its PR. It lives in
+// `packages/shared` (pending-rules.ts, with its reasons) because the SPA recognises it to leave it
+// off a card whose queue chip or merge row already says so; re-exported here for this module's
+// callers and tests.
+export { MERGE_QUEUE_CARD_DETAIL };
+/** The state as a sentence. CODE-WRITTEN, TIME-FREE (the forward-card rule — it is hashed nowhere
+ *  today, but it is the ranker's `reason` shape), and it says what the state chip beside it cannot.
+ *  `readyDetail` is the caller's `mergeCardDetail('merge', mss, 0, inMergeQueue)`, so a ready
+ *  dependency PR and a `merge` card say the same sentence.
+ *
+ *  ⚠ WHILE GITHUB'S QUEUE HOLDS THE PR (`inMergeQueue === true`, a positive observation — null is
+ *  "not observed" and claims nothing), every state the queue settles by itself says
+ *  `MERGE_QUEUE_CARD_DETAIL` instead: "behind", "needs review" and "blocked" are all things the
+ *  queue has already accepted the PR past. `conflicts` and `ci_red` keep their own sentences — a
+ *  real fault the queue will eject the entry for is still news. */
+export function dependencyStateDetail(state, p, readyDetail) {
+    if (p.inMergeQueue === true && state !== 'conflicts' && state !== 'ci_red') {
+        return MERGE_QUEUE_CARD_DETAIL;
+    }
+    switch (state) {
+        case 'conflicts':
+            return `Conflicts with ${p.baseRefName ?? 'the base branch'}`;
+        case 'ci_red':
+            return 'CI is failing';
+        case 'behind':
+            return 'GitHub blocks the merge until the branch is updated';
+        case 'ready':
+            return readyDetail;
+        case 'needs_review':
+            return p.reviewDecision === 'changes_requested'
+                ? 'Changes were requested'
+                : 'Needs an approving review';
+        case 'blocked':
+            return 'Required checks or reviews aren’t satisfied';
+        case 'unknown':
+            return 'GitHub has not worked out if it can merge this yet';
+    }
+}
+/** The security sentence for a proven fix PR, or '' — when only alerts put the card here, and for
+ *  an INFERRED fix, whose header already says "Likely security fix" (a sentence could only repeat it,
+ *  or explain what we cannot know; the why lives in the card's info popover). `advisoryIds` are the
+ *  ids the FIX names (the PR's own markers) — never an alert's, which the PR may not fix. */
+export function securityFixDetail(fix, advisoryIds) {
+    if (fix == null || fix === 'inferred')
+        return '';
+    const [first] = advisoryIds;
+    if (first == null)
+        return 'Fixes a known security advisory';
+    const more = advisoryIds.length - 1;
+    return more > 0 ? `Fixes ${first} and ${more} more` : `Fixes ${first}`;
+}
+/** Every id a security card names, as the wire carries it: complete up to this safety cap — the
+ *  detector's own per-PR cap — so a reader knows the list is whole below it. */
+const ADVISORY_IDS_MAX = 50;
+/** Fix ids first, then each alert's ids, canonical, deduplicated, capped at the 50-id safety cap. */
+export function unionAdvisoryIds(fixIds, alerts) {
+    const out = [];
+    const seen = new Set();
+    for (const raw of [...fixIds, ...alerts.flatMap((a) => a.advisoryIds)]) {
+        const id = canonicalAdvisoryId(raw);
+        if (seen.has(id))
+            continue;
+        seen.add(id);
+        out.push(id);
+        if (out.length >= ADVISORY_IDS_MAX)
+            break;
+    }
+    return out;
+}
+/** Where a Dependencies-tab card starts on the Do next scale. `state` null = a person's PR a
+ *  security tool flagged (no merge row of its own) → 'security_alert'. 'ready' splits on approval
+ *  exactly like a `merge` card. Everything else reads DEPENDENCY_STATE_BASE. */
+export function dependencyProximityBase(state, approvals) {
+    if (state == null)
+        return 'security_alert';
+    if (state === 'ready')
+        return approvals > 0 ? 'merge_approved' : 'merge_unapproved';
+    return DEPENDENCY_STATE_BASE[state];
+}
+//# sourceMappingURL=dependency-cards.js.map