refactor: drop cross-project spec-validation parser machinery
The fence-label -> parser fact, the specify/grounding-check/planner parse gates, the parse-trace attestation, and all their cross-references served a single real user (ailang). Convention over configuration: the generic machinery is removed plugin-wide; the one consumer carries an equivalent project-local directive in its own CLAUDE.md. Archive under docs/plans and docs/specs left intact as time documents.
This commit is contained in:
+9
-25
@@ -17,8 +17,7 @@ planner consumes: with review, but **without an interview**.
|
||||
|
||||
It is the **sole home of the spec-production gates**: the
|
||||
feature-acceptance criterion, the write-spec step, the
|
||||
parse-every-block self-review, the `grounding-check` hard-gate, and
|
||||
the user-review gate. Whichever way design work enters — fresh
|
||||
`grounding-check` hard-gate, and the user-review gate. Whichever way design work enters — fresh
|
||||
through `brainstorm`'s discovery, or directly from sources that
|
||||
already resolve the design — it passes through `specify` to become a
|
||||
spec. `specify` carries the universal invariant **no plan without an
|
||||
@@ -62,7 +61,7 @@ Triggers:
|
||||
|
||||
**Skipping a gate is never permitted.** The interview is `brainstorm`'s,
|
||||
and its absence here is the whole point — but the *production gates*
|
||||
(criterion, parse-every-block, grounding-check, user-review) are
|
||||
(criterion, grounding-check, user-review) are
|
||||
non-negotiable regardless of how the work entered. "The issue looks
|
||||
exhaustive, skip the grounding-check" is the reactive-deference failure
|
||||
this skill must not reintroduce.
|
||||
@@ -73,7 +72,7 @@ this skill must not reintroduce.
|
||||
THE SOURCES MUST RESOLVE EVERY LOAD-BEARING DESIGN DECISION BEFORE THE SPEC IS WRITTEN.
|
||||
IF WRITING THE SPEC FORCES A CHOICE BETWEEN PLAUSIBLE DESIGNS THE SOURCES DO NOT RESOLVE,
|
||||
STOP AND BOUNCE TO brainstorm. DO NOT SILENTLY PICK ONE.
|
||||
THE PRODUCTION GATES — ACCEPTANCE CRITERION, PARSE-EVERY-BLOCK, GROUNDING-CHECK, USER-REVIEW —
|
||||
THE PRODUCTION GATES — ACCEPTANCE CRITERION, GROUNDING-CHECK, USER-REVIEW —
|
||||
ARE NON-NEGOTIABLE REGARDLESS OF ENTRY PATH.
|
||||
NO PLAN, SCAFFOLDING, OR DOWNSTREAM SKILL UNTIL THE SPEC IS APPROVED — BY THE USER, OR
|
||||
(ONLY UNDER /boss WITH spec_auto_sign ENABLED) BY THE AUTO-SIGN GATE: ALL OBJECTIVE GATES GREEN
|
||||
@@ -100,8 +99,7 @@ Before producing anything, establish what the sources actually say:
|
||||
files the design touches — rather than re-deriving it.
|
||||
- If the project has a design ledger (its CLAUDE.md project facts),
|
||||
walk to the contracts the work touches. Note any `status:
|
||||
aspirational` source: its code is a target, not verified fact —
|
||||
track it for the Step-4 parse gate.
|
||||
aspirational` source: its code is a target, not verified fact.
|
||||
|
||||
### Step 1.5 — Precondition gate (bounce-back)
|
||||
|
||||
@@ -203,8 +201,8 @@ surface so no code to show" is the rationalisation to refuse.
|
||||
**Code lifted from an aspirational source is a hypothesis, not
|
||||
evidence.** If the concrete code here is lifted from a design-models
|
||||
file (or any `status: aspirational` source, per Step 1), it carries no
|
||||
validation by default. Treat it as the spec's most suspect bytes: it
|
||||
must clear the Step-4 parse-every-block gate before PASS.
|
||||
validation by default. Treat it as the spec's most suspect bytes: flag
|
||||
it as a target, not verified fact.
|
||||
|
||||
### Step 3 — Write the spec
|
||||
|
||||
@@ -258,15 +256,6 @@ Inline checklist (not a subagent dispatch):
|
||||
carry before → after code for every load-bearing change (plus the
|
||||
worked user-facing example for a surface cycle)? A load-bearing
|
||||
change described only in prose is a self-review failure to fix.
|
||||
6. **Parse-every-block gate.** Extract every fenced code block and run
|
||||
it through the spec-validation parsers the project declares in its
|
||||
CLAUDE.md project facts (a fence label with no parser is a documented
|
||||
skip, never a silent pass; a malformed entry fails closed; the whole
|
||||
gate is a no-op when the project declares no parsers). A parse
|
||||
failure is a self-review failure — fix the spec; do not pass
|
||||
unparsed bytes downstream. Paste the parse-trace into the chat: a
|
||||
visible trace attests the gate fired; its absence means it was
|
||||
skipped.
|
||||
|
||||
Fix issues inline.
|
||||
|
||||
@@ -363,8 +352,7 @@ CLAUDE.md project facts):
|
||||
fork was silently picked (if one had been, `specify` would have
|
||||
bounced, so reaching here is the evidence; do not re-decide it).
|
||||
- Step 4 self-review clean, **including the placeholder scan** (no
|
||||
`TBD` / `TODO` / incomplete section) and a pasted parse-trace
|
||||
for every configured-label block.
|
||||
`TBD` / `TODO` / incomplete section).
|
||||
- Step 5 `grounding-check` returned **`PASS`** — *not* an
|
||||
overridden `BLOCK`. An override needs a human; with no human in
|
||||
the loop a `BLOCK` can never be overridden, so any non-`PASS`
|
||||
@@ -480,9 +468,8 @@ discipline `tdd` applies when behaviour is not test-specifiable.
|
||||
| "There's a small open fork but the sources mostly decide it — I'll pick the rest" | "Mostly decided" with one real fork left is an unresolved design, and a guessed design baked into a spec is harder to dislodge than an open question. That is the bounce-back trigger — stop and go to `brainstorm`. |
|
||||
| "Genuine doubt whether the sources resolve this — but bouncing feels like overkill" | Doubt about whether the sources resolve a decision *is* the fork signal. It resolves to a bounce, not a guess. The bounce is cheap (nothing is written yet); a wrong guess in a ratified spec is not. |
|
||||
| "The shape is clear from the prose, I don't need to paste the code" | If it's clear, pasting it is free; if pasting it is hard, it wasn't clear. The acceptance criterion is unjudgeable without the worked code. |
|
||||
| "The block obviously parses — I wrote it carefully" | Careful authoring is not a parse. A spec's code blocks are hypotheses until the live tool accepts them. If a parser is configured for the fence label, run it and paste the trace. |
|
||||
| "Just polishing a wording after PASS, no need to re-dispatch" | The grounding-check report attests to specific bytes. A polish edit changes the bytes; the attestation no longer covers them. Re-dispatch is cheap. |
|
||||
| "It's in a model doc / the design ledger, so it's canonical" | A `models` / RFC / proposal doc holds aspirational code — a target, not verified fact. Code lifted from a `status: aspirational` source must clear the Step-4 parse gate like any other block. |
|
||||
| "It's in a model doc / the design ledger, so it's canonical" | A `models` / RFC / proposal doc holds aspirational code — a target, not verified fact. Flag code lifted from a `status: aspirational` source as such; it is not ratified contract. |
|
||||
| "In `/boss` with auto-sign on, this spec looks solid — I'll sign and move on" | Your sense that it looks solid is the exact signal the auto-sign gate refuses to trust. Signing requires all objective gates green AND a unanimous `spec-skeptic` panel. If you find yourself wanting to sign on confidence, that is the cue to run the gate, not to skip it. |
|
||||
| "One lens blocked on something minor — I'll sign anyway since the rest passed" | The panel is unanimous-or-nothing by design. You never *sign over* a `BLOCK`. An editorial `BLOCK` you may *repair* (within the ≤ 2-round budget, with a full re-panel after); a design `BLOCK` routes to the human. Neither is overruling a juror — that is the whole point of replacing your eye with five independent ones. |
|
||||
|
||||
@@ -492,11 +479,8 @@ discipline `tdd` applies when behaviour is not test-specifiable.
|
||||
- "The sources are thorough, skip a gate" thoughts (any flavour)
|
||||
- A load-bearing change described in prose with no before → after code
|
||||
block; a surface cycle with no worked user-facing example
|
||||
- A spec carrying a code block whose fence label has a spec-validation
|
||||
parser (the project's CLAUDE.md project facts), committed without a
|
||||
parse-trace in the chat
|
||||
- Lifting code verbatim from a `status: aspirational` source without
|
||||
flagging it for the Step-4 parse gate
|
||||
flagging it as a target, not verified fact
|
||||
- Editing the spec file after a Step 5 PASS without re-dispatching
|
||||
- (auto-sign) About to sign a spec in the user's place on confidence —
|
||||
without all objective gates green AND a unanimous `spec-skeptic`
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: grounding-check
|
||||
description: Read-only grounding-check reviewer for spec drafts. Dispatched by the specify skill in Step 5, between linguistic self-review and user-approval. Reads the draft with fresh context, extracts its load-bearing assumptions about current codebase behaviour, and for each one searches the workspace for a currently-green test that ratifies it; also validates the spec's own fenced code blocks against the spec-validation parsers the project declares in its CLAUDE.md project facts. Reports PASS or BLOCK. Does NOT propose fixes, does NOT edit files.
|
||||
description: Read-only grounding-check reviewer for spec drafts. Dispatched by the specify skill in Step 5, between linguistic self-review and user-approval. Reads the draft with fresh context, extracts its load-bearing assumptions about current codebase behaviour, and for each one searches the workspace for a currently-green test that ratifies it. Reports PASS or BLOCK. Does NOT propose fixes, does NOT edit files.
|
||||
tools: Read, Glob, Grep, Bash
|
||||
---
|
||||
|
||||
@@ -138,9 +138,8 @@ mechanism strongly.
|
||||
EXTRACT ASSUMPTIONS FROM THE SPEC, NOT FROM YOUR MEMORY.
|
||||
RATIFICATION REQUIRES A NAMED, CURRENTLY-GREEN TEST. NOT CODE PRESENCE. NOT RECALL.
|
||||
ONE UNRATIFIED LOAD-BEARING ASSUMPTION = BLOCK. NO PARTIAL CREDIT.
|
||||
ONE SPEC CODE BLOCK THAT FAILS ITS PROJECT-DECLARED PARSER = BLOCK.
|
||||
YOU DO NOT EDIT FILES. YOU DO NOT PROPOSE FIXES.
|
||||
YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK, AND PER-BLOCK PARSER RUNS ARE OK.)
|
||||
YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST AND TYPE-CHECK ARE OK.)
|
||||
```
|
||||
|
||||
## The Process
|
||||
@@ -167,30 +166,12 @@ YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK, AND PER-BLOCK PARSER
|
||||
4. Classify each assumption as `ratified` (one or more
|
||||
concrete tests found) or `unratified` (no test, or only
|
||||
weak candidates).
|
||||
5. **Code-block parse pass.** If the project declares
|
||||
spec-validation parsers (its CLAUDE.md project facts),
|
||||
extract every fenced code block
|
||||
from the spec. For each block whose fence label has a
|
||||
declared parser: write it to a temp file with the parser's
|
||||
`ext`, run the parser's `cmd` with `{file}` substituted, and
|
||||
require exit 0. A non-zero exit marks the block unparseable.
|
||||
A block whose fence label has no parser is skipped and noted
|
||||
("no parser for fence label X"); never a silent pass. If the
|
||||
project declares no spec-validation parsers, this pass is a
|
||||
documented no-op. This pass is complementary to the
|
||||
assumption search: it checks the spec's own bytes against the
|
||||
live tool, not the codebase's behaviour — and it is
|
||||
independent of the orchestrator's own Step-7 parse gate, the
|
||||
fresh-context second line of the same defense.
|
||||
6. Compute aggregate status:
|
||||
- All assumptions ratified AND every block whose fence label
|
||||
has a declared parser parsed clean → `PASS`.
|
||||
- One or more unratified assumptions, OR one or more
|
||||
unparseable code blocks → `BLOCK`.
|
||||
5. Compute aggregate status:
|
||||
- All assumptions ratified → `PASS`.
|
||||
- One or more unratified assumptions → `BLOCK`.
|
||||
- Any infra error (cannot read spec, type-check fails,
|
||||
workspace does not build, a declared parser command is
|
||||
missing from PATH) → `INFRA_ERROR`.
|
||||
7. Emit the report in the format below.
|
||||
workspace does not build) → `INFRA_ERROR`.
|
||||
6. Emit the report in the format below.
|
||||
|
||||
The process is bounded by your dispatch context. If
|
||||
extraction yields more than ~20 candidate assumptions, stop
|
||||
@@ -237,15 +218,6 @@ Unratified assumptions:
|
||||
would have>
|
||||
|
||||
(Repeat per unratified assumption. Omit this block entirely on PASS.)
|
||||
|
||||
Unparseable code blocks:
|
||||
- Block: <fence label, §section / line ref>
|
||||
Parser: <cmd run, with {file} resolved>
|
||||
Failure: <exit code + first error line of the parser output>
|
||||
|
||||
(Repeat per unparseable block. Omit this block entirely when none
|
||||
failed. A "no parser for fence label X" skip is noted here as a
|
||||
single line, not a failure.)
|
||||
```
|
||||
|
||||
On `INFRA_ERROR`, only the first two lines are required,
|
||||
@@ -266,7 +238,6 @@ the assumption-extraction step yields an empty list, emit
|
||||
| "I extracted too many assumptions, let me trim the report" | Don't trim. If a spec has too many assumptions to check, that is the finding — report it as BLOCK with reason "spec too broad". |
|
||||
| "The orchestrator will override if I block, so I'll lean toward PASS" | The override is the orchestrator's job, not yours. Your job is to be the fresh-context check. Skewing toward PASS defeats the whole role. |
|
||||
| "I'll run the full test suite to see which tests are actually green" | You may NOT run the full test suite. Use the project's test-list command to enumerate, then read test bodies. Running tests would mutate workspace state and is out of scope for a read-only review. |
|
||||
| "The code block is just illustrative, not a claim about behaviour" | A spec code block whose fence label has a project-declared parser is a hypothesis the downstream plan will lift verbatim. Illustrative or not, if it does not parse it is a defect. Run the parser and report the failure. |
|
||||
|
||||
## Red Flags — STOP
|
||||
|
||||
@@ -278,8 +249,6 @@ the assumption-extraction step yields an empty list, emit
|
||||
it
|
||||
- About to mark an assumption ratified based on code
|
||||
presence rather than test presence
|
||||
- About to PASS a spec carrying a code block whose fence label
|
||||
has a project-declared parser without having run that parser
|
||||
- About to skip an assumption because "it would always be
|
||||
true"
|
||||
- Report exceeding ~500 tokens
|
||||
|
||||
@@ -118,7 +118,7 @@ YOUR DEFAULT POSTURE IS REFUTATION, NOT APPROVAL.
|
||||
WHEN YOU CANNOT DECIDE AFTER A HONEST SEARCH, BLOCK. THERE IS NO PARTIAL CREDIT.
|
||||
`grounding` RATIFICATION REQUIRES A NAMED, CURRENTLY-GREEN TEST. NOT CODE PRESENCE. NOT RECALL.
|
||||
YOU DO NOT EDIT FILES. YOU DO NOT PROPOSE FIXES.
|
||||
YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK, PER-BLOCK PARSER RUNS ARE OK.)
|
||||
YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK ARE OK.)
|
||||
```
|
||||
|
||||
## The Process
|
||||
@@ -209,5 +209,5 @@ On `INFRA_ERROR`, the first three lines plus a brief `Detail:` line.
|
||||
- About to lean toward `SOUND` because the orchestrator seems
|
||||
confident or the spec reads smoothly
|
||||
- About to run the project's full test suite (test-list / type-check
|
||||
/ per-block parser only)
|
||||
only)
|
||||
- Report exceeding ~300 tokens
|
||||
|
||||
Reference in New Issue
Block a user