Rust S-Expression L1 Corpus Review

Decision

The Rust parser-only corpus slice is accepted. It closes the promoted KiCad corpus round-trip gate. Typed PCB, schematic, rendering, and downstream interchange expansion remained outside this decision until the later Phase 1 promotion review.

Reviewed Boundary

• Rack and the existing Python corpus helpers retain ownership of archive extraction, KM_CORPUS archive selection, suffix selection, excluded output trees, and stable path ordering.
• A test-only Rust example accepts explicit paths on standard input and emits one versioned JSON record per file. It does not add archive, CLI, or serialization dependencies to the production parser library.
• Every file must complete byte read, parse, deterministic build, reparse, semantic equality, and byte-stable second build.
• Failure records preserve the read, lex, tree, build, reparse, and compare phases used by the Python oracle family.

Evidence

• The content-addressed corpus contributed 1,774 S-expression files and 862,334,442 input bytes: 236 boards, 651 schematics, 123 symbol libraries, 731 footprints, and 33 worksheets.
• Real-world project paths contributed to both parser-only gates; the corpus did not reduce to synthetic fixtures.
• Rack L1_022 passed all 1,774 Rust records. The largest file was a 71,556,836-byte board and completed successfully.
• The pre-existing Python L1_018 oracle passed the identical resolved path set with both its corpus-wide and real-world assertions.
• On the review workstation, the release Rust gate completed in about 34 seconds and the Python oracle in about 624 seconds. This is useful directional evidence, not a ratified cross-platform performance floor.

Review Findings

• The first Rack metadata entry named the Rust crate as though it were a Python module. Removing that field closed the warning while preserving the explicit Rust runner and function names in the test and review.
• The runner processes and releases one complete tree at a time; it does not retain the corpus or canonical outputs in aggregate memory.
• The Rust byte API deliberately rejects invalid UTF-8, while the legacy Python corpus loader requests replacement decoding. All promoted files are valid UTF-8, so this policy difference is not exercised or hidden by the accepted evidence.
• Corpus evidence proves semantic round trips and deterministic output within each implementation. Exact cross-language canonical text is covered by the shared L0 vectors, not asserted for all 853 MB of built corpus output.

Retained Gates

1. Measure peak memory and throughput on named small, medium, and large content-addressed corpus cases before ratifying performance floors.
2. Measure select-everything sorting, deepest-path ownership, and many-path selector scaling before changing the indexed representation.
3. Retain streaming-select, source-patch, and browser-WASM transfer measurements for pre-cutover budgets or a profile-triggered review.

Gate Closed Since This Review

The build-operation envelope was initially private pending a handwritten TypeSpec-union semantic validator. Phase 1 closed that gate with kind/payload exclusivity, identity, depth, node-count, integer-range, bounded-output, native, and executable WASM evidence.

TypeSpec now also generates strict Python msgspec models and strict TypeScript declarations. Rack rejects stale generated output, unknown Python fields, and TypeScript consumer compilation failures.

The Phase 1 promotion review accepted the parser correctness and architecture boundary. Streaming, patch, and actual WASM resource-limit correctness are covered; additional performance measurements are advisory until a real typed-reader profile or pre-cutover review calls for them.

Next Authorized Slice

Begin the TypeSpec-first footprint reader/writer vertical slice. Further profiling is advisory until real typed-reader workloads or pre-cutover budgets require it.