ibex 0.1.0 → 0.3.0

data/docs/bison-import.md

@@ -0,0 +1,103 @@
+# Bison grammar import for analysis
+
+`ibex import bison` converts Bison-shaped grammar structure into ordinary
+extended Ibex source for analysis. It is a one-way adapter, not a parser
+generator compatibility mode. Imported C actions remain opaque, are never
+executed by analysis, and make Ruby generation fail before code is emitted.
+
+```sh
+ibex import bison parser.y -o parser.analysis.y
+ibex import bison --format=json parser.y > import-report.json
+ibex explain --state=STATE parser.y
+ibex metrics parser.y
+```
+
+`explain`, `metrics`, `diff`, and the other read-only grammar analysis paths
+recognize a file with two Bison `%%` section markers and import it in memory.
+Source-repair commands need a canonical imported file because edits against
+the generated analysis source do not map byte-for-byte onto the Bison input.
+
+## Conversion contract
+
+| Classification | Directives | Treatment |
+|---|---|---|
+| converted | `%token`, `%left`, `%right`, `%nonassoc`, `%precedence`, `%start`, `%expect`, `%expect-rr`, `%empty`, `%prec` | existing extended declarations or production syntax |
+| recognized metadata | `%nterm`, `%type`, `%union`, `%destructor`, `%printer`, `%param`, `%parse-param`, `%lex-param`, `%define`, `%code` | positioned report entries; no new Ibex syntax is invented |
+| unsupported | `%dprec`, `%merge`, GLR controls, generator/output controls, and every unknown directive | every occurrence is reported with its original line and column |
+
+`$$`, `$1`, `$<type>1`, and `@$` become `result`, `val[0]`, `val[0]`, and
+`result_loc` inside an opaque hexadecimal action sentinel. Ordinary `@1`
+locations remain `@1`. Balanced action scanning handles nested braces,
+strings, character literals, and C comments iteratively.
+
+Bison permits uppercase nonterminals, lowercase terminals, names that collide
+after punctuation removal, and names that are Ibex declaration words. The
+adapter deterministically namespaces nonterminals as `bison_nt_*`, maps
+lowercase terminals into `BISON_T_*`, and adds stable numeric suffixes to
+sanitization collisions. Named LHS forms such as `expression[result]:` are
+recognized.
+
+The source and JSON report distinguish general unsupported directives from
+structural gaps. Output/language controls and opaque initialization hooks do
+not make the recovered production graph incomplete. Unknown directives,
+`%dprec`, `%merge`, GLR semantics, and grammar-macro directives do. A generated
+header therefore contains exactly one of:
+
+```text
+# ibex-bison-structural-status: complete
+# ibex-bison-structural-status: incomplete
+```
+
+`ibex fix` refuses a structurally incomplete import. This prevents a repair
+from being called safe when the bounded comparison only covered an
+approximation of the source grammar.
+
+## Limits and failure behavior
+
+The defaults are 20 MiB of input, 1,000,000 structural tokens, 50,000 rule
+groups, and 100,000 actions. Override them with `--max-bytes`,
+`--max-tokens`, `--max-rules`, and `--max-actions`; every value must be
+positive. Exhaustion produces a version-1 JSON envelope and exits 2.
+Successful import exits 0 even when unsupported directives are present,
+because the report—not silence—is the result. Invocation and malformed-input
+errors go to stderr and exit 1.
+
+`-o` writes atomically, rejects an input/output alias, and refuses symlink
+targets or files with multiple hard links. Third-party grammar files are not
+packaged or committed.
+
+## External evidence and the `parse.y` boundary
+
+The scheduled external gate downloads five checksum-pinned GNU Bison grammars
+listed in [`gallery/EXTERNAL.md`](../gallery/EXTERNAL.md). It validates the
+import report, parses the generated source, normalizes it, and builds an Ibex
+LALR automaton. Current aggregate evidence is:
+
+| Grammar | Rule groups | Actions | Productions | Ibex states | Unresolved S/R |
+|---|---:|---:|---:|---:|---:|
+| GNU Bison calc | 5 | 7 | 13 | 22 | 0 |
+| jq | 29 | 167 | 167 | 311 | 408 |
+| PHP | 177 | 552 | 635 | 1,203 | 0 |
+| PostgreSQL | 795 | 2,436 | 3,640 | 6,942 | 0 |
+| CRuby Bison-era `parse.y` | 223 | 594 | 781 | 1,303 | 0 |
+
+For the pinned Bison-era CRuby grammar, GNU Bison 3.8.2 and Ibex both recover
+781 non-augmented productions and zero unresolved conflicts. Bison reports
+1,304 states while Ibex reports 1,303. The one-state difference is explained
+by the acceptance convention: Bison shifts end-of-input into a separate
+accept state, while Ibex accepts from the completed augmented start item.
+
+Current CRuby `parse.y` is an Lrama input, not raw GNU Bison input. The pinned
+current file imports 231 rule groups and 486 actions, but reports 22
+structurally unsupported occurrences, including `%rule` grammar macros. The
+approximate automaton has 1,152 states and 27 unresolved S/R conflicts.
+Selecting state 413 keeps `explain` bounded and yields one nonunifying
+reachability witness for the `'rescue' modifier` shift/reduce choice within 8
+tokens and 10,000 configurations. That is useful diagnostic evidence about
+the recovered approximation, not a claim about CRuby's actual Lrama table.
+`fix` refuses this input because proposing a language-preserving repair across
+unexpanded `%rule` definitions would be unsound.
+
+The external gate reads public grammar text and GNU Bison's black-box report
+only. It does not inspect Bison implementation source or generated C, and
+publishes only aggregate counts.

