Manual Structure Guide

Purpose:

keep the user-manual architecture explicit without turning docs/ root back into a large mixed bag
define how START_HERE.md, USER_MANUAL.md, manual chapters, and in-app help should relate to each other

Current living entrypoints:

Manual chapters:

Shipped behavior still belongs in docs/STATUS.md, docs/START_HERE.md, docs/USER_MANUAL.md, and the relevant chapter files.

Chapter Shape

01_start_here.md
- what Taskdeck is for
- 2-minute first-value path
- glossary for Boards, Projects, Inbox, Review, Today, and Agents
02_home_and_today.md
- Home
- Today
- daily and weekly routines
03_projects_and_cards.md
- board or project basics
- cards, labels, comments, due dates, blocked state
- starter packs and the board action rail
04_inbox_and_review.md
- capture sources
- triage
- proposal review
- risk, provenance, and trust model
05_advanced_automation.md
- Chat
- Queue
- Notifications
- Activity
- Ops
- Archive
- Access
06_agents.md
- future shipped Agents and Runs surfaces
07_integrations_and_knowledge.md
- future shipped imports, connectors, knowledge, and search surfaces
08_recipes.md
- concrete step-by-step workflows
09_troubleshooting.md
- empty pages
- triage failure
- review-before-apply reasoning
- advanced-page discoverability
- demo or sample workspace enablement

Keep in-app help blocks mapped back to the manual structure:

Help topic ID or future surface	Manual target
`home`	`02_home_and_today.md`
`today`	`02_home_and_today.md`
`board`	`03_projects_and_cards.md`
`inbox`	`04_inbox_and_review.md`
`review`	`04_inbox_and_review.md`
`activity-selectors`	`05_advanced_automation.md`
`board-access-selectors`	`05_advanced_automation.md`
future `agents` or `runs`	`06_agents.md`
future `integrations` or `knowledge`	`07_integrations_and_knowledge.md`

explain the user goal before the mechanism
prefer examples over abstractions
add When should I use this page? near the top of each section
add If this page is empty when the route has a meaningful empty or first-run state
add Common mistakes near the end of each section
keep advanced or operator sections clearly separated from normal-user paths
distinguish shipped behavior from future-facing placeholders explicitly

Update the matching chapter whenever any of these change on a product surface:

route label or visible navigation placement
help-callout purpose text
empty-state guidance or recovery path
first-run or setup-loop steps
trust, review, or provenance wording that affects how users are meant to operate the page

When a chapter changes materially, also check:

The manual is now intentionally split because the novice-first shell is shipped and stable enough to justify chapter-level guidance.

Keep docs/USER_MANUAL.md as the short manual index. Keep the detailed guidance in the chapter files under docs/manual/.