Release-candidate notes — cf664fd (post-v1, N49–N75)

Frozen evidence for one tested commit. This file records what was verified at cf664fd45e4920913550f21a10130f34c5c45a6f and is not updated as the project moves. Current implementation truth is ../capability-matrix.md; what is not done is ../limitations.md.

Nothing has been tagged, pushed or published. This is a candidate. Making it a release is a person’s decision, and the procedure for it is at the end of this file.

What this candidate is

Nazm after the post-v1 programme, N49–N74, audited in N75: the v1 foundation of 84d3c80.md plus function values, closures and effect parameters (N50, N51), resource and information-flow facts (N52), the runtime as its own crate with typed channels (N53), select, deadlines and cancellation (N54), C strings and exported libraries (N55), a local package registry (N56), cross-compilation to six targets (N57, N62, N64), a live debugger and a profile (N58), SSA temporaries in the LLVM emitter (N59), restriction profiles v2 (N60, N63, N69, N72), a formal core under bounded model checking (N61), a freestanding board target and real-time bounds (N62, N63), WebAssembly (N64), a REPL, comptime and reload checks (N65), a vectorised summation (N66), a GPU map kernel (N67), field-by-field vector layout (N68), contracts — a chain-neutral model, an EVM backend, a WebAssembly adapter and account metadata (N69–N72) — seeded fuzzers, build provenance and an evidence bundle (N73), and project templates, API docs, C-header bindings and an editor client (N74).

Identities

Targets, and what was run on each

Compile-only and run-verified are kept apart; a self-skip is not evidence.

Reproducibility. One program, one toolchain, two clean directories: byte-identical executables under both backends (N46) and one provenance record (N73). Across toolchains, for aarch64-unknown-linux-gnu: Apple clang 21 and clang 19 give byte-identical program and entry objects at -O0 and -O2; the runtime object differs — one symbol-table byte at -O0, code layout at -O2 (N73’s measurement).

The gate

Contained (Docker, offline, nazm-contained:1.98.1, the runner image’s compatibility key 6a1d76f8…), 2026-10-02/03, from a clean worktree: every stage at 34e2380; at 53c6ef7, whose only change is one mutant’s declared killer, that mutant and the checks; at cf664fd, whose only further change is the release script, the release assembly — which itself runs formatting, lints, the architectural gates, the whole workspace suite, the release build and the bootstrap chain again at that commit.

Beside it, on the host at this commit: the nine platform runs of the table above (all passed); the seeded fuzzers at release scale — the front end over 20,000 mutated sources, the differential tiers over 100 programs of seed 75 — clean; the formal core’s seven properties (nazm-formal) hold to their bound. These are separate classes of evidence and are reported apart.

What the gate and the audit found, every item fixed before the candidate (commit, then what):

• cf664fd — the release script could not assemble a candidate: compiler/conformance has held the directories modules/ and refused/ since N14E, and the script’s plain cp of its entries fails under GNU cp with set -e — found by the first assembly to reach that step. Copied with tar, recursively and without .nazm caches: 107 files, as tracked.

• 53c6ef7 — the full catalogue’s one non-verdict: a-channel-goes-while-another-reference-remains (a channel’s storage released while a task still holds it) had no declared killer; in the workspace suite a task waited for ever and the tier timed out at 2,400 s. The runtime harness test the_runtime_s_services_keep_their_contract_when_called_directly observes the early release under its own deadline in seconds; declared, and verified contained: pristine passes, mutant fails, restored passes.

• The harness, not the tree: the last sessions needed more than the runner’s fixed 3,000 s — each began with the verification cache over its 16 GiB cap and emptied, a cold build and the pristine suite, and the next mutant needed the whole suite — so the same mutant was restarted every session. Sessions 24 on ran under a supervisor built from 34e2380’s xtask with two constants changed (a 7,200 s deadline, a 40 GiB cap) and the unmodified tree mounted, so the campaign’s identity and journal carried over; the release assembly likewise ran with a 4,800 s deadline and --skip-bench (its benchmark is the gate’s own stage), after the stock 2,400 s run reached its deadline in that step having passed the suite, the release build and the bootstrap chain.

• 34e2380 — the release audit: the capability matrix’s summary still counted N48’s rows (one MISSING); limitations.md said “no select” beside N54’s select, “four targets” beside six, and “eleven rules, no bounded-loop rule” beside fourteen with one; N73’s and N74’s four schemas were not documented in docs/diagnostics.md — found first by the N74 workspace run’s docs suite.

