[INSTALL-06] [P1] Gate publication on the actual installer and archive journey for every shipped OS #556

Goal

A green release must demonstrate that the exact bytes users download can be installed and used from a fresh directory, not only that the source can compile.

Priority: P1 · Classification: Verified integration-test gap and stale test expectations

Reviewed baseline: main 56ad6438653f, 6 October 2026. Published distribution inspected: v0.8.0 (CLI build commit 615e501). Recheck these installation surfaces against the current branch before implementing.

Current behavior and evidence

CI already has a useful installed-journey release blocker, but it runs cargo install --locked --path . on Ubuntu. Both packagers also unpack their own archive and smoke --version/check/run on the rich build host.

The separate ignored provisioned_archive_cli_and_daemon_work_outside_checkout test is not selected anywhere in ci.yml. It provides a useful owning harness but needs repair before promotion.

Its calculator fixture expects a small older file inventory and graph schema v10. The actually downloaded v0.8.0 starter contains AGENTS.md and src/core.spx in addition to the older entries. The old single-file graph invocation against src/app.spx also refuses the current multi-module starter with SPX-G172 (source module imports require Workspace Semantic Graph resolution). Merely enabling the ignored test or changing its schema assertion will not establish current installation coverage.

Current tests do not exercise the new bootstrap's user-prefix/PATH lifecycle because that bootstrap does not yet exist. This issue adds those distribution boundaries without re-creating the broad language/agent test suite.

• Existing source-installed journey
• Journey builds the standalone compiler from the checkout
• Unix same-host archive smoke
• Windows same-host archive smoke
• Existing ignored archive/daemon journey
• Stale scaffold inventory and schema expectation

Implementation scope

1. Update the existing release_archive_product_v1 owning harness to the actual supported starter/product contract, preserving independent assertions about meaningful behavior. Refresh stale inventories deliberately. Adapt the old graph step to an admitted project-aware route or a standalone emitted module such as src/core.spx, with correct schema/identity expectations. Do not solve the mismatch by removing negative cases or accepting arbitrary output.
2. Run a post-package install matrix for each advertised release target using the exact retained archive and scripts from [INSTALL-02] [P1] Add a one-command Unix installer with version pinning and clean removal #552 and [INSTALL-03] [P1] Add a per-user PowerShell installer for Windows #553. Put the new gate between artifact production and public publication, preserving the original exact-tag gate.
3. Avoid a dependency cycle: the source release-gate currently precedes release-artifacts. Add a post-artifact install gate required by publication; do not make the source gate depend on artifacts that already depend on it.
4. Before publication, supply the exact candidate bytes through a local fixture endpoint or staged candidate transport exercising the installer's normal resolution/download path. Stage the same real verification metadata before the consumer gate, or consume the existing producer per-target attestation bundles, then publish the already-tested bytes. Aggregate manifest/provenance/signature material currently generated in publish-release must be staged earlier if that path is used. Do not add a skip-verification installer mode or present synthetic signing fixtures as production evidence. Do not require an already-public release to test a release that is not yet allowed to publish. Include a bounded read-only post-publication URL check for discoverability, without automatically deleting a release.
5. Use a fresh user-owned prefix and working directory outside the checkout. Verify that resolved executables come from that prefix and hashes match the chosen archive, then run --version/new/check/test/run. Exercise the daemon with its supported bounded protocol handshake/start/stop, not semapraxd --version.
6. Keep the basic runtime independent of Rust/Cargo, Clang, Node, source fixtures, model credentials and a GUI editor. An isolated container/VM or sanitized runtime account is appropriate; a PATH-only check on a rich host must be described accurately.
7. Cover paths with spaces, same-version reinstall, upgrade, failed verification and ownership-safe removal. The bootstrap unit tests can own detailed failure combinations; the release gate needs a small real happy path and one decisive damaged-artifact control.
8. Retain exact tag/commit, archive digest, install route, OS/runtime baseline and journey outcome. Fail publication on a failed install; do not rebuild a substitute binary to make the consumer test green.

Acceptance criteria

• Each currently published target passes the actual artifact → installer → PATH → starter-project journey before its release becomes public.
• The existing source installed-journey remains active; the new stage extends it at the distribution boundary.
• The ignored archive test's current scaffold expectations are valid, and a deliberately damaged/wrong executable is rejected.
• CLI identity matches the expected version/commit; daemon identity is established by the signed archive/receipt and supported protocol behavior.
• The Windows path-with-spaces and Unix non-default-prefix cases are exercised with no preexisting Semaprax installation resolving ahead of them.
• Installer failure or partial content blocks publication; workflow dependencies remain acyclic and cannot skip the new blocker.
• Native/web/compiler-host capability tests retain their own prerequisites and are not falsely represented as part of the dependency-free beginner path.

Verification

• Run existing archive-product/unit gates and the new matrix against candidate bytes from the exact tag.
• Use a source-checkout binary with a different digest as a negative control to prove the consumer gate cannot accidentally select it.
• Test workflow topology and the failure propagation into publish-release using the existing release-publish/reconcile fixtures.

Existing issues and boundaries

• #144 is the implemented source-installed journey; extend it rather than reopening its original scope.
• #167 owns the exact-tag state machine. The additional gate must fit that DAG.
• #444 and #454 already have targeted distribution/harness smoke evidence; reuse appropriate checks.
• #335 is an independent live-agent demonstration and is not a prerequisite for this basic installation gate.

Implementation dependencies

• [INSTALL-02] [P1] Add a one-command Unix installer with version pinning and clean removal #552
• [INSTALL-03] [P1] Add a per-user PowerShell installer for Windows #553

Delivery notes

Implement in the existing owning modules and test harnesses. Follow AGENTS.md and the relevant release/editor contracts. Keep fixes focused, preserve unrelated behavior, and attach the actual verification results. Do not replace existing signing, publication, project generation or harness setup with a second system.