Guides that quietly go stale
A written guide with no link to the code describes last quarter’s screen for months, and people stop trusting it. Keeping pages in the repository means the screen and its guide move together.
The foundation under itUI and contentdocumentation
The guides
A written guide for every part of the workspace.
The guides walk through Growth-OS the way you use it: signing in and what your role allows, companies and the pipeline, meetings and evidence, objectives and decisions, campaigns and content, playbooks, the Time Machine, finance, and the wider workspace around them. Pages are typed content in the repository, so a guide changes in the same pull request as the screen it describes.
- 26 guides, each placed exactly once
- 9 grouped sections in the sidebar
- 0 content services to run
20 of 22 in The foundation under it
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 and no file-system conventions to learn.
- 2
Place it in the menu once
Each slug appears exactly once in the category list, and that single placement sets its group and its reading order.
- 3
Everything else derives
The index, sidebar, search corpus, page metadata and next and previous links are computed from that list at build time.
- 4
Tests guard the structure
A page missing from the menu, or listed twice, fails the build. Structure and content cannot fall out of step.
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
Signing in and what a role allows
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 content system for a couple of dozen pages
Credentials, webhooks and an editorial pipeline before the first page is live. There is nothing to host here: the guides compile with the app.
A sidebar nobody trusts
When each page lists its own neighbors, someone adds a page, forgets the links, and the sidebar and the next button disagree. One list drives all of it, and a test fails when it is wrong.
Highlights
Why it matters
One list runs everything
Pages and their order live in one typed file. The index, sidebar, search corpus and next links are all derived from it.
Reader comforts included
Search on Cmd or Ctrl and K, a table of contents, reading progress, mobile navigation and feedback all work rather than being planned.
The menu cannot lie
A test fails the build if a page is missing from navigation or listed twice, so the structure cannot quietly drift from the content.
Engineering guarantees
What this does and does not promise
Safety boundary
These pages describe what the workspace does and link on; the engineering rules stay in the repository docs folder. The site is compiled with the app, not served by a hosted content system, and the Sanity scaffold stays disabled.
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
Used alongside this
These capabilities share contracts and boundaries with this one.
What the guides rests on
The docs describe the same contracts this page demonstrates.