data/docs/comparison-policy.md

@@ -0,0 +1,127 @@
+# Comparative claim policy
+
+This policy defines when Ibex documentation may compare Ibex with another
+parser tool. The machine-readable registry is [`claims.yml`](claims.yml), and
+`bundle exec rake quality:comparative_claims` validates the registry and its
+public claim markers.
+
+The initial comparison set is Racc, Lrama, GNU Bison, Menhir, Tree-sitter, and
+ANTLR. A tool being in the set does not imply that a comparison has been made.
+An unmeasured tool remains `not_compared`; unknown facts remain `unknown`.
+Each entry also owns its canonical public aliases. README scanning recognizes
+only this declared set and aliases; adding a tool or spelling requires a
+reviewed registry change.
+
+Tool-level state is derived from every registered claim that names that tool.
+`pending_claims` is the canonical ordered list of claim IDs that are not yet
+`measured`, and the reason is generated deterministically from those IDs,
+their pending state, and their declared missing evidence. A tool with no claims
+is `not_compared` with an empty pending list and unknown identity. A tool with
+any pending claim is `evidence_pending`, even if another claim for that tool is
+measured. `compared` is valid only when the tool has at least one claim, every
+one is measured, and `pending_claims` is empty.
+
+## Required record
+
+Every measured, evidence-pending, or review-pending record contains:
+
+- an immutable claim ID and narrowly scoped wording;
+- each subject's exact released version and, when applicable, repository
+  revision;
+- one public command represented as an executable and an ordered argv list;
+- fixed corpus paths and external revisions;
+- known environment values and an explicit list of unrecorded values;
+- excluded or unsupported semantics;
+- the subjective review method and its completion state;
+- repository-relative evidence paths and explicit limitations; and
+- the SHA-256 of the canonical marker body, including every table and note; and
+- an exact-revision validity scope, expiry statement, and conditions that
+  require review.
+
+Repository subjects and corpora use immutable 40- or 64-hex revisions. Released
+tools use an exact release version and may use `not_applicable` only for the
+repository revision. It must not conceal missing information. Every required
+environment identity is either recorded as a non-placeholder value or listed
+as `unknown`, and each unknown field is repeated in the public limitations.
+
+No extra JSON Schema is used for this YAML registry. Its cross-file rules—file
+existence, canonical ordering, public markers, and wording restrictions—need an
+explicit repository validator and would not be made clearer by duplicating
+them in a data-only schema.
+
+## Public interface and corpus rules
+
+Comparisons use public commands, public callbacks, or documented artifact
+formats. Do not inspect another tool's implementation or generated source to
+manufacture an advantage. If a public interface cannot expose a value, record
+that limitation instead of inferring it.
+
+Inputs, grammar revisions, lifecycle choices, lexer inclusion, runtime backend,
+warm-up, repetitions, random seeds, and instrumentation must be fixed before a
+measurement. Failure rows stay in the evidence. Results from different
+environments or configurations form separate observations and must not be
+silently merged.
+
+## Subjective review
+
+Diagnostic and repair usefulness are human judgments. The review method must
+fix case IDs and the allowed labels, retain rationale and disagreements, and
+separate maintainer assessment from independent assessment. A record whose
+required independent review is missing stays `review_pending`; a record missing
+its direct result artifact stays `evidence_pending`. Neither state can use a
+public strong-claim marker or be worded as a completed comparative conclusion.
+
+Performance statistics and deterministic behavior digests do not require a
+subjective reviewer, but their scope and limitations still require ordinary
+code review.
+
+## Scoped wording
+
+Comparative wording names the claim ID and states the relevant revision or
+release, corpus, environment, measurement category, and important limitation.
+For example:
+
+> At revision X, on corpus Y and environment Z, metric M had the recorded
+> relationship to tool version V. This does not describe other revisions,
+> workloads, backends, or semantic capabilities.
+
+Do not publish wording such as “faster than Racc” or “better diagnostics”
+without those boundaries. README comparative strength wording is enclosed by
+`comparative-claim` markers. Only a `measured` record with a direct result
+artifact may use that marker. Pending material instead uses a
+`comparative-evidence` marker around the full table or conclusion it records.
+The validator requires each marker body to contain the registry wording exactly
+and every registered table anchor. It also canonicalizes line endings and
+trailing whitespace and requires the complete body SHA-256 to match, so any
+other prose, table-cell, row, or blank-line change fails independently of its
+vocabulary. It always scans README, even when no claim targets README, and
+rejects unmarked paragraphs that combine a declared tool alias with English or
+Japanese strength wording.
+
+## No cross-category ordering
+
+<!-- comparison-policy:forbidden-terms:start -->
+Do not collapse performance, diagnostics, recovery, migration, ecosystem, and
+verification into an aggregate score or tool ranking. The categories have
+different semantics and trust boundaries. Publish each observation and its
+limitations separately. Numeric totals never imply semantic equivalence.
+<!-- comparison-policy:forbidden-terms:end -->
+
+## Review and update workflow
+
+1. Add evidence without deleting unfavorable or failed rows.
+2. Add or update the claim in canonical claim-ID order. Keep corpus and evidence
+   entries ordered by ID and path.
+3. Mark unavailable tools or facts `not_compared` or `unknown`; do not estimate
+   values.
+4. Bind measured wording with claim markers or pending tables and conclusions
+   with evidence markers. The body must retain the exact registered wording.
+5. After reviewing an intentional marker-body diff, run the quality task. Its
+   mismatch reports both the registered and actual SHA-256; copy the actual
+   digest into `body_sha256` only in the same reviewed change. Never refresh a
+   digest merely to make the task pass.
+6. Run `bundle exec rake quality:comparative_claims`, the focused tests, and
+   documentation coverage.
+7. When a review condition fires, either remeasure under a new claim ID or
+   narrow the old wording to its historical scope. Historical observations are
+   retained rather than rewritten as current results.

