Rust-backed Cruncher CLI compatibility - Phase 6

Status: P6_040 accepted and closed.

Decision and boundary

P6_040 preserves the installed kicad-cruncher, kcr, and python -m kicad_cruncher entry points and the primary design, design-review, and dr workflow. On the selected Windows path, the existing Python facade remains responsible for argument parsing, project discovery, Design JSON, netlist JSON, presentation, manifest and README assembly, logging, and transactional publication. Its promoted PCB physical-base SVG, compiled-graph, and version-E netlist providers are the packaged Rust operations and have no Python retry.

This is the bounded meaning of native CLI delivery for the current Phase 6 sequence. It is not a claim that the universal Cruncher wheel contains a separately compiled Rust kicad-cruncher executable or that all public Cruncher workflows have been rewritten in Rust. A literal all-Rust command and application-orchestration replacement would require a new decision and separately versioned contracts.

Public compatibility

The existing command manifest remains authoritative for the public command inventory. Every listed command and alias retains command-level help. The release-acceptance workflow exercises the three installed entry mechanisms, while full artifact acceptance is deliberately scoped to the design alias family. Its established arguments remain an optional .kicad_pro or .kicad_sch positional input, -o/--output, and --no-indexes.

Exit status 0 means success, help, or version reporting; argparse syntax and unknown-argument failures use status 2 and stderr; resolved-input, malformed-source, provider, resource, and runtime failures use status 1. Cruncher command logging retains its established stdout channel. Evidence normalizes terminal color, absolute temporary paths, and elapsed-time text without weakening message order or channel assertions.

Artifact and failure contract

The design-review manifest remains Cruncher-owned. Its strict package schema and semantic checks cover the existing a0 artifact index, relative output references, graph metadata and linkage, schematic and PCB SVG records, native design-facts provenance, netlist byte count and digest, and the README. Every referenced artifact must remain beneath the selected output root and must exist before publication.

Repeated entry points over the same input produce the same governed facts and artifact structure. The --no-indexes switch changes only its documented Design JSON lookup-index surface. Missing native executables, incompatible handshakes, timeout, truncated or malformed results, resource rejection, malformed KiCad input, and invalid manifests return failure without invoking a Python physical, graph, or version-E writer fallback. The sibling-tree transaction preserves a prior destination and removes unpublished staging output.

Contracts and packaging

P6_040 introduces no Monkey transport operation and does not change the frozen Phase 5 Plotter-IR roots or the accepted Phase 6 A0/A1/A2 native envelopes. Command arguments, streams, exit status, and the output tree are Cruncher process and artifact contracts rather than Monkey TypeSpec transport. The universal Cruncher wheel continues to declare an ordinary public kicad-monkey>=2026.8.18 dependency. The selected Windows Monkey wheel supplies the package-owned native executable; neither distribution embeds workspace paths or the other package's source tree.

Evidence and promotion

Cruncher owns focused public-CLI and installed-artifact tests for entry points, aliases, arguments, normalized logs, exits, exact manifest and artifact topology, repeatability, hostile provider behavior, and transaction cleanup. Root Rack L3_026 composes those tests with the accepted no-fallback physical-provider and source-bound design-facts gates. The reusable Windows workflow builds the native executable, runs L3_026 under the four-job/two-thread cap, and is ordered after P6_030 in CI and release.

The final local Windows run passed L3_026 1/1 in 239.86 seconds (240.86 seconds including Rack orchestration), composing 116 focused transport, provider, manifest, CLI, artifact-build, and isolated-install tests.

P6_040 closed after executable evidence, three independent approvals, and the recorded Rack runtime agreed with this boundary. Native application delivery remains in progress: P6_050 still owns the final selected Windows bot/public-release hard switch, clean public-distribution installation, artifact provenance, corpus/oracle evidence, and final runtime decision.