diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-23 12:59:31 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-23 12:59:31 -0500 |
| commit | 7f2aea1e022c93f3eb463e5222bdb0d8ae6288b9 (patch) | |
| tree | cbbd70275d9384d102d1825e441a114b0e84ca36 /scripts/remove.sh | |
| parent | 2d34e9ac3a9cec1f625df75f08890ee85836afa3 (diff) | |
| download | rulesets-7f2aea1e022c93f3eb463e5222bdb0d8ae6288b9.tar.gz rulesets-7f2aea1e022c93f3eb463e5222bdb0d8ae6288b9.zip | |
feat(workflows): add spec-review and spec-response workflow pair
These two workflows form a reviewer side and an author side for taking a design spec to implementation-ready. spec-review judges a spec against a readiness gate, reads the code before critiquing, evaluates across dimensions, assigns a rubric (Ready / Ready-with-caveats / Not-ready / Needs-research), and writes a <spec>-review.org file when it isn't ready. spec-response consumes that file: it decides accept / modify / reject for every recommendation, weaves the accepts into the spec body, records the modifies and rejects with reasons in a "Review dispositions" section, and reconciles tensions when coupled specs get reviewed together. The review file is the contract between them.
Both were validated by a real run on 2026-05-23 before landing here. I then reviewed them against established practice and tightened five things. The readiness gate now covers security/privacy and observability, since a spec shouldn't pass with those undefined. Phase 1 is a fast triage and Phase 3 is the authoritative gate after the code read. Finding severity maps to blocking power. A rejection goes back to the reviewer instead of standing as a unilateral call. And the response loop has an explicit termination condition.
I added both to INDEX.org under a new "Specs and design" section with trigger phrases, cross-linked as a pair, and kept the canonical and mirror copies identical.
Diffstat (limited to 'scripts/remove.sh')
0 files changed, 0 insertions, 0 deletions
