This is a fresh recipe copied from the previous comparator. The old directory, compiled executable and closed self-check evidence remain untouched. Rust main, two fixtures, six expected JSON files and catalog are byte-identical; their previous acceptance is historical, not a current-source run. No current LIST receipt or verifier hash is inferred from a filename.

This is a separate core-only evaluator. It does not change the spacing oracle or product. name compares an independently captured pre-edit incident source Project with an actual saved source, allowing only the supplied element's exact new Name. typed compares an actual saved service source with one of six independently authored, published core checkpoints. There is no generic ignore list and no field projection.

Both source inputs use actual source_files::load_project, compile_bundle, unchanged compiled-versus-input SourceBundle, exactly one reachable file, and empty-batch core admission. Full Project JSON object keys are sorted only; arrays and serialized scalars remain exact, including signed zero. UUIDs, aliases, scenario.steps, other records, replies, types and every saved view remain part of the comparison. Formatting/comments may differ between two source files, but neither parse may need migration or identity insertion. This does not inspect the desktop's accepted source buffer or history.

Independent expectations

The exact incident Name task already declared by the native plan is element 70200000-0000-4000-8000-000000000020, from Initial incident report to Initial incident report [Details trial]. Capture the pre-edit source and its SHA before that edit; do not derive a baseline or NewName from the result. Save the working fixture at the intended accepted Name checkpoint before comparing. Revert/Undo equality checks can continue using the existing spacing oracle's same mode. This new Name mode refuses unchanged names and Diagram IDs; the native SavedB case checks inspector access, not a Diagram-name mutation.

expected/ contains exact baseline/1/3a/3b/3c/3d JSON bytes from the published core evidence. These were produced independently of future native output. expected-catalog.json binds each checkpoint SHA and fixture identity. The runner rejects any other expected bytes; Rust also requires the exact embedded approved bytes, complete Project round-trip, correct service owner/view and core admission. The five edit checkpoints are cumulative as specified in that fixture: payload edit, Reply annotation removal, operation/field replacement, Reply annotation addition, final pressure edit. A rejected change after task1 compares to checkpoint1. No expected value is learned from Actual.

Deferred build

No comparator compilation or execution has occurred. The builder requires the closed successful exactb10 desktop LIST, actual1095 names,301 focused membership, and its hash-bound expected-inputs.json with base=b10, count=612 and exactly612 files, plus the bound test EXE and matching test fingerprint. The current gate has no finalization.json; the recipe does not invent or require one. It checks desktop -> core, desktop -> serde_json and core -> serde_json fingerprint edges, same compiler fingerprint, Cargo.lock/core/all source inputs, actual compiler/linker versions and link/search artifacts before/after. This is sufficient for the core-only evaluator; it does not invoke the native verifier's five-stage admission. The reused verifier supplies read-only source/membership helpers only. Its path and reviewed SHA256 are required explicit build arguments, as are the closed LIST path and reviewed SHA256. No hash is guessed or baked in before parent review. The new canonical source-path selection asserts every intended local/product source record is included before invoking the compiler; omitted or duplicate fixture records are rejected. Native staging still requires all five gates.

Only after the parent grants the exclusive compiler slot:

./build.ps1 -SourcePin 'b10b28cefd1d0794073ba241a0c8de9a83e85f68' `
  -ReferenceReceipt $ReviewedB10ListReceipt -ReferenceReceiptSha256 $ReviewedB10ListReceiptSha256 `
  -NativeVerifier $ReviewedB10NativeVerifier -NativeVerifierSha256 $ReviewedB10NativeVerifierSha256 `
  -RuntimeDll $VerifiedToolchainRuntimeDll `
  -DesktopFingerprint '<absolute actual oa-desktop-.../test-bin-arcadia-studio.json>' `
  -CoreRlib '<absolute matching liboa_core-....rlib>' `
  -SerdeJsonRlib '<absolute matching libserde_json-....rlib>' `
  -WindowsImportLibDirectory '<absolute windows_x86_64_gnullvm-0.52.6/lib>' `
  -Output '<fresh build evidence directory>'

RuntimeDll is required explicitly; use the verified toolchain libunwind.dll, exactly190464 bytes/SHA256 aa282fa47bb2c4e210cea5e470cdbdca58568f0be0bc73e404d86ab9cd95ef6a. No old private-package default remains. The builder hashes it among inputs, copies it adjacent to the comparator only after successful linking, and records path/size/SHA. No global PATH or profile changes occur. Rlib names above are deliberately not guessed: the explicit paths must pass the actual closed-list/fingerprint checks. Build with -D warnings; preserve a failure rather than reuse its output directory.

Deferred execution

The checker requires explicit reviewed EXE and build-receipt SHA256 values. It verifies the successful build, before/after manifests, compile/toolchain receipts, current comparator plus all bound source inputs, and the actual adjacent libunwind.dll before and after execution. It snapshots native source/expected input files before invoking the comparator with a child-only package/Windows PATH. Each run needs a fresh output directory and preserves stdout/stderr, decoded expected/actual JSON, request, before/after inputs and final receipt. It does not stage or run the desktop.

# Define these from the successfully reviewed build receipt, never placeholders:
$exe = '<absolute details-source-oracle.exe>'
$exeSha = '<64-hex reviewed executable SHA>'
$receipt = '<absolute build-receipt.json>'
$receiptSha = '<64-hex reviewed receipt SHA>'

./check.ps1 -OracleExe $exe -OracleSha256 $exeSha -BuildReceipt $receipt -BuildReceiptSha256 $receiptSha `
  -Mode self-check -Output '<fresh self-check directory>'

./check.ps1 -OracleExe $exe -OracleSha256 $exeSha -BuildReceipt $receipt -BuildReceiptSha256 $receiptSha `
  -Mode name -Baseline '<immutable pre-edit incident.arcadia>' -BaselineSha256 '<previously recorded SHA>' `
  -Actual '<saved named incident.arcadia>' -Target '70200000-0000-4000-8000-000000000020' `
  -NewName 'Initial incident report [Details trial]' -Output '<fresh name comparison directory>'

./check.ps1 -OracleExe $exe -OracleSha256 $exeSha -BuildReceipt $receipt -BuildReceiptSha256 $receiptSha `
  -Mode typed -ExpectedProject './expected/after-1.expected.project.json' -Checkpoint '1' `
  -Actual '<saved service-details.arcadia after task1>' -Output '<fresh typed comparison directory>'

The prepared Rust self-check admits both real fixtures, checks all six approved typed checkpoints and the actual service baseline, and falsifies wrong occurrence, extra alias, reordered semantic steps, extra layout change, signed-zero collapse, non-element target, unchanged Name, wrong checkpoint, wrong expected Project identity and unknown expected fields. These assertions are unexecuted until the parent builds/runs the comparator. PowerShell syntax checks are not Rust compilation or fixture self-check acceptance. ./validate-scripts.ps1 also invokes only three pure definitions extracted from the actual builder: exact artifact-hash admission, current LIST metadata admission and canonical source-record selection. The preparation check reads the actual LIST-bound expected-inputs schema as its positive example; synthetic old counts/pin, missing/extra input records, failed/unbound LIST, wrong hashes and missing/unnormalized/duplicate fixture records must reject. It never invokes the builder body, native helper, compiler or comparator.

Scope: complete parsed saved Project and passive parse nonmutation only. No runtime Scene/camera/editor state, actual click/selection, draft recovery, Undo stack, source-writer transaction or native acceptance is established. Core command/history evidence remains the separate published probe; the desktop source-writing and native observations still have to be exercised.