Proposals
Everything under this folder is future work awaiting implementation — one self-contained spec per feature, written so a cold implementation session can execute it without extra context. When a proposal ships, it is rewritten as an as-built feature page under its product area and deleted from here.
Each product area's roadmap is the prioritized index over its proposals:
- users roadmap
- esbabbler roadmap
- posts roadmap
- platform roadmap
- sheet editor roadmap
- achievements roadmap
- virrun roadmap
- infra roadmap
The list is which areas keep a roadmap, not which have work open — a mature area's roadmap often reads "no open work", and an area with none has never needed one. ls */roadmap.md answers the first question and the page itself answers the second.
Repo-wide refactor plans have no area roadmap and live here directly:
- ESLint → oxlint migration — move rules to oxlint as coverage lands, prioritized by ESLint rule time.
- dependency reduction — what a third-party package must earn to stay in the catalog, and the ranked backlog of absorptions.
- test harness workarounds — the shims the suite carries for a gap in a runner or its DOM, each with the probe that retires it.
Sweeps are not proposals. A proposal designs behaviour that does not exist yet; a sweep carries a settled convention across code that already works and changes nothing about what it does. They are tracked as repo state in .agents/ledgers/, one ledger file per sweep — or one coverage folder, once a sweep outgrows a single file.
