limn-review 0.1.123

package/dist/db/actor-lanes.js

@@ -0,0 +1,213 @@
+// WHO DID THE WORK — the seven lanes, resolved per user id for one workspace.
+//
+// The period report's twelve metrics answer "what happened"; this answers "how much of it was a
+// person". Both are needed, because on a real workspace the blend is severe enough to make the
+// headline figures describe nobody:
+//
+//   BNG, one fortnight — 117 merged PRs, of which 46 were Dependabot.
+//     median PR size: Dependabot 14 lines · humans 142 lines · REPORTED 68
+//
+//   That 68 is not a compromise between two numbers, it is a number no pull request in that
+//   workspace resembled, and it understated real human PR size by 2.1×.
+//
+// ── WHY LANES AND NOT "BOT vs HUMAN" ─────────────────────────────────────────────────────────
+//
+// Because automation contaminates DIFFERENT metrics depending on what it does, and one bucket
+// cannot tell those apart:
+//
+//   • a DEPENDENCY bot authors bumps   → distorts throughput, lead time, PR size
+//   • a CODE AGENT authors real changes → distorts the same metrics and means the OPPOSITE
+//   • a QUALITY GATE responds/approves  → distorts review counts and approvals
+//   • an AI REVIEWER writes findings    → the only automation whose review volume means anything
+//   • RELEASE automation merges/tags    → its merges are governance events, not work
+//   • HOUSEKEEPING greets and labels    → pure noise in every one of the above
+//
+// "Your throughput is inflated by bumps" and "your approvals are automated" are different
+// problems with different fixes, and a single `isBot` flag can state neither. The same workspace
+// showed SonarQube posting 786 comments — every one of them a "Quality Gate Passed/Failed" badge
+// — so folding its volume in with an AI reviewer's findings would report 786 pieces of feedback
+// where there were none.
+//
+// The dependency/code-agent split is the one that most resists being collapsed back: both author
+// pull requests, so any "bot vs human" view puts them together, and yet a merged Dependabot bump
+// is overhead a team absorbed while a merged agent PR is work it shipped. A single "automation
+// authored 40% of merges" figure that mixes them tells the reader nothing they can act on.
+//
+// ── THE DUPLICATE-IDENTITY DEFENCE ───────────────────────────────────────────────────────────
+//
+// Real accounts carry the SAME actor as two user rows with CONFLICTING flags: `dependabot` and
+// `dependabot[bot]`, `github-actions` and `github-actions[bot]`. On the measured account one of
+// each pair sat at `workspace_reviewers.automated = 0`, i.e. counted as a human. Merging the rows
+// is not an option — they have different GitHub node ids and may be genuinely different accounts
+// (an App vs a user of the same name) — so this resolver never trusts a single signal:
+//
+//   automated  ⇐  workspace verdict ∪ users.isBot ∪ the login vocabularies
+//   human      ⇐  only when NO signal fires, or a human explicitly said so
+//
+// A genuine manual "this is a person" still wins (that rule is load-bearing elsewhere and is not
+// weakened here); what does not win is the mere ABSENCE of an automated verdict.
+import { inArray } from 'drizzle-orm';
+import { db, schema } from './client.js';
+import { roleForBotLogin } from '../sync/bot-detection.js';
+import { automatedReviewerUserIds, classificationKindForUser, manualHumanUserIds, manualRoleUserIds, reviewerRoleForUser, } from './queries.js';
+const { users } = schema;
+/** The vendor `kind`s that denote SUBSTANTIVE AI review, as opposed to a scanner wearing a vendor
+ *  brand. Anything classified with one of these is in the `ai_review` lane even if its login is
+ *  unknown to the local vocabulary — a user's manual vendor classification is a real judgement. */
+const AI_REVIEW_KINDS = new Set([
+    'coderabbit',
+    'greptile',
+    'copilot',
+    'qodo',
+    'sourcery',
+    'bito',
+    'ellipsis',
+    'korbit',
+    'baz',
+    'graphite',
+    'cursor',
+    'devin',
+    'entelligence',
+    'codex',
+    // `vendor` = a generic proprietary reviewer a HUMAN classified when it wasn't a known brand.
+    // That is a real judgement that the actor reviews, so it belongs here.
+    'vendor',
+]);
+// ⚠ `in_house` IS NOT IN THAT SET, and the shared type's description ("the account's OWN AI")
+// is not what the column actually holds. Measured on the live database: of 37 rows carrying
+// `kind: 'in_house'`, 25 were assigned by `source: 'github_type'` — the fallback for "this is a
+// GitHub App and we don't recognise the brand". That bucket contains sonarqubecloud,
+// dependabot[bot], github-actions[bot], gitguardian, socket-security, google-cla and jit-ci.
+// Not one of them is an AI reviewer.
+//
+// Treating it as one produced the exact failure this module exists to prevent: `github-actions`
+// landed in `quality_gate` while `github-actions[bot]` — the SAME actor, second user row, the one
+// carrying the `in_house` classification — landed in `ai_review`. One CI bot, two lanes, both
+// under-counted, and the "is our AI review tooling earning its licence" number quietly inflated
+// by 384 automated approvals.
+//
+// So an unbranded automation falls through to the `quality_gate` default. That is the asymmetric
+// choice stated in `resolveActorLanes`: under-claiming an AI reviewer costs nothing anyone acts
+// on, over-claiming one corrupts the single number a team would use to cancel a subscription.
+// MIRRORED from `REVIEWER_ROLE_LANE` in @pierre-review/shared — the backend cannot import shared
+// at RUNTIME (a value import fails the release build), so the map is spelled twice and
+// `actor-lanes.test.ts` asserts the two are identical. It is deliberately 1:1: a user who picks
+// "Release automation" and finds the actor filed under "Quality gate" has been told their choice
+// did not take.
+const ROLE_LANE = {
+    review: 'ai_review',
+    quality_check: 'quality_gate',
+    dependency: 'dependency',
+    code_agent: 'code_agent',
+    release: 'release',
+    housekeeping: 'housekeeping',
+};
+/**
+ * Resolve the lane of every actor that could appear in a workspace's metrics.
+ *
+ * ORDER IS THE CONTRACT, because the categories genuinely overlap — `github-advanced-security` is
+ * a scanner with a vendor brand, SonarQube is a quality check that some accounts have classified
+ * by hand, and Copilot both reviews and (elsewhere) authors. Earlier rules win:
+ *
+ *   1. manual "this is a person"              → human          (nothing overrules it)
+ *   2. no automation signal at all            → human
+ *   3. MANUAL role                            → that role's lane
+ *   4. known login vocabulary                 → that role's lane
+ *   5. stored role other than 'review'        → that role's lane   (a seed we derived)
+ *   6. vendor kind in AI_REVIEW_KINDS         → ai_review
+ *   7. anything else automated                → quality_gate   (CI scripts, unknown apps)
+ *
+ * ⚠ RULES 3 AND 5 ARE THE SAME COLUMN READ TWICE, AND SPLITTING THEM IS THE POINT. `role` defaults
+ * to `'review'`, so a stored `'review'` is ambiguous: it means "a person chose Review bot" on a
+ * manual row and "we have never heard of this login" on every other. Collapsing the two either
+ * ignores the user's choice (mark Copilot a code agent, watch the report keep calling it AI
+ * review) or lets a stale default beat a login we positively recognise. `manualRoleUserIds`
+ * carries the disambiguation, and it is automated-rows-only so a manual HUMAN cannot be handed a
+ * bot lane by whatever role their row happens to carry.
+ *
+ * Rule 7 is deliberately NOT `ai_review`, and it is also NOT `housekeeping`: an unrecognised
+ * automation is far more likely to be a CI script than a reviewer, and the cost of the mistakes is
+ * asymmetric. Miscounting a script as a quality gate understates nothing anyone acts on;
+ * miscounting it as an AI reviewer inflates the one number a team would use to judge whether their
+ * review tooling is earning its licence, and filing it under housekeeping would quietly drop it
+ * out of every count instead of merely declining to credit it.
+ */
+export async function resolveActorLanes(accountId, scope) {
+    const [automatedFromWorkspace, kindMap, roleMap, vouchedHuman, manualRoles] = await Promise.all([
+        automatedReviewerUserIds(accountId, scope.workspaceId, 'all'),
+        classificationKindForUser(accountId, scope.workspaceId),
+        reviewerRoleForUser(accountId, scope.workspaceId),
+        manualHumanUserIds(accountId, scope.workspaceId),
+        manualRoleUserIds(accountId, scope.workspaceId),
+    ]);
+    // ⚠ THE ONE SIGNAL THAT BEATS THE UNION. Widening automation detection to `users.isBot` and the
+    // login vocabularies is what fixes the duplicated identities — and it also re-admits an actor a
+    // person has explicitly marked human, because such an actor usually has a bot-ish login or a
+    // stale global flag, which is exactly WHY someone corrected it by hand.
+    const vouched = new Set(vouchedHuman);
+    // The GLOBAL bot flag, which catches exactly what the workspace verdict misses: an actor nobody
+    // has opened the Bots tab for, and the second row of a duplicated identity. `users` is a global
+    // table, so this is read by id — never handed to a tenant.
+    const flaggedBotIds = new Set();
+    const loginById = new Map();
+    const candidateIds = new Set([...automatedFromWorkspace, ...kindMap.keys(), ...roleMap.keys()]);
+    const botRows = await db
+        .select({ id: users.id, login: users.githubLogin, isBot: users.isBot })
+        .from(users)
+        .where(inArray(users.isBot, [true]))
+        .execute();
+    for (const r of botRows) {
+        flaggedBotIds.add(r.id);
+        loginById.set(r.id, r.login);
+        candidateIds.add(r.id);
+    }
+    // Logins for the workspace-classified ids the global flag did not cover.
+    const missing = [...candidateIds].filter((id) => !loginById.has(id));
+    if (missing.length > 0) {
+        const rows = await db
+            .select({ id: users.id, login: users.githubLogin })
+            .from(users)
+            .where(inArray(users.id, missing))
+            .execute();
+        for (const r of rows)
+            loginById.set(r.id, r.login);
+    }
+    const workspaceAutomated = new Set(automatedFromWorkspace);
+    const lane = new Map();
+    const automatedIds = new Set();
+    for (const id of candidateIds) {
+        if (vouched.has(id))
+            continue; // a person said this is a person — nothing overrules that
+        const login = loginById.get(id) ?? '';
+        // ONE call, not five predicates in an order this file gets to choose: the vocabularies are
+        // asserted pairwise disjoint, so `roleForBotLogin` has exactly one answer per login.
+        const loginRole = roleForBotLogin(login);
+        // THE UNION (see the header). A login vocabulary hit counts on its own, which is what covers
+        // the duplicated-identity row whose stored verdict says `automated: 0`.
+        const automated = workspaceAutomated.has(id) || flaggedBotIds.has(id) || loginRole != null;
+        if (!automated)
+            continue;
+        automatedIds.add(id);
+        const manualRole = manualRoles.get(id);
+        const storedRole = roleMap.get(id);
+        const kind = kindMap.get(id);
+        if (manualRole != null)
+            lane.set(id, ROLE_LANE[manualRole]);
+        else if (loginRole != null)
+            lane.set(id, ROLE_LANE[loginRole]);
+        // A DERIVED `'review'` is the default an unknown login gets, so it is not evidence and does
+        // not short-circuit; every other derived role was positively concluded and does.
+        else if (storedRole != null && storedRole !== 'review')
+            lane.set(id, ROLE_LANE[storedRole]);
+        else if (kind != null && AI_REVIEW_KINDS.has(kind))
+            lane.set(id, 'ai_review');
+        else
+            lane.set(id, 'quality_gate');
+    }
+    return {
+        lane,
+        automatedIds,
+        laneOf: (userId) => (userId == null ? 'human' : (lane.get(userId) ?? 'human')),
+    };
+}
+//# sourceMappingURL=actor-lanes.js.map