data/docs/configuration-model.md

@@ -0,0 +1,59 @@
+---
+title: Configuration model
+description: Decide which parser settings belong to grammar source and which belong to an invocation.
+---
+
+# Configuration model
+
+Ibex keeps reproducible grammar intent in the grammar and keeps environment or
+review choices at the invocation boundary. This separation prevents a build
+flag from silently changing a source-owned parser contract.
+
+## Grammar-owned settings
+
+Declare settings in an extended grammar when every consumer should observe the
+same choice:
+
+```text
+class ExampleParser
+pragma extended
+parser
+  algorithm ielr
+  entries isolated
+end
+```
+
+The current grammar-owned parser block supports `slr`, `lalr`, `ielr`, or
+`lr1` construction and `shared` or `isolated` entry handling. The declaration
+is part of normalized Grammar IR and is visible in generated reports.
+
+## Invocation-owned settings
+
+Keep these choices at the CLI or API call site because they describe a local
+operation rather than the grammar's meaning:
+
+- output path and embedded-runtime selection (`-o`, `-E`);
+- table representation and diagnostic format;
+- warnings, verification strictness, resource budgets, and report output;
+- a temporary analysis algorithm used for comparison or investigation; and
+- external command execution for explicitly unsafe fuzz or reduction workflows.
+
+An invocation may select an analysis algorithm, but it must report that the
+selection is noncanonical when it differs from the grammar declaration. A
+conflicting canonical selection is rejected at the declaration location.
+
+## Review checklist
+
+When adding a setting, ask:
+
+1. Would two independent users of the same grammar need the same value? If so,
+   it is grammar-owned.
+2. Is the value about this run, host, output, or evidence capture? If so, it is
+   invocation-owned.
+3. Does changing it alter generated parser behavior, persisted IR, or runtime
+   ABI? Update the relevant schema, fixture, maturity entry, and migration note.
+4. Is the setting opt-in? Keep the compatible default unchanged and document
+   the activation boundary next to the option.
+
+See the [stability policy](stability.md), [grammar reference](grammar-reference.md),
+and [development guide](development.md) for contract and verification rules.

