chore(bundle-budget): re-baseline production after investigating main's 8% drift - #2099
Conversation
…'s 8% drift The production baseline was captured on 2026-08-13 at ca788d4 and never refreshed. By 2026-08-18 main measured +8.03% against it — inside the 10% tolerance, but with about two points of headroom, so the next feature to land would fail Build for weight that was not its own. PR #2096 hit exactly that: 2.7 points of Dictionary pushed the total to +10.5%. AGENTS.md says a production failure means find the regression rather than move the ceiling, so this is the investigation before the move. Two full builds from one worktree with .next removed each time — main at 9d83245 and the baseline commit ca788d4 — attributing chunks to routes through the same _client-reference-manifest.js files the check itself reads. Measuring ca788d4 independently reproduced 1,405,170 bytes against the 1,405,202 recorded in bundle-budget.json, a 32-byte difference, which validates the method. The delta is +110.2 KiB spread across the app: of 101 non-mockup routes, 52 grew, 48 were unchanged and 1 shrank, median +8.2 KiB, maximum +24.5 KiB. No route doubled, no isolated chunk appeared, no new client-bearing route landed, and package-lock.json is byte-identical between the two commits. That is what 374 commits of feature work looks like, not an accidentally-bundled dependency, which would concentrate in one chunk. Refresh production.gzipBytes to 1,518,033 with updatedAt and baselineSource so the next investigation knows where to reproduce from. The five route budgets are left tighter on purpose — each is within its own tolerance and keeps a stricter second guard on the Lighthouse journeys — and the mockups budget and every tolerancePct are untouched. Full measurement in docs/evidence/bundle-budget-production-rebaseline-2026-08-18.md. Queues an outstanding-issues request: nothing schedules a baseline refresh, so the same squeeze recurs for whichever unrelated PR lands last. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…production-baseline
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in:12 minutes Limit details: You’ve used all 1 included review currently available under your plan. You completed 101 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour. Your organization has reached its usage spending cap. Adjust your spending cap in the billing tab. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
Comment |
This pull request has been ignored for the connected project Preview Branches by Supabase. |
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Uh oh!
There was an error while loading. Please reload this page.
Summary
productionbundle-budget baseline from 1,405,202 to 1,518,033 bytes gzip, after investigating where the growth came from rather than moving the ceiling to make a gate pass.docs/evidence/bundle-budget-production-rebaseline-2026-08-18.mdwith the full measurement: method, both builds, the per-route table, and what was deliberately left alone.Why this exists
The
productionbaseline was captured on 2026-08-13 atca788d41and never refreshed. By 2026-08-18mainmeasured +8.03% against it — inside the 10% tolerance, but with roughly two points of headroom, so the next feature to land would failBuildfor weight that was not its own. PR #2096 hit exactly that: 2.7 points of Dictionary took the total to +10.5% and turned the gate red.AGENTS.mdis explicit that a production failure means find the regression, not raise the ceiling. So this PR is the investigation first and the refresh second.Measurement
Two full production builds from one worktree with the same
node_modules,.nextremoved before each so no cached output could be measured:mainat9d832452d, and the recorded baseline commitca788d41. Chunks were attributed to routes through the per-route_client-reference-manifest.jsfiles — the same sourcescripts/check-bundle-budget.mjsreads — and gzip-measured per chunk. Chunk filenames are content-hashed, so the comparison is per route rather than per chunk.ca788d419d832452dMeasuring
ca788d41independently reproduced 1,405,170 bytes against the 1,405,202 recorded inbundle-budget.json— 32 bytes apart, 0.002%. That validates both the method and that the recorded baseline really was captured at that commit.Why it is not a regression
Of the 101 non-mockup routes present in both builds, 52 grew, 48 were unchanged, 1 shrank; median growth +8.2 KiB, maximum +24.5 KiB. No route doubled, no isolated chunk appeared, and the only route added since the baseline (
/api/documents/signed-urls) ships no client JavaScript.package-lock.jsonis byte-identical between the two commits, so no dependency contributes.That shape is diffuse growth in shared chunks — 374 commits and +16,559/−6,988 lines across 254 source files. An accidentally-bundled dependency looks the opposite: one chunk or one route jumps while everything else holds still. The routes that grew most (
/therapy-compass/*,/calculators,/specifiers/map) are exactly where the largest client-side diffs landed.Deliberately not changed
routesbudgets — each is within its own 10% tolerance today, and leaving them tighter keeps a stricter second guard on the Lighthouse journeys.mockupsbudget — within tolerance onmain, and a separate hygiene ceiling.tolerancePct— the tolerance was never the problem; the staleness was.Verification
npm run verify:pr-local— partially, by selection; see below.verify:pr-local --dry-runfails closed to the heavy plan for this diff becausebundle-budget.jsonis unrecognised scope. What was actually run:npm run build+npm run check:bundle-budget— production 1482.5 KiB against the new 1482.5 KiB baseline, all five route budgets and the mockups bucket within tolerance..nextwas removed before the build, so the numbers are not stale cache.tests/bundle-budget.test.ts—Test Files 1 passed (1)/Tests 33 passed (33).npm run check:outstanding-issues,npm run check:ledger-write-discipline,npm run docs:check-links— all passed (docs link check passed: 1870 repo path references resolve;Ledger inbox check passed: 17 pending request(s), 234 applied).npm run format— clean.Not run, with reason: the full unit suite,
lintandtypecheck. The diff is one JSON baseline value, one documentation file, one inbox request and one ledger record — no source file changes, so there is no compile or behaviour path for them to detect. CI runs them anyway.npm run verify:ui— no UI, routing, styling or browser behaviour changes.npm run verify:release— provider-backed, not authorized.npm run eval:retrieval:quality/eval:rag— no retrieval, ranking, selection, chunking, scoring or answer-generation change.npm run check:production-readiness— no clinical workflow, privacy, environment, Supabase, source-governance or deployment behaviour change.Risk and rollout
ca788d41baseline andmainimmediately reads +8.03%.Notes
docs/outstanding-issues-inbox/) asks for a refresh to have an owner or a trigger — a scheduled re-measure, a drift warning below the failure threshold, or printing the baseline's commit distance so staleness is visible before it blocks somebody. Runnpm run issues:reconcilefrom a serialized ledger branch after this lands.Buildon feat(dictionary): add the eight-route Dictionary reference mode #2096 once this is onmain.