# Allocation drawing native recipes — preparation only Candidate source 301126f6098286bf440c1bd1b1ed685753984723; gates must pass before staging. No stage, evaluator, converter, compiler or GUI execution was performed to prepare these recipes. They implement the predeclared fixture/relations in ../baseline.draft.json and ../relation-contracts.json. This plan supersedes the draft fixture README's `working/allocation.arcadia` destination: use **working/allocation-trial.arcadia** as the unique declared entry. Allocation declarations in this fixture use the existing performer modules. No fixture data or expected relation semantics were changed. ## Admission and stage Copy these six files into a NEW final native root. Parent supplies admission.json with approved_for_staging=true, full source_commit, repo, gate_summary, gate_receipts (all mandatory raw source/context/result/log/config/relocation records), artifacts mapping arcadia-studio.exe/attachment_snapshot.exe/libunwind.dll to preserved final gate records, baseline, relation_contract, native_plan (this README), and converter_admission (the reviewed #31 converter admission). Records use path/bytes/sha256. Then `python FINAL_ROOT/stage.py --admission FINAL_ROOT/admission.json`. Never stage into preparation or overwrite an earlier root. Admission requires the exact clean source and all six same-pin desktop gate steps with fixed argv/cwd/context/input equality. GUI and attachment_snapshot come from that final gate's preserved artifacts. The separately reviewed converter remains source-attributed to17f1f89fef4a6bf520f4b09a2116548b967d030e; stage verifies identical Git trees for crates/oa-core, Cargo.toml and Cargo.lock between converter and candidate. It copies the preserved converter and raw build/review receipts, records relocation and original source attribution, and binds only packaged execution bytes. This is reuse of a validated identical core, not a claim that the converter was rebuilt at the admitted candidate. Converter SHA expected from prior reviewed admission:70743dfd3e0d6ab077bb2db5447d74fe7884b010bb48913525436385c05c8c70; admitted LLVM runtime aa282fa47bb2c4e210cea5e470cdbdca58568f0be0bc73e404d86ab9cd95ef6a. Stage uses the final matching attachment_snapshot to canonicalize B and validate predeclared O/OS with reserved relation IDs. Complete Project equality must hold without normalization of any declared relation field. B/O/OS expected templates, contract, plan, raw source map, provenance, recipes and package are frozen in the manifest before launch. Stage fails rather than guessing when admission, signatures or schemas differ. Private profile and unrelated cwd start empty; no mutable shared-target binary is bound. ## Actual workflow and fixed oracle Launch `pwsh -File FINAL_ROOT/launch.ps1 -Run 1`. Open working/import.json through UI; Save As working/allocation-trial.arcadia before first B checkpoint. Save may produce multiple modules: every checkpoint captures all .arcadia files and verifies their direct include closure. The reused converter reads only this snapshot, refuses loading/compile errors, migration or UUID stabilization, validates the Project and requires its self-contained formatted source to roundtrip exactly. The same-pin attachment_snapshot evaluates that self-contained source. The checker compares the complete Project to frozen semantics, then rechecks original/snapshot inventories and immutable inputs. Use fresh checkpoint directories, e.g. `python FINAL_ROOT/check.py --expected B --checkpoint runs/run-01/checkpoints/00-baseline`. Expected values are B, O, OS only. First O may bind one canonical UUIDv4 for the exact declared OA Allocation, absent from every baseline identity. First OS requires the already bound OA identity and may bind one distinct fresh UUIDv4 for the exact SA Allocation. All aliases, names (including arrow), description/body/endpoints and all other Project data are fixed. There is no position tolerance, new element, placement or parent edit. Identity files are create-new only, after complete bundle/Project success. B and O after Undo exclude the later relations while retained bindings remain fixed for Redo/reopen. Any failure after checkpoint capture begins permanently writes UNACCEPTED.json; preflight admission/path failures refuse before capture without creating a checkpoint or quarantine; stop, preserve evidence and bindings, never delete/relearn them. Sequence: B save; OA Allocation palette→Rescue team→Assess incident, save O; Undo/save B; Redo/save O; start Duty officer→occupied Assess incident and observe refusal/highlight behavior, Escape/cancel, save O; select SA Containment, Allocation→Rescue system→Evaluate report, save OS; Undo/save O; Redo/save OS. Inspect OA/SA relation details and unchanged placements. Close normally, then Run2 opens the same source, Save/check OS and closes. Native captures establish actual two-click direct drawing, eligibility/cancel feedback and save/reopen; automated tests cover other invalid targets, stale/draft guards, mixed Traceability and allocated-work nesting. Do not claim those extra workflows were exercised natively. Launch/normal-close receipts now inventory the complete current saved .arcadia bundle and both relation bindings. Repeat launch rejects quarantined trials, rehashes both prior relation bindings and requires their exact inventory to match (including absence), requires the full bundle to equal the prior close, and chains exact launch/PID/start/close records. Deleting a relation binding cannot authorize relearning on a new run. Checkpoint and lifecycle bundle inventories concern saved bytes at observation times; no atomic snapshot or held-preview claim is made. Parent must compare the final close bundle to the last accepted checkpoint and record normal-close cause separately. Missing saved entry causes observer failure, not proof of application crash. Capture helper is `captureAllocation(name,note,freshSkyState)` with globalThis.allocationRunRoot set to the actual numbered run. It records observed UI/process identity and current default entry hash; that hash alone is not the complete bundle. Checkpoint and launch/close inventories supply the wider byte evidence. Never reuse stale Sky state or infer semantic acceptance from a screenshot. ## Pre-execution review Source/AST/PowerShell syntax checks only; final gate success, actual B/O/OS stage validation, new-manifest review and native observations are still required. The existing fixture's placeholder candidate metadata is explanatory; the admitted source pin and frozen exact Project templates are authoritative for this run. Keep earlier failed histories separate and unmodified. No publication/integration/release or other-platform claim follows from these recipes.