v1.6.0 ·
A design is not done until it is actionable: the task breakdown
The problem
The implementation skill says "break the implementation into discrete steps" — but the steps are not an artifact. The plan lives only in the session that wrote it: when the session ends, is compacted, or hands off, the decomposition dies and the next session re-derives it from design.md at full context cost. aidlc-continue resumes at phase granularity ("implementation is incomplete") when what saves real context is task granularity ("resume at T3; T1–T2 are done").
The framework already has every ingredient the artifact needs to compose with: stable AC IDs and a closed-grammar parser (traceability-ids), a gate criterion seam (evaluateGate + per-criterion extensions), and per-instance state files. The work breakdown is the missing joint between design and code.
How it could be solved
A design that says what to build but not in what order leaves the first implementation session re-reading the design to plan — which is exactly the cost a written design was supposed to remove. So the question was where decomposition belongs, and in what form.
Putting it at the end of Design rather than the start of Implementation looks like a small scheduling choice. It is not. The design phase already has an adversarial review gate, so a breakdown produced there gets reviewed too — a missing task or an oversized one gets caught before any code exists. Deferring it to Implementation keeps the design phase tidier and loses that entirely. Design got longer; the review got sharper.
The format question had three candidates. Markdown checkboxes with a closed grammar won: it is a proven pattern in this repository, the acceptance-criteria identifiers work the same way, and it is greppable, diff-friendly, and free of any sync problem. Its weakness is thin semantics, mitigated by a real parser plus a lint that flags near-misses instead of silently ignoring them.
A markdown body with a YAML status sidecar was rejected for v1 — two files to keep in step, and no consumer yet needs the richer fields. A pure YAML task list was rejected for the opposite reason: machine-friendly, but hostile to the human review loop, and these are documents people read and edit during review.
The last piece was status granularity, and it is what keeps the gate honest. Open and done are obvious. The third state — explicitly deferred, with a dated reason — exists so that a task overtaken by events cannot be quietly deleted. Without it, a blocking gate on open tasks just teaches everyone to delete inconvenient ones.
How AIDLC solves it
PR #1 — https://github.com/rasensio/aidlc/pull/1
Merged to main 2026-08-19T22:57:26Z, merge commit 639193f93e7b4beb8b8530cf13185523f0384586.
First PR-based deployment for this repo (prior instances merged locally; the worktree-era remote made the PR flow the natural fit).