package/dist/db/automation-ids.js

@@ -0,0 +1,97 @@
+// ── THE GLOBAL AUTOMATION READERS (CORE) ─────────────────────────────────────────────────────
+//
+// Two account-free signals that an actor is automation, beside `users.isBot` and the review-bot
+// login table (queries.ts `botUserIds` / `reviewBotUserIds`):
+//
+//   • GitHub TYPES the account a Bot (`users.github_type = 'Bot'`) — the App accounts `isLikelyBot`
+//     misses because GraphQL returns their login WITHOUT `[bot]`. Measured on the dev DB: seven such
+//     users with `is_bot = 0` (Copilot, lumberbot-app, gitguardian, socket-security, google-cla,
+//     cdp-github-action, jit-ci), who wrote 112 PR comments on open PRs.
+//   • the login is a known NON-review vendor (`AUTOMATION_VENDORS`, bare or `[bot]`, plus the
+//     per-org prefixes such as Semgrep's `semgrep-code-<org>`) — Renovate, Snyk, ImgBot…
+//
+// A separate module, not private functions in queries.ts, because My Turn's mention scanner
+// (`db/pr-mentions.ts`, which imports nothing but `client.js`) builds its automation set from these
+// too; reaching them through queries.ts would drag that whole module (and its cycle with
+// ml-labels.ts) into it.
+//
+// ⚠ IDS, used only as MEMBERSHIP tests. `users` is a GLOBAL table: nothing here may hand a tenant
+// a row, and a caller that needs a workspace's answer folds these through
+// `resolveWorkspaceReviewers`, where a person's manual "this is a human" still wins.
+// ⚠ ONE reader returns a LOGIN, and it matches EXACT vendor logins only — a public identity, like
+// the REVIEW_BOTS seed. The PREFIX half (`semgrep-code-<org>`) matches logins that name ANOTHER
+// tenant's organisation, so it only ever yields ids. A new reader here returns ids.
+import { eq, inArray, like, or, sql } from 'drizzle-orm';
+import { db, schema } from './client.js';
+import { automationVendorLoginsForSql, automationVendorPrefixes } from '../sync/bot-detection.js';
+const { users } = schema;
+/** Users GitHub itself types as a Bot (`users.github_type = 'Bot'`) — the App accounts
+ *  `isLikelyBot` misses because GraphQL returns their login WITHOUT `[bot]` (socket-security,
+ *  gitguardian, jit-ci, Copilot, google-cla, lumberbot-app, cdp-github-action on the dev DB). */
+export async function githubTypeBotUserIds() {
+    const rows = await db
+        .select({ id: users.id })
+        .from(users)
+        .where(eq(users.githubType, 'Bot'))
+        .execute();
+    return rows.map((r) => r.id);
+}
+/** `lower(github_login)` — built per call, never at import: tests that mock `client.js` with a
+ *  partial schema import this module too. */
+const loweredLogin = () => sql `lower(${users.githubLogin})`;
+/** Users whose login is in AUTOMATION_VENDORS (bare or `[bot]`) or matches a vendor PREFIX:
+ *  `lower(github_login) IN (…) OR lower(github_login) LIKE 'semgrep-code-%' OR … 'semgrepcode-%'`.
+ *  ⚠ Lowercased on BOTH sides, so pg's case-sensitive `LIKE` and SQLite's case-blind one agree;
+ *  no prefix contains `_`, LIKE's single-character wildcard. */
+export async function automationVendorUserIds() {
+    const rows = await db
+        .select({ id: users.id })
+        .from(users)
+        .where(or(inArray(loweredLogin(), automationVendorLoginsForSql()), ...automationVendorPrefixes().map((p) => like(loweredLogin(), `${p}%`))))
+        .execute();
+    return rows.map((r) => r.id);
+}
+/**
+ * THE BALL RULE'S AUTOMATION SET — every actor we know to be automation WITHOUT a workspace:
+ * `users.isBot` ∪ `users.github_type = 'Bot'` ∪ the AUTOMATION_VENDORS logins and prefixes. GLOBAL,
+ * so the unscoped `getMyTurn` (browser notifications, the CLI) and the scoped one (the board, the
+ * brief) agree, and the mention scanner (db/pr-mentions.ts) honours exactly the mentions the ball
+ * rule would.
+ *
+ * WHY NOT `users.isBot` ALONE: My Turn's newer rules read OTHER people's comments ("a person
+ * commented after you", "a person replied to you", "a person @-mentioned you"), and on the dev DB
+ * the accounts GitHub types as a Bot but `isBot` misses wrote 112 PR comments on 82 open PRs
+ * (google-cla 73, socket-security 24, cdp-github-action 12, gitguardian 2, jit-ci 1). Under the
+ * `isBot`-only set each of those summons the viewer as though a colleague had answered them. The
+ * Pending cards already call the same accounts automation.
+ *
+ * ⚠ STILL NOT `hiddenBotUserIds`: that union needs a workspaceId, and `getMyTurn` also runs
+ * unscoped. A workspace's manual "this is a human" therefore cannot reach this set — accepted,
+ * because every member here is an account GitHub types as an App or a known vendor login.
+ * ⚠ `users.isBot` keeps its own meaning; this set is a union READ, never a write.
+ */
+export async function globalAutomationUserIds() {
+    const [flagged, typed, vendors] = await Promise.all([
+        db
+            .select({ id: users.id })
+            .from(users)
+            .where(eq(users.isBot, true))
+            .execute()
+            .then((rows) => rows.map((r) => r.id)),
+        githubTypeBotUserIds(),
+        automationVendorUserIds(),
+    ]);
+    return new Set([...flagged, ...typed, ...vendors]);
+}
+/** The users whose login is EXACTLY a vendor login (bare or `[bot]`), with that login — the kind
+ *  seed in queries.ts (`classificationKindForUser`) names each one's vendor from it. ⚠ NEVER the
+ *  prefix half: that kind map is also the bot drill-downs' "is this id classified here" gate, which
+ *  then resolves the login, so a prefix match would read another org's name back to any tenant. */
+export async function exactAutomationVendorUsers() {
+    return db
+        .select({ id: users.id, login: users.githubLogin })
+        .from(users)
+        .where(inArray(loweredLogin(), automationVendorLoginsForSql()))
+        .execute();
+}
+//# sourceMappingURL=automation-ids.js.map

