ARCADIA-Studio/harness/release-deployability-handoff-audit-20260907.md

Deployability/source-handoff audit — 2026-09-07

Read-only code/docs/package inspection; no build, Cargo, VM, GUI input or change to the rejected boot action. Frozen when root redirected work to basic diagram usability. Findings below concern concrete handoff paths, not the already-recorded Linux GUI/boot acceptance gap. No fixes applied.

Priority	Exact seam and evidence	Minimal correction
P2	README.md:24–27 tells an engineer to build release and run target/release/arcadia-studio; crates/oa-desktop/src/home.rs:50–51 allows the repository example fallback only with debug assertions. home.rs:56–71 otherwise looks beside the executable. Cargo's documented build does not copy the lesson there. A normal fresh optimized source run therefore cannot open the Home water-pressure walkthrough, although debug source runs can.	Stage the whole examples/release1 directory beside the optimized binary and document that step, or provide an explicit safe source-run lookup policy. Include all37files/evidence; source-only Save As is insufficient. Pin release-mode resolution expectations.
P2	deployment/Dockerfile.dockerignore:1–10 excludes .git, target/dist and some caches but not .local, .env* or model-store. docs/server.md:74 builds from repository root. Those paths are Git-ignored, which does not make them Docker-ignored; current .local contains large toolchain/QA artifacts and disposable guest keys. No Docker transmission was performed.	Add the intended private/cache/data exclusions, preferably use a minimal allowlist matching Dockerfile COPY inputs; test the resulting context file inventory without running a container. Docker context rules describe exclusion before transfer.
P2	No scripts/package-linux* exists. .github/workflows/ci.yml:22–29 uploads only desktop/server executables, while deployment/Dockerfile:14–18 also installs only the server executable. Neither path stages this project's license, Rust/dependency notices, examples or release runtime inventory. The current Windows collector/package path does those jobs; Linux final-package handoff is unfinished, independently of whether the binary runs.	Add a reproducible Linux staging/archive path that takes already-built inputs and exact source/toolchain provenance, includes matching notices and the complete example, records ELF dependencies/ABI baseline and validates archive contents. Reuse the reviewed notice policy rather than treating bare CI binaries as final distributions.
P2	scripts/package-windows.ps1:87–127 intentionally refuses unknown imports, including VC redistributable DLLs; MSVC has no runtime-source input. But docs/windows-packaging.md:10–12 presents ordinary README MSVC release outputs as the standard packaging path, without selecting a static CRT. Rust MSVC normally uses the dynamic CRT; Rust's target source documents implicit vcruntime/ucrt linking. This is a source-backed expected refusal, not an observed current MSVC build/import failure.	Make the supported MSVC release recipe explicit: either verify a targeted static-CRT build and keep strict import checks, or implement provenance/notice-bound VC redistributable staging. Do not merely allowlist those DLLs as Windows system files. Verify actual optimized MSVC imports before claiming closure.
P2	scripts/package-windows.ps1:135–137 includes only two harness reports, but copies the repository README unchanged. Inspecting the actual preview README found nine broken relative links (including repeated harness/STATE.md, native tutorial fixtures, journal review and source7 decision). The packaged Windows guide/server links themselves resolve.	Supply a package-specific README/entry page with valid included evidence links, or include a bounded reachable documentation closure. Add an archive-relative link check. The existing package's binaries/runtime integrity is unaffected.
P3	docs/server.md:3 still says schema5, despite current source/schema7. README.md claims Windows/Linux CI is configured, but only GitHub Actions exists and the actual origin is GitLab; no .gitlab-ci.yml exists. The workflow follows stable and does not test declared1.90 explicitly. These are documentation/automation coverage gaps, not proof of a source build failure.	Correct current schema wording, state the actual CI provider/activation requirement, and add an explicit MSRV job when CI ownership is settled. Preserve historical verification scope.

Paths inspected without another defect established

Docker source COPY now includes build/, resolving the earlier Windows-manifest include omission. The server build avoids desktop renderer compilation; docs/openapi.json is copied for the production include. The systemd unit's binary/data/token paths agree with its installation text. The current Windows package stages the full lesson and hashes/readbacks its contents, and its START-HERE correctly says source checkout is required for Cargo/Docker instructions. The notice collector refuses missing source/supplement/runtime evidence before creating the output claim; that refusal should be retained.

Optimized MSVC imports, a fresh minimal Docker build/context and an actual Linux package were not executed in this audit. The current development previews and earlier runtime results do not establish those unrun paths. Root deferred these fixes when prioritizing the user's basic diagram creation/placement feedback.