ARCADIA-Studio/harness/release-readiness-audit-20260910.md

Independent release readiness audit — 2026-09-10

Post-audit Linux probe supersedes the readiness hypothesis below: root subsequently authorized one isolated supported WSL2 import. It failed in 1.18 seconds with HCS_E_HYPERV_NOT_INSTALLED, despite the earlier --status omission. No Linux runtime, installation of packages, Cargo or GUI ran. See release-wsl-readiness-20260910.md. The reboot is a verified change; Linux VM creation remains blocked. The recommended next action is a viable external Linux runner or an externally corrected virtualization environment, without retrying denied QEMU modifications.

Codex /root/release_audit. Read-only product/source/platform inspection from HEAD 1797516; the palette worker may change its owned files concurrently. Reviewed PROJECT_GOAL.md, AGENTS.md, current ledgers/coverage, Gitea issue #1 and comments, open PR list (none), Wiki Home and Branch-publication. Only this report is edited. No Cargo, GUI, import, VM, service launch, installation or system modification occurred. Code evidence below establishes implementation seams, not fresh runtime acceptance.

Verdict and highest-value missing outcomes

The release is incomplete. The strongest next move is to complete a normal engineer's creation→allocation→OA/SA transition→save/reopen workflow on the current palette, then use the changed host state to establish Linux runtime access. Another broad semantic expansion is not currently justified by this audit. Historical absence findings for communication means, selective views, completeness warnings and source7 contextual links must not be carried forward as current gaps.

1. P1 — Current basic editing is not accepted. HEAD was published with two palette compilation errors, with repair/build owned by palette_finish. The previous 584-test pass and preview predate the current palette. Release acceptance must establish tool→point→inline name→Enter, Escape without a placeholder, F2 without duplicate history, existing-element placement, explicit allocation and understandable OA↔SA counterparts at normal and minimum dimensions. A compile fix alone does not answer the user's rejection of the earlier authoring workflow. Use the concrete acceptance in release-capella-basic-editing-20260907.md; the behavior auditor independently owns process/scenario criticism.
2. P1 — Linux acceptance has a newly feasible path, but no current pass. The host has rebooted since the failed import. Fresh WSL status no longer reports the old WSL2 virtualization error. No distribution is installed, so neither WSL2 execution nor WSLg rendering is proven. Corrected Linux server tests, current desktop rendering and actual file dialogs/history/reopening remain mandatory. Existing Linux core and cross-build evidence is valuable but scoped to older immutable snapshots.
3. P1 — No coherent first-release distribution is ready. The Windows preview is a development build of an older UI; Linux has no equivalent current final archive pipeline. CI uploads naked binaries. Release artifacts must contain matching optimized desktop/server, runtime inventory, complete examples, licenses/notices, usable documentation, source/toolchain provenance and archive hashes, then be exercised after extraction with development PATH assumptions removed.
4. P2 — Onboarding still describes the rejected UI. guide.rs:190–191 tells beginners to use the Create toolbar, name first and choose position; current design is palette→point→inline name. This is a directly verified mismatch, not merely stale test totals. Update the built-in beginner tutorial and README against accepted controls, then follow the tutorial from Home using only its instructions. It must teach ownership versus allocation versus occurrence reuse and the meaning of a counterpart review.

Current implementation and evidence boundaries

