Pulls closed as already on the base before 4e481725 stop counting as landed in the vitals and home KPIs #8759

Pulls closed as already on the base before 4e481725 are now marked carried, so they stop counting as landings. readVitals also gets the carried = 0 filter it was missing.

What changed

• src/core/migrations/20261102200000-pull-carried-backfill.ts (pinned): sets pull.carried = 1 where merged_at IS NOT NULL AND merged_oid != '' AND merged_oid = base_oid. This is how a carried close was stored before the column existed: closeAsMerged in src/core/pulls.ts saved the base it found as the merged commit. No real landing stores that: a merge or squash writes a new commit, and a fast-forward stores the head. Pulls brought in by the importer have no merged commit, so the migration does not touch them. No pull title or other guesswork is used.
• src/flow/vitals.ts: landed1h and landed6h now require p.carried = 0. 4e481725 added this check to the clog tick, the keeper's rate, the per-repo flow and the home figures, but not to readVitals. So the vitals were still counting carried closes, both old and new.
• test/flow-carried-backfill.test.ts: builds a database with every migration up to the backfill. It adds two real landings, three old-style carried closes, one imported merged pull and one unmerged pull, then reopens with all migrations. Only the three carried closes are marked. readVitals counts 2 landings in 1 h, and 3 in 6 h because the import still counts. readKpis counts 2. Without the migration, the carried = 1 and landed1h checks fail.

Not done

• The home KPIs (src/flow/kpis.ts) needed no change. They already left out pulls whose merged commit equals their base, so their number stays the same; the backfill adds the flag the other readers check.
• One kind of carried close is left as it is: closing onto the pull's own earlier landing (refs/pull/N/merged). That commit really did land once, and the home figures already count it only once.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. test/schema-migrations.test.ts, test/flow-carried.test.ts, the new test, and the 14 test files that use readVitals or readKpis all pass. scripts/fast.ts picked 419 files, too many to run here, so the full suite is left to the forge's check.

How to try it: bun test test/flow-carried-backfill.test.ts. On a deployed forge, the opened/landed line in the vitals drops by the number of old carried closes still inside each window.

🤖 Generated with Claude Code

Closes #8738

Pulls closed as already on the base before 4e481725 are now marked carried, so they stop counting as landings. readVitals also gets the carried = 0 filter it was missing.

What changed

• src/core/migrations/20261102200000-pull-carried-backfill.ts (pinned): sets pull.carried = 1 where merged_at IS NOT NULL AND merged_oid != '' AND merged_oid = base_oid. This is how a carried close was stored before the column existed: closeAsMerged in src/core/pulls.ts saved the base it found as the merged commit. No real landing stores that: a merge or squash writes a new commit, and a fast-forward stores the head. Pulls brought in by the importer have no merged commit, so the migration does not touch them. No pull title or other guesswork is used.
• src/flow/vitals.ts: landed1h and landed6h now require p.carried = 0. 4e481725 added this check to the clog tick, the keeper's rate, the per-repo flow and the home figures, but not to readVitals. So the vitals were still counting carried closes, both old and new.
• test/flow-carried-backfill.test.ts: builds a database with every migration up to the backfill. It adds two real landings, three old-style carried closes, one imported merged pull and one unmerged pull, then reopens with all migrations. Only the three carried closes are marked. readVitals counts 2 landings in 1 h, and 3 in 6 h because the import still counts. readKpis counts 2. Without the migration, the carried = 1 and landed1h checks fail.

Not done

• The home KPIs (src/flow/kpis.ts) needed no change. They already left out pulls whose merged commit equals their base, so their number stays the same; the backfill adds the flag the other readers check.
• One kind of carried close is left as it is: closing onto the pull's own earlier landing (refs/pull/N/merged). That commit really did land once, and the home figures already count it only once.

Checks run: bun scripts/gate.ts and bun x tsc --noEmit are clean. test/schema-migrations.test.ts, test/flow-carried.test.ts, the new test, and the 14 test files that use readVitals or readKpis all pass. scripts/fast.ts picked 419 files, too many to run here, so the full suite is left to the forge's check.

How to try it: bun test test/flow-carried-backfill.test.ts. On a deployed forge, the opened/landed line in the vitals drops by the number of old carried closes still inside each window.

🤖 Generated with Claude Code