v1.6.0 ·
A design is not done until it is actionable: the task breakdown
The implementation skill told the agent to break the work into discrete steps. But the steps were never written down. The plan lived in the session that made it. When that session ended, got compacted or handed off, the plan died, and the next session re-derived it from design.md at full context cost.
Resuming had the same flaw. aidlc-continue could only say "implementation is incomplete". What saves context is "resume at the third task, the first two are done".
What changed
A design now ends with a tasks.md: a list of checkbox lines, each tied to the acceptance criteria it covers. A parser reads it. aidlc gate fails while any task is still open, and aidlc status shows a Tasks column with done out of total. The full-feature and quick-feature templates require the file at design time. Bugfix makes it optional, and micro-task and spike are untouched.
A task has a third state besides open and done: deferred, with a dated reason. That one matters. Without it, a gate that blocks on open tasks teaches everyone to delete the inconvenient ones. A task overtaken by events gets deferred on the record instead of quietly vanishing.
Why this way
I put the breakdown at the end of design, not the start of implementation. It looks like a scheduling detail. It is not. Design already has an adversarial review, so the breakdown gets reviewed too, and a missing or oversized task is caught before any code exists. Design got longer. The review got sharper.
For the format I chose markdown checkboxes with a closed grammar. This repository already uses that pattern for acceptance-criteria identifiers, and it is greppable and diff-friendly with nothing to keep in sync. Its weakness is thin meaning. A real parser covers that, plus a lint that flags near-misses instead of silently ignoring a line that almost parsed.
I rejected a markdown body with a YAML status sidecar. Two files to keep in step, and nothing needed the richer fields yet. I rejected a pure YAML list for the opposite reason: easy for machines, hostile to a person reviewing and editing it.
What it does not do
Instances that were already past design have no tasks.md. A legacy filter makes the requirement bind only instances whose design state already lists the artifact, so nothing in flight breaks.
The merged tree ran 1114 tests across 75 files, all passing. I also ran the gate on this feature's own ten tasks, and it passed.