Docs that quietly go stale
Your docs live in an external CMS with no link to the code. You rename a feature, ship it, and the public docs describe the old one for months. Here, docs live in the repo and change in the same pull request.
Ship every weekUI and contentdocumentation
Docs site included
A polished docs site for your product, with search, no CMS to run.
Your product gets a real docs site on day one: search, sidebar, reading progress, next-page links. Pages live in your repo as typed content, so docs ship and review like code. Tests catch a page that fell out of the menu.
- 14 docs pages ready to edit
- 5 grouped sections in the sidebar
- 0 CMS services to run
5 of 6 in Ship every week
How it works
The mechanism end to end, as implemented in the repository.
- 1
Write the page as typed content
Add or edit a page in one content file with its title, slug, and sections. No markdown pipeline, no file-system magic.
- 2
Place it in the menu once
Each page slug appears exactly once in the category list. That one placement sets its group and reading order.
- 3
Everything else derives
The index, sidebar, Cmd+K search, page metadata, and next/previous links are all computed from that list at build time.
- 4
Tests guard the structure
If a page is missing from the menu or listed twice, the build fails. Structure and content can't fall out of sync.
Interactive example
See it working
This walkthrough demonstrates the implemented backend contract without using an account, credentials, or provider calls.
Interactive example
Explore the implemented decisions
Local and provider evidence
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.
A whole CMS for fourteen pages
You just wanted product docs. Now you're managing CMS credentials, webhooks, and an editorial pipeline before page one is live. Here, there's nothing to host: docs compile with the app.
The sidebar nobody trusts
Each page hand-lists its neighbors. Someone adds a page, forgets the links, and now the sidebar and the next buttons disagree. Here, one list drives all of it, and tests fail when it's wrong.
Highlights
Why it matters
One list runs everything
Pages and their order live in one typed file. The sidebar, search, and next/previous links all derive from it automatically.
Reader comforts included
Cmd+K search, a table of contents, reading progress, mobile navigation, and feedback ship working, not as a to-do list.
The menu can't lie
Tests fail the build if a page is missing from navigation or listed twice, so the docs structure never quietly drifts.
Engineering guarantees
What this does and does not promise
Safety boundary
This is a docs site in your repo, not a hosted CMS (the disabled Sanity scaffold stays disabled). Your canonical engineering rules stay in repository docs; public pages summarize and link back.
Implementation evidence
The boundary above is code, not a claim. These files carry the contract:
src/modules/docs/content.tssrc/modules/docs/DocsSearch.tsxsrc/routes/_public/docs
Questions
Frequently asked questions
Related capabilities
These capabilities share contracts and boundaries with this one.
Build on the docs site included foundation
The docs describe the same contracts this page demonstrates.