aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-06-12 19:15:15 -0500
committerCraig Jennings <c@cjennings.net>2026-06-12 19:15:15 -0500
commit7c052535f371c67956947a5afe711c71350feaf4 (patch)
tree8ef25952f98223ed892b1714878c722f7ed59aaf
parentf11dd5c4e70ebbf487205aa72998e87b123d7f9d (diff)
downloadrulesets-7c052535f371c67956947a5afe711c71350feaf4.tar.gz
rulesets-7c052535f371c67956947a5afe711c71350feaf4.zip
feat(workflows): spec decisions become org TODO/DONE tasks
Each spec decision is now an org TODO task that flips to DONE when the decision-maker agrees, with a [/] cookie on the Decisions heading and a Discussion child for disputes. This replaces the inline State: proposed | accepted | superseded field. spec-response folds settled decisions by flipping them to DONE. spec-review's readiness gate and Ready rubric require the cookie to read complete. A spec can't move past draft to implementation-ready while any decision is still TODO. From the .emacs.d handoff 2026-06-12.
-rw-r--r--.ai/workflows/spec-create.org25
-rw-r--r--.ai/workflows/spec-response.org13
-rw-r--r--.ai/workflows/spec-review.org8
-rw-r--r--claude-templates/.ai/workflows/spec-create.org25
-rw-r--r--claude-templates/.ai/workflows/spec-response.org13
-rw-r--r--claude-templates/.ai/workflows/spec-review.org8
6 files changed, 62 insertions, 30 deletions
diff --git a/.ai/workflows/spec-create.org b/.ai/workflows/spec-create.org
index 42f36b9..daf56f7 100644
--- a/.ai/workflows/spec-create.org
+++ b/.ai/workflows/spec-create.org
@@ -48,12 +48,12 @@ Capture, in this order:
1. *Design* — overview first, then detail. Write the reasoning as *prose, not bullet dumps* — prose exposes weak logic that bullets let you hide. Use bullets only for genuinely enumerable lists. When the thing has an interface, use the *two-altitude* split (Rust RFC): explain it once for a user/caller, once for an implementer.
2. *Alternatives considered* — the load-bearing section authors skip and reviewers need most. For each option, force a why-not with the MADR grammar: "Good, because… / Bad, because… / Neutral, because…". Even one rejected option, with the reason, beats presenting one path as inevitable.
-3. *Decisions* — capture each real choice as an inline mini-ADR (Nygard's spine):
- - =State:= proposed | accepted | superseded
+3. *Decisions* — capture each real choice as an org =TODO= task carrying an inline mini-ADR (Nygard's spine):
+ - The heading is =** TODO <Decision name>=. It flips to =DONE= when the decision-maker agrees with the call; until then it stays =TODO=.
- =Context:= the forces motivating the choice
- =Decision:= the call, stated actively ("We will…")
- =Consequences:= what gets easier *and* what gets harder (both halves — a decision with only upsides is under-examined)
- An *open* decision is simply =State: proposed= plus an *owner* and a *by-when*; resolving it flips to =accepted= with the rationale in Decision. Never rewrite a resolved decision — mark it =superseded= and keep the old one. Keep decisions inline here; promote to a standalone numbered ADR only when a decision outlives or spans beyond this one spec. (The decision =State= is distinct from the spec-wide =Status= in the metadata header.)
+ An *open* decision is a =TODO= task with an *owner* and a *by-when*; agreeing flips it to =DONE=. If the decision-maker doesn't agree, it stays =TODO= and the back-and-forth continues under a =*** Discussion= child header — never overwrite the decision body to win an argument. Put a =[/]= statistics cookie on the =* Decisions= heading so the resolved tally is visible at a glance. To revisit a =DONE= decision, either reopen it to =TODO= (carrying the new dispute in its =*** Discussion= thread, prior text preserved) or write a fresh decision that supersedes it; don't silently rewrite the old one. Keep decisions inline here; promote to a standalone numbered ADR only when a decision outlives or spans beyond this one spec. (The per-decision =TODO/DONE= is distinct from the spec-wide =Status= in the metadata header — see the implementation-ready gate in Phase 6.)
** Phase 3 — Make it buildable
@@ -90,7 +90,7 @@ This is where the spec earns a "Ready" from review: an engineer must be able to
** Phase 6 — Hand-off readiness
Self-assess against =spec-review='s rubric before handing off, so the review starts from a clean spec instead of catching basics:
-- *Decisions:* no =State: proposed= decisions remain, or the author *consciously accepts* the risk of building with one open (recorded).
+- *Decisions:* every decision is =DONE= (the =[/]= cookie reads complete), or the author *consciously accepts* the risk of building with one still =TODO= (recorded). *Implementation-ready gate:* the spec Status cannot move past =draft= to an implementation-ready state while any decision is still =TODO=.
- *APIs:* every external API assumption is verified or listed as a research prerequisite — otherwise the honest verdict is =Needs research=.
- *Self-rubric:* Ready / Ready with caveats / Not ready / Needs research. If it isn't at least =Ready with caveats=, keep drafting.
- *Defer:* log open decisions and vNext items to =todo.org= (v1 work =[#B]=, vNext/someday =[#D]=) — don't leave them only in the spec.
@@ -105,10 +105,14 @@ Then it's ready for =spec-review.org=. Snapshot-vs-living rule: keep the spec li
,#+DATE: <YYYY-MM-DD>
,* Metadata
-| Status | draft |
-| Owner | <name> |
-| Reviewer | <name(s)> |
+| Status | draft |
+|----------+---------------|
+| Owner | <name> |
+|----------+---------------|
+| Reviewer | <name(s)> |
+|----------+---------------|
| Related | [[file:...][task / ticket]] |
+|----------+---------------|
,* Summary
<2-3 sentences: what this is and why it exists.>
@@ -135,13 +139,14 @@ Then it's ready for =spec-review.org=. Snapshot-vs-living rule: keep the spec li
- Bad, because <…>
- Neutral, because <…>
-,* Decisions
-,** <Decision name>
-- State: proposed | accepted | superseded
+,* Decisions [/]
+,** TODO <Decision name>
- Owner / by-when: <name> / <when> (open decisions only)
- Context: <forces>
- Decision: We will <…>
- Consequences: easier <…>; harder <…>
+,*** Discussion (only while the decision is contested / not yet agreed)
+- <ongoing back-and-forth; the decision flips to DONE when agreed>
,* Implementation phases
,** Phase 1 — <smallest noun phrase>
diff --git a/.ai/workflows/spec-response.org b/.ai/workflows/spec-response.org
index 8ff2d71..2686cf8 100644
--- a/.ai/workflows/spec-response.org
+++ b/.ai/workflows/spec-response.org
@@ -31,7 +31,7 @@ A spec's review is fully processed when:
2. *Accepted recommendations are woven into the spec body* — the spec reads as if they were always there, not appended as a changelog.
3. *Modified and rejected recommendations are documented in a bottom section* (e.g. "Review dispositions") with a one-paragraph reason each, so the reviewer can find the reasoning.
4. *Review/response provenance is documented in the spec* — iteration count/date, contributor, role, what changed, and why.
-5. *Pre-agreed decisions are baked in as decisions*, moved out of "open questions."
+5. *Pre-agreed decisions are flipped to =DONE=* — each settled decision's =TODO= becomes =DONE=, and the =[/]= cookie on the spec's =* Decisions= heading reflects the tally.
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.
@@ -93,7 +93,7 @@ For each recommendation, choose one:
- *Reject:* the review floated a separate =default-issue-filter= defcustom. Rejected as redundant — a fixed default command plus a default-view preference already covered it.
- *Modify (scope):* "split representation from network into modules" — adopted the logical boundaries but kept a single file, because the package is a single-file MELPA target and a file split is a larger restructuring.
-*Honor pre-agreed decisions.* If the reviewer marked a decision "agreed" (or the user pre-encoded it), treat it as accepted and settled — move it from the spec's open questions into a decisions section.
+*Honor pre-agreed decisions.* If the reviewer marked a decision "agreed" (or the user pre-encoded it), treat it as accepted and settled — flip its decision task to =DONE= (adding the decision to the spec's =* Decisions= section first if it only existed as an open question).
** Phase 3: Reconcile cross-spec tensions
@@ -114,8 +114,8 @@ When related specs were reviewed together, two reviews can recommend opposite th
- *What changed:* compact summary of accepted, modified, and rejected work.
- *Why:* the rationale or decision pressure behind the changes.
- *Artifacts:* review filename, disposition section, task IDs, source checks, or commits when useful.
-4. *Move settled questions out of "Open decisions"* into an "Agreed decisions" (or equivalent) section. Open decisions should contain only what genuinely still blocks.
-5. *Raise the spec to implementation-ready:* consolidate decisions up front, add any implementation prerequisites the review surfaced (e.g. a schema-verification checklist), a consolidated test strategy, and a phased plan ordered so dependencies (like an output model everything depends on) come early.
+4. *Flip settled decisions to =DONE=.* Each decision the decision-maker has agreed flips its =TODO= to =DONE=; the =[/]= cookie on the =* Decisions= heading tracks the tally. A contested decision stays =TODO= with the back-and-forth under its =*** Discussion= child header. Decisions still =TODO= should be only what genuinely still blocks, each with an owner and a by-when.
+5. *Raise the spec to implementation-ready:* consolidate decisions up front, add any implementation prerequisites the review surfaced (e.g. a schema-verification checklist), a consolidated test strategy, and a phased plan ordered so dependencies (like an output model everything depends on) come early. *Gate:* the spec Status cannot move past =draft= to implementation-ready while any decision is still =TODO= — the =[/]= cookie must read complete, or the author consciously accepts and records the risk of building with one open.
6. *Update the status line* to note "review incorporated (<reviewer>, <date>)."
** Phase 5: Close out and iterate
@@ -208,3 +208,8 @@ Update this workflow as we learn what works. Capture new disposition patterns, b
- *What:* Backfilled this section with entries for the workflow file's prior iterations (Draft 1, Review-and-Fold, Requirement addition). Used commit author dates where exact; Draft 1's timestamp is an opaque-id placeholder since no exact time was recorded.
- *Why:* The iteration-history requirement landed in =55adf6e= without retroactive entries for the workflow file's own prior history. This pass closes that gap so the section starts with full provenance rather than empty.
- *Artifacts:* Working draft sources at =working/spec-workflows-iteration-history-backfill/draft-entries.org= (deleted on this commit). Spec-response cycle (two Codex reviews and three rulesets responses on the draft) validated the entries and the entry-shape before splicing.
+
+** 2026-06-12 Fri @ 19:09:00 -0500 — Claude Code (rulesets) — responder
+- *What:* Reconciled this workflow to spec-create's new Decisions convention (each decision is an org =TODO= task that flips to =DONE= on agreement, with a =[/]= cookie on the =* Decisions= heading and a =*** Discussion= child for disputes). Exit Criterion 5, Phase 2's pre-agreed-decisions step, and Phase 4 steps 4-5 now speak in flip-to-=DONE= terms, and the implementation-ready step gates on the all-=DONE= cookie.
+- *Why:* The convention change landed in spec-create.org via an .emacs.d handoff (originated in its keymap-consolidation spec); this workflow still described the retired =State: proposed | accepted | superseded= model.
+- *Artifacts:* Handoff =inbox/2026-06-12-1906-from-.emacs.d-spec-create-decisions-todo-note.org=. Paired spec-create.org and spec-review.org edits in the same commit.
diff --git a/.ai/workflows/spec-review.org b/.ai/workflows/spec-review.org
index db8c528..61c1239 100644
--- a/.ai/workflows/spec-review.org
+++ b/.ai/workflows/spec-review.org
@@ -74,6 +74,7 @@ Mark the spec implementation-ready only if *all* of these hold:
- Scope is explicit: v1, out-of-scope, and vNext are separated.
- Project principles are explicit where the feature touches user data, remote systems, destructive actions, long-running operations, or public extension points.
- All prior review questions/recommendations are answered or intentionally deferred.
+- Every decision in the spec's =* Decisions= section is =DONE= (the =[/]= cookie reads complete), or each still-=TODO= decision carries a consciously-accepted, recorded risk.
- The expected UX is concrete enough to implement without guessing.
- Existing platform/framework affordances are reused, wrapped, or intentionally replaced; lost opportunities are called out.
- The data model, state ownership, persistence, and sync behavior are defined.
@@ -185,7 +186,7 @@ Deferred features to capture in task tracking.
Assign one label consistently:
-- =Ready= — no blocking open questions; implementation can start.
+- =Ready= — no blocking open questions; implementation can start. Requires every decision in the spec's =* Decisions= section to be =DONE= (the =[/]= cookie reads complete) — a decision still =TODO= holds the rubric at =Not ready=, or =Ready with caveats= if the author consciously accepts and records the risk.
- =Ready with caveats= — can start if the caveats are accepted and tracked.
- =Not ready= — blocking ambiguity / missing decisions would force implementers to invent product behavior.
- =Needs research= — external API/library/platform assumptions must be verified first.
@@ -343,3 +344,8 @@ Sources:
- *What:* Promoted the two Codex (emacs-d) passes above into the canonical workflow. The reusable checks had been written into =.emacs.d='s synced copy, which the startup rsync overwrites from canonical, so they would not have survived or propagated. Folded them into =claude-templates/.ai/workflows/spec-review.org= and synced the =.ai/= mirror, so every project picks them up on next startup. Verified the promotion is a pure superset — every change is an added or expanded generic check, no regressions.
- *Why:* The handoff =inbox/2026-06-06-spec-review-workflow-update.md= asked for it: reusable review practice belongs in the canonical workflow, spec-specific findings stay in the spec. Exit Criterion 7 and the Living-Document harvesting guidance, added in the same passes, name this as the intended path.
- *Artifacts:* Handoff preserved at =docs/design/2026-06-06-spec-review-reusable-checks-handoff.md=. Paired spec-response.org Phase 6 (author-side implementation-task breakdown) committed in the same session.
+
+** 2026-06-12 Fri @ 19:09:00 -0500 — Claude Code (rulesets) — responder
+- *What:* Reconciled this workflow to spec-create's new Decisions convention (each decision is an org =TODO= task that flips to =DONE= on agreement, with a =[/]= cookie on the =* Decisions= heading). The Phase 1/3 readiness gate gains an all-decisions-=DONE= item, and the Phase 6 =Ready= rubric label now requires the =[/]= cookie to read complete (a still-=TODO= decision holds the rubric at =Not ready=, or =Ready with caveats= on a recorded, consciously-accepted risk).
+- *Why:* The convention change landed in spec-create.org via an .emacs.d handoff (originated in its keymap-consolidation spec); the rubric still gated on the retired =State:= field model.
+- *Artifacts:* Handoff =inbox/2026-06-12-1906-from-.emacs.d-spec-create-decisions-todo-note.org=. Paired spec-create.org and spec-response.org edits in the same commit.
diff --git a/claude-templates/.ai/workflows/spec-create.org b/claude-templates/.ai/workflows/spec-create.org
index 42f36b9..daf56f7 100644
--- a/claude-templates/.ai/workflows/spec-create.org
+++ b/claude-templates/.ai/workflows/spec-create.org
@@ -48,12 +48,12 @@ Capture, in this order:
1. *Design* — overview first, then detail. Write the reasoning as *prose, not bullet dumps* — prose exposes weak logic that bullets let you hide. Use bullets only for genuinely enumerable lists. When the thing has an interface, use the *two-altitude* split (Rust RFC): explain it once for a user/caller, once for an implementer.
2. *Alternatives considered* — the load-bearing section authors skip and reviewers need most. For each option, force a why-not with the MADR grammar: "Good, because… / Bad, because… / Neutral, because…". Even one rejected option, with the reason, beats presenting one path as inevitable.
-3. *Decisions* — capture each real choice as an inline mini-ADR (Nygard's spine):
- - =State:= proposed | accepted | superseded
+3. *Decisions* — capture each real choice as an org =TODO= task carrying an inline mini-ADR (Nygard's spine):
+ - The heading is =** TODO <Decision name>=. It flips to =DONE= when the decision-maker agrees with the call; until then it stays =TODO=.
- =Context:= the forces motivating the choice
- =Decision:= the call, stated actively ("We will…")
- =Consequences:= what gets easier *and* what gets harder (both halves — a decision with only upsides is under-examined)
- An *open* decision is simply =State: proposed= plus an *owner* and a *by-when*; resolving it flips to =accepted= with the rationale in Decision. Never rewrite a resolved decision — mark it =superseded= and keep the old one. Keep decisions inline here; promote to a standalone numbered ADR only when a decision outlives or spans beyond this one spec. (The decision =State= is distinct from the spec-wide =Status= in the metadata header.)
+ An *open* decision is a =TODO= task with an *owner* and a *by-when*; agreeing flips it to =DONE=. If the decision-maker doesn't agree, it stays =TODO= and the back-and-forth continues under a =*** Discussion= child header — never overwrite the decision body to win an argument. Put a =[/]= statistics cookie on the =* Decisions= heading so the resolved tally is visible at a glance. To revisit a =DONE= decision, either reopen it to =TODO= (carrying the new dispute in its =*** Discussion= thread, prior text preserved) or write a fresh decision that supersedes it; don't silently rewrite the old one. Keep decisions inline here; promote to a standalone numbered ADR only when a decision outlives or spans beyond this one spec. (The per-decision =TODO/DONE= is distinct from the spec-wide =Status= in the metadata header — see the implementation-ready gate in Phase 6.)
** Phase 3 — Make it buildable
@@ -90,7 +90,7 @@ This is where the spec earns a "Ready" from review: an engineer must be able to
** Phase 6 — Hand-off readiness
Self-assess against =spec-review='s rubric before handing off, so the review starts from a clean spec instead of catching basics:
-- *Decisions:* no =State: proposed= decisions remain, or the author *consciously accepts* the risk of building with one open (recorded).
+- *Decisions:* every decision is =DONE= (the =[/]= cookie reads complete), or the author *consciously accepts* the risk of building with one still =TODO= (recorded). *Implementation-ready gate:* the spec Status cannot move past =draft= to an implementation-ready state while any decision is still =TODO=.
- *APIs:* every external API assumption is verified or listed as a research prerequisite — otherwise the honest verdict is =Needs research=.
- *Self-rubric:* Ready / Ready with caveats / Not ready / Needs research. If it isn't at least =Ready with caveats=, keep drafting.
- *Defer:* log open decisions and vNext items to =todo.org= (v1 work =[#B]=, vNext/someday =[#D]=) — don't leave them only in the spec.
@@ -105,10 +105,14 @@ Then it's ready for =spec-review.org=. Snapshot-vs-living rule: keep the spec li
,#+DATE: <YYYY-MM-DD>
,* Metadata
-| Status | draft |
-| Owner | <name> |
-| Reviewer | <name(s)> |
+| Status | draft |
+|----------+---------------|
+| Owner | <name> |
+|----------+---------------|
+| Reviewer | <name(s)> |
+|----------+---------------|
| Related | [[file:...][task / ticket]] |
+|----------+---------------|
,* Summary
<2-3 sentences: what this is and why it exists.>
@@ -135,13 +139,14 @@ Then it's ready for =spec-review.org=. Snapshot-vs-living rule: keep the spec li
- Bad, because <…>
- Neutral, because <…>
-,* Decisions
-,** <Decision name>
-- State: proposed | accepted | superseded
+,* Decisions [/]
+,** TODO <Decision name>
- Owner / by-when: <name> / <when> (open decisions only)
- Context: <forces>
- Decision: We will <…>
- Consequences: easier <…>; harder <…>
+,*** Discussion (only while the decision is contested / not yet agreed)
+- <ongoing back-and-forth; the decision flips to DONE when agreed>
,* Implementation phases
,** Phase 1 — <smallest noun phrase>
diff --git a/claude-templates/.ai/workflows/spec-response.org b/claude-templates/.ai/workflows/spec-response.org
index 8ff2d71..2686cf8 100644
--- a/claude-templates/.ai/workflows/spec-response.org
+++ b/claude-templates/.ai/workflows/spec-response.org
@@ -31,7 +31,7 @@ A spec's review is fully processed when:
2. *Accepted recommendations are woven into the spec body* — the spec reads as if they were always there, not appended as a changelog.
3. *Modified and rejected recommendations are documented in a bottom section* (e.g. "Review dispositions") with a one-paragraph reason each, so the reviewer can find the reasoning.
4. *Review/response provenance is documented in the spec* — iteration count/date, contributor, role, what changed, and why.
-5. *Pre-agreed decisions are baked in as decisions*, moved out of "open questions."
+5. *Pre-agreed decisions are flipped to =DONE=* — each settled decision's =TODO= becomes =DONE=, and the =[/]= cookie on the spec's =* Decisions= heading reflects the tally.
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.
@@ -93,7 +93,7 @@ For each recommendation, choose one:
- *Reject:* the review floated a separate =default-issue-filter= defcustom. Rejected as redundant — a fixed default command plus a default-view preference already covered it.
- *Modify (scope):* "split representation from network into modules" — adopted the logical boundaries but kept a single file, because the package is a single-file MELPA target and a file split is a larger restructuring.
-*Honor pre-agreed decisions.* If the reviewer marked a decision "agreed" (or the user pre-encoded it), treat it as accepted and settled — move it from the spec's open questions into a decisions section.
+*Honor pre-agreed decisions.* If the reviewer marked a decision "agreed" (or the user pre-encoded it), treat it as accepted and settled — flip its decision task to =DONE= (adding the decision to the spec's =* Decisions= section first if it only existed as an open question).
** Phase 3: Reconcile cross-spec tensions
@@ -114,8 +114,8 @@ When related specs were reviewed together, two reviews can recommend opposite th
- *What changed:* compact summary of accepted, modified, and rejected work.
- *Why:* the rationale or decision pressure behind the changes.
- *Artifacts:* review filename, disposition section, task IDs, source checks, or commits when useful.
-4. *Move settled questions out of "Open decisions"* into an "Agreed decisions" (or equivalent) section. Open decisions should contain only what genuinely still blocks.
-5. *Raise the spec to implementation-ready:* consolidate decisions up front, add any implementation prerequisites the review surfaced (e.g. a schema-verification checklist), a consolidated test strategy, and a phased plan ordered so dependencies (like an output model everything depends on) come early.
+4. *Flip settled decisions to =DONE=.* Each decision the decision-maker has agreed flips its =TODO= to =DONE=; the =[/]= cookie on the =* Decisions= heading tracks the tally. A contested decision stays =TODO= with the back-and-forth under its =*** Discussion= child header. Decisions still =TODO= should be only what genuinely still blocks, each with an owner and a by-when.
+5. *Raise the spec to implementation-ready:* consolidate decisions up front, add any implementation prerequisites the review surfaced (e.g. a schema-verification checklist), a consolidated test strategy, and a phased plan ordered so dependencies (like an output model everything depends on) come early. *Gate:* the spec Status cannot move past =draft= to implementation-ready while any decision is still =TODO= — the =[/]= cookie must read complete, or the author consciously accepts and records the risk of building with one open.
6. *Update the status line* to note "review incorporated (<reviewer>, <date>)."
** Phase 5: Close out and iterate
@@ -208,3 +208,8 @@ Update this workflow as we learn what works. Capture new disposition patterns, b
- *What:* Backfilled this section with entries for the workflow file's prior iterations (Draft 1, Review-and-Fold, Requirement addition). Used commit author dates where exact; Draft 1's timestamp is an opaque-id placeholder since no exact time was recorded.
- *Why:* The iteration-history requirement landed in =55adf6e= without retroactive entries for the workflow file's own prior history. This pass closes that gap so the section starts with full provenance rather than empty.
- *Artifacts:* Working draft sources at =working/spec-workflows-iteration-history-backfill/draft-entries.org= (deleted on this commit). Spec-response cycle (two Codex reviews and three rulesets responses on the draft) validated the entries and the entry-shape before splicing.
+
+** 2026-06-12 Fri @ 19:09:00 -0500 — Claude Code (rulesets) — responder
+- *What:* Reconciled this workflow to spec-create's new Decisions convention (each decision is an org =TODO= task that flips to =DONE= on agreement, with a =[/]= cookie on the =* Decisions= heading and a =*** Discussion= child for disputes). Exit Criterion 5, Phase 2's pre-agreed-decisions step, and Phase 4 steps 4-5 now speak in flip-to-=DONE= terms, and the implementation-ready step gates on the all-=DONE= cookie.
+- *Why:* The convention change landed in spec-create.org via an .emacs.d handoff (originated in its keymap-consolidation spec); this workflow still described the retired =State: proposed | accepted | superseded= model.
+- *Artifacts:* Handoff =inbox/2026-06-12-1906-from-.emacs.d-spec-create-decisions-todo-note.org=. Paired spec-create.org and spec-review.org edits in the same commit.
diff --git a/claude-templates/.ai/workflows/spec-review.org b/claude-templates/.ai/workflows/spec-review.org
index db8c528..61c1239 100644
--- a/claude-templates/.ai/workflows/spec-review.org
+++ b/claude-templates/.ai/workflows/spec-review.org
@@ -74,6 +74,7 @@ Mark the spec implementation-ready only if *all* of these hold:
- Scope is explicit: v1, out-of-scope, and vNext are separated.
- Project principles are explicit where the feature touches user data, remote systems, destructive actions, long-running operations, or public extension points.
- All prior review questions/recommendations are answered or intentionally deferred.
+- Every decision in the spec's =* Decisions= section is =DONE= (the =[/]= cookie reads complete), or each still-=TODO= decision carries a consciously-accepted, recorded risk.
- The expected UX is concrete enough to implement without guessing.
- Existing platform/framework affordances are reused, wrapped, or intentionally replaced; lost opportunities are called out.
- The data model, state ownership, persistence, and sync behavior are defined.
@@ -185,7 +186,7 @@ Deferred features to capture in task tracking.
Assign one label consistently:
-- =Ready= — no blocking open questions; implementation can start.
+- =Ready= — no blocking open questions; implementation can start. Requires every decision in the spec's =* Decisions= section to be =DONE= (the =[/]= cookie reads complete) — a decision still =TODO= holds the rubric at =Not ready=, or =Ready with caveats= if the author consciously accepts and records the risk.
- =Ready with caveats= — can start if the caveats are accepted and tracked.
- =Not ready= — blocking ambiguity / missing decisions would force implementers to invent product behavior.
- =Needs research= — external API/library/platform assumptions must be verified first.
@@ -343,3 +344,8 @@ Sources:
- *What:* Promoted the two Codex (emacs-d) passes above into the canonical workflow. The reusable checks had been written into =.emacs.d='s synced copy, which the startup rsync overwrites from canonical, so they would not have survived or propagated. Folded them into =claude-templates/.ai/workflows/spec-review.org= and synced the =.ai/= mirror, so every project picks them up on next startup. Verified the promotion is a pure superset — every change is an added or expanded generic check, no regressions.
- *Why:* The handoff =inbox/2026-06-06-spec-review-workflow-update.md= asked for it: reusable review practice belongs in the canonical workflow, spec-specific findings stay in the spec. Exit Criterion 7 and the Living-Document harvesting guidance, added in the same passes, name this as the intended path.
- *Artifacts:* Handoff preserved at =docs/design/2026-06-06-spec-review-reusable-checks-handoff.md=. Paired spec-response.org Phase 6 (author-side implementation-task breakdown) committed in the same session.
+
+** 2026-06-12 Fri @ 19:09:00 -0500 — Claude Code (rulesets) — responder
+- *What:* Reconciled this workflow to spec-create's new Decisions convention (each decision is an org =TODO= task that flips to =DONE= on agreement, with a =[/]= cookie on the =* Decisions= heading). The Phase 1/3 readiness gate gains an all-decisions-=DONE= item, and the Phase 6 =Ready= rubric label now requires the =[/]= cookie to read complete (a still-=TODO= decision holds the rubric at =Not ready=, or =Ready with caveats= on a recorded, consciously-accepted risk).
+- *Why:* The convention change landed in spec-create.org via an .emacs.d handoff (originated in its keymap-consolidation spec); the rubric still gated on the retired =State:= field model.
+- *Artifacts:* Handoff =inbox/2026-06-12-1906-from-.emacs.d-spec-create-decisions-todo-note.org=. Paired spec-create.org and spec-response.org edits in the same commit.