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.

specify/agents/grounding-check.md

@@ -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