[Later] Compose roadmap, milestone, and checkpoint planning #97

Outcome

Provide one reusable Aether planning spec and thin composable skill that turn a repository or cross-repository goal into a small, evidence-backed roadmap, outcome-based GitHub milestones, and executable issue checkpoints.

Capture this as later work. It is not a prerequisite for advancing the current Repository Intelligence implementation or trying a minimal end-to-end canary.

Existing foundation and scope boundary

Aether already has architecture-roadmap and create-roadmap-document. They deliberately keep strategic ROADMAP.md content separate from tactical issue queues. Preserve that distinction and compose them; do not create a competing roadmap format or turn ROADMAP.md into a backlog.

Reuse:

• Add roadmap-impact reconciliation as a completion hook for repository-changing agents #88 — roadmap-impact reconciliation at completion.
• 🏗️ [architecture] Specify bounded issue checkpoints and resumable agent execution #92 — bounded checkpoints and resumable execution.
• feat(specs): add bounded worker strategy and Flow bootstrap #96 — draft worker-strategy spec and implementation-first trial.
• Add reviewable brain-dump triage and GitHub backlog promotion skill #78 — brain-dump triage before ideas become committed work.
• Define the canonical organization roadmap and repository-roadmap inheritance contract hygiene#60 — organization roadmap ownership and repository inheritance.

Aether owns authoring and planning guidance. Hygiene owns organization policy and applicability. GitHub owns tactical work state; consumers own their roadmap intent. The draft strategy does not establish organization-wide adoption.

Required behavior

1. Inspect live source, issues, PRs, existing milestones, and handoffs within a bounded scan. Distinguish implemented, validated, merged, published, blocked, and unknown work. Report access gaps.
2. Present a concise Now / Next / Later plan linked to canonical outcomes and dependencies. Keep optional ideas separate from the finite current finish line.
3. Map outcomes to a few milestones with explicit entry/exit criteria, linked scope, and an owner. Dates are optional; do not invent deadlines or confuse milestone completion with a published release.
4. Preserve the strategic roadmap → milestone → parent issue → checkpoint → PR/evidence relationship. Reuse existing IDs and tracker records before creating anything.
5. Keep repository-scoped milestones associated with their owning repository. Link cross-repository initiatives through the canonical organization contract instead of treating one milestone number or title as a global identity.
6. Use proportional decomposition: a small issue stays small; larger issues get the smallest useful implementation checkpoints and explicit tests, documentation, local validation, audit, and repair work under the worker strategy.
7. Produce a reviewable proposed tracker diff and apply only changes within existing user authorization. Reruns must avoid duplicate milestones, issues, or children; never silently close work or rewrite strategic priority.
8. Leave a durable handoff and a short report of what changed, what remains, and the next bounded job. Measure progress against scoped outcomes, not issue-count reduction alone.

Suggested implementation checkpoints

• Define the composition contract and compact roadmap-to-milestone plan template.
• Add a thin skill with bounded discovery, duplicate reconciliation, and authorized GitHub materialization.
• Add synthetic examples/evaluations, documentation, and generated catalog/projections.
• Trial one existing repository, record limitations, and audit for unnecessary process overhead.

Execute one checkpoint at a time. Separate implementation from deferred validation explicitly; completion requires the relevant acceptance evidence.

Acceptance criteria

• Existing strategic roadmap spec/skill boundaries remain intact.
• A fresh session can produce a usable plan without the original chat.
• Milestones express finite outcomes with clear exit criteria and optional dates.
• Examples cover a small unsplit issue, an existing checkpoint tree, and a cross-repository initiative.
• An unchanged second run produces no duplicate issues or milestones.
• Partial inventories and implementation-only progress cannot imply full completion.
• Deferred quality work remains reachable after implementation checkpoints close.
• Synthetic evaluation and relevant catalog/distribution checks are recorded when implemented.

Non-goals

Implementing the Intelligence dashboard, rewriting all fleet roadmaps, creating milestones across the organization immediately, automatic merges/releases, mandatory due dates, exhaustive project management, or a new issue-tracking system.

Source

Maintainer direction on 2026-10-02: retain a flexible shared planning workflow, include milestones, prioritize short implementation checkpoints, and defer this tooling while advancing Repository Intelligence and later EgoLint/Realm integration. A tiny build-identity canary is an example of an outcome-sized first milestone, not a claim that the whole platform is complete.