v2.19.0 ·
Ideas get argued with, and the roadmap says what each item is
This release is about what happens before the code: how an idea gets questioned, how a big decision gets written down, how a repo states its scope, and how you see all of it on one page. Four changes, one theme. Work used to get very little scrutiny until it was already being built.
Ideas, decisions and scope
I kept typing the same three requests into almost every roadmap item: ask me questions, challenge my idea, do some research. The step that does that rarely runs. In this project 145 of 173 instances ran at the default scope, which skips it. So the roadmap item was the only place an idea got any scrutiny, and capture was built to have no friction.
Now, when a person is there and the request does not start with idea: or say "just capture", capture refines the item before writing it. It reads the code the idea touches, the knowledge graph, and every existing roadmap item, finished and declined ones included. Then it writes the strongest case against the idea and puts it to you, up to two rounds. The item gets a ## Research section and a ## Challenge section. Nothing reads them. They are prose for whoever triages or builds the item, not a new gate.
Big decisions had the same problem later on. Every design decision used to go to one place: a knowledge graph entry with a name and a sentence of reasoning. Fine for a column name. Not fine for a new dependency or a choice you cannot back out of, because the next agent sees a one-liner and quietly reverses it.
Design now sorts its decisions. A one-way door, a new dependency, a new service, or a change to a stated constraint goes to docs/adr/decision-register.md, with the options considered and a line saying what would reopen it. It starts as Proposed, and only a person's answer makes it Accepted. Later work that touches an entry reads that reopen line first and asks before reversing it.
Scope too. AIDLC can give a repo a constitution, a short statement of what it is for and what it must never become, that later phases check against. You only got one if you arrived with a vision document. Most new projects do not have one.
Now the skill asks five questions instead, all in one message, each skippable. Your answers are written in your words to docs/vision.md and imported the same way a written vision is. If no answer says what the repo must never do, the constitution says "None stated in the vision." rather than inventing prohibitions.
The roadmap page says what each item is
The roadmap page had a dependency map I could not read. It took 434 lines of layout code to answer a question that, on the day I looked, had three answers: only 3 of 34 open items waited on unfinished work. The map is gone. Dependencies is now a list of cards, each with a line like Blocked · waits on 1 or Done · v2.18.0, and small squares beside it. Red for work not done, grey for work on hold, striped if it was declined, green for done.
Every item can now carry a ## In plain words section of at most 90 words, and the 33 open items each got one. Items without one show a draft built from their executive summary. Shipped is grouped by release, read from git. My first version placed 98 of 175 done items, because 53 older instances never recorded their branch. Finding those by the branch name aidlc start gives them took it to 150.
What it does not prove
Three of these four are skill and doc text. Their tests prove the instructions are written, not that an agent follows them in a live session, or that a constitution from five short answers is any good. Watching the next few captures and decisions will tell. The roadmap change had a rougher path: the unattended run hit its $10 cap with 34 tests failing, and I finished it by hand. A fresh review then found two tests that could not fail. Both check something real now.