package/dist/db/automation-output.js

@@ -0,0 +1,349 @@
+// ── THE AUTHORING-AUTOMATION OUTPUT VECTOR (CORE, deterministic) ─────────────────────────────
+//
+// What a bot that WRITES PRs produced in one period, in one workspace. The sibling of
+// db/person-period.ts, and it copies that file's discipline wholesale (window-pure two-sided
+// predicates, computed on read, no table, no migration) — but it is deliberately NOT the same
+// vector, because the question is different. A person's numbers answer "how is this teammate
+// doing"; an automation's answer "what is this thing costing us", which is why
+// `prs_merged_without_human_review` and `human_review_comments_received` are here and response
+// times are not.
+//
+// WHY IT EXISTS: the People report's bot sections read `getBotAnalytics`, whose columns are all
+// REVIEW output (threads, comments, acted-on). That is the whole story for the `review` and
+// `quality_check` roles only. For `dependency` / `code_agent` / `release` / `housekeeping`
+// automation every one of those columns is legitimately zero, and a wall of zeros reads as "it
+// did nothing" when the truth is "it did a different thing". The section used to say so in prose
+// and chart nothing; this fold is what it charts instead.
+//
+// ⚠ EVERY WINDOWED METRIC IS WINDOW-PURE with a TWO-SIDED `>= from AND < to` predicate, so a
+// stored/forwarded period stays reproducible. There is deliberately no live-basis escape hatch
+// here (PersonPeriod has three, marked on the wire): every question this vector asks is about
+// what HAPPENED in the window, so a "currently open" count would be the only unreproducible
+// figure on the page and it would not earn its place.
+//
+// ⚠ `prs_merged_without_human_review` looks like it breaks window purity — it asks "did any human
+// ever review this PR?", which is not itself a windowed question. It does not: the population is
+// PRs MERGED INSIDE the window, and a review of a merged PR necessarily predates its merge, so
+// the answer is fixed the moment the PR lands and can never move afterwards. Restricting the
+// review probe to the window would be the bug — a PR opened and reviewed in March and merged in
+// April would count as "merged without review".
+//
+// ⚠ `users` IS A GLOBAL TABLE (the listUsers precedent). The subject is admitted only after an
+// authored-PR probe INSIDE the workspace scope, and only the login and display name ever leave.
+//
+// ⚠ MIRROR IMAGE OF THE PERSON FOLD'S LANE CHECK: person-period refuses anything the lane
+// resolver calls automation; this refuses anything it calls `'human'`. Neither is a login
+// heuristic — both go through db/actor-lanes.ts, so a manual "this account is a person"
+// judgement moves an actor between the two folds in one place.
+import { and, count, desc, eq, gte, inArray, isNull, lt, ne, or } from 'drizzle-orm';
+import { db, schema } from './client.js';
+import { resolveActorLanes } from './actor-lanes.js';
+import { median, round2 } from './period-metrics.js';
+import { PERSON_EVIDENCE_CAP } from './person-period.js';
+import { reviewerRoleForUser } from './queries.js';
+const { pullRequests, repos, reviewComments, reviews, users } = schema;
+// MIRRORED from @pierre-review/shared (AUTOMATION_METRIC_KEYS) for the same types-only reason the
+// person keys are inlined: `shared` ships no runtime. `automation-output.test.ts` imports the
+// shared original and asserts the two spellings are identical, so drift fails CI, not a reader.
+export const AUTOMATION_METRIC_KEYS = [
+    'prs_opened',
+    'prs_merged',
+    'prs_closed_unmerged',
+    'merge_rate_pct',
+    'median_hours_to_merge',
+    'median_pr_size_lines',
+    'prs_merged_without_human_review',
+    'human_review_comments_received',
+    'repos_touched',
+];
+/** Repos listed under the vector. Rendering cap only — the `repos_touched` METRIC counts them
+ *  all, so a workspace with 40 repos reports 40 and lists the busiest few. */
+const REPO_LIST_CAP = 8;
+/** The merged-PR scan that feeds the medians and the no-human-review probe. Bounded for the same
+ *  reason PERIOD_FIRST_REVIEW_PR_CAP is: the ids travel onward as BIND PARAMETERS. A dependency
+ *  bot can merge hundreds of PRs in a fortnight, so this is the one fold here that can get big. */
+const AUTOMATION_MERGED_PR_CAP = 2000;
+function cell(key, value, sampleSize) {
+    return { key, value, sampleSize };
+}
+/** A count is never null — zero merges IS zero, not "no sample". Medians and rates are the ones
+ *  that go null (the period-metrics rule: a null renders "—", never 0). */
+function countCell(key, n) {
+    return cell(key, n, n);
+}
+export async function getAutomationOutput(accountId, scope, userId, window, opts = {}) {
+    const from = new Date(window.fromMs);
+    const to = new Date(window.toMs);
+    // An empty workspace admits nobody — and without this guard the probe below would read the
+    // whole account (`inArray(…, [])` is false, but be explicit about the state).
+    if (scope.repoIds.length === 0)
+        return null;
+    const lanes = await resolveActorLanes(accountId, scope);
+    if (lanes.laneOf(userId) === 'human')
+        return null;
+    const inScope = and(eq(pullRequests.accountId, accountId), inArray(pullRequests.repoId, scope.repoIds));
+    const authored = and(inScope, eq(pullRequests.authorId, userId));
+    // ── Admission probe (ALL TIME, inside the scope) ────────────────────────────────────────────
+    // An automation that has never authored a PR in this workspace is not this fold's subject —
+    // it is a reviewer, and `getBotAnalytics` already describes it. Returning null here is what
+    // lets the caller decide which of the two sections to render, and it is also why the route is
+    // not an existence oracle: an unknown id degrades identically.
+    const [probe] = await db
+        .select({ c: count() })
+        .from(pullRequests)
+        .where(authored)
+        .execute();
+    if ((probe?.c ?? 0) === 0)
+        return null;
+    const [identity] = await db
+        .select({ login: users.githubLogin, name: users.displayName })
+        .from(users)
+        .where(eq(users.id, userId))
+        .execute();
+    // ── The windowed counts ────────────────────────────────────────────────────────────────────
+    const [openedRow, mergedRow, closedRow, humanCommentsRow, repoRows, mergedPrs] = await Promise.all([
+        db
+            .select({ c: count() })
+            .from(pullRequests)
+            .where(and(authored, gte(pullRequests.openedAt, from), lt(pullRequests.openedAt, to)))
+            .execute(),
+        db
+            .select({ c: count() })
+            .from(pullRequests)
+            .where(and(authored, gte(pullRequests.mergedAt, from), lt(pullRequests.mergedAt, to)))
+            .execute(),
+        // Closed WITHOUT merging, inside the window. `mergedAt IS NULL` is the discriminator —
+        // GitHub stamps closedAt on a merge too, so a bare closedAt window would double-count every
+        // merged PR as wasted churn.
+        db
+            .select({ c: count() })
+            .from(pullRequests)
+            .where(and(authored, isNull(pullRequests.mergedAt), gte(pullRequests.closedAt, from), lt(pullRequests.closedAt, to)))
+            .execute(),
+        // Human review comments left ON its PRs in the window — the time it cost people. Bot-authored
+        // comments are excluded through the lane resolver, not a login test, so one bot reviewing
+        // another bot's PRs never reads as human attention.
+        db
+            .select({ authorId: reviewComments.authorId, c: count() })
+            .from(reviewComments)
+            .innerJoin(pullRequests, eq(pullRequests.id, reviewComments.prId))
+            .where(and(authored, gte(reviewComments.createdAt, from), lt(reviewComments.createdAt, to)))
+            .groupBy(reviewComments.authorId)
+            .execute(),
+        // Repos touched: PRs it OPENED or MERGED in the window, by repo. One two-sided predicate per
+        // column, OR-ed — a PR opened before the window and merged inside it still counts the repo.
+        db
+            .select({ repoId: pullRequests.repoId, owner: repos.owner, name: repos.name, c: count() })
+            .from(pullRequests)
+            .innerJoin(repos, eq(repos.id, pullRequests.repoId))
+            .where(and(authored, 
+        // Portable `or(and(…), and(…))`, never a raw `sql` template: drizzle binds a template's
+        // `${date}` straight through, and better-sqlite3 refuses a Date — the same expression
+        // that type-checks fine throws at the first call. Two-sided on both columns.
+        or(and(gte(pullRequests.openedAt, from), lt(pullRequests.openedAt, to)), and(gte(pullRequests.mergedAt, from), lt(pullRequests.mergedAt, to)))))
+            .groupBy(pullRequests.repoId, repos.owner, repos.name)
+            .orderBy(desc(count()))
+            .execute(),
+        // The merged-in-window population, carrying everything the medians need in one read.
+        db
+            .select({
+            id: pullRequests.id,
+            openedAt: pullRequests.openedAt,
+            mergedAt: pullRequests.mergedAt,
+            additions: pullRequests.additions,
+            deletions: pullRequests.deletions,
+        })
+            .from(pullRequests)
+            .where(and(authored, gte(pullRequests.mergedAt, from), lt(pullRequests.mergedAt, to)))
+            .orderBy(desc(pullRequests.mergedAt))
+            .limit(AUTOMATION_MERGED_PR_CAP)
+            .execute(),
+    ]);
+    const opened = openedRow[0]?.c ?? 0;
+    const merged = mergedRow[0]?.c ?? 0;
+    const closedUnmerged = closedRow[0]?.c ?? 0;
+    const humanComments = humanCommentsRow
+        .filter((r) => lanes.laneOf(r.authorId) === 'human')
+        .reduce((sum, r) => sum + r.c, 0);
+    // Merge rate over the RESOLVED population (merged + closed-unmerged, both windowed). Not over
+    // `opened`: a PR opened on the last day of the window has not had its chance yet, and dividing
+    // by it would make a busy final week look like a failing bot.
+    const resolved = merged + closedUnmerged;
+    const mergeRate = resolved > 0 ? round2((merged / resolved) * 100) : null;
+    const hoursToMerge = mergedPrs
+        .map((p) => p.mergedAt != null && p.openedAt != null
+        ? (p.mergedAt.getTime() - p.openedAt.getTime()) / 3_600_000
+        : null)
+        .filter((v) => v != null && Number.isFinite(v) && v >= 0);
+    const sizes = mergedPrs.map((p) => p.additions + p.deletions);
+    // ── "Merged with no human in the loop" ─────────────────────────────────────────────────────
+    // Over the merged-in-window ids, ALL-TIME (see the header note on why that is still
+    // window-pure). A PR counts as human-touched if any human submitted a review OR left a review
+    // comment on it, ever.
+    const mergedIds = mergedPrs.map((p) => p.id);
+    let mergedNoHuman = null;
+    if (mergedIds.length > 0) {
+        const [reviewRows, commentRows] = await Promise.all([
+            db
+                .select({ prId: reviews.prId, authorId: reviews.authorId })
+                .from(reviews)
+                .where(and(inArray(reviews.prId, mergedIds), ne(reviews.state, 'pending')))
+                .execute(),
+            db
+                .select({ prId: reviewComments.prId, authorId: reviewComments.authorId })
+                .from(reviewComments)
+                .where(inArray(reviewComments.prId, mergedIds))
+                .execute(),
+        ]);
+        const touched = new Set();
+        for (const r of [...reviewRows, ...commentRows]) {
+            if (lanes.laneOf(r.authorId) === 'human')
+                touched.add(r.prId);
+        }
+        mergedNoHuman = mergedIds.filter((id) => !touched.has(id)).length;
+    }
+    const metrics = [
+        countCell('prs_opened', opened),
+        countCell('prs_merged', merged),
+        countCell('prs_closed_unmerged', closedUnmerged),
+        cell('merge_rate_pct', mergeRate, resolved),
+        cell('median_hours_to_merge', hoursToMerge.length > 0 ? round2(median(hoursToMerge)) : null, hoursToMerge.length),
+        cell('median_pr_size_lines', sizes.length > 0 ? Math.round(median(sizes)) : null, sizes.length),
+        cell('prs_merged_without_human_review', mergedNoHuman, mergedIds.length),
+        countCell('human_review_comments_received', humanComments),
+        countCell('repos_touched', repoRows.length),
+    ];
+    const roleByUser = await reviewerRoleForUser(accountId, scope.workspaceId);
+    const role = roleByUser.get(userId) ?? null;
+    const out = {
+        userId,
+        login: identity?.login ?? null,
+        displayName: identity?.name ?? null,
+        role,
+        repos: repoRows.slice(0, REPO_LIST_CAP).map((r) => ({
+            repoId: r.repoId,
+            repoFullName: `${r.owner}/${r.name}`,
+            prs: r.c,
+        })),
+        metrics,
+    };
+    if (opts.evidence === true) {
+        out.evidence = await loadAutomationEvidence(accountId, scope, userId, out.login, from, to, lanes);
+    }
+    return out;
+}
+/** The receipt rows. Each group is capped at PERSON_EVIDENCE_CAP with an honest remainder, and
+ *  each is the SAME population as the metric it sits under — a card a reader can check the
+ *  figure against, never a differently-filtered list that happens to look related. */
+async function loadAutomationEvidence(accountId, scope, userId, subjectLogin, from, to, lanes) {
+    const inScope = and(eq(pullRequests.accountId, accountId), inArray(pullRequests.repoId, scope.repoIds));
+    const authored = and(inScope, eq(pullRequests.authorId, userId));
+    // Everything DigestPrRef renders, selected once. The table draws PR | CI | age | author | diff,
+    // so omitting `ciStatus`/`openedAt`/`changedFiles` leaves two columns as bare dashes on every
+    // row — the shape looks finished and reads as "no data" rather than "not selected".
+    const selectPr = {
+        prId: pullRequests.id,
+        prNumber: pullRequests.number,
+        repoId: pullRequests.repoId,
+        repoOwner: repos.owner,
+        repoName: repos.name,
+        title: pullRequests.title,
+        state: pullRequests.state,
+        ciStatus: pullRequests.ciStatus,
+        openedAt: pullRequests.openedAt,
+        additions: pullRequests.additions,
+        deletions: pullRequests.deletions,
+        changedFiles: pullRequests.changedFiles,
+    };
+    const [mergedRows, mergedTotal, closedRows, closedTotal, commentedRows] = await Promise.all([
+        db
+            .select(selectPr)
+            .from(pullRequests)
+            .innerJoin(repos, eq(repos.id, pullRequests.repoId))
+            .where(and(authored, gte(pullRequests.mergedAt, from), lt(pullRequests.mergedAt, to)))
+            .orderBy(desc(pullRequests.mergedAt))
+            .limit(PERSON_EVIDENCE_CAP)
+            .execute(),
+        db
+            .select({ c: count() })
+            .from(pullRequests)
+            .where(and(authored, gte(pullRequests.mergedAt, from), lt(pullRequests.mergedAt, to)))
+            .execute(),
+        db
+            .select(selectPr)
+            .from(pullRequests)
+            .innerJoin(repos, eq(repos.id, pullRequests.repoId))
+            .where(and(authored, isNull(pullRequests.mergedAt), gte(pullRequests.closedAt, from), lt(pullRequests.closedAt, to)))
+            .orderBy(desc(pullRequests.closedAt))
+            .limit(PERSON_EVIDENCE_CAP)
+            .execute(),
+        db
+            .select({ c: count() })
+            .from(pullRequests)
+            .where(and(authored, isNull(pullRequests.mergedAt), gte(pullRequests.closedAt, from), lt(pullRequests.closedAt, to)))
+            .execute(),
+        // PRs of its that drew review comments in the window, with the commenter so the human filter
+        // runs through the lane resolver rather than in SQL. Capped generously before folding, since
+        // the fold collapses many comments onto few PRs.
+        db
+            .select({
+            ...selectPr,
+            commenterId: reviewComments.authorId,
+            commentedAt: reviewComments.createdAt,
+        })
+            .from(reviewComments)
+            .innerJoin(pullRequests, eq(pullRequests.id, reviewComments.prId))
+            .innerJoin(repos, eq(repos.id, pullRequests.repoId))
+            .where(and(authored, gte(reviewComments.createdAt, from), lt(reviewComments.createdAt, to)))
+            .orderBy(desc(reviewComments.createdAt))
+            .limit(PERSON_EVIDENCE_CAP * 20)
+            .execute(),
+    ]);
+    // No cast: every DigestPrRef field is spelled out, so dropping one from `selectPr` becomes a
+    // compile error rather than a silently blank column.
+    const toRef = (r) => ({
+        prId: r.prId,
+        prNumber: r.prNumber,
+        repoId: r.repoId,
+        repoFullName: `${r.repoOwner}/${r.repoName}`,
+        title: r.title,
+        // The author is the subject of this whole vector, so the login is resolved once by the caller
+        // rather than re-joined per row; `authorId` is what the table renders an avatar from.
+        authorLogin: subjectLogin,
+        authorId: userId,
+        state: r.state,
+        ciStatus: r.ciStatus,
+        additions: r.additions,
+        deletions: r.deletions,
+        changedFiles: r.changedFiles,
+        openedAt: r.openedAt?.toISOString() ?? null,
+    });
+    // One row per PR, newest comment first, humans only.
+    const seen = new Set();
+    const humanReviewed = [];
+    let humanReviewedSeen = 0;
+    for (const r of commentedRows) {
+        if (lanes.laneOf(r.commenterId) !== 'human')
+            continue;
+        if (seen.has(r.prId))
+            continue;
+        seen.add(r.prId);
+        humanReviewedSeen += 1;
+        if (humanReviewed.length < PERSON_EVIDENCE_CAP)
+            humanReviewed.push(toRef(r));
+    }
+    const mergedCount = mergedTotal[0]?.c ?? 0;
+    const closedCount = closedTotal[0]?.c ?? 0;
+    return {
+        merged: mergedRows.map(toRef),
+        mergedMore: Math.max(0, mergedCount - mergedRows.length),
+        closedUnmerged: closedRows.map(toRef),
+        closedUnmergedMore: Math.max(0, closedCount - closedRows.length),
+        humanReviewed,
+        // The remainder here is over what the capped scan SAW, so it can under-report on a very
+        // chatty period. That is why the caption says "at least" — it must never claim to be the
+        // population figure the way the two above do.
+        humanReviewedMore: Math.max(0, humanReviewedSeen - humanReviewed.length),
+    };
+}
+//# sourceMappingURL=automation-output.js.map