limn-review 0.1.123

package/dist/db/migrations/0031_events_pr_idx.sql

@@ -0,0 +1,7 @@
+-- Correlated "does this PR have an event since <cutoff>" EXISTS lookups filter events by
+-- pr_id (getTeamInsights open-PR staleness, getOpenPrs, new-since checks, feed joins). With
+-- no pr_id index they fall back to events_account_idx and scan every account event per PR
+-- (O(open PRs × events)) — the getTeamInsights Overview took ~9s on 14 watched repos. This
+-- composite (pr_id, occurred_at) makes the lookup ~450× faster (also resolves the time bound
+-- inside the index).
+CREATE INDEX IF NOT EXISTS `events_pr_idx` ON `events` (`pr_id`, `occurred_at`);

package/dist/db/migrations/0032_benchmark_contributions.sql

@@ -0,0 +1,29 @@
+-- Cross-org benchmark network (CORE, cloud-only, opt-in), Phase 0: the opt-in flag on
+-- accounts + the aggregate-only weekly contributions table. See schema.sqlite.ts for the
+-- full rationale (no PII, in_house/pierre excluded, written only by the firewalled rollup).
+-- The Postgres baseline is maintained separately (migrations-pg/0019_*).
+ALTER TABLE `accounts` ADD `benchmark_opt_in` integer DEFAULT false NOT NULL;
+--> statement-breakpoint
+CREATE TABLE `benchmark_contributions` (
+	`id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+	`account_id` integer NOT NULL,
+	`vendor_kind` text NOT NULL,
+	`week_start` integer NOT NULL,
+	`threads` integer DEFAULT 0 NOT NULL,
+	`comments` integer DEFAULT 0 NOT NULL,
+	`acted_on` integer DEFAULT 0 NOT NULL,
+	`untouched` integer DEFAULT 0 NOT NULL,
+	`human_follow` integer DEFAULT 0 NOT NULL,
+	`oldest_untouched_days` integer,
+	`org_size_bucket` text NOT NULL,
+	`ml_metrics` text,
+	`schema_version` integer DEFAULT 1 NOT NULL,
+	`created_at` integer DEFAULT (unixepoch()) NOT NULL,
+	FOREIGN KEY (`account_id`) REFERENCES `accounts`(`id`) ON UPDATE no action ON DELETE cascade
+);
+--> statement-breakpoint
+CREATE UNIQUE INDEX `bench_contrib_uniq` ON `benchmark_contributions` (`account_id`,`vendor_kind`,`week_start`);
+--> statement-breakpoint
+CREATE INDEX `bench_contrib_account_idx` ON `benchmark_contributions` (`account_id`);
+--> statement-breakpoint
+CREATE INDEX `bench_contrib_cohort_idx` ON `benchmark_contributions` (`vendor_kind`,`week_start`);

package/dist/db/migrations/0033_thread_addressed_confidence.sql

@@ -0,0 +1,9 @@
+-- Part A: deterministic "was this thread addressed?" upgrade. Store a graded addressed-confidence
+-- + a machine reason tag + who resolved the thread, alongside the existing derivedState. All
+-- additive (defaulted / nullable) so the backfill is a no-op — the next sync recomputes them.
+-- The Postgres baseline is regenerated separately via `pnpm db:generate:pg`.
+ALTER TABLE `review_threads` ADD `addressed_confidence` text DEFAULT 'none' NOT NULL;
+--> statement-breakpoint
+ALTER TABLE `review_threads` ADD `addressed_reason` text;
+--> statement-breakpoint
+ALTER TABLE `review_threads` ADD `resolved_by_login` text;

package/dist/db/migrations/0034_thread_resolved_at.sql

@@ -0,0 +1,6 @@
+-- Resolution-latency support: record WHEN a review thread was first observed resolved. Nullable
+-- (unknown for threads already resolved at first sight); stamped by sync only on a witnessed
+-- unresolved→resolved transition. Additive — the backfill is a no-op (existing resolved threads
+-- keep a null resolvedAt; the metric only counts resolves observed going forward).
+-- The Postgres baseline is regenerated separately via `pnpm db:generate:pg`.
+ALTER TABLE `review_threads` ADD `resolved_at` integer;

package/dist/db/migrations/0035_pr_first_review_requested_at.sql

@@ -0,0 +1,5 @@
+-- Review-pickup support: store the earliest review-request time (first ReviewRequestedEvent) so
+-- we can trend request→first-review latency. Nullable (null = never requested / pre-existing PRs
+-- until the next sync backfills it from the timeline). Additive.
+-- The Postgres baseline is regenerated separately via `pnpm db:generate:pg`.
+ALTER TABLE `pull_requests` ADD `first_review_requested_at` integer;

package/dist/db/migrations/0036_search_index.sql

@@ -0,0 +1,25 @@
+-- Cross-team full-text search index (CORE, no AI). One row per searchable text unit — a PR
+-- (title + description), a review body, a review-comment (carrying its thread_id for deep-linking),
+-- or a PR-comment. Populated inside persistPr() (delete-by-pr_id then insert) and backfilled from
+-- already-stored data at startup. Denormalized account_id is the tenant anchor; matching is portable
+-- case-insensitive substring (lower(body) LIKE …). FKs cascade so a repo/PR delete cleans up.
+-- The Postgres baseline is maintained separately (migrations-pg/).
+CREATE TABLE `search_index` (
+	`id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+	`account_id` integer NOT NULL,
+	`repo_id` integer NOT NULL,
+	`pr_id` integer NOT NULL,
+	`kind` text NOT NULL,
+	`ref_id` integer NOT NULL,
+	`thread_id` integer,
+	`author_id` integer,
+	`body` text NOT NULL,
+	`created_at` integer NOT NULL,
+	FOREIGN KEY (`account_id`) REFERENCES `accounts`(`id`) ON UPDATE no action ON DELETE cascade,
+	FOREIGN KEY (`repo_id`) REFERENCES `repos`(`id`) ON UPDATE no action ON DELETE cascade,
+	FOREIGN KEY (`pr_id`) REFERENCES `pull_requests`(`id`) ON UPDATE no action ON DELETE cascade,
+	FOREIGN KEY (`author_id`) REFERENCES `users`(`id`) ON UPDATE no action ON DELETE no action
+);
+--> statement-breakpoint
+CREATE INDEX `search_account_repo_idx` ON `search_index` (`account_id`,`repo_id`);--> statement-breakpoint
+CREATE INDEX `search_pr_idx` ON `search_index` (`pr_id`);

