Design: `flow` delivers its own documentation — help, man, `flow docs`, MCP resources, LSP hover, and an eventual website, all rendering one pinned content set

Docs-delivery design record — the product half of #425 (which routes authoring; this routes rendering). The principle extends unchanged: every delivery surface renders the same pinned content, and no renderer holds a private copy. What exists today, probed:

The asymmetry is the finding: agents are served better than humans. An MCP client gets the DSL guide and task catalog from inside the binary; a human at a terminal gets flow docs generate (which writes maintainer files at them) and raw roff. The fixes, in dependency order:

1. flow docs grows a reading mode. flow docs dsl, flow docs tasks, flow docs <topic> — rendering the same embedded artifacts the MCP resources serve (the mirror tree ships in the binary already; this is a renderer, not new content). Terminal rendering is #376's scoped glamour item — the one place a markdown engine is sanctioned, because the source really is markdown. generate moves under a maintainer-flagged spelling or gains a clear "this writes files for the repo" description so readers stop tripping over it (#379's index/detail shape applies here too: flow docs alone lists topics).

2. flow man becomes installable, not just visible. Per-command pages (flow-run.1, flow-schedule-create.1 — the GenManTree shape kubectl/gh use, which mango can be driven to or supplemented for), a --dir to write them for packaging, and the bare invocation on a TTY either pipes itself through the pager (man on a temp file) or says what it is instead of printing roff (#398's greeting rule, same disease). Enterprise reality: deb/rpm/brew formulae want a man tree and completions at build time — one flow docs generate --man --completions --dir style entry point is what packagers script against.\n\n3. The owner's manual is a curation, not new prose. An operator onboarding a deployment needs one ordered read: install → server trust policy → workers and versioning → egress/secrets policy → tenancy → observability → upgrade discipline. Every section exists (DEPLOYMENT.md, ARCHITECTURE.md's invariants, the auth/secrets/netpolicy package docs #408 writes, docs/reference/envvars.md). The manual is a hand-authored sequence with connective tissue under docs/ (MANUAL.md or docs/manual/), linking rather than excerpting per #425 — and it ships embedded so flow docs manual answers on an airgapped host, which is precisely the enterprise environment that needs it most.\n\n4. The website is a rendering decision to defer, and a readiness constraint to adopt now. When wanted: a static generator over docs/ + the generated reference, plus pkg.go.dev for the Go API — no bespoke content. Adopt today only the constraint that keeps that cheap: docs/ stays plain CommonMark + mermaid (no generator-specific front matter), relative links that resolve on GitHub and in a site build, and the #425 mermaid pin so diagrams can't rot. GitHub rendering remains the canonical web experience until a real audience needs more.\n\nThe parity rule that makes it one system: flow docs <topic> (human, terminal), flowstate://docs/<topic> (agent, MCP), and the website page (human, web) are three renderers over one embedded artifact set, versioned with the binary — so "what does this flow know" has the same answer regardless of who asks and how. LSP hover stays the fourth renderer, drawing from the task schema and proto comments per #425's routing, so the editor never disagrees with the terminal.\n\nRelated: #376 (glamour scope), #379 (tasks index/detail), #398 (TTY greetings), #408/#415/#425 (the authoring half), #373 (flow version — packaging metadata rides the same enterprise-distribution concern).\n\n---\n_Generated by Claude Code_

Start by reading the existing flow docs generator, hidden flow man command, MCP resources, and the docs/ inventory, including DEPLOYMENT.md, ARCHITECTURE.md, and docs/reference/envvars.md. Use related issues #376, #379, #398, and #425 to establish scope; done means the selected delivery surfaces render one pinned embedded content set without private copies.