data/docs/configuration-report.md

@@ -0,0 +1,28 @@
+# Effective configuration reports
+
+`ibex config` explains every key in `Ibex::Configuration::Registry` without generating or loading a parser:
+
+```console
+ibex config grammar.y
+ibex config --format=json grammar.y
+ibex config --from=grammar-ir --format=json grammar.json
+```
+
+The command has a `static-no-user-code` trust boundary. For grammar source it uses the contained source resolver, so
+the root grammar and its import closure are parsed as data while parent traversal, absolute imports, glob imports,
+and symlink escapes are rejected. Parser actions, lexer actions, user-code sections, and generated parser classes are
+never executed or required. Grammar IR input is accepted only through the normal current-format validator.
+
+Each setting reports its effective value, owner, override policy, origin and source location when recorded,
+explicit or implicit selection, canonical or noncanonical conformance, recording status, and source evidence.
+Evidence is classified as `accepted`, `ignored`, `duplicate`, or `conflicting`. The JSON projection is deterministic,
+uses schema version 1, and always lists canonical keys in lexical order.
+
+The current Grammar IR `parser_contract` entries are authoritative for `parser.algorithm`, `parser.entries`, and `cst.trivia`.
+A matching command-line request is retained as accepted evidence. A contradictory request produces a positioned,
+structured conflict report and exits nonzero. An unspecified entry remains explicitly `unspecified`; a document without
+the current contract is rejected. A current builtin or CLI value is never presented as a historical fact.
+
+The source grammar syntax supports the root-only declarative parser block in extended mode. CST ownership is
+declared as `cst_trivia leading|balanced|drop` and requires `pragma cst`; `ibex config` reports the resulting
+value and source location without executing user code. It does not recognize generic or unknown settings.

data/docs/conflict-explanation-reviews/v1/records/README.md