package/dist/db/migrations/0037_author_indexes.sql

@@ -0,0 +1,15 @@
+-- Author indexes for the contributor popover (`getUserStats`).
+--
+-- Its four counts all drive from `pull_requests` (the only side carrying `account_id`) and
+-- probe each child table by `pr_id`, so the work scaled with the ACCOUNT's PR count rather
+-- than with the person being asked about: measured ~55ms on a 6k-PR local DB for a busy
+-- reviewer AND for one with zero reviews. better-sqlite3 is synchronous, so that is 55ms of
+-- blocked event loop per popover open, and it grows with the tenant.
+--
+-- No table had an `author_id` index before this. Indexing the selective side lets the planner
+-- drive from the user instead. Purely additive — no column or constraint changes.
+-- The Postgres baseline is regenerated separately via `pnpm db:generate:pg`.
+CREATE INDEX IF NOT EXISTS `pr_author_idx` ON `pull_requests` (`author_id`);--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `rv_author_idx` ON `reviews` (`author_id`);--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `prc_author_idx` ON `pr_comments` (`author_id`);--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `rc_author_idx` ON `review_comments` (`author_id`);

package/dist/db/migrations/0038_auto_merge_requests.sql

@@ -0,0 +1,37 @@
+-- Auto-merge intents ("arm it and walk away"), SQLite / local mode.
+--
+-- One row per (account, PR) recording a STANDING INTENT to merge once the blockers clear.
+-- This is Pierre-side, not GitHub's native auto-merge, so it works on repos that don't enable
+-- it and can offer a rebase-from-trunk step GitHub can't.
+--
+-- The safety property is `expected_head_oid`: arming is consent to merge THAT code. A new push
+-- moves the head, the watcher sees the mismatch and disarms ('disarmed_head_moved') rather than
+-- merging commits nobody looked at. `expires_at` is the second backstop, so an intent that never
+-- becomes mergeable dies instead of lingering for weeks.
+--
+-- FKs CASCADE (unlike the rest of the core schema, which has none) so a repo/PR delete and an
+-- account erasure clean this up without touching the intricate hand-ordered delete in
+-- `deleteRepo`. The Postgres twin is migrations-pg/0025_auto_merge_requests.sql.
+CREATE TABLE IF NOT EXISTS `auto_merge_requests` (
+  `id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+  `account_id` integer NOT NULL REFERENCES `accounts`(`id`) ON DELETE cascade,
+  `pr_id` integer NOT NULL REFERENCES `pull_requests`(`id`) ON DELETE cascade,
+  `merge_method` text NOT NULL,
+  `update_strategy` text NOT NULL,
+  `expected_head_oid` text NOT NULL,
+  `state` text NOT NULL,
+  `armed_at` integer NOT NULL,
+  `expires_at` integer NOT NULL,
+  `last_checked_at` integer,
+  `last_reason` text,
+  `created_at` integer NOT NULL DEFAULT (unixepoch()),
+  `updated_at` integer NOT NULL DEFAULT (unixepoch())
+);
+--> statement-breakpoint
+-- One armed request per PR per tenant — the upsert conflict target. Re-arming OVERWRITES.
+CREATE UNIQUE INDEX IF NOT EXISTS `amr_account_pr` ON `auto_merge_requests` (`account_id`,`pr_id`);
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `amr_account_idx` ON `auto_merge_requests` (`account_id`);
+--> statement-breakpoint
+-- The watcher's scan: "every still-armed row".
+CREATE INDEX IF NOT EXISTS `amr_state_idx` ON `auto_merge_requests` (`state`);

package/dist/db/migrations/0039_branch_status.sql

@@ -0,0 +1,44 @@
+-- Default-branch status ("is trunk green?"), SQLite / local mode.
+--
+-- Everything else in this app is PR-shaped, so the one thing that invalidates EVERY open PR's
+-- CI at once — a broken default branch — had nowhere to live. Two additive pieces:
+--
+--  1. Four nullable columns on `repos`: a snapshot of the default branch head. Kept SEPARATE
+--     from the existing `default_branch` column (written by the activity sync from GraphQL
+--     defaultBranchRef.name for the maintainer inference) so the two syncs can't silently
+--     clobber each other's freshness expectations.
+--  2. `branch_commits`: the recent commits ON that branch with their observed CI state. This
+--     is NOT derivable from the existing `commits` table, which is PR-scoped — a squash-merged
+--     PR never appears there under its trunk SHA.
+--
+-- `branch_commits` FKs CASCADE so a repo delete / account erasure cleans up automatically.
+-- Postgres twin: migrations-pg/0026_branch_status.sql.
+ALTER TABLE `repos` ADD `default_branch_name` text;
+--> statement-breakpoint
+ALTER TABLE `repos` ADD `default_branch_head_sha` text;
+--> statement-breakpoint
+ALTER TABLE `repos` ADD `default_branch_ci_status` text;
+--> statement-breakpoint
+ALTER TABLE `repos` ADD `default_branch_updated_at` integer;
+--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS `branch_commits` (
+  `id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+  `account_id` integer NOT NULL REFERENCES `accounts`(`id`) ON DELETE cascade,
+  `repo_id` integer NOT NULL REFERENCES `repos`(`id`) ON DELETE cascade,
+  `sha` text NOT NULL,
+  `message_headline` text NOT NULL,
+  `author_user_id` integer REFERENCES `users`(`id`),
+  `author_name` text,
+  `author_avatar_url` text,
+  `committed_at` integer NOT NULL,
+  `ci_status` text,
+  `created_at` integer NOT NULL DEFAULT (unixepoch())
+);
+--> statement-breakpoint
+-- Idempotent upsert target — a re-sync of the same window updates CI state in place.
+CREATE UNIQUE INDEX IF NOT EXISTS `bc_account_repo_sha` ON `branch_commits` (`account_id`,`repo_id`,`sha`);
+--> statement-breakpoint
+-- The read: one repo's window, newest first.
+CREATE INDEX IF NOT EXISTS `bc_account_repo_time` ON `branch_commits` (`account_id`,`repo_id`,`committed_at`);
+--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `bc_account_idx` ON `branch_commits` (`account_id`);

