test(native): automate packaged-state release qualification for built Tauri desktop artifacts

[qnbs]

CURRENT AUTHORITATIVE STATE — post-v1.29.1 durable harness — 2026-09-29

This issue remains non-blocking for the current v1.29.1 recovery.

V1_29_1_BLOCKER = NO
START_AFTER = #872 v1.29.1 VERIFIED

The #910 review adds two explicit future packaged scenarios to the acceptance surface:

• unmodified real v1.28.8 CURRENT profile → exact candidate open/save/quit/reopen with content/identity/hash preservation;
• true fresh isolated profile → create/save/quit/reopen with durable identity/content proof.

These are separate from FUTURE, UNSUPPORTED_OLDER, legacy migration, and second-instance checks. The current release uses the bounded manual protocol; this issue automates the durable post-release form.

---

Linear planning mirror: QNB-144
Release relation: #872 · post-v1.29 only · V1_29_BLOCKER = NO

---

Purpose

Create the durable post-v1.29 owner for automating packaged-desktop qualification against already-built exact-SHA Tauri artifacts.

This issue exists because the v1.28.7 → v1.28.8 cycle demonstrated a release-class failure that ordinary source tests and successful native compilation did not catch: first boot of a real packaged app with persisted desktop state from an older/other build could enter a recovery dead end.

For v1.29 itself, the release owner #872 will reuse the bounded real-artifact technique already demonstrated for v1.28.8 and may supplement it with a maintainer-run target-environment protocol. Building this durable harness is not a v1.29 blocker.

V1_29_BLOCKER = NO
START_AFTER_V1_29 = YES

Historical trigger

v1.28.7 shipped after green CI and a successful pre-tag native dispatch, but the published Linux AppImage exposed a persisted-state startup defect: an active project classified as FUTURE / UNSUPPORTED_OLDER could leave the user in a Retry-only loop.

#804/#807 fixed the product behavior and v1.28.8 was cut as the hotfix.

The v1.28.8 release qualification then established a useful real-artifact Linux method using:

built AppImage
+ isolated HOME/XDG_* profile
+ --appimage-extract-and-run where required
+ headless Xvfb
+ real XTest click-through
+ FUTURE fixture
+ UNSUPPORTED_OLDER fixture
+ refused-project hash preservation
+ active-project marker checks

That technique is strong release evidence, but it is not yet a durable first-class native harness.

Goal

Provide a maintainable qualification lane that can consume the exact artifact produced by an existing candidate/native-build run and exercise release-critical persisted-state/recovery behavior without touching real user data.

Evaluate the smallest reliable implementation. tauri-driver / WebDriver is one option, but it is not prescribed. Reuse existing tooling if it can prove the required contracts with less complexity.

Artifact identity contract

The harness must never silently rebuild a second binary and call it the candidate.

Record at least:

SOURCE_SHA
BUILD_WORKFLOW_RUN_ID
ARTIFACT_NAME
ARTIFACT_HASH
HARNESS_RUN_ID
FIXTURE_ID
FIXTURE_HASH
RESULT

If the consumed artifact does not map unambiguously to the intended SHA/build run, fail closed.

Isolation and safety

The harness must never use or mutate a maintainer's actual WorldScript profile.

Each run gets disposable, explicitly recorded equivalents of:

• HOME;
• XDG_CONFIG_HOME;
• XDG_DATA_HOME;
• XDG_CACHE_HOME;
• other platform-specific app-data roots where applicable.

Cleanup is restricted to those run-owned paths.

No broad rm -rf against real user directories.

Required scenario A — FUTURE Safe Open

Start the packaged app with a disposable profile whose active project is a real FUTURE-schema fixture.

Prove:

• correct recovery classification/copy;
• Safe Open reaches a usable portal/workspace shell;
• no Continue path re-admits the refused project;
• refused project bytes/hash are unchanged;
• active-project marker remains on the refused project until a new admitted project is successfully written;
• after the new write, the marker advances only to the admitted new identity.

Required scenario B — UNSUPPORTED_OLDER Safe Open

Use a separate fixture, not the FUTURE fixture relabeled.

Prove the same preservation and marker invariants plus the distinct expected recovery classification.

Required scenario C — legacy migration + reopen

Start from a real supported legacy desktop fixture and prove:

legacy source
→ admitted migration
→ canonical durable representation
→ close packaged app
→ reopen packaged app
→ exact relevant content survives
→ no silent modeled-field loss
→ no source corruption

Capture before/after identity/hash evidence according to the migration contract.

Required scenario D — stale writer / second window

Do not build a large new multi-window framework merely to increase native coverage.

First inventory what existing lower-level/unit/Playwright contracts already prove for the #553 stale-writer and second-window-revert classes.

Add packaged-native interaction only where it supplies unique signal that cannot be obtained below the packaging boundary.

Evidence-plane boundaries

This issue owns packaged Tauri functional qualification.

It does not replace:

