v1.13.0 ·
A roadmap more than one person can write
The idea backlog was built for one author capturing braindumps mid-session. A flat directory of markdown files, a three-value status field, no stable identifier, and conventions that lived in skill prose. No code read or validated any of it.
That works for one technical person talking to an agent in a terminal. It fails the moment a project has more than one. Several people propose work, with mixed technical depth. You cannot ask a non-technical contributor to hand-write YAML frontmatter, or a contributor outside the repository to run the CLI. And "somebody submitted this" and "we agreed to build this" become different states that one flat directory cannot show.
What changed
Status is now the directory an item sits in. There are five: inbox, backlog, in progress, done and hold. Changing status is a git mv, and the tree is the report. Nothing reads a status field any more, and the roadmap skill forbids writing one. A file in the done directory with status: raw in its header is a bug you cannot see by looking, so I removed the second place to record the fact.
I had planned four directories. Writing down the real requirement showed the problem: with one column for un-started work, somebody else's proposal looks the same as something the team committed to. So the inbox directory holds what is submitted and not yet triaged.
Every item gets an identifier, assigned once and never recomputed, so it survives renames and moves. Dependencies point at identifiers, not filenames. A history list records when an item entered each status. It is advisory: a missing entry costs a date, never a status.
When an instance finishes, a lifecycle action moves its item to done and appends the history. Otherwise the directories become decoration within a month.
Existing projects upgrade with no manual step. Two migrations run inside aidlc update: one moves a legacy backlog into the new layout, the other removes skill files orphaned by the rename. The first uses git for tracked files, so every move is one command from undone.
Why a skill, not a command
The hard question was how someone with no checkout produces a correctly formatted file. A CLI command would not reach them, and it would add a command surface, a generated reference page and a website assertion. A web form is a product of its own.
So the framework emits a portable authoring skill, stamped with the installed AIDLC version and re-stamped on every update. The contributor loads it into whichever AI agent they already use. The agent formats; the person describes the idea. It names no AI vendor, and a check fails the build if one appears.
Two things followed. The file cannot go through the platform adapters, since each re-serializes frontmatter from a fixed key set and would have dropped the version stamp, the one field this depends on. And the version is substituted at install time, because a literal in the source is a bump site the release script can forget. A build check now fails on a hardcoded one.
What it does not do
It never decides what to build. Watching a folder for new files, or pulling a document into an instance without a human, was never on the table. The lifecycle has no file-change event, I do not want daemons, and promotion is a judgement. Filing completed items is bookkeeping, so that is automatic.