Acquisition-audit SCALE-007 closure (Sprint 6 ACQ, 2026-05-16).
The web/src codebase has ~45 React.lazy() call sites (`grep -rE
'lazy\(' web/src --include='*.tsx' | wc -l`), heavily route-
splitting the SPA. Pre-2026-05-16 there was no CI guard on bundle
size, so unintended bloat in a vendor chunk or a page chunk would
slip in unnoticed until somebody profiled cold-start performance.
This commit adds:
- web/.size-limit.json — 11 budget entries: per-chunk caps on the
load-bearing chunks (main entry, vendor-recharts, vendor-react,
vendor-query, vendor-router, vendor-icons, OnboardingWizard,
CommandPalette, Timestamp) + two roll-up tiers (total vendor JS,
total app JS). Budgets tuned to current vite-build output +
~15% headroom in brotli-compressed bytes (the size-limit
default measurement mode — closest analogue to what a real
browser downloads).
- web/package.json + web/package-lock.json: `npm run size` script
+ size-limit + @size-limit/file devDeps.
- .github/workflows/ci.yml: new "Frontend bundle-size budget
(size-limit)" step in the frontend-build job, runs immediately
after the vite build.
- scripts/ci-guards/G-frontend-bundle-budget.sh: local-runnable
wrapper matching the existing ci-guards/<id>.sh contract — exits
0 on clean, non-zero with ::error:: prefix on regression.
Acceptance verified locally:
- npm install in web/ regenerates package-lock cleanly
- `npm run size` exits 0 against the committed web/dist/
- `bash scripts/ci-guards/G-frontend-bundle-budget.sh` exits 0
- All current chunks measured (brotli, kB): main entry 23.3
(cap 30), vendor-recharts 91.2 (cap 110), vendor-react 37.4
(cap 45), OnboardingWizard 28.6 (cap 35), total vendor 149.5
(cap 180), total app 351.1 (cap 425)
A regression that bloats a chunk past its cap fails CI and forces
an explicit operator decision: fix the regression, or raise the
cap in web/.size-limit.json with a rationale comment in the
commit message. Do not raise caps blindly.
shankar0123