User outcome	Current implementation inspected	What this audit can substantiate
OA and SA engineering model	Three Rust crates; typed Project/Command boundary. model.rs contains OA CommunicationMean, ExchangeCategory, contextual occurrence endpoints/purposes and explicit operation identity. validation/coverage.rs supplies advisory completeness checks.	The older missing-primitive list is superseded. Tests exist in communication_means, coverage_diagnostics, source6_view_contract, source7_contract, release capability/state/scenario/topology suites. No new execution here.
Graphical/source equivalence	docs/language.rst, parser/source project/updater, source identity/nested update tests and shared history. Source7 tests cover nested caller identities, operation direction/allocation, removal repair, reverse omission and migration.	Normative contract and executable checks are substantial. Full parity requires observing the final GUI transaction against complete model and authored source, including comments/modules and saved view state; a JSON serialization check alone is insufficient.
Bidirectional transitions and traceability	Shared counterpart/semantic review and source7 explicit reverse operation omission; typed artifacts with URI/revision/fragment. README/scope describe attachment, ordered and combined review controls.	Existing native records establish selected Windows histories/recovery/reopen paths. Remaining variants must be selected by changed behavior and high-impact failure paths, rather than declaring every GUI row absent or every old pass current.
Programmatic service	oa-server shares core; project/source bundle, query, transaction, transition and artifact routes; ETag-based atomic coupled storage. HTTP suites include source7_contracts.rs, source-project restart/conflict cases, communication limits and port-anchor persistence.	Recorded Windows server 56/56 and OpenAPI 72 fixtures/204 schemas/90 leaves are real bounded evidence. Linux corrected suite has not run. A deployment recipe and local transport suite do not establish a running systemd/container deployment. Public remote hosting is not itself required to prove deployability.
Offline guide/examples	Rust-owned searchable guide.rs, Home walkthrough resolution and examples/release1 with 37 teaching/evidence files. release1_teaching.rs checks exact regeneration, identities, rejection and transition changes.	Guide exists and is offline; current beginner instructions drift. Packaged walkthrough lookup is independent of working directory, but only if staged beside the executable.

Concrete delivery defects rechecked in current files

These findings revalidate the earlier deployability report rather than assuming it still applies.

• README.md:24–27 builds and runs optimized executables directly. home.rs:50–51 enables repository fallback only with debug assertions; home.rs:56–71 otherwise requires examples/release1/project.arcadia beside the executable. Cargo does not stage it. The documented optimized source-run workflow therefore cannot open its Home walkthrough on a fresh checkout. Add a reproducible stage step for the entire example and exercise that exact documented path.
• deployment/Dockerfile.dockerignore does not exclude .local, .env* or model-store data; the documented build uses repository-root context. These ignored-by-Git inputs include large development caches and disposable private QA material. Prefer an explicit context allowlist matching Dockerfile COPY inputs, then verify its inventory before an actual container build. No context transfer occurred in this audit.
• There is only scripts/package-windows.ps1; .github/workflows/ci.yml:22–29 uploads executables without examples/notices. Linux staging/archive and runtime dependency documentation remain independent release work. The Docker runtime stage also copies only the server executable, so its redistributable notice policy needs closure.
• Windows packaging intentionally rejects unknown DLL imports, including VC redistributables (package-windows.ps1:87–117), whereas README recommends ordinary MSVC builds. Choose and actually verify static CRT or implement a documented redistributable strategy; do not weaken the import allowlist. This is an unresolved packaging recipe, not a newly observed MSVC link failure.
• package-windows.ps1:124–137 copies repository README and only two harness reports. README links to STATE and native fixtures outside that closure. Ship a package-specific entry page or a bounded documentation closure, and check local Markdown links against extracted archive paths.
• docs/server.md:3 still says schema 5 while the model/source is 7. README/scope link a 6 September “current” coverage report whose missing items were later implemented. Promote a concise current acceptance matrix instead of making the new engineer reconcile several contradictory chronological paragraphs.
• Both Git remotes are GitLab/Gitea; only GitHub Actions configuration exists. There is no evidence of an active runner on either configured host. The workflow follows stable and does not explicitly check declared Rust 1.90. Root should settle the supported runner/provider and compiler matrix before treating configured CI as a release gate.

Changed Linux environment and exact supported next probe

Fresh read-only observations at this audit:

