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.

README.md

@@ -92,9 +92,6 @@ project's own `CLAUDE.md` under `## Skills plugin: project facts`:
 - Regression scripts; architect sweeps
 - Design ledger / glossary / contracts / models / bench / public
   interface / fieldtest-examples paths
-- Spec-validation parsers (fence label → `{ext, cmd}`, `cmd` carrying
-  the `{file}` placeholder; a label with no entry is a documented
-  skip, never a silent pass)
 - Per-role standing reading
 - Issue-tracker repo slug + list / show commands
 - Spec auto-sign (off by default)
@@ -115,8 +112,8 @@ auto-sign in its CLAUDE.md project facts.
 With it on, the orchestrator may sign a spec in the user's place, but
 never on its own confidence. Signing requires two stages to clear:
 
-- **Objective gates** — the precondition gate, the parse-every-block
+- **Objective gates** — the precondition gate and a `grounding-check`
-  gate, and a `grounding-check` `PASS` with no human override.
+  `PASS` with no human override.
 - **A unanimous adversarial panel** — the `spec-skeptic` agent
   dispatched five times in parallel, one per lens (`criterion`,
   `grounding`, `scope-fork`, `ambiguity`, `plan-readiness`), each

docs/conventions.md

@@ -112,7 +112,6 @@ Under `## Skills plugin: project facts`, where applicable:
 | **doc-build command** | docwriter | Optional; prints warnings on stderr. |
 | **regression scripts** | audit (bencher) | Optional list; non-zero exit = regress. |
 | **architect sweeps** | audit (architect) | Optional list; non-zero exit = drift suspicion. |
-| **spec-validation parsers** | specify, grounding-check | Optional; fence-label → `{ext, cmd}` table. `cmd` MUST contain `{file}`. Absent label → documented skip, never silent pass. |
 | **design ledger** | architect, most agents | Optional path (e.g. `design/INDEX.md`). |
 | **glossary** | every role | Optional path; implicitly standing reading. |
 | **design contracts / models** | docwriter, specify | Optional dirs. Aspirational-source frontmatter marker recommended (see below). |
@@ -140,5 +139,5 @@ validated-against: <commit-sha | "no validation">
 
 When the marker is absent the signal is simply absent — `specify`
 degrades to treating the content as unmarked, never hard-failing.
-Content lifted from an aspirational source is flagged and must clear
+Content lifted from an aspirational source is flagged as a target,
-the parse-every-block gate before it ships in a spec.
+not verified fact, before it ships in a spec.

docs/design.md

@@ -80,8 +80,8 @@ project's `CLAUDE.md` under `## Skills plugin: project facts`:
 code roots, build / test / lint / doc-build commands, regression
 scripts, architect sweeps, design-ledger / glossary / contracts /
 models / bench / public-interface / fieldtest-examples paths,
-spec-validation parsers, by-role standing reading, the issue-tracker
+by-role standing reading, the issue-tracker repo slug and commands,
-repo slug and commands, and spec auto-sign. The template is in
+and spec auto-sign. The template is in
 `../templates/CLAUDE.md.fragment`; the per-fact reference is the
 table in `conventions.md`.
 

docs/pipeline.md

@@ -98,9 +98,8 @@ Hard-gate before plan — the spec-production core and the carrier of the
 "no plan without an approved spec" invariant. Takes a settled design
 (directly from sources, or a ratified design handed over by
 `brainstorm`), applies the feature-acceptance criterion, writes the
-spec to `docs/specs`, runs the parse-every-block and
+spec to `docs/specs`, runs the `grounding-check` gate, and takes user
-`grounding-check` gates, and takes user sign-off — with review but no
+sign-off — with review but no interview. Bounces to `brainstorm` the moment the sources do not
-interview. Bounces to `brainstorm` the moment the sources do not
 resolve a load-bearing design decision. A core node — the
 spec-production gate before `planner` on every design path.
 

planner/SKILL.md

@@ -221,22 +221,6 @@ Before handing the plan off, run this checklist inline:
    so "nothing ran" cannot masquerade as "nothing
    regressed". This is a recurring defect family — scrub
    every Run step whose assertion lives in a filter string.
