# Validation status

The configured acceptance checks pass for the tested Darwin/arm64 and Linux/arm64 builds. Published npm packages are early-access builds, not a claim of unrestricted generation, universal containment, or support for untested platforms.

## Executed checks

| Lane | Retained result |
| --- | --- |
| Mac source release | 16 gates passed, including strict declarations, native lint, behavior-based requirements, docs and benchmarks. |
| Linux source release | The same 16 gates passed inside the isolated runner. |
| Local tests, each platform | All local owner cases plus explicitly labelled transport-double cases passed with zero failures/skips. Current counts live in each run's `local-tests.log`, not in this document. |
| Integration owners, each platform | All integration owner cases plus the separate native LSP cancellation case passed with zero failures/skips. These include labelled Pi doubles and negative fault injection, which are not native-positive claims; current counts live in each run's `native-integration.log`. |
| Installed tarball, each platform | 48 owner cases passed against that platform's actual installed package, including labelled fault injection. Mac consumer declarations, exports and initialization also passed. |
| Browser | 15 pages, keyboard search, responsive navigation, real clipboard copy/read with origin-scoped permission, and zero console/runtime errors passed. Later changes were prose-only; no new browser execution is claimed for them. |
| Executable docs | Quickstart and printer fixtures passed strict types and execution against a fresh consumer of the tested Mac tarball. Quickstart published accepted bytes in required mode. |

## Evidence

Local run logs under `.oxcgen/` were pruned after publication (only the pinned
runtime is retained). The facts below were recorded from the executed runs; the
published npm artifact and git history are the durable receipts.

- Mac source release and packed consumer: `.oxcgen/local-runs/2026-09-10T03-34-59.330Z-0bf027c0/summary.json` and its `source-release/release-result.json` (pruned).
- Fresh dependency installation: `.oxcgen/local-runs/2026-09-10T02-45-59.322Z-6e5243b1/install-dependencies.log`. That run's original packed-consumer failure remains a failure; the corrected consumer evidence is the later run above.
- Linux source and installed consumer: `.oxcgen/review-linux/container-result.json` and `.oxcgen/review-linux/source-release/release-result.json`.
- Browser: `.oxcgen/completion-browser-active-permission/result.json`, `commands.json`, and screenshots in that directory.
- Executable docs: `.oxcgen/docs-consumer-{install,quickstart,printer,types}.log`.
- Native build identities: `native/upstream-lock.json`, platform build receipts, and each run's `native-build.log`.
- Pi declaration correction and local dependency artifact provenance: [vendor/README.md](vendor/README.md).

Source reports use `sourceChecksPassed`. Their `accepted`/`fullyVerified` fields deliberately do not certify the separate browser, installed-consumer and platform work. The latest Mac `--validate-only` report did not perform another dependency installation; its `installationComplete: false` is not an installation failure.

## Performance and resource evidence

The existing benchmark now includes 96 authored files, 204,828 characters and the actual Zod dependency tree (828 files, 5,797,652 bytes). The final Linux run resolved 94 dependency members and reported zero inspection diagnostics. Its cold/warm verification samples were approximately 13.38/13.09 seconds; these are individual observations, not percentiles or a throughput guarantee.

The original Linux benchmark failed when unbounded per-file policy exports exhausted thread-creation resources. Exports were first serialized; a snapshot's per-file policies are now exported by one native process, which stops on failure. With the unchanged 6 GiB, 2-CPU and 256-PID limits, 47 cgroup samples recorded a highest cumulative memory peak of 5,095,464,960 bytes (about 4.75 GiB) and 113 PIDs, with no recorded OOM or PID-limit events. Cgroup memory includes filesystem cache and the observer; parent Node RSS is not aggregate subprocess memory. These samples do not establish the original spike's unrecorded RAM peak.

See `.oxcgen/review-linux/resources.jsonl` and `source-release/printer-benchmark.log`. Linux ran separately from Mac acceptance and reused the checksum-verified Oxlint build. The earlier failed Linux run remains under `.oxcgen/completion-linux/`.

Batch policy export (Darwin/arm64, `npm run bench`, single observations, same host and corpus before and after): cold verification of 12, 96 and 384 files took 12.4, 22.8 and 65.9 seconds with one export process per file and 0.75, 0.82 and 1.14 seconds with the snapshot's policies exported by one process; the warm 96-file median moved from 10.96 to 0.43 seconds. Publication of one constructed file moved from 2.14 to 1.84 seconds. These are not percentiles or a throughput guarantee.