• Windows 11 Pro build 26200, VMware20,1; LastBootUpTime = 2026-09-10T05:07:04.5-07:00, HypervisorPresent true, total RAM approximately 8 GiB. The earlier pending-restart statement is historical.
• wsl --version: WSL 2.7.13.0, kernel 6.18.33.2-2, WSLg 1.0.73.2. wsl --status: default version 2 and a WSL1 optional-component warning; the old WSL2 virtualization failure text is absent. wsl --list --verbose: no installed distributions. This does not prove nested virtualization or GUI execution succeeds.
• Only wslservice was present among WSL/QEMU/Docker/Podman processes. Docker/Podman/SSH/QEMU were not found on the current PATH; task-local QEMU/cross-build assets remain. This is not a claim those programs are absent everywhere.
• One snapshot during the palette build had 2,692,384 KiB free RAM and 9,852,825,600 bytes free disk. Recheck before a new resource lease; do not concurrently start another compiler or memory-heavy guest.

The preserved official Ubuntu WSL image is .local/linux-wsl/ubuntu-24.04.4-wsl-amd64.wsl, 391,541,571 bytes (about 373.4 MiB). Fresh SHA256 is 9b2f7730dc68227dd04a9f3e5eab86ad85caf556b8606ad94f1f29ff5c4fd3f5, matching retained SHA256SUMS and the recorded HTTPS verification in release-linux-validation-options.md:120. The Canonical release directory identifies this exact WSL image. No new OpenPGP verification is claimed.

After the palette worker releases resources, root can verify the destination is absent and run one bounded supported import:

wsl.exe --import ArcadiaLinuxQA C:\Users\User\Documents\Git\ARCADIA-Studio\.local\linux-wsl\ArcadiaLinuxQA C:\Users\User\Documents\Git\ARCADIA-Studio\.local\linux-wsl\ubuntu-24.04.4-wsl-amd64.wsl --version 2
wsl.exe --list --verbose
wsl.exe -d ArcadiaLinuxQA --exec /bin/sh -lc 'uname -a; cat /etc/os-release; df -h /; free -m; printf "%s\n" "$DISPLAY" "$WAYLAND_DISPLAY" "$XDG_RUNTIME_DIR"; ls -ld /mnt/wslg'

The import registers one task-named distro and creates its disk under the task directory; it is not purely a file extraction. Use a fresh name/path if either exists; do not overwrite/unregister an existing distro. Microsoft documents the tar import command and WSL2 option. The earlier local import failed before registration with HCS_E_SERVICE_NOT_AVAILABLE; the changed host justifies this supported probe, without retrying the rejected QEMU kernel workaround.

Resource estimates, not measurements: allow roughly 2 GiB for the base expanded distro, another 0.5–1.5 GiB for graphics/portal runtime packages, and preserve at least 5 GiB host free disk. A 5-minute import/bootstrap checkpoint should establish boot/readiness or produce a specific failure. Current free space is tight for an additional full native Rust dependency/target tree; prefer an existing ELF runtime probe before choosing native compilation or copying caches. Recheck actual df, installed package state and simulated package sizes before installation. Do not change global .wslconfig solely for this probe or terminate unrelated distributions.

WSLg and the preserved cross-built GUI

The candidate .local/cross-linux-qa/gui-runs/20260907T1025486926611Z/package/arcadia-studio is 72,953,296 bytes, recorded SHA256 330A3872D48EBF24AD21E6D4FA13CB6098BEBB3CB7FF82A2E082925CCF3DD346. Its retained ELF inventory is x86-64 PIE, interpreter /lib64/ld-linux-x86-64.so.2, GLIBC requirements through 2.28, and only libc-family direct NEEDED entries. The package has all 37 lesson files. Retained status explicitly says runtime NOT RUN; this binary predates the new palette.

Inference: it is a plausible Ubuntu 24.04/WSLg runtime candidate. WSLg supports Linux X11/Wayland apps on WSL2 and is installed here; Iced enables both backends. Microsoft GUI prerequisites support the route, not success of this application. Start with file, ldd, exact hash readback and display/socket inspection in the imported distro. A successful ldd is insufficient: WGPU/winit load graphics/window libraries dynamically, and rfd needs working DBus/portal dialogs.