-9. **Parse-the-bytes-you-inline gate.** Every verbatim code body
-   the plan inlines into a task step must be run through the
-   spec-validation parsers the project declares in its CLAUDE.md
-   project facts, following the parser-invocation protocol in
-   `docs/conventions.md` (which owns the no-parser skip, the
-   malformed-entry failure, and the no-op when the project
-   declares no spec-validation parsers) before
-   hand-off. The target is the surface-language snippets the plan
-   lifts verbatim (example programs, fixtures); the project's
-   source-language test / implementation bodies are NOT the
-   target — the `implement` compile gate catches those. A parse
-   failure is a plan failure — the plan would hand the
-   implementer bytes that do not parse, the last defensive line
-   before dispatch — fix the plan, do not hand off. The
-   parse-trace goes into the planner's self-review activity (the
-   session) as the attestation the gate fired.
 
 Fix issues inline.
 
@@ -268,7 +252,6 @@ The planner skill does not perform the commit itself.
 | "Step 5 'implement the parser' is fine, I'll detail it at execution time" | Then it's not a step, it's a wish. Steps are bite-sized OR the plan isn't done. |
 | "Task 7 is similar to Task 4, just say so" | The executor may read tasks out of order. Repeat the code. |
 | "The spec has a TBD too, I can pass it through" | Bounce back to `specify`. Plans inherit spec gaps; spec gaps are not plan placeholders. |
-| "The example program came straight from the spec, it must be valid" | The spec's code blocks are hypotheses, not verified bytes — specify's parse gate can be skipped and a post-spec edit can break them. Re-parse every surface-language body you inline against the spec-validation parsers the project declares in its CLAUDE.md project facts; this is the last line before the implementer hits it (issue #1 Fix 4). |
 
 ## Red Flags — STOP
 
@@ -279,10 +262,6 @@ The planner skill does not perform the commit itself.
 - Step descriptions longer than the code they describe
 - Header missing parent spec reference
 - Self-review skipped because "the plan looks fine"
-- A task step inlining a surface-language code body whose fence
-  label has a project-declared spec-validation parser (its
-  CLAUDE.md project facts), handed off without a parse-trace in
-  the planner session
 
 ## Cross-references
 

specify/SKILL.md

@@ -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
+`grounding-check` hard-gate, and the user-review gate. Whichever way design work enters — fresh
-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 —
+  aspirational` source: its code is a target, not verified fact.
-  track it for the Step-4 parse gate.
 
 ### 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
+validation by default. Treat it as the spec's most suspect bytes: flag
-must clear the Step-4 parse-every-block gate before PASS.
+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
+       `TBD` / `TODO` / incomplete section).
-       for every configured-label block.
      - 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`

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
+5. Compute aggregate status:
-   spec-validation parsers (its CLAUDE.md project facts),
+   - All assumptions ratified → `PASS`.
-   extract every fenced code block
+   - One or more unratified assumptions → `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`.
    - Any infra error (cannot read spec, type-check fails,
-     workspace does not build, a declared parser command is
+     workspace does not build) → `INFRA_ERROR`.
-     missing from PATH) → `INFRA_ERROR`.
+6. Emit the report in the format below.
-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
@@ -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

specify/agents/spec-skeptic.md

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

templates/CLAUDE.md.fragment

@@ -129,17 +129,6 @@ that does not apply.
   bench, is forbidden to it). Example: `README.md, docs, examples`.
 - **Fieldtest examples** — optional path where the `fieldtester` writes
   fixtures. Example: `examples/fieldtest`.
-- **Spec-validation parsers** — optional. A fence-label → parser table
-  the `specify` parse-gate and `grounding-check` use to validate spec
-  code blocks. A block whose label has no entry is a documented skip,
-  never a silent pass. `cmd` MUST contain the `{file}` placeholder.
-  Example:
-
-  | Fence label | Temp ext | Command |
-  |-------------|----------|---------|
-  | `ail`       | `.ail`     | `ail check {file}` |
-  | `ail-json`  | `.ail.json`| `ail check {file}` |
-
 - **By-role standing reading** — optional. Extra files/commands a
   specific agent role reads on every dispatch, beyond the universal
   `CLAUDE.md` + `git log -10`. Role names match agent slugs (`architect`,