package/dist/db/migrations/0040_pr_review_decision.sql

@@ -0,0 +1,10 @@
+-- PR review decision, SQLite / local mode.
+--
+-- `merge_state_status = 'blocked'` says branch protection is unmet but never WHY, so every
+-- merge surface could only render a shrug. GitHub's `PullRequest.reviewDecision` names the
+-- review half of it ('review_required' / 'changes_requested' / 'approved'), which is what lets
+-- the collapsed merge verdict say something actionable.
+--
+-- Additive + nullable, so the backfill is a no-op: the next sync populates it. Stored lowercased
+-- to match this schema's enum convention. Postgres twin: migrations-pg/0027_pr_review_decision.sql.
+ALTER TABLE `pull_requests` ADD `review_decision` text;

package/dist/db/migrations/0041_branch_commit_detail.sql

@@ -0,0 +1,38 @@
+-- Default-branch commit DETAIL, SQLite / local mode. Two additive nullable columns on
+-- `branch_commits` plus one index on `pull_requests`.
+--
+-- The strip added in 0039 answers "is trunk green?" with a dot per commit. Both halves here
+-- answer the two questions a red dot immediately raises:
+--
+--  1. `failing_checks` — WHICH checks were failing on that commit (name, state, url, workflow
+--     name). Failures ONLY, never the passing contexts, so a green commit stores NULL and a
+--     healthy repo's rows are unchanged in size. Deliberately NOT a second copy on `repos`: the
+--     head commit is the first node of the same history walk, so it already has a row here, and
+--     the read derives the repo-level summary by matching `repos.default_branch_head_sha`. One
+--     writer, one reader, one invariant.
+--
+--     NOT lean-gated (unlike `pull_requests.check_runs`): names-only metadata, capped per commit
+--     by the writer, and a trunk commit belongs to no PR so there is no hydrate-on-demand path
+--     to be lazy INTO. Gating it would delete the feature in cloud. Same reasoning (and same
+--     column name, though a different shape) as `ci_status_events.failing_checks`.
+--
+--  2. `pr_number` — the PR the commit landed from (GraphQL Commit.associatedPullRequests), or
+--     NULL for a direct push to trunk. A plain number, NOT a `pull_requests` FK: the PR is often
+--     not synced when the commit is observed (squash-merged before the backfill window, or the
+--     repo was added later), a stored id would go stale on the next PR re-sync, and a real FK
+--     would drag this table into both delete paths. The read layer resolves number → local id
+--     per request, scoped by (account_id, repo_id), because a PR number is unique only within a
+--     repo.
+--
+-- No index on either new column — both are read out of an already-fetched row, never used as a
+-- predicate. The `pull_requests` index IS needed: the number→id resolution runs on a route the
+-- Activity console hits on every mount, and without it the planner narrows to the repo via
+-- `pr_repo_idx` and then scans that repo's entire PR set.
+--
+-- No backfill: the branch sync re-fetches the same commit window every tick and upserts on
+-- (account_id, repo_id, sha), so existing rows gain both values on the next sync. Until then the
+-- read resolves NULL → [] / null and the strip renders exactly as it does today.
+-- Postgres twin: migrations-pg/0028_branch_commit_detail.sql.
+ALTER TABLE `branch_commits` ADD `failing_checks` text;--> statement-breakpoint
+ALTER TABLE `branch_commits` ADD `pr_number` integer;--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `pr_account_repo_number_idx` ON `pull_requests` (`account_id`,`repo_id`,`number`);

