feat(workflows): build implementation tasks on Ready in spec-response

I added Phase 6 to spec-response: once the author confirms a spec is Ready, file the full implementation-task breakdown in todo.org rather than leave a Ready spec nobody can act on. The phase creates one task per implementation phase, runs a completeness pass against every acceptance criterion and principle rule, marks :solo: only where the agent can build and verify end to end, collects the rest under a Manual-testing task, and defers outward-facing publish steps until the user confirms.

This is the author-side complement to spec-review's Phase 6, which emits the drop-in task block. Review produces the block, response files the work.

2 files changed, 38 insertions, 0 deletions

diff --git a/.ai/workflows/spec-response.org b/.ai/workflows/spec-response.org
index c659a0e..8ff2d71 100644
--- a/.ai/workflows/spec-response.org
+++ b/.ai/workflows/spec-response.org
@@ -35,6 +35,7 @@ A spec's review is fully processed when:
 6. *Cross-spec tensions are reconciled in writing* when related specs were reviewed together.
 7. *The review file is deleted* once 1-6 hold.
 8. *Tracking is updated* — the spec's VERIFY/task body notes "review incorporated" and whether it's implementation-ready.
+9. *Implementation tasks exist* — once the author confirms the spec is Ready, the project's =todo.org= carries the full implementation-task breakdown (Phase 6), reviewed for completeness, with =:solo:= marked and a Manual-testing task for everything else.
 
 The whole run is done when no =*-review.org= files remain and each spec is judged implementation-ready (or its remaining blockers are named).
 
@@ -125,6 +126,24 @@ When related specs were reviewed together, two reviews can recommend opposite th
 4. *Move to the next review file.* Repeat Phases 1-5 until none remain.
 5. *Report* what was accepted-wholesale, what was modified/rejected and why, any cross-spec reconciliations, and the implementation-ready verdict per spec.
 
+** Phase 6: On Ready, build the implementation-task breakdown
+
+This is the *last* step of the workflow, and it runs *only after the author confirms the spec is Ready* — never during review iterations. A Ready spec nobody can act on is unfinished; this phase turns it into tracked work. It applies to every project type (library, application, service, docs set).
+
+1. *Decide where the tasks live.* If the work is spinning off into its own project/repo, move the parent task into that project's =todo.org= (and relocate the spec with it); otherwise use the current project's =todo.org=. One parent task owns the effort; the phase tasks hang under it.
+
+2. *Create one task per implementation phase* from the spec's =Implementation phases=, in dependency order, so the task set as a whole describes the *full* milestone (e.g. v1) with no gaps. Each task body names the deliverable, its tests, and how it is verified. Carry over deferred/vNext work and any publish/release steps as their own tasks.
+
+3. *Turn a critical eye on completeness.* Re-read the spec — every phase, every acceptance criterion, every named deliverable, every data-safety/principle rule — and confirm each has a home in a task. The work is not done when the tasks merely exist; it is done when nothing in the spec is left untracked. This completeness pass is mandatory regardless of project type.
+
+4. *Mark =:solo:=* on every task the agent can both build *and* verify end-to-end with no involvement from the user — including self-verification of visuals via a headless/screenshot harness. Anything that needs the user's hands, eyes, real hardware, real hosts/credentials, or sign-off is *not* =:solo:=.
+
+5. *Add a "Manual testing and validation" task* (per =verification.md=) collecting everything not =:solo:=. As you write the phase tasks and discover items that need the user, add a child test under it with: a one-line "What we're verifying", the exact steps (one action per line), and an explicit "Expected" result — written so someone familiar with the project's domain but *not* this feature can run it from the text alone.
+
+6. *Add publish/release tasks* — remote creation, initial push, mirroring/release — and *defer the outward-facing steps* (creating a public remote, enabling a mirror, tagging a release) until the user explicitly confirms. Surface anything that needs the user's infrastructure (a server-side repo, credentials) rather than guessing it.
+
+The workflow is complete when these tasks exist, the completeness pass confirms nothing in the spec is untracked, and the user can pick up implementation from the task list alone.
+
 * Principles to Follow
 
 ** Every recommendation gets a decision
diff --git a/claude-templates/.ai/workflows/spec-response.org b/claude-templates/.ai/workflows/spec-response.org
index c659a0e..8ff2d71 100644
--- a/claude-templates/.ai/workflows/spec-response.org
+++ b/claude-templates/.ai/workflows/spec-response.org
@@ -35,6 +35,7 @@ A spec's review is fully processed when:
 6. *Cross-spec tensions are reconciled in writing* when related specs were reviewed together.
 7. *The review file is deleted* once 1-6 hold.
 8. *Tracking is updated* — the spec's VERIFY/task body notes "review incorporated" and whether it's implementation-ready.
+9. *Implementation tasks exist* — once the author confirms the spec is Ready, the project's =todo.org= carries the full implementation-task breakdown (Phase 6), reviewed for completeness, with =:solo:= marked and a Manual-testing task for everything else.
 
 The whole run is done when no =*-review.org= files remain and each spec is judged implementation-ready (or its remaining blockers are named).
 
@@ -125,6 +126,24 @@ When related specs were reviewed together, two reviews can recommend opposite th
 4. *Move to the next review file.* Repeat Phases 1-5 until none remain.
 5. *Report* what was accepted-wholesale, what was modified/rejected and why, any cross-spec reconciliations, and the implementation-ready verdict per spec.
 
+** Phase 6: On Ready, build the implementation-task breakdown
+
+This is the *last* step of the workflow, and it runs *only after the author confirms the spec is Ready* — never during review iterations. A Ready spec nobody can act on is unfinished; this phase turns it into tracked work. It applies to every project type (library, application, service, docs set).
+
+1. *Decide where the tasks live.* If the work is spinning off into its own project/repo, move the parent task into that project's =todo.org= (and relocate the spec with it); otherwise use the current project's =todo.org=. One parent task owns the effort; the phase tasks hang under it.
+
+2. *Create one task per implementation phase* from the spec's =Implementation phases=, in dependency order, so the task set as a whole describes the *full* milestone (e.g. v1) with no gaps. Each task body names the deliverable, its tests, and how it is verified. Carry over deferred/vNext work and any publish/release steps as their own tasks.
+
+3. *Turn a critical eye on completeness.* Re-read the spec — every phase, every acceptance criterion, every named deliverable, every data-safety/principle rule — and confirm each has a home in a task. The work is not done when the tasks merely exist; it is done when nothing in the spec is left untracked. This completeness pass is mandatory regardless of project type.
+
+4. *Mark =:solo:=* on every task the agent can both build *and* verify end-to-end with no involvement from the user — including self-verification of visuals via a headless/screenshot harness. Anything that needs the user's hands, eyes, real hardware, real hosts/credentials, or sign-off is *not* =:solo:=.
+
+5. *Add a "Manual testing and validation" task* (per =verification.md=) collecting everything not =:solo:=. As you write the phase tasks and discover items that need the user, add a child test under it with: a one-line "What we're verifying", the exact steps (one action per line), and an explicit "Expected" result — written so someone familiar with the project's domain but *not* this feature can run it from the text alone.
+
+6. *Add publish/release tasks* — remote creation, initial push, mirroring/release — and *defer the outward-facing steps* (creating a public remote, enabling a mirror, tagging a release) until the user explicitly confirms. Surface anything that needs the user's infrastructure (a server-side repo, credentials) rather than guessing it.
+
+The workflow is complete when these tasks exist, the completeness pass confirms nothing in the spec is untracked, and the user can pick up implementation from the task list alone.
+
 * Principles to Follow
 
 ** Every recommendation gets a decision