Documentation operations

Develop, build, verify, and deploy the Blume site.

Commands

bun run docs:dev

bun run docs:build

bun run docs:preview

The static build lands in dist/. .github/workflows/docs.yml verifies every documentation change and deploys the public site to GitHub Pages when the repository variable ENABLE_GITHUB_PAGES is set to true.

The workflow also compares the canonical SDK manifest with npm every Monday and on every documentation deployment. A package release therefore cannot remain silently out of sync with the versions shown on the site.

Reader and agent outputs

PropType

markdown?{route}.md

Component-aware plain Markdown mirror.

Type{route}.md

mdx?{route}.mdx

Exact source MDX mirror.

Type{route}.mdx

llms?/llms.txt

Compact, structured page index.

Type/llms.txt

llmsFull?/llms-full.txt

Full documentation corpus.

Type/llms-full.txt

manifest?/agent-readability.json

Machine-discoverable content surface.

Type/agent-readability.json

rss?/blog/rss.xml | /changelog/rss.xml

Dated content feeds.

Type/blog/rss.xml | /changelog/rss.xml

Why remote content sources are not enabled

Blume can pull MDX and GitHub Releases at build time. The sibling implementation and spec repositories are private, and the distilled workflow token is intentionally scoped only to this repository. Adding a cross-repository token merely to import a handful of READMEs would weaken the release posture and make builds depend on remote content.

Instead, this site owns durable architecture and usage docs, labels repository access honestly, and publishes a generated support matrix from docs/sdk-manifest.json. A remote source becomes worthwhile when a sibling repo develops a substantial docs subtree and can expose it through a narrowly scoped GitHub App or public mirror.