The explanation that lived in a chat thread
Someone explains why we stopped doing something, and three months later the reasoning is buried under a thousand messages. A post keeps it findable, with the screenshot of the screen it was about.
The foundation under itUI and contentblog
The blog
Where we write down how we work, and what we decided not to do.
Four posts so far: a week in Growth-OS from Monday to Friday, what Growth-OS deliberately will not do, how a decision survives the month it was made in, and why every insight carries the quote it came from. A post is one typed entry, and the listing, filters, reading time, related stories and article markup all derive from it.
- 4 posts written for the team
- 6 kinds of content block
- 1 featured story at a time
21 of 22 in The foundation under it
How it works
The mechanism end to end, as implemented in the repository.
- 1
Add a typed post
Define the post in one content file with its slug, date, description, author, tags and content blocks. The required fields are enforced by the type.
- 2
Discovery derives itself
The featured story, category filters, search, reading time and listing cards are computed from the catalog, with no wiring per post.
- 3
One shell renders every post
The shared article component renders all six block types, and a related link must point at a post that exists, so it cannot go stale.
- 4
Crawlers see what readers see
The post page emits article markup from the same metadata that renders on screen, so the two cannot disagree.
Interactive example
See it working
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Explore the decisions this makes
Typed article card
Deterministic sample data only. No account, provider, or network connection is used by the interaction.
The problem this solves
Without a shared foundation, every team rebuilds these edge cases, differently.
Posts with holes in them
One post with no date, another with no author, a third with no description. Making those fields part of the type means an incomplete post cannot build.
Every post its own layout job
Hand-rolled markup per article makes callouts, screenshots and code blocks drift apart, and writing turns into coding. Six block types through one shell keeps every post consistent.
Highlights
Why it matters
One entry, fully wired
Add a post to one typed file and the listing, filters, reading time and related stories update on their own.
Six kinds of block, one shell
Paragraphs, lists, callouts, code, screenshots of the real workspace and quotes all render through one shared article layout, so every post reads the same way.
Required fields stay required
Date, author and description are part of the type, so an incomplete post fails the build rather than publishing with holes in it.
Engineering guarantees
What this does and does not promise
Safety boundary
Posts live in the repository and are checked at build time. A screenshot block names a capture taken from the real workspace, and a name that does not exist renders nothing rather than a broken image. RSS, stored feedback and generated social images are not built, and the disabled Sanity scaffold is not an active content system.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/modules/blog/content.tssrc/modules/blog/BlogArticle.tsxsrc/routes/_public/blog
Questions
Frequently asked questions
Used alongside this
These capabilities share contracts and boundaries with this one.
What the blog rests on
The docs describe the same contracts this page demonstrates.