package/dist/db/migrations/0042_repo_reviewers.sql

@@ -0,0 +1,176 @@
+-- THE BOT OBJECT BECOMES PER REPO. SQLite / local mode; Postgres twin:
+-- migrations-pg/0029_repo_reviewers.sql. Migration 0043 then splits the ACTOR grain back out of
+-- the table this one creates — read the two together, they are one change in two steps:
+--
+--   0042  RE-KEY     (account, author)        →  (account, repo, author)     columns unchanged
+--   0043  NORMALISE  the actor-grain columns  →  their own table `account_reviewers`
+--
+-- Keeping them separate is deliberate: the re-key is a fan-out with a footprint rule and a
+-- careful backfill, the normalisation is a lift of three columns and a price. Fused into one
+-- file, a reader cannot tell which statement is doing which job.
+--
+-- `bot_review_classification` answered "is this login a bot, and what kind" once per ACCOUNT.
+-- `repo_reviewers` answers it once per (account, REPO, author), and that row IS the bot object.
+--
+-- WHY THE REPO IS THE KEY. A bot is installed per repository — GitHub Apps are installed on
+-- repos, CI configs live in repos — while a team is a bag of repos someone can re-bag tomorrow.
+-- Keying the judgement on a team made the answer move when team membership was edited and forced
+-- an inheritance chain (team row → default row → auto-detect) whose null-means-inherit rules
+-- leaked into every read. Keying on the repo removes the chain: one row per repo, nothing to fall
+-- back to, nothing to merge, and NO DEDUPLICATION anywhere — a vendor on six repos is six rows,
+-- which is the intended display.
+--
+-- IT REPLACES THE OLD TABLE RATHER THAN EXTENDING IT. `bot_review_classification` is DROPPED at
+-- the bottom: leaving it would leave a second, differently-keyed answer to the same question
+-- sitting in every database, which is exactly how two surfaces come to disagree.
+--
+-- ── THE BACKFILL, AND WHY IT IS ASYMMETRIC ──────────────────────────────────────────────────
+-- MANUAL rows fan out to EVERY repo in the account. A human judgement is the only thing here
+-- that cannot be regenerated, it was made account-wide, and fanning it out reproduces that
+-- meaning exactly — every repo row agrees, which is the invariant ("only a human edit should ever
+-- make two of an actor's rows disagree") stated as data.
+--
+-- AUTO rows land only on repos where the actor ACTUALLY HAS A FOOTPRINT — submitted a review,
+-- opened an inline thread, or left a PR comment there. Two reasons: an auto verdict is cheap and
+-- re-derived on the next classification pass, so nothing is lost if this misses; and a row for a
+-- repo the reviewer has never touched is not a bot object, it is a fabricated one. On a real
+-- account that is the difference between a few hundred rows and actors × repos of noise.
+--
+-- The footprint CTE is MATERIALIZED on purpose: without it SQLite may re-evaluate the union for
+-- every (row, repo) pair, turning a one-off migration into minutes of nested scans.
+--
+-- The role seed at the bottom is the one judgement this migration adds. Static analysis /
+-- coverage / lint (SonarQube, Codecov, Hound) posts review comments and IS automated, but it is
+-- not reviewing, and counting it as a reviewer is what makes the Bot-ROI numbers lie. AUTO rows
+-- for those logins are re-roled in place so an account that already classified SonarQube (today
+-- it resolves to `in_house` via the githubType step — the exact miscount `role` fixes) reads
+-- correctly on first load. MANUAL rows are never touched.
+--
+-- ── TENANCY IS STRUCTURAL HERE, NOT A ROUTE CHECK ───────────────────────────────────────────
+-- `repo_id` is the FIRST column in this schema that arrives in a REQUEST BODY rather than from
+-- sync (`RepoReviewerJudgementBody.repoId` — the row IS the object, so a judgement names one).
+-- A plain `REFERENCES repos(id)` would happily accept (account 2, repo 10) where repo 10 belongs
+-- to account 1: both halves are individually valid, and the only thing standing between that and
+-- a row written into another tenant's repo would be one hand-written predicate in one handler.
+-- So the FK is COMPOSITE — `(repo_id, account_id) REFERENCES repos(id, account_id)` — which the
+-- unique index below exists to make legal (SQLite requires a UNIQUE index over the parent key
+-- columns; Postgres accepts the same plain unique index, verified on 16.13). The cross-account
+-- insert then fails with "FOREIGN KEY constraint failed" in BOTH dialects, in every code path,
+-- including a hand-written one. It replaces the single-column repo FK rather than joining it:
+-- the composite subsumes it, and two overlapping FKs is two things to keep in step.
+--
+-- THE CONSTRAINT IS NAMED, and the name is the one `schema.sqlite.ts` declares. SQLite parses and
+-- stores a `CONSTRAINT <name> FOREIGN KEY` clause but never reports it (its violation message is
+-- the bare "FOREIGN KEY constraint failed" and `PRAGMA foreign_key_list` has no name column), so
+-- here it is documentation that at least matches the stored DDL; in Postgres the same name is
+-- what the violation message quotes. Previously neither file named it, so drizzle's `name:` field
+-- pointed at nothing: pg auto-named the constraint `repo_reviewers_repo_id_account_id_fkey`.
+--
+-- ── ON RE-RUNNING THIS FILE ─────────────────────────────────────────────────────────────────
+-- Every statement is written IF NOT EXISTS / ON CONFLICT DO NOTHING, and the legacy table is
+-- stubbed below, so a hand-replay is a no-op rather than a crash. That is the SQLite answer to
+-- the pg twin's `to_regclass` guard, which exists for the same reason: this file ends by dropping
+-- the table its own backfill reads.
+-- The parent key for the composite FK, and nothing else — `repos.id` is already the PK, so this
+-- index is redundant for lookups and exists purely so the FK is expressible.
+CREATE UNIQUE INDEX IF NOT EXISTS `repos_id_account` ON `repos` (`id`,`account_id`);--> statement-breakpoint
+-- Unrelated to the FK, and here because THIS migration is where it starts costing: `review_threads
+-- .original_commenter_id` has never had an index, and it is one of the three columns the footprint
+-- CTE below unions on (a full scan of `review_threads`) AND the column the per-repo footprint
+-- counts (`RepoReviewerFootprint.threads`) group by on every bot listing.
+CREATE INDEX IF NOT EXISTS `thread_original_commenter_idx` ON `review_threads` (`original_commenter_id`);--> statement-breakpoint
+-- THE LEGACY SOURCE, STUBBED. On every database this migration is meant for, the real table is
+-- already there and this is a no-op. It exists so the backfill below is still a legal, empty
+-- statement on a database where the table has already gone — a hand-replay of this file, or a
+-- machine that ran an earlier draft of it while this branch was unpushed. The stub is dropped at
+-- the bottom along with the real thing, so it leaves nothing behind either way.
+CREATE TABLE IF NOT EXISTS `bot_review_classification` (
+	`account_id` integer,
+	`author_user_id` integer,
+	`automated` integer,
+	`kind` text,
+	`label` text,
+	`confidence` text,
+	`source` text,
+	`reasons_json` text,
+	`updated_at` integer
+);--> statement-breakpoint
+-- `kind` / `label` / `identity_source` ARE CREATED HERE AND REMOVED AGAIN IN 0043. This step is a
+-- pure re-key: every column of the old row is carried across unchanged so the two migrations can
+-- be read (and reasoned about) one at a time. 0043 is where they become one row per actor.
+CREATE TABLE IF NOT EXISTS `repo_reviewers` (
+	`id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+	`account_id` integer NOT NULL,
+	`repo_id` integer NOT NULL,
+	`author_user_id` integer NOT NULL,
+	`automated` integer NOT NULL,
+	`kind` text,
+	`label` text,
+	`identity_source` text DEFAULT 'auto' NOT NULL,
+	`role` text DEFAULT 'review' NOT NULL,
+	`confidence` text NOT NULL,
+	`source` text NOT NULL,
+	`reasons_json` text,
+	`updated_at` integer DEFAULT (unixepoch()) NOT NULL,
+	FOREIGN KEY (`account_id`) REFERENCES `accounts`(`id`) ON UPDATE no action ON DELETE cascade,
+	CONSTRAINT `repo_reviewers_repo_account_fk` FOREIGN KEY (`repo_id`,`account_id`) REFERENCES `repos`(`id`,`account_id`) ON UPDATE no action ON DELETE cascade,
+	FOREIGN KEY (`author_user_id`) REFERENCES `users`(`id`) ON UPDATE no action ON DELETE no action
+);--> statement-breakpoint
+CREATE UNIQUE INDEX IF NOT EXISTS `repo_reviewers_account_repo_author` ON `repo_reviewers` (`account_id`,`repo_id`,`author_user_id`);--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `repo_reviewers_account_repo_idx` ON `repo_reviewers` (`account_id`,`repo_id`);--> statement-breakpoint
+CREATE INDEX IF NOT EXISTS `repo_reviewers_account_author_idx` ON `repo_reviewers` (`account_id`,`author_user_id`);--> statement-breakpoint
+WITH footprint AS MATERIALIZED (
+  SELECT DISTINCT p.repo_id AS repo_id, x.uid AS author_user_id
+    FROM pull_requests p
+    JOIN (
+      SELECT pr_id, author_id             AS uid FROM reviews         WHERE author_id IS NOT NULL
+      UNION ALL
+      SELECT pr_id, original_commenter_id AS uid FROM review_threads  WHERE original_commenter_id IS NOT NULL
+      UNION ALL
+      SELECT pr_id, author_id             AS uid FROM pr_comments     WHERE author_id IS NOT NULL
+    ) x ON x.pr_id = p.id
+)
+INSERT INTO `repo_reviewers`
+  (`account_id`, `repo_id`, `author_user_id`, `automated`, `kind`, `label`, `identity_source`,
+   `role`, `confidence`, `source`, `reasons_json`, `updated_at`)
+-- `identity_source` is derived from the old row's `source` because the old model had only ONE
+-- provenance field covering both grains: a manual row's `kind`/`label` WERE a human's opinion,
+-- and importing them as 'auto' would let the next classification pass silently revert a vendor
+-- correction someone made by hand.
+SELECT b.account_id, r.id, b.author_user_id, b.automated, b.kind, b.label,
+       CASE WHEN b.source = 'manual' THEN 'manual' ELSE 'auto' END,
+       'review', b.confidence, b.source, b.reasons_json, b.updated_at
+  FROM bot_review_classification b
+  JOIN repos r ON r.account_id = b.account_id
+ WHERE (b.source = 'manual'
+    OR EXISTS (
+         SELECT 1 FROM footprint f
+          WHERE f.repo_id = r.id AND f.author_user_id = b.author_user_id
+       ))
+-- The `WHERE true` disambiguator SQLite needs before ON CONFLICT in an `INSERT … SELECT … FROM`
+-- is already satisfied by the real WHERE above (sqlite.org/lang_upsert.html §"Parsing Ambiguity");
+-- Postgres has no such ambiguity, which is why the twin's clause reads identically without it.
+--
+-- ON CONFLICT DO NOTHING never fires on a database this migration is meant for: the legacy table
+-- is unique on (account_id, author_user_id), so one row per (account, repo, author) comes out. It
+-- is here for the state an unpushed rewrite can leave behind — a machine that ran the deleted
+-- team-keyed draft has up to one row per (account, TEAM, author), which collides. The winner is
+-- then arbitrary, which is the right answer for a draft artifact and the wrong answer to reach
+-- for anywhere else.
+ON CONFLICT (`account_id`, `repo_id`, `author_user_id`) DO NOTHING;--> statement-breakpoint
+UPDATE `repo_reviewers`
+SET `role` = 'quality_check'
+WHERE `source` <> 'manual'
+  AND `author_user_id` IN (
+    SELECT `id` FROM `users` WHERE lower(`github_login`) IN (
+      'sonarqubecloud', 'sonarqubecloud[bot]',
+      'sonarcloud', 'sonarcloud[bot]',
+      'codecov', 'codecov[bot]',
+      'codeclimate', 'codeclimate[bot]',
+      'codefactor-io', 'codefactor-io[bot]',
+      'houndci-bot', 'houndci-bot[bot]',
+      'coveralls', 'coveralls[bot]',
+      'codacy-bot', 'codacy-bot[bot]'
+    )
+  );--> statement-breakpoint
+DROP TABLE IF EXISTS `bot_review_classification`;

package/dist/db/migrations/0043_account_reviewers.sql

@@ -0,0 +1,131 @@
+-- NORMALISE THE ACTOR GRAIN OUT OF `repo_reviewers`. SQLite / local mode; Postgres twin:
+-- migrations-pg/0030_account_reviewers.sql. Second half of the change 0042 starts:
+--
+--   0042  RE-KEY     (account, author)        →  (account, repo, author)     columns unchanged
+--   0043  NORMALISE  the actor-grain columns  →  their own table `account_reviewers`
+--
+-- ── WHAT WAS WRONG WITH LEAVING THEM ON THE REPO ROW ────────────────────────────────────────
+-- After 0042, `kind`, `label` and `identity_source` sit on every one of an actor's repo rows,
+-- REPLICATED, held consistent by convention with no constraint anywhere. That is precisely the
+-- hazard that giving cost its own storage was meant to eliminate — left in place for three other
+-- columns — and it was the source of three standing obligations on code that has not been written
+-- yet:
+--   1. creating a NEW repo row for an actor had to SEED all three from its siblings, or the
+--      newest repo rendered the vendor differently from the rest;
+--   2. persist() had to gate on TWO different provenance flags sitting side by side in one row
+--      (`identity_source` for kind/label, `source` for automated/role), and confusing them
+--      reverts a human's vendor correction or freezes auto-detection account-wide;
+--   3. the account-wide identity the wire serves was documented as "a straight read of any one of
+--      them" — which silently ELECTS A WINNER the moment two rows disagree, and no tie-break can
+--      make the losing rows editable or even visible.
+-- One row per actor deletes all three. There is no seeding (nothing to seed from), no second
+-- provenance flag in the same row (they are on different tables now), and no election (there is
+-- one row).
+--
+-- ── COST IS FOLDED IN, NOT GIVEN A THIRD TABLE ──────────────────────────────────────────────
+-- A price is just another actor-level property. A separate `reviewer_costs` keyed on the same two
+-- columns would be joined at every call site — this table with extra steps. ONE TABLE PER GRAIN
+-- is the clearest possible statement of the model, and it is the same argument that moves
+-- kind/label here.
+--
+-- `monthly_cents` IS THEREFORE NULLABLE, where a standalone cost table had it NOT NULL. That was
+-- the point there: "no price" was "no row", so clearing a price was a DELETE and there was no
+-- third state. A row that also carries identity exists for reasons that have nothing to do with
+-- money, so the column must be nullable.
+--
+-- DO NOT REINTRODUCE THE OLD FEAR. The bug class that made nullable money dangerous was
+-- nullable-means-INHERIT: NULL meant "fall through to the team-0 row", so 0 ("free HERE") and
+-- NULL ("ask my parent") had to be told apart with `??` and never `||` — one character from a
+-- silently wrong price. THERE IS NO INHERITANCE ANYWHERE ANY MORE. NULL means "no price set" and
+-- 0 means "free": two states, no chain, no fallback, nothing to resolve. Clearing a price is
+-- `SET monthly_cents = NULL`, not a DELETE — deleting the row would take the identity with it.
+--
+-- ── WHY `account_reviewers` ─────────────────────────────────────────────────────────────────
+-- Named for its KEY, exactly as `repo_reviewers` is, so the two table names ARE the statement of
+-- the model: one row per (account, author) here, one per (account, repo, author) there. It is
+-- deliberately not named after any single fact it holds — `reviewer_identities` would make
+-- `monthly_cents` look like a stray column, and `reviewer_costs` made `kind`/`label` look the
+-- same way. The table is defined by its grain, so the next actor-level fact (a plan tier, a
+-- contract end date) lands here without renaming anything.
+--
+-- ── REPLAY ──────────────────────────────────────────────────────────────────────────────────
+-- Everything down to the DROP is IF NOT EXISTS / ON CONFLICT DO NOTHING. The three DROP COLUMNs
+-- are NOT re-runnable: SQLite has no `DROP COLUMN IF EXISTS` (the pg twin uses one). drizzle's
+-- journal never re-runs an applied migration, so that is a hand-replay limitation only, and it is
+-- stated rather than hidden.
+--
+-- ⚠ WHAT THE COMMITTED DRAFT'S OWN COLUMNS DO *NOT* CARRY, and why the omission is deliberate.
+-- The superseded 0042/0043 on this branch added `team_id`, `role` and `cost_monthly_cents` to
+-- `bot_review_classification`. A database at the 0041 state — every fresh clone, CI, and every
+-- peer — has NONE of those columns, and a single .sql file cannot reference a column that may or
+-- may not exist (SQLite has no conditional DDL and would fail to PARSE the statement, not skip
+-- it). So 0042 reads only the pre-draft column set and writes `role` as its default.
+-- Consequence, scoped honestly: on a machine that ran the superseded draft, a per-team `role`
+-- override and a price typed INLINE are not carried. Prices that came from the legacy
+-- `pro_settings.bot_cost_json` blob are unaffected — pro 0019 re-imports them, and the blob is
+-- never dropped. That leaves only values typed into the one-day-old inline editor, on unpushed
+-- dev machines, which is a set of two on the author's box and empty everywhere else; both were
+-- preserved by hand. Contorting this file for a state that exists on one machine and can never
+-- occur again would make it wrong for every machine that matters.
+--
+-- ⚠ DRAFT-STATE HOUSEKEEPING — DELETE BEFORE THIS BRANCH MERGES. `reviewer_costs` was created by
+-- an earlier draft of 0043 while this branch was unpushed and never existed in any released
+-- version. The stub + carry-over + drop below exist ONLY so a machine that ran that draft keeps
+-- the prices it typed. On every other database the stub is created empty, carries nothing, and is
+-- dropped again. Once no such machine is left, delete these three statements.
+CREATE TABLE IF NOT EXISTS `reviewer_costs` (
+	`account_id` integer,
+	`author_user_id` integer,
+	`monthly_cents` integer
+);--> statement-breakpoint
+CREATE TABLE IF NOT EXISTS `account_reviewers` (
+	`id` integer PRIMARY KEY AUTOINCREMENT NOT NULL,
+	`account_id` integer NOT NULL,
+	`author_user_id` integer NOT NULL,
+	`kind` text,
+	`label` text,
+	`identity_source` text DEFAULT 'auto' NOT NULL,
+	`monthly_cents` integer,
+	`updated_at` integer DEFAULT (unixepoch()) NOT NULL,
+	FOREIGN KEY (`account_id`) REFERENCES `accounts`(`id`) ON UPDATE no action ON DELETE cascade,
+	FOREIGN KEY (`author_user_id`) REFERENCES `users`(`id`) ON UPDATE no action ON DELETE no action
+);--> statement-breakpoint
+CREATE UNIQUE INDEX IF NOT EXISTS `account_reviewers_account_author` ON `account_reviewers` (`account_id`,`author_user_id`);--> statement-breakpoint
+-- ONE ROW PER ACTOR, LIFTED OFF WHICHEVER REPO ROW IS MOST AUTHORITATIVE. After 0042 an actor's
+-- rows agree by construction, so on a freshly migrated database any of them would do; the
+-- tie-break exists because this is exactly the "elect a winner" step the new shape abolishes, and
+-- doing it ONCE, here, with a stated rule is the honest way to abolish it: prefer a MANUAL
+-- identity (a human named this thing), then the most recently updated row.
+--
+-- The `max(...)` in the subquery is not decoration. SQLite's documented bare-columns rule — when
+-- a query has exactly one min()/max() aggregate, the other bare columns are taken FROM THE ROW
+-- THAT MATCHED — is what makes kind/label/identity_source/updated_at come from one single row
+-- rather than four independent aggregates. The pg twin spells the same rule as DISTINCT ON with
+-- an ORDER BY; different syntax, identical selection.
+INSERT INTO `account_reviewers`
+  (`account_id`, `author_user_id`, `kind`, `label`, `identity_source`, `updated_at`)
+SELECT `account_id`, `author_user_id`, `kind`, `label`, `identity_source`, `updated_at`
+  FROM (
+    SELECT `account_id`, `author_user_id`, `kind`, `label`, `identity_source`, `updated_at`,
+           max((`identity_source` = 'manual') * 100000000000 + `updated_at`) AS pick
+      FROM `repo_reviewers`
+     GROUP BY `account_id`, `author_user_id`
+  )
+ WHERE true
+ON CONFLICT (`account_id`, `author_user_id`) DO NOTHING;--> statement-breakpoint
+UPDATE `account_reviewers`
+   SET `monthly_cents` = (
+         SELECT rc.`monthly_cents` FROM `reviewer_costs` rc
+          WHERE rc.`account_id`     = `account_reviewers`.`account_id`
+            AND rc.`author_user_id` = `account_reviewers`.`author_user_id`)
+ WHERE EXISTS (
+         SELECT 1 FROM `reviewer_costs` rc
+          WHERE rc.`account_id`     = `account_reviewers`.`account_id`
+            AND rc.`author_user_id` = `account_reviewers`.`author_user_id`);--> statement-breakpoint
+DROP TABLE IF EXISTS `reviewer_costs`;--> statement-breakpoint
+-- The point of the whole file: after this, a repo row can say nothing about WHO the actor is.
+-- `RepoReviewer` on the wire exposes no identity field and `ReviewerIdentity` exposes no
+-- judgement field, and now the storage says the same thing.
+ALTER TABLE `repo_reviewers` DROP COLUMN `kind`;--> statement-breakpoint
+ALTER TABLE `repo_reviewers` DROP COLUMN `label`;--> statement-breakpoint
+ALTER TABLE `repo_reviewers` DROP COLUMN `identity_source`;