refactor: fold spec review findings into the spec itself

The spec-review/spec-response pair wrote findings to a sibling <spec>-review.org file that spec-response deleted once processed. The deletion left the iteration-history Artifacts line dangling and dropped the verbatim review. Keeping the file instead collided with spec-response's file discovery and its "no review files remain" done-condition.

Findings now live in the spec under a * Review findings section as TODO tasks with a [/] cookie, the same shape * Decisions already uses. The reviewer records findings there. The responder completes each in place (accept and modify finish DONE, reject finishes CANCELLED with the reason), and the readiness rubric gates on the cookie. A scope-expanding response re-runs the rubric and files any new obligation as a finding or decision before claiming Ready, because resolving every finding can still introduce unreviewed assumptions.

Also folds in two reviewer-practice principles: keep review and response roles explicit, and cite the source for external-dependency facts in a finding. Updates spec-create.org and the workflow INDEX so the trio describes one convention.

1 files changed, 2 insertions, 2 deletions

diff --git a/.ai/workflows/spec-create.org b/.ai/workflows/spec-create.org
index f90c511..508b969 100644
--- a/.ai/workflows/spec-create.org
+++ b/.ai/workflows/spec-create.org
@@ -10,7 +10,7 @@ The guiding principle, drawn from how Google, Oxide, Amazon, Basecamp, and the A
 
 It is the front of a trio:
 - =spec-create.org= (this one) — author writes the spec.
-- =spec-review.org= — a reviewer gates the spec for implementation-readiness and writes =<spec-basename>-review.org=.
+- =spec-review.org= — a reviewer gates the spec for implementation-readiness and records findings in the spec's =* Review findings= section.
 - =spec-response.org= — the author folds the review back in.
 
 The spec this workflow produces has to *pass spec-review's gate* — that gate is the definition of done. So the structure below is built to answer the reviewer's questions up front. Keep it lightweight anyway: a short required spine plus a *readiness-dimensions menu* where each item is either answered or explicitly marked "N/A because…". The best spec is the shortest one that still lets an engineer build it, test it, and ship behavior that matches the user's mental model.
@@ -59,7 +59,7 @@ Capture, in this order:
 
 This is where the spec earns a "Ready" from review: an engineer must be able to build it in steps, know when it's done, and never have to invent product behavior mid-implementation.
 
-1. *Implementation phases* — decompose the work into phases each small enough to finish in one focused session and each leaving the tree in a working (not half-broken) state. =spec-review= lifts this section straight into =todo.org= tasks, so a spec that can't be phased fails the gate — the absence is itself a finding.
+1. *Implementation phases* — decompose the work into phases each small enough to finish in one focused session and each leaving the tree in a working (not half-broken) state. =spec-review= checks this section decomposes cleanly and =spec-response= lifts it into =todo.org= tasks, so a spec that can't be phased fails the gate — the absence is itself a finding.
 2. *Acceptance criteria* — the observable conditions that mean the feature works, written as checkable items. The review's test-surface task mirrors these.
 3. *Readiness dimensions* — walk this menu and, for each, either define the behavior or write "N/A because…". The escape hatch keeps a simple spec short; the prompt keeps a hidden decision from slipping into implementation:
    - *Data model & ownership* — what's user-authored / generated / cached / remote; who owns each editable region; what persists vs refreshes.