• test(prod-e2e): add risk-based functional canaries against the built production bundle #712 — exact built web dist functional canaries;
• test(e2e): harden the required Playwright gate, locale-safe selectors, sharding policy and web/native boundaries #736 — ordinary browser Playwright gate architecture;
• native: promote macos-15-intel qualification lane into the release matrix #507 — Intel macOS target admission/promotion;
• release(native): establish platform code signing, notarization, artifact identity & rollback trust #574 — OS-native signing, notarization, artifact trust and rollback;
• ci(vercel): prune stale Preview deployments after PR closure #627 — Vercel deployment retention;
• DA-02 residual risk: cross-tab writer coordination for SW-update reloads is heuristic, not authoritative #518 — the shared service-worker reload-flush/cross-tab coordination residual.

Where fixtures or semantic scenario descriptions can be shared, share them without collapsing these authorities.

Platform scope

Initial implementation may be Linux-first if that is the smallest way to preserve the v1.28.8 real-artifact evidence class.

Any Windows/macOS expansion should be justified by unique native semantics and CI feasibility, not by a requirement to duplicate the same React behavior on every OS.

OS-native signing/notarization is not an acceptance criterion here.

Failure semantics

Distinguish at least:

PRODUCT_REGRESSION
HARNESS_FAILURE
ARTIFACT_IDENTITY_MISMATCH
FIXTURE_INVALID
ENVIRONMENT_LIMITED
PLATFORM_UNSUPPORTED

An environment limitation must not be reported as a passing product qualification.

CI/admission design constraints

A future automated lane should be:

• explicit/manual or release-qualification scoped until stability is proven;
• secret-minimal;
• read-only except for run-owned artifacts/profile paths;
• bounded in runtime;
• artifact-producing enough for diagnosis (logs/screenshots/state/hash record);
• incapable of publishing releases or mutating branch protection;
• incapable of touching production credentials unnecessarily.

Do not make it a required PR check before it has accumulated stability evidence.

Acceptance criteria

• exact built-artifact identity is proven and recorded;
• disposable profile isolation is fail-closed and tested;
• FUTURE Safe Open scenario is deterministic;
• UNSUPPORTED_OLDER uses a distinct fixture and is deterministic;
• refused project bytes remain unchanged in both refusal scenarios;
• active-project marker behavior is verified;
• legacy migration survives close/reopen with no silent field loss;
• packaged stale-writer/second-window work is limited to unique packaging signal;
• failures produce sufficient diagnostic artifacts;
• real user data and credentials are never required;
• the lane does not create/push tags, publish GitHub Releases, change production, or alter repository protection;
• v1.29 is not delayed to implement this issue.

Sequencing

#872 / v1.29 publish + post-release truth sync
→ review the actual v1.29 packaged-state evidence
→ re-baseline fixtures and artifact contracts
→ implement the smallest durable harness
→ accumulate stability evidence
→ only then decide whether any part belongs in a required release gate

Related: #872, #804, #807, #712, #736, #507, #574, #518.

[qnbs]

v1.29.1 review-derived acceptance refinement — 2026-09-29

The current #910 review exposed two packaged qualification cases that should become explicit first-class scenarios in this durable harness after v1.29.1:

Scenario E — real previous-release CURRENT profile

Consume an unmodified profile produced by the published v1.28.8 AppImage and launch the exact candidate artifact against it.

Prove at minimum:

• CURRENT project opens normally;
• title/manuscript and modeled identity survive;
• no unintended migration/refusal occurs;
• any save writes only the admitted project;
• quit/reopen preserves the same content and identity;
• before/after hashes and active-project marker are recorded;
• real user data remains untouched.

Scenario F — true fresh-install save/reopen

Use a completely fresh isolated profile with no prior WorldScript state.

Prove:

• first launch succeeds;
• create a new project with distinctive content;
• durable save completes;
• project identity/marker/file hashes are recorded;
• quit and reopen the exact packaged artifact;
• project reopens with the expected content/identity;
• no fallback/reconstruction silently changes state.

These are separate from FUTURE / UNSUPPORTED_OLDER / legacy migration / second-instance checks.

A release gate should not be a label plus “hashes/screenshots”; the harness/protocol must define setup, exact artifact/profile identity, executable steps, expected transitions, evidence and PASS/FAIL criteria.

Sequencing remains unchanged: #906 is post-v1.29.1 durable automation and is not a blocker for the current recovery cut, whose bounded manual protocol is owned by #872/#910.

[qnbs]

v1.30.0 promotion — R-15 Gate 6 evidence owner — 2026-10-01

This issue is now a direct evidence dependency of #924 (R-15 Gate 6) and release milestone #926 (v1.30.0).

The harness should be extended/reused to consume exact-SHA packaged artifacts for the at-rest qualification matrix rather than creating a second R-15-specific packaged harness.

Required unique signal for the milestone includes, as platform semantics require: secure-store available/unavailable behavior, upgrade profiles, migration/rekey crash+resume, corrupted/substituted records, durable-write interruption, writer fencing/autosave races, restart/reopen, and exact artifact/fixture identity.

This promotion does not mean every scenario must be duplicated on every OS; preserve the issue's unique-signal principle. It does mean packaged secure-storage evidence is now release-critical before Gate 7 / v1.30.0.