Skip to content

Roadmaps

Roadmaps remain useful working documents. The docs app should index them, summarize stable decisions, and extract durable reference material only when it has stopped moving quickly.

  • working-notes/FUTURE_FEATURES_ROADMAP.md
  • working-notes/DEV_DEPLOYMENT_AND_CD_ROADMAP.md
  • working-notes/AUTH_PUSH_ROADMAP.md
  • App-local feature roadmaps under the front-end app.
  • Keep implementation checklists in roadmaps while they are active.
  • Move stable decisions into admin, developer architecture, testing, release, or operations/platform pages.
  • When roadmap content becomes redundant with settled docs-site content, strip the roadmap back to actionable future work.
  • After promotion, roadmaps should keep only remaining tasks, open questions, blockers, proof still needed, and links to the durable reference page.
  • Use ADRs to track durable decisions that may eventually need full decision records.
  • Keep roadmap links close to the extracted pages so the live planning trail remains discoverable.
  • Avoid turning the docs app into a second roadmap tracker.

Use this map before copying from a roadmap into another roadmap or into a new docs page. When a durable home already exists, update that page for stable reference and trim the roadmap back to the next action.

Roadmap AreaDurable HomeRoadmaps Should Still Own
Monorepo shape and cross-app feature flowMonorepo Map and Feature Slice WorkflowNew package/app boundaries that are still being tested in active work.
Auth, route access, and permission patternsAuthentication And Authorization and Admin Content ModelBrowser-runtime hardening, future profile/MFA work, and admin/permissions UX follow-through.
Testing layers, commands, runtime contracts, and smoke postureTesting and Local Development RuntimeBuilt-app Playwright migration, browser-safe backend paths, and future smoke-promotion decisions.
i18n resources, runtime, assets, and guardrailsi18n, Contributor Workflows, and GuardrailsBranch-specific localization sweeps, unsettled verifier ideas, and future app/runtime consumers.
Media architecture and validation lanesMedia Storage And Delivery and Media Workflow And ValidationReal-cloud media proof, discrepancy-report scheduling decisions, Azure continuity, and future ingest derivatives.
Public entity identity, canonical URLs, and DTO IDsPublic Entity IdentifiersEvent/venue/series detail-route canonicalization, user handles, and global resolver decisions.
Lifecycle, provenance, ownership seams, and audit vocabularyContent Entity GovernanceEvent time modeling, soft-delete rollout, ownership implementation, and full audit-trail implementation.
Relationship modeling, query controls, URL state, and saved viewsDomain Relationships, Query Controls And Browsing State, and Front End StateThe reusable EntityRelationshipSheet contract and relationship-row lifecycle/provenance decisions.
Deployed-dev, CD, infrastructure, runbooks, and recoveryOperations / Platform and its focused deployment, lifecycle, runbook, and recovery pagesPreview-summary automation, environment profiles, backup/restore proof, and later-environment gates.
Public CLI, typed operations, and shell-script conventionsWavemap CLI, Wavemap CLI Command Reference, and Shell Scripting ConventionsGenerated command-reference source decisions and future cross-environment command-profile work.
Docs site, release identity, ADRs, and generated docsDocs Content Model, Release And Versioning, ADRs, and Generated DocumentationRelease-note policy, docs previews/versioning, generated API docs, and full ADR promotion triggers.

These are not automatic new pages. Promote them when the implementation pattern or operating rule has stopped moving fast enough that future contributors need reference more than branch history.

Use the readiness tier to decide whether the next action is writing reference, gathering proof, or leaving the topic in working notes.

No current candidate is ready for a docs-only promotion without one more proof run, product surface, or source-of-truth decision. If a candidate reaches this tier, update the durable home first, then trim the roadmap back to links and remaining follow-ups.

These topics already have likely durable homes, but the docs should wait for evidence from implementation, repeated runs, or a settled operating shape.

CandidateNeeded Before PromotionLikely Home
Environment profilesMore than one command or environment depends on a stable profile shape for account, region, stack, lifecycle, and destructive-operation posture.Configuration And Secrets, Deployment Workflows, or a future focused operations page.
Built-app browser smokePlaywright smoke has moved off next dev, auth/browser-safe routing is stable, and repeated runs show the signal is worth the cost.Testing and Deployment Workflows.
Backup/restore learning drillReal commands, artifact location, disposable restore target, validation evidence, and restore friction have been recorded.Data Durability And Recovery and Runbooks.

These topics still need product shape, cross-surface proof, or a stronger source-of-truth decision before they should become reference material.

CandidateKeep In Notes UntilLikely Home
Event time modelEvent detail/edit work resumes and the product can choose local datetime, timezone, UTC instant, time TBA, doors/end, and recurrence semantics.Content Entity Governance or a focused event architecture page.
Admin authoring and permissions UXContent authoring, role display, permission editing, audit, or moderation surfaces exist as product workflows.Admin Content Model or focused admin pages.
Entity relationship management shellThe EntityRelationshipSheet contract is proven beyond one surface and its assignment, pagination, metadata, and permissions boundaries are stable.Domain Relationships and Front End Components.
Generated CLI reference sourceRoute contracts, root scripts, wrapper metadata, or a dedicated manifest becomes the clear source of truth.Wavemap CLI Command Reference and Wavemap CLI.
Full ADRsA focused reference page no longer preserves enough tradeoff history for a durable cross-cutting decision.ADRs.

Keep these outside the curated docs site until a reviewer intentionally promotes a sanitized summary:

  • Branch-specific implementation checklists and sequencing notes.
  • Proof history, failed attempts, and raw command evidence.
  • Raw cloud inventory, Pulumi exports, workflow logs, provider identifiers, and other private operational artifacts.
  • Unsettled questions where the project still needs options, not reference.
  • App-local feature notes until the pattern matters outside the owning route or package.
  • Detailed route, handler, or component inventories when a curated page already summarizes the stable boundary.