How it works
The four parts of the platform, and how content moves between them.
How it works
Section titled “How it works”Staleless has four parts. Content moves between them in one direction: it is staged, then committed, then merged, then served.
The parts
Section titled “The parts”| Part | What it does |
|---|---|
| Your repository | Holds the Markdown. It is the source of truth. |
| The writer | A block editor at https://app.staleless.com over the same files. |
| The MCP server | Lets an agent read, draft and commit. It cannot publish. |
| The published site | A static build, served from the edge. |
How a change reaches a reader
Section titled “How a change reaches a reader”-
Somebody drafts
A writer edits in the browser, an agent calls
docs_write, or a developer edits the file in the repository. A draft lives on a branch. -
The rules run
The linter checks the whole tree: dead links, missing assets, undefined variables, duplicate slugs, and 21 other rules. See Lint rules.
-
A person reads the diff
This step never moves. Publishing is a merge, and a merge needs a human.
-
The site rebuilds
The merge triggers a build. The output is static files, served by the edge.
Why the repository is the source of truth
Section titled “Why the repository is the source of truth”A documentation tool that owns your content owns your exit. Staleless keeps the Markdown in a repository you control, so:
- your existing review process still applies;
- a git history that predates Staleless is not lost;
- you can leave, and your documentation is already checked out.
Warning
Because the repository is the source of truth, there is no push command. A
second way to change the same files is how two writers overwrite each other. A
merge publishes.
What runs where
Section titled “What runs where”The published site is static output on the edge. The API, the database and the background jobs run on servers Staleless operates. A build needs Node and a git checkout, so builds run there and the edge serves only the result.