Project growth, measured before the publication-policy batching and snapshot-hash reuse being landed in the same working tree (Darwin/arm64 Apple M4 Max, `npm run bench`, single observations, one host, HEAD 8743e1c): with the candidate set held at one file whose content never changes, verification of that single candidate took 0.76 seconds cold and 0.42 seconds warm in a project of 792 checked files, 1.00 and 0.51 seconds at 1,392 files, and 1.53 and 0.78 seconds at 2,592 files. Growing the project 3.27 times while the candidate set stayed at one file multiplied the cold time by 2.00 and the warm time by 1.85, a slope of about 0.42 milliseconds cold and 0.20 milliseconds warm per added project file, so this cost tracks the project rather than the candidate. The benchmark reports these sizes and ratios as its `projectGrowth` and `growth` objects; they are the before-comparison for the after-numbers, and they are not percentiles or a throughput guarantee.

Project growth after the publication-policy batching, snapshot-hash reuse and incremental snapshot construction (Darwin/arm64 Apple M4 Max, `npm run bench`, paired single observations taken back to back on the same build and comparable load): with the candidate held at one unchanged file while the project grows from 792 to 2,592 checked files, cold verification moved from 767/986/1,605 ms to 757/947/1,377 ms across the three sizes, so the cold ratio for a 3.27x larger project fell from 2.09 to 1.82 and the marginal cost per project file fell from 0.465 to 0.344 ms. The warm ratio (1.92 to 1.80) is unchanged code and should be read as noise, because an unchanged project with the same overlay key already took the reuse path. Publication of one candidate in a 2,500-file project took 2.1 seconds against the 517 seconds recorded before the policy export was batched, and verification of the same project took 1.4 seconds against 55. Single observations on a loaded host are unreliable: a run at load average 91 inflated the absolutes roughly eightfold while the ratios stayed within the same band. `npm run bench` now fails when the marginal cold cost exceeds 1 ms per project file, and reports `growthGate: "skipped-under-load"` instead when the one-minute load average is at or above half the core count, because a timing assertion on a loaded machine is not evidence. Cost still scales with project size; the remaining project-proportional work is the per-file policy export and the native program build over every checked file.

## Artifacts

- Mac: `.oxcgen/local-runs/2026-09-10T03-34-59.330Z-0bf027c0/artifacts/oxcgen-0.2.1-validation.2.tgz` (historical, pruned).
- Linux: `.oxcgen/review-linux/oxcgen-0.2.1-validation.2.tgz` (historical, pruned).
- Published: `oxcgen@0.2.0` plus optional per-platform packages `oxcgen-darwin-arm64`, `oxcgen-linux-arm64` and `oxcgen-linux-x64`, built and published by the release workflow. npm installs only the package matching the consumer's `os`/`cpu`; the main package carries no native binaries. A registry install of `oxcgen@0.1.2` on macOS arm64 ran the CLI and passed the installed native tests (48/48). `darwin-x64` has no package and is untested: its Intel macOS runner is dispatch-only.

Binary footprint work: retired stale JSON-replay executables removed, Go hosts built with `-ldflags "-s -w"`, the Rust binding built with `CARGO_PROFILE_RELEASE_STRIP=symbols` and thin LTO, and the policy JS bundle copies the parser-verified import closure. Isolated Linux builds reuse Cargo/policy-build caches through named volumes; source still comes from a fresh read-only mount each run.

## Supported scope

- Three built-in intent-driven normalization strategies are implemented; other enabled rules remain native acceptance constraints.
- Policy export uses the initialized, pinned Oxlint 1.83.0 host, including external JavaScript plugins. Authored acceptance checks root and per-file policy identity as well as exact output bytes and snapshot freshness.
- Versioned inspection returns Oxc projections and native facts/program/graph evidence. Input/file/deadline limits and killable isolation are enforced; post-construction AST checks do not establish a hard construction-memory bound.
- Range edits preserve the complement of complete top-level statement ranges. Final-byte maps retain known provenance. Native fixes without mapping provenance fail closed for mapped/ranged output.
- React accounting reports observable module outcomes and explicit source directives. The pinned NAPI does not expose per-function outcomes or recoverable-bailout details. React 19 client/SSR output was executed with React 19; runtime verification is intentionally React 19-only.
- Publication is cooperative and per-file, not globally atomic. Process-crash recovery can itself be resumed after a crash; legacy ownerless recovery locks fail closed rather than being deleted on an ownership guess.
- Pi edit/write routing and receipts are not shell/MCP confinement. OS restrictions require the explicitly launched restricted host. Windows and other untested platform combinations are not certified.
- `npm audit` reports zero vulnerabilities. The ICNS/JXL/HEIF infinite-loop advisories in `image-size@2.0.2` have no published upstream fix; they are resolved by the vendored, regression-tested `image-size@2.0.2-fix.2` forward-progress guards ([vendor/README.md](vendor/README.md)).

Current requirement coverage is in [OXCGEN_REQUIREMENTS_MATRIX.md](OXCGEN_REQUIREMENTS_MATRIX.md). Historical failures and the September 8 audit are retained, not converted into passing results.