diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-12 19:15:15 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-12 19:15:15 -0500 |
| commit | 7c052535f371c67956947a5afe711c71350feaf4 (patch) | |
| tree | 8ef25952f98223ed892b1714878c722f7ed59aaf | |
| parent | f11dd5c4e70ebbf487205aa72998e87b123d7f9d (diff) | |
| download | rulesets-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.org | 25 | ||||
| -rw-r--r-- | .ai/workflows/spec-response.org | 13 | ||||
| -rw-r--r-- | .ai/workflows/spec-review.org | 8 | ||||
| -rw-r--r-- | claude-templates/.ai/workflows/spec-create.org | 25 | ||||
| -rw-r--r-- | claude-templates/.ai/workflows/spec-response.org | 13 | ||||
| -rw-r--r-- | claude-templates/.ai/workflows/spec-review.org | 8 |
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. |
