FeatureRoadmap
Every prompt becomes a ticket. Nothing happens off the record.
Roadmap tickets for AI coding agents turn a week of prompts into a week of work you can read back. Every command runs a ticket, and a prompt with no ticket behind it gets one. Each ticket carries its own mission, and no ticket moves forward without evidence.
Last updated:
Two ways in
Plan it, or just say it
Most backlogs die because they demand ceremony before work. This one takes your ticket when you have one and writes it when you do not.
| What you do | What the roadmap does |
|---|---|
| You write a ticket in your own words | It becomes an implementation ticket with the mission filled in: goal, intent, boundaries, acceptance criteria. Your wording is kept; the structure is added. |
| You type a prompt that matches an open ticket | The run binds to that ticket. Weeks later the work and the reason still point at each other. |
| You type a prompt that matches nothing | A ticket is created from your sentence and linked to the run. The record exists whether or not you were in a planning mood. |
| You finish, and the checks pass | The ticket advances, carrying the evidence that let it. Without evidence it does not move. |
The ticket
A ticket that holds the mission, not a title and a hope
A ticket is only useful if it says what done means. This one has to, because the same fields decide the verdict.
RG-CHECKOUT-VALIDATION-1
Example – illustrative ticket, not real registry dataid RG-CHECKOUT-VALIDATION-1
status validated
source prompt, 2026-08-11 14:19
goal Fix the checkout validation bug, payments untouched
intent bugfix
allowed src/checkout/validation.py, tests/
protected src/payments/**, alembic/versions/**
accepts empty postcode yields a field error, not a 500
tests/test_checkout_validation.py passes
runs rg-4f2a verdict BLOCKED protected path changed
rg-5b81 verdict VERIFIED pytest -q exit 0
evidence receipt rc-77e (digest verified)The two failed attempts stay in the ticket. That is the point: a backlog that only records the version that worked teaches you nothing, and the run that was blocked is exactly the one worth remembering.
Status
Every step forward is earned
The status machine validates each transition, and the seven states below refuse to be entered without an evidence reference.
| State | What it takes to get there |
|---|---|
| implemented | A run that changed the declared files, read from Git rather than reported. |
| validated | The approved checks executed, with the exit codes Reality Graph observed. |
| reviewed | A trust review bound to that run, with its verdict and its limitations. |
| accepted | A person decided, and the decision is recorded against the run, HEAD and scope it was made for. |
| committed · pushed · released | The corresponding evidence reference. Reality Graph performs none of these for you and records each of them when you do. |
The registry is append-only, so the history of a ticket is the history, not the current opinion of it. Paired with the verdict and its receipts, a finished ticket is something you can hand to a reviewer who was not in the room.
By design
Where the roadmap stops
A planning layer with write access to your repository is a liability. This one has none.
What it does
- Bind every command to a ticket, and create one from your prompt when nothing matches.
- Carry the mission inside the ticket, so the plan and the yardstick are the same artefact.
- Validate every status transition and refuse the ones that arrive without evidence.
- Keep an append-only record, so the attempt that failed stays as legible as the one that worked.
What it never does
- Touch your source, your runtime stores, your .env or your tool folders.
- Activate a sprint, reprioritise your backlog, or decide what matters next.
- Commit, push or release anything on your behalf.
- Replace Jira or Linear. It records what actually happened in the repository, which is a different job.
The mission inside a ticket is the same artefact documented on the mission contract page, and the board itself lives in the local dashboard.
Questions people actually ask
- Do I have to write tickets before I can work?
- No. Write them when you want to plan, and skip them when you want to move. A prompt with no ticket behind it gets one, built from your own sentence and linked to the run it produced. Planning ahead is an option; leaving a record is not.
- What does a ticket contain?
- The mission: the goal, the declared intent, the paths that may change, the paths that stay off limits, and the acceptance criteria. That is the same artefact the run is judged against, so the ticket and the yardstick are one thing rather than two that drift apart.
- Can a ticket be marked done without proof?
- No. Implemented, validated, reviewed, accepted, committed, pushed and released all require an evidence reference, and the status machine rejects any transition that does not have one. A ticket cannot claim to be finished on somebody's word.
- Does the roadmap touch my repository?
- It writes to its own registry and nothing else. Your source, your runtime state, your .env and your tool folders are off limits by construction, it never activates a sprint on its own, and it never commits.
Look at what your team shipped last sprint
Not the commits. The reasons. If you cannot reconstruct them, that is the gap this closes.
Keep going
Step 8 of 9