[Parked until validation backlog stabilizes] Public GitHub Project board

Summary

Stand up a public GitHub Projects board (Now / Next / Later / Done columns fed by milestones and labeled issues), link it from README and docs, and define a lightweight sync policy so the README roadmap table and docs/stability.md checklists reference the board instead of duplicating status by hand.

Why this matters

The README roadmap table is detailed but hand-maintained — exactly the drift class the project has repeatedly fought (closed #242, #252: stale roadmap entries; #309: stale version rows). With 129 open issues and explicit Beta/1.0 gates, a board gives adopters a trustworthy "what's actually moving" view and gives contributors an honest picture of priorities — without another generated-file gate.

Current evidence

• README Roadmap table (13 rows, hand-edited each release); closed launch bugs #242/#252 document past staleness.
• docs/stability.md Beta/1.0 checklists track issue numbers manually.
• Rich label taxonomy already exists (docs/agent-context/labels.md, area/* labels seen on open issues) — board automation can key off it.
• No open issue proposes roadmap infrastructure (checked).

External context

Public project boards are the GitHub-native roadmap norm; they auto-update from issue state, eliminating the drift problem rather than gating it.

Proposed implementation

1. Maintainer creates the Project (this issue documents structure: views by milestone and by area label; Now/Next/Later status field).
2. Trim the README table to milestone-level history + a prominent board link; stability.md links the board for live blocker status (keep the criteria text, drop per-issue status duplication where the board covers it).
3. Document the sync policy in the maintainer playbook (board is source of truth for in-progress; README is history).
4. Optional: auto-add workflow (actions/add-to-project) for issues labeled roadmap.

AI-agent execution notes

• Inspect first: README roadmap section, docs/stability.md, docs/agent-context/labels.md, existing roadmap label usage (#425-427 carry it).
• Requires maintainer action for board creation/permissions — scope the PR to docs + optional workflow; coordinate.
• Don't delete historical milestone rows (they serve the launch narrative).

Acceptance criteria

• Board exists, linked from README and stability.md; labeled-issue auto-add working if adopted.
• README roadmap section restructured (history + link) with no information loss.
• Sync policy documented.

Test plan

Docs build/link check; verify auto-add workflow on a test issue if included.

Documentation plan

README, stability.md, maintainer playbook; CHANGELOG note.

Migration and compatibility notes

Not expected to require migration.

Risks and tradeoffs

Boards rot too if untriaged — the sync policy and label automation reduce manual surface; some duplication remains between milestones and board (acceptable).

Suggested labels

adoption, documentation, contributor-experience

Start with the README roadmap section, docs/stability.md, docs/agent-context/labels.md, and existing roadmap label usage in issues #425-427. Coordinate the required GitHub Project creation and permissions with a maintainer, then scope changes to the documented board links, roadmap and stability references, sync policy, and optional auto-add workflow. Done means the board and links exist, documentation retains historical information, and the docs link check passes.