• Earlier in the programme, each composed gate’s survivors and the fixes they forced are recorded in the milestone reports (Gate C 163/163; Gate D’s one survivor, n46-a-cycle-is-not-noticed, killed by 18eb20e; Gate E 99/99).

Results

cargo test --workspace, run through cargo xtask contained on Linux at 34e2380, the gate’s workspace stage (and again, passing, inside the release assembly at cf664fd): 2249 passed, 0 failed, 38 ignored. Across 172 suites.

Mutation catalogue accounting

Every one of the catalogue’s 1,089 entries has a verdict, and every verdict is caught:

Composed, and how. 1,088 verdicts at 34e2380, one campaign (journal db2d0899a035bcb8) across 24 resumed sessions, each verdict decided once and reused thereafter; and 1 at 53c6ef7, the mutant that timed out, with its killer verified in that session. Every killer that decided a verdict was verified — pristine passes, mutant fails, restored passes — in the session that decided it. No verdict was reclassified. The journals are kept with the gate’s logs.

Performance at this candidate

../performance.md, The post-v1 baseline — N75: the contained figures at this candidate, which replace N48’s as the reference, and host figures for the scheduler, packages, a contract’s gas bound and the freestanding images, each scoped to how it was measured. No universal score; nothing here compares Nazm with another language.

Known limitations

../limitations.md, by area, audited in N75. The ones a user meets first: one OS thread per task, so the tasks alive at once are bounded by the host’s thread limit; no traits or methods; the foreign boundary passes Int, Bool and borrowed strings only; a local registry only; the freestanding and WebAssembly targets refuse the heap; contracts run on one EVM implementation and under one reference WebAssembly host; fuzzing is seeded, not coverage-guided; verified on aarch64 hosts and the emulators named above only.

Evidence index

Kept outside the repository with the gate’s working files, as an evidence bundle of 48 files indexed by cargo xtask evidence (nazm.evidence/1, BLAKE3 per file; index.json SHA-256 2f1dc77eafbcf9414664fe4de3d7e8834070ac8eda41c0462e48156b7cdec0da) and verified by cargo xtask evidence --verify:

Independently verified on the host (macOS, shasum and Python’s hashlib, not the tool that made them): the archive extracted, every file’s SHA-256 recomputed — 188 listed, 188 present, none mismatched, missing or unlisted.

The human release procedure

Every step is a person’s, in this order, from a clean checkout of exactly this commit. Stop at the first step that does not pass.

1. Check out the commit. git checkout cf664fd45e4920913550f21a10130f34c5c45a6f and confirm git status --porcelain prints nothing.
2. Build the images (network needed here and nowhere after): docker build -f docker/contained.Dockerfile -t nazm-contained:1.98.1 ., and for the platform runs docker/qemu.Dockerfile (nazm-qemu:n62), docker/wasm.Dockerfile (nazm-wasm:n64), docker/evm.Dockerfile (nazm-evm:n70) and the debugger image (nazm-debug:n58).
3. Run the gates, contained and offline, each of which must exit 0:
   • cargo xtask contained --profile p4w2t4 tests
   • cargo xtask contained --profile p1 run "cd /src && cargo test -p xtask --test lifecycle -- --ignored --test-threads 1"
   • cargo xtask contained selfhost and cargo xtask contained bootstrap
   • cargo xtask contained bench (compare against The post-v1 baseline — N75)
   • cargo xtask check and cargo test -p nazm-cli --test docs
   • the mutation campaign: cargo xtask contained --profile p4t4 mutate --strategy targeted --verify-killers, resumed with --resume until it completes; it must report 0 survived and no mutant without a verdict.
4. Run the platform tests on the host (Docker for the images, macOS for the GPU): cargo test -p nazm-cli --test accel --test freestanding --test realtime --test wasm --test wasm_contract --test evm --test debugger -- --ignored.
5. Assemble the local candidate: cargo xtask contained release — the stock runner gives it 2,400 s, which one CPU did not fit with the benchmark comparison; run it with a longer deadline or with --skip-bench passed to scripts/release-candidate.sh (step 3’s bench is the measurement), as this candidate’s was. It runs every gate again, builds the artefact under target/, writes MANIFEST.txt and PROVENANCE.txt, and verifies the artefact against the manifest. It tags, pushes and uploads nothing.
6. Verify independently on the host: extract the artefact and compare every file’s SHA-256 with MANIFEST.txt (counts must match both ways); then cargo xtask evidence --verify DIR over the evidence bundle, which recomputes every BLAKE3 digest of index.json.
7. Decide. Only then, and only by a person: tag (git tag -a v2.0.0-rc.1 cf664fd -m "…"), push the branch and the tag, and publish the artefact with this file beside it. None of this has been done.