aboutsummaryrefslogtreecommitdiff
path: root/scripts/remove.sh
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-05-23 12:59:31 -0500
committerCraig Jennings <c@cjennings.net>2026-05-23 12:59:31 -0500
commit7f2aea1e022c93f3eb463e5222bdb0d8ae6288b9 (patch)
treecbbd70275d9384d102d1825e441a114b0e84ca36 /scripts/remove.sh
parent2d34e9ac3a9cec1f625df75f08890ee85836afa3 (diff)
downloadrulesets-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