For most of the Hub's history, three different content surfaces — news posts, SSO carousel slides, and legal documents — lived in three different storage paths, with three different repository patterns and three different ways to invalidate caches. That worked. It also drifted over time.
This week the three surfaces converged. They now share one S3 bucket,
one repository pattern (content_news, content_slides,
legal_versions), one MCP surface, and one boot-time scanner that
re-indexes the bucket into Postgres if the two ever disagree.
The post you're reading is itself stored under this new system: an MDX body and a manifest, side by side in the bucket, indexed by the content repository, and rendered through the same pipeline that draws the SSO slides and the live Privacy Policy page.
What that buys us
- Strict Zod manifest schemas. Each kind has a schema; unknown fields are rejected at write time, so a typo can't quietly land in production.
- Scan-and-reindex on boot. If the database forgets what's in the bucket — fresh environment, restored backup, migrated cluster — the watchdog rebuilds the index on first start, behind an advisory lock so multiple replicas don't race.
- One MCP surface for editors.
write_news_page,write_slide_page, andwrite_legal_versionall behave the same way: body, manifest, coordinates, done.
A handful of legacy paths and a TS-bridge fallback shipped briefly to keep the migration safe; both have since been removed now that the six-phase rollout is complete and the bucket is the source of truth.
It is a small piece of plumbing. It is also the piece that makes every subsequent content-type — release notes, status posts, changelog entries — a one-day feature instead of a one-month one.