A dynamic, read-only build governance layer that defines which pages may remain static, which internal routes must become dynamic or manifest-rendered, and what budgets TheoB must meet before launch.
Every TheoB pathway can move through Past, Present, and Future without losing context.
Read current signals, conditions, and live context.
Voice ready
TheoB can keep beautiful public doors fast while moving internal machinery into dynamic hubs and manifest records. The goal is simple: cut static bloat, reduce page-data collection, protect deep links, and stop feeding the 13-minute deploy dragon.
Static Page Budget Policy is active as a non-destructive build governance layer. TheoB can define static page classes, dynamic requirements, manifest-render preferences, build budgets, CSS budgets, and static route approval rules, but it cannot convert routes, redirect routes, delete routes, delete CSS, upgrade providers, or mutate production yet.
Allow public-facing core entry pages to remain static when they provide user-facing value and fast first load.
Examples: /, /watch, /observatory, /cacao, /village, /academy, /world, /vault, /joinStatic pages should be public doors, not internal machinery.Allow lightweight marketing, onboarding, demo, and public story pages to remain static when they do not hydrate heavy internal registries.
Examples: /founder, /brand-blueprint, /theob-design-language, /demo-flowMarketing pages must stay light.Review tools one by one. Simple tools may remain static; dynamic tools or tools with state, APIs, user input, or heavy dependencies should be dynamic.
Examples: /tools, /tools/apps, /tools/calculator, /tools/measurementA calculator is not the same as a live operating cockpit.Require internal readiness, registry, gate, layer, foundation, queue, receipt, provider, telemetry, governance, and system routes to be dynamic or manifest-rendered.
Examples: *-readiness-layer, *-registry, *-gate, *-foundation, *-layer, *-queue, *-receiptInternal machinery should not be prebuilt like a public landing page.Prefer manifest records rendered through dynamic hubs for internal concepts instead of one route per concept.
Examples: /readiness-hub/[recordId], /dynamic-readiness-hub-rendererOne renderer, many records.API routes, live routes, status routes, provider routes, and telemetry routes remain dynamic.
Examples: /api/live/*, /api/*Live data is not static wallpaper.Dynamic app routes with params should be reviewed for whether they need static params, dynamic rendering, or manifest lookup.
Examples: /invite/[slug], /readiness-hub/[recordId]Parameterized routes need explicit rendering posture.Pages with no public value, no traffic, repeated UI, and manifest parity should become archive or redirect candidates.
Examples: old standalone internal readiness pages after hub parityArchive only after traffic review and visual parity.Reduce static pages by converting internal and repeated system routes to dynamic or hub-rendered records.
Target: under 80 static pagesCurrent problem: recent builds generated about 193 static pages after partial dynamic conversionRemove top-level heavy page calculations and reduce static route graph pressure.
Target: under 60 secondsCurrent problem: recent page data collection has taken multiple minutesCollapse internal routes, reduce CSS, and use manifest-rendered hubs before considering provider upgrades.
Target: under 4 minutes before public launchCurrent problem: production deploy still sits near 13 minutesMigrate repeated page shells to shared utilities and delete old CSS only after visual parity.
Target: under 8,000 lines in phase one, under 4,000 laterCurrent problem: globals.css has exceeded 20,000 linesNew internal concept must first become a manifest record.
Target: zero new standalone internal readiness routes by defaultCurrent problem: new concepts were historically added as full routesSeparate public route strategy from internal architecture route strategy.
Target: public pages may expand only when tied to user acquisition, onboarding, education, or core product valueCurrent problem: public and internal route types are mixed togetherPublic entry pages may be static; internal system pages should be dynamic or manifest-rendered.
Do not make the build carry the whole operating system.Any new internal readiness, registry, gate, layer, or foundation concept must first be added to a manifest registry.
No more one-page-per-thought architecture.New static pages need a reason: user acquisition, onboarding, education, SEO, or core public product value.
Static is not free just because it works.Page data collection time must be tracked like infrastructure cost.
Slow builds are product debt.A feature that adds unique CSS, repeated shell patterns, or heavy visual blocks must justify that build and maintenance cost.
Pretty clutter is still clutter.Old routes can only redirect after manifest record exists, hub renderer works, visual parity is checked, and traffic review passes.
No broken deep links.Vercel or CI upgrades can help later, but route and static generation pressure should be reduced first.
Do not pay more to carry avoidable weight.Static Page Budget Policy defines rules only and does not convert, delete, redirect, or mutate routes.
No writes. No sync. No surprise.