Skip to content

Roadmap

Milestones that order what to build next. Progress comes from build status, dependency order from references, and Up next feeds the work agents pick up.

The Roadmap page holds the project's milestones, in priority order. A milestone says what the team means to build together; SpecsGraph works out how far it is, what it depends on and what to build next. There are no estimates, sprints, assignees or timelines: order is the priority.

Milestones

FieldWhat it holds
Number and nameM-1, M-2, ... per project, and a name such as Checkout v2.
GoalWhat the milestone is for, in a few sentences.
Target dateInformation only. A milestone past its date and not complete is marked overdue.
Tracker keyOptional, such as the key of a Jira epic (KAN-43); it links to your tracker. Nothing is synced.
Done whenMerged (the default), Deployed on an environment, or Verified on an environment.
MembersWhat it plans, in order: features, bounded contexts, subdomains, workstreams and buildable artefacts.

Members are resolved on Main every time you look: a feature brings in the use cases that realise it, a bounded context its artefacts, a subdomain the contexts that implement it, and a workstream what its tasks scope and what it changes. Terms, roles and decisions cannot be members, as they have no build status. An artefact created in a workstream and not yet on Main shows as Not on Main yet.

An artefact can sit in several milestones. Its home is the earliest open one; later milestones show where it is planned.

Progress and phase

  • Progress reads "12 of 30 done", with a bar by build status. Done follows the milestone's Done when: at Merged, a rolled back artefact still counts, because its code is merged; at Deployed or Verified on an environment, it does not.
  • Phase is Not started, Active or Complete, or Empty when nothing resolves. An outdated artefact keeps a milestone Active.
  • Complete does not close. Choose Close milestone to accept it as finished. Closing one that is not complete lists the leftovers and asks you to confirm. Drop says it is no longer intended; Reopen brings either back to the end of the order.

Dependencies and warnings

A needs B when A's version on Main refers to B by a type, a trigger or a tag. Artefacts that need each other form a cycle and are built together. The context map adds one more check between bounded contexts.

Warnings point out what does not add up. They never refuse a change:

  • an artefact needs something planned in a later milestone, or in none;
  • an artefact needs something that is outdated;
  • a cycle is split across milestones, or an upstream context comes later than its downstream;
  • a member is archived, its workstream was abandoned, or it is planned twice;
  • a feature member realises no use case, or the members resolve to nothing to build;
  • no deployment has used the done environment yet, or the target date has passed.

Most warnings offer a fix, such as adding the missing artefact to the milestone.

Up next

The Up next panel lists what to build next: buildable artefacts on Main that are Not started and whose direct dependencies already have code, in milestone order. Include unplanned adds artefacts no milestone plans. Outdated artefacts appear on the Build page as rework, not here.

Up next feeds agents. work_item_next orders ready work items by the milestone of their artefacts, and when nothing is ready it answers Up next, so the agent can propose work with proposal_plan. A person still accepts the plan and marks the task Ready.

Who can change the roadmap

People create, edit, order and close milestones: Editors and above who may edit the project, by dragging cards and from the milestone dialogs. Agents read the roadmap with roadmap_get and never change it, even with Agent autonomy on. A project holds up to 50 open milestones of up to 200 members each.

Next steps