diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-29 18:44:30 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-29 18:44:30 -0500 |
| commit | bb28cfa331d3cba9ae9f265f7c448b5bd6b4fa6c (patch) | |
| tree | a0f104a12f1efa533a4fd7a98262366e15bab3bc /.ai/workflows/spec-review.org | |
| parent | 7355d21d9a36716afbeeb7d63de58dff302f44c1 (diff) | |
| download | rulesets-bb28cfa331d3cba9ae9f265f7c448b5bd6b4fa6c.tar.gz rulesets-bb28cfa331d3cba9ae9f265f7c448b5bd6b4fa6c.zip | |
feat(workflows): add -spec.org precondition to spec-review and spec-response
Both workflows now check that the file under review (or the spec
being responded to) ends with -spec.org before proceeding. If it does
not, the workflow stops and surfaces the mismatch with the rename
suggestion.
The suffix is the identifier per Craig's spec-naming convention:
every design, decision, or planning document under a project's docs/
directory ends with -spec.org. The .org extension alone is not enough
because docs/ holds non-spec org files too (tutorials, frozen
inventories, reference material).
spec-review.org gained a top-level Precondition section between When
to Use and Approach. spec-response.org gained the same Precondition
section in the parallel position, with a note that the review-file
convention <spec-basename>-review.org means a misnamed spec produces
a mis-pointed review file too.
Inbox source: 2026-05-28-0858-from-home-spec-naming-convention-apply-to-spec.org.
Home renamed two docs to the new convention and asked rulesets to
update the template workflows so the next startup rsync in every
project picks up the guard.
Diffstat (limited to '.ai/workflows/spec-review.org')
| -rw-r--r-- | .ai/workflows/spec-review.org | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/.ai/workflows/spec-review.org b/.ai/workflows/spec-review.org index b4ca437..159202e 100644 --- a/.ai/workflows/spec-review.org +++ b/.ai/workflows/spec-review.org @@ -44,6 +44,22 @@ Trigger when: Run it *early* — design review exists to catch viability problems and costly mistakes before implementation, not after. +* Precondition: spec filename + +Before Phase 1, verify the file under review ends with =-spec.org=. Every design, decision, or planning document under a project's =docs/= directory carries that suffix as its identifier. The =.org= extension alone is not enough because =docs/= holds non-spec org files too (tutorials, frozen inventories, reference material). + +If the file does not end with =-spec.org=, stop immediately and surface the mismatch: + +#+begin_example +The file <path> does not end with -spec.org. Either the wrong file was named, or +the file should be renamed first. Spec workflows require the -spec.org suffix as a +guard against pointing the workflow at tutorial, inventory, or setup docs. +#+end_example + +The user resolves the mismatch (rename the file, or point at a different one) and re-invokes the workflow. Do not proceed with the review against a misnamed file. + +Anywhere the rest of this workflow refers to "the spec," "the spec file," or "the file under review," the path is the =-spec.org= file confirmed here. + * Approach: How We Work Together ** Phase 1: First-pass readiness gate |
