feat: grounding-check code-block parse pass (issue #1 Fix 2)

Adds a third pass to the grounding-check agent: when the profile
declares `spec_validation.parsers`, every fenced spec block whose
fence label has an entry is run through its parser (temp file + `ext`,
`cmd` with {file}); a non-zero exit marks the block unparseable and
the aggregate status becomes BLOCK. Complementary to the existing
test-ratification search (checks the spec's own bytes, not codebase
behaviour) and independent of the orchestrator's Step-7 gate (Fix 1) —
a fresh-context second line of the same defense.

Amends the Iron Law to permit per-block parser runs (same read-only
spirit as test-list/type-check), adds an "Unparseable code blocks"
report section, a Common Rationalisation, a Red Flag, and the agent
description.

refs #1

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

brainstorm/agents/grounding-check.md

@@ -1,6 +1,6 @@
 ---
 name: grounding-check
-description: Read-only grounding-check reviewer for spec drafts. Dispatched by the brainstorm skill in Step 7.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.
+description: Read-only grounding-check reviewer for spec drafts. Dispatched by the brainstorm skill in Step 7.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 project's configured parsers. Reports PASS or BLOCK. Does NOT propose fixes, does NOT edit files.
 tools: Read, Glob, Grep, Bash
 ---
 
@@ -135,8 +135,9 @@ 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 CONFIGURED PARSER = BLOCK.
 YOU DO NOT EDIT FILES. YOU DO NOT PROPOSE FIXES.
-YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST AND TYPE-CHECK ARE OK.)
+YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST, TYPE-CHECK, AND PER-BLOCK PARSER RUNS ARE OK.)
 ```
 
 ## The Process
@@ -163,12 +164,29 @@ YOU DO NOT RUN THE FULL TEST SUITE. (TEST LIST AND TYPE-CHECK ARE OK.)
 4. Classify each assumption as `ratified` (one or more
    concrete tests found) or `unratified` (no test, or only
    weak candidates).
-5. Compute aggregate status:
+5. **Code-block parse pass.** If the project profile declares
-   - All assumptions ratified → `PASS`.
+   `spec_validation.parsers`, extract every fenced code block
-   - One or more unratified → `BLOCK`.
+   from the spec. For each block whose fence label has a
+   `parsers` entry: write it to a temp file with the entry's
+   `ext`, run the entry's `cmd` with `{file}` substituted, and
+   require exit 0. A non-zero exit marks the block unparseable.
+   A block whose fence label has no entry is skipped and noted
+   ("no parser for fence label X"); never a silent pass. If the
+   profile declares no `spec_validation`, 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 configured-label block
+     parsed clean → `PASS`.
+   - One or more unratified assumptions, OR one or more
+     unparseable code blocks → `BLOCK`.
    - Any infra error (cannot read spec, type-check fails,
-     workspace does not build) → `INFRA_ERROR`.
+     workspace does not build, a configured parser command is
-6. Emit the report in the format below.
+     missing from PATH) → `INFRA_ERROR`.
+7. Emit the report in the format below.
 
 The process is bounded by your dispatch context. If
 extraction yields more than ~20 candidate assumptions, stop
@@ -215,6 +233,15 @@ 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,
@@ -235,6 +262,7 @@ 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 configured 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
 
@@ -246,6 +274,8 @@ 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 configured parser without having run that parser
 - About to skip an assumption because "it would always be
   true"
 - Report exceeding ~500 tokens