Inspect/install only missing runtime dependencies: X11/Xcursor/Xi/Xrandr/XKB, Wayland client/cursor/EGL, Vulkan loader and Mesa Vulkan drivers, plus a session bus and xdg-desktop-portal with a working backend for file dialogs. Use the exact installed lavapipe ICD path when testing software Vulkan, for example WGPU_BACKEND=vulkan VK_DRIVER_FILES=/usr/share/vulkan/icd.d/lvp_icd.x86_64.json, after verifying the file exists. No full Linux desktop environment is needed just to use WSLg. Copy the entire package into the guest for local-filesystem Save/reopen tests; preserve the snapshot and hash. A passed old-ELF launch would discharge only environment viability. Rebuild current source and rerun acceptance for release. Record whether X11 or Wayland was exercised; do not claim both from one launch.

Verification strategy on the final integrated candidate

1. Windows authoring first. Root serializes Cargo after repair; focused architecture tests followed by cargo test --locked -p oa-desktop --bin arcadia-studio -- --test-threads=1, formatting and strict Clippy. Freeze source and binary hash before native work. Run the basic editing story, current behavior fixes and tutorial at normal/minimum dimensions. Capture full model/source before/after, Undo/Redo equality, save/reopen and representative cancellation/invalid-draft recovery. Do not count screenshots alone as persistence proof.
2. Shared semantics and HTTP. Run cargo test --locked -p oa-core --all-targets -- --test-threads=1 and cargo test --locked -p oa-server --all-targets -- --test-threads=1 on the candidate, plus crates/oa-server/tests/semantic_schema.py --check --validate. Strictly render both reST specifications and compare generated HTML. Verify teaching regeneration and full multi-file examples without mutating historical oracles. Run same core/server commands under explicit Rust 1.90 on Linux when capacity permits. Corrected HTTP preparation-phase test must pass on Linux with unchanged production deadline/assertions; no load-dependent weakening.
3. One parity story across all surfaces. In a commented source bundle create OA participants/activities, interaction and communication means; allocate explicitly; derive/review SA boundary/functions; add typed operation/scenario and a reused process occurrence; attach an artifact. Modify graphically, edit source, apply an equivalent REST transaction, fetch through desktop, then reject stale ETag and structurally invalid edits without changing accepted model/source/disk. Restart the actual service and compare the coupled envelope. This tests integration of existing semantics rather than adding new primitives.
4. Actual Linux app and service. After WSL bootstrap, execute current optimized Linux desktop through WSLg and service against an isolated local guest data directory. Include native open/save dialogs, Unicode/path-with-spaces, multi-file source, counterpart review, direct behavior edit, Undo/reopen and minimum-window selection. Exercise configured authentication, process lock, restart and backup/restore per server docs. WSLg is real Linux user-space runtime evidence with a specifically named display environment, not evidence of every Linux GPU/session.
5. Release artifacts and independent closure. Run cargo fmt --all -- --check, cargo clippy --locked --workspace --all-targets -- -D warnings, workspace tests and cargo build --release --locked --workspace --bins with recorded target/compiler. Package Windows/Linux and the documented server deployment path. Verify clean extraction, executable equality, runtime libraries, complete lessons, notices, relative links and checksums. Have a fresh reviewer use the final matrix and produced artifacts; close material findings. Keep logs tied to source/binary hashes and avoid aggregating historical reruns into a misleading single green total.

Root decisions required

• Assign the next exclusive resource lease to bounded WSL import/readiness after palette compilation; decide native Linux compilation only after actual disk/RAM measurements. If supported import still fails, retain its precise error and request a viable Linux runner instead of revisiting denied boot modifications.
• Select and document Windows distribution toolchain/CRT and Linux runtime baseline. The existing GNU/LLVM preview path and Ubuntu 24.04 acceptance basis are reasonable candidates, not proof of optimized MSVC/all-Linux support.
• Assign small packaging/docs corrections independently of semantic implementation, and choose an actually active CI provider. These are reversible engineering choices; no user scope relaxation is needed.
• Keep first-release OA/SA acceptance broad enough to answer the user's workflows. This audit found no reason to introduce LA/PA, simulation or Capella file compatibility; equally, it found no basis to relabel current native/platform/delivery gates as optional merely because semantics and test volume are extensive.