@@ -0,0 +1,28 @@
+# H004 independent review records
+
+During blind collection, review only
+`docs/conflict-explanation-reviews/v1/blind-study-v1.json`. Do not inspect the
+source study, review registry, implementation, or repository history until the
+submission has been sealed. The blind artifact uses neutral IDs and excludes
+the source case ID, shape, grammar path, and maintainer hypothesis. For every
+case, use its state items, competing actions, bounded witness, and repair
+section to identify the cause and choose an edit without executing grammar
+actions.
+
+A record must match `schema/conflict-explanation-review-v1.schema.json`'s
+`review_record` definition and contain exactly one review for each of
+`H004-BLIND-01` through `H004-BLIND-04`. Copy the blind artifact SHA-256 into
+the record, set `submitted_before_reveal` to true only when accurate, record
+your own cause and edit text, and leave `reveal_comparison.status` as `pending`.
+If the machine artifact offers no verified repair, `chosen_edit` may describe a
+manual edit and `repair_usefulness` should remain `no_verified_repair` unless
+there is an actual proposal to assess.
+
+The registry remains in `blind_collection` and `HOLD` until it has at least two
+records from distinct reviewers. Only then may the source study be revealed.
+During `reveal_comparison`, map every neutral ID to its source case, bind the
+source study digest, and record cause/edit alignment plus notes without
+rewriting the original blind answers. The registry reaches `review_complete`
+and `PASS` only when every record has a completed reveal comparison. Do not
+collapse disagreements into a majority label; preserve them in each record and
+in the registry summary.

data/docs/conflict-explanation-study.md

@@ -0,0 +1,62 @@
+# Conflict-explanation usefulness study
+
+H004 separates reproducible machine evidence from subjective usefulness
+review. The committed version-1 corpus contains four grammar shapes and five
+conflicts:
+
+- an ambiguous expression and dangling `else` shift/reduce conflict;
+- an ambiguous reduce/reduce choice;
+- two nonunifying reduce/reduce conflicts introduced by LALR context merging.
+
+Each case binds its grammar bytes, Automaton IR digest, conflicting state items,
+competing actions, resolution, and bounded witness. It also runs the existing
+`fix` candidate search with fixed limits. Only the expression case currently
+has a machine-verified proposal: declaring right associativity for `PLUS`
+removes the conflict and finds no language or mapped-tree difference within the
+recorded bounds. The other cases truthfully record `no_safe_proposal`; advice
+that merely acknowledges a conflict or changes recovery is labeled as not a
+verified repair.
+
+Every witness records its typed search outcome, explored configuration count,
+exhaustion flag, and token/configuration bounds. A configuration-budget
+exhaustion is `inconclusive`; it is never relabeled as a nonunifying witness or
+accepted into the fixed study capture.
+
+Regenerate or verify the machine capture with:
+
+```sh
+bundle exec ruby tool/conflict_explanation_study.rb --write
+bundle exec rake quality:conflict_explanations
+```
+
+The normative machine artifact is
+[`study-v1.json`](../test/fixtures/conflict_explanations/study-v1.json),
+validated by the closed
+[`schema`](../schema/conflict-explanation-study-v1.schema.json). The capture
+uses repository-owned grammars and never executes grammar actions. Search,
+candidate, build, equivalence, and verifier limits are explicit; exhaustion is
+not success. The detailed pre-implementation contract and kill conditions are
+recorded in the [investigation](investigations/H004-conflict-explanation-study.md).
+
+## Independent human gate
+
+The machine capture proves reproducibility, not usefulness. Independent
+reviewers receive only the deterministic
+[`blind-study-v1.json`](conflict-explanation-reviews/v1/blind-study-v1.json)
+view. It uses neutral case IDs and omits the repository case ID, shape, grammar
+path, and `maintainer_hypothesis`. Reviewers use its state/items and witness to
+identify the cause, then choose an edit and explain whether the explanation and
+proposed repair helped. Each submission binds the blind artifact digest and is
+sealed before any expected answer is revealed.
+The [record instructions](conflict-explanation-reviews/v1/records/README.md)
+and [review schema](../schema/conflict-explanation-review-v1.schema.json)
+preserve per-case rationales and reviewer disagreement.
+
+The current subjective gate is **HOLD** with zero external records, as recorded
+in the [status registry](conflict-explanation-review-status-v1.json). Once at
+least two distinct blind submissions cover every neutral case, the repository
+case mapping and maintainer hypotheses may be revealed. Each reviewer record
+must then retain a per-case comparison against that revealed material. PASS is
+possible only after every comparison is complete; disagreement cannot be
+replaced with a majority percentage. Until then no usefulness rate,
+comparative superiority, or general conflict-repair claim is publishable.

data/docs/construction-profiling.md

@@ -0,0 +1,157 @@
+# IELR and multi-entry construction profiling
+
+This document closes H005's profiling work without selecting or implementing a
+new construction algorithm. The machine-readable authority is
+[`construction-profile-v1.json`](../tool/profile/evidence/construction-profile-v1.json),
+validated by
+[`construction-profile-v1.schema.json`](../schema/construction-profile-v1.schema.json).
+It is an `internal_local_observation`, not release or adoption evidence.
+
+## Public profiler
+
+Run the repository-owned and synthetic profiles with:
+
+```sh
+bundle exec ruby tool/construction_profile.rb \
+  --wall-seconds=60 \
+  --output=tool/profile/evidence/construction-profile-v1.json
+bundle exec rake quality:construction_profile
+```
+
+Third-party observations require a full checkout that the existing public
+workload manifest can verify. Each checkout must have the exact revision,
+origin, clean status, grammar digest, and structural baseline:
+
+```sh
+bundle exec ruby tool/construction_profile.rb \
+  --checkout=namae=/path/to/namae \
+  --checkout=bcdice_command=/path/to/BCDice \
+  --checkout=nokogiri_css=/path/to/nokogiri
+```
+
+Omitting a checkout records its exact registry metadata as `not_run`; it does
+not silently profile a cached file or substitute a synthetic grammar.
+
+The artifact separates reconstructible source provenance from host-bound
+observations. `provenance.base_revision` is only the Git base: when capture is
+dirty, every H005 contract path records its observed digest, base-object
+digest, and `base` / `modified` / `untracked` state. The clean flag is derived
+from the exact porcelain status; the status, bound-path set, implementation
+subset, host observation, and measurement policy each have an integrity
+digest. The evidence file is excluded from the source and implementation
+digests, so no digest refers to the bytes that contain itself.
+
+The quality gate reconstructs the base objects, requires the base to be an
+ancestor of the checked revision, verifies current contract bytes against the
+bound paths, and checks all derived digests and workload/run entry identities.
+Ruby version and options, kernel, CPU, and other host fields remain explicitly
+host-bound rather than cross-platform goldens, but their recorded values are
+validated against `environment_observation_sha256` before that observation is
+excluded from the deterministic structural comparison.
+
+Every construction has an explicit wall-time limit. Exceeding it records the
+resource and limit. `NoMemoryError` and `SystemStackError` are recorded as
+resource exhaustion. Those results establish only that a bound was observed;
+they are not negative proofs about the language or algorithm.
+
+## Counting contract
+
+The profiler records these structural quantities from the construction that
+already exists:
+
+| Field | Meaning |
+| --- | --- |
+| `lr0_states` | Distinct LR(0) cores materialized directly or represented by the canonical collection. |
+| `lr0_items` | Core-item occurrences across those distinct cores. |
+| `canonical_states` / `canonical_items` | Canonical LR(1) states and item triples, only when that collection completes. |
+| `final_states` / `final_items` | States and core-item occurrences after merge or IELR partitioning. |
+| `final_lookahead_items` | Lookahead memberships across final core items. |
+| `propagation_edges` | Deduplicated direct-LALR lookahead propagation edges; canonical paths report `not_applicable`. |
+| `ielr_initial_partitions` / `ielr_final_partitions` | Compatible partitions before and after transition refinement. |
+
+`not_applicable` is reserved for metrics that the selected construction path
+does not perform, such as canonical-state counts in direct LALR. A metric that
+would apply but could not be collected because construction timed out or
+failed is `not_measured`; failure never masquerades as algorithmic absence.
+
+Elapsed seconds are retained only as host-bound observations. The schema fixes
+`release_gate` to `false`, and the quality gate deliberately removes elapsed
+values before comparing evidence. Ruby's live-slot counters are neither a
+peak measurement nor reproducible retained-object accounting, so peak retained
+objects are truthfully `not_measured`. The current builders also expose no
+state budget or portable per-build heap limit; both omissions are explicit in
+the evidence.
+
+Profiling is opt-in through `Builder(profile: true)`. Ordinary generation does
+not calculate the additional item/core summaries. Parser tables, conflicts,
+generated source, runtime ABI, Grammar IR, and Automaton IR are unchanged.
+
+## Current observations
+
+Synthetic and real workloads are separate cohorts. All repository grammar
+revisions and SHA-256 digests come from the public workload registry. The
+multi-entry diagnostic is the existing representative matrix grammar at the
+recorded exact revision, not a new language fixture.
+
+| Workload | Class | LR(0) states/items | Direct propagation edges | Canonical LR(1) states/items | IELR partitions initial/final | Final states |
+| --- | --- | ---: | ---: | ---: | ---: | ---: |
+| `gallery-calc` | repository synthetic | 15 / 76 | 99 | 27 / 674 | 15 / 15 | 15 |
+| `gallery-json` | repository synthetic | 27 / 82 | 111 | 57 / 272 | 27 / 27 | 27 |
+| `gallery-sql-lite` | repository synthetic | 26 / 53 | 55 | 26 / 115 | 26 / 26 | 26 |
+| `matrix-multi-entry` | repository synthetic | 9 / 14 | n/a | 9 / 20 | 9 / 9 | 9 |
+| `ibex-frontend` | repository real | 227 / 633 | 749 | 456 / 10,482 | 227 / 227 | 227 |
+
+The table pairs direct-LALR edge counts with the canonical collection used by
+current IELR. The multi-entry row reports the shared result; its committed run
+records also contain isolated LALR and IELR. On this diagnostic all four
+shared/isolated combinations retain 9 states, 14 final core items, and 20 final
+lookahead memberships. That bounded synthetic equality is not evidence that a
+direct multi-entry implementation lacks value on real grammars.
+
+The three `public_real` identities—Namae, BCDice command, and Nokogiri CSS—are
+recorded as `not_run` because no checkout satisfying the public manifest was
+supplied for this evidence capture. They contribute no state, item, edge,
+partition, failure, or timing observation. The only measured real workload is
+the repository's production frontend; it has no unresolved conflict requiring
+IELR, and current IELR partitions its 456 canonical states back to the same 227
+final states as direct LALR.
+
+## Decisions
+
+Direct IELR is **NO-GO** under the current verifier and workload evidence.
+Direct multi-entry is **MORE DATA**.
+
+### Direct IELR — NO-GO
+
+The threshold is at least two verified representative real grammars that both
+show a practical canonical-collection cost and require IELR for semantically
+meaningful conflicts. The current artifact has one measured real grammar, zero
+real IELR-required conflict cases, and no verified public checkout.
+
+[V001](verifier-trust-boundary.md) is complete, so the trust-boundary threshold
+is satisfied. It also establishes a current NO-GO condition: default and
+strict `ielr1` verification both enumerate the full canonical LR(1)
+collection. A direct builder would therefore not remove canonical scale cost
+from the current verified workflow, and the verifier does not establish IELR
+adequacy or split witnesses. Together with no real IELR-required workload,
+that makes direct IELR unjustified now rather than merely unmeasured.
+
+Evidence that can change the decision must include verified real grammars,
+material canonical state/item cost or observed exhaustion, meaningful
+conflicts removed by IELR, a bounded verification plan that does not make full
+canonical enumeration mandatory, and an owner accepting the specification and
+maintenance budget. State-count vanity alone is insufficient.
+
+### Direct multi-entry — MORE DATA
+
+The threshold is at least two verified real multi-entry grammars plus either an
+observed construction bound or at least twofold structural overhead in the
+current shared path relative to an admitted direct plan. The registry contains
+zero real multi-entry workloads. The existing synthetic matrix exercises both
+shared and isolated modes, but neither its elapsed time nor its equal state
+counts justify a production algorithm.
+
+Evidence that can change the decision must add verified real multi-entry
+grammars, preserve entry dispatch and shared conflict attribution, demonstrate
+material structural cost, and identify an owner for the semantic and
+maintenance plan.