[Task] Prove persisted SQLite upgrades against the accepted stable 3.10.0 candidate #8639

Program: #8194
Parent: #8219
Related: #8220, #8216

Outcome and readiness

Prove the accepted stable 3.10.0 candidate can migrate and resume the existing persisted SQLite fixture from released 3.8.4 and 3.9.0 on .NET 8, 9 and 10. Reuse the accepted six-cell lifecycle from #8629/#8632, preserving its original proof-artifact adapter and guards. The previous proof-version results cannot certify these different stable bytes.

Accepted through PR #8644, merged into codex/elsa-integration-program as 306cbaf5465f7d54d2876b5e4b8a4b6e3a12824b. Its merge tree exactly matches reviewed head 7435c03446c4a748f5aa8bf5238b0f9534792ff3, with unchanged first parent 93d9135deacafa60c94e0e39b624cf738e1d16dd. Lead acceptance and exact-head gates bind the full hosted matrices, independent artifact/database audits and fresh original-candidate availability. Required input #8631 remains accepted; the original failed local path-alias attempt remains recorded separately. #8643 is next for paired browser compatibility; #8636 remains blocked on its recorded ownership decision.

Accepted input identity

• Source: ba5b348aa2414fdf7c19d9d8806e87b7c91a4205; version: 3.10.0.
• Candidate workflow run: 37456860080, attempt 1.
• Original artifact: 11412848210, name consolidated-candidate-ba5b348aa2414fdf7c19d9d8806e87b7c91a4205-37456860080-1.
• Original archive SHA-256: ace85260c3389916fe3dcd7ee9cd5b766e4030dd6cee13c7f89285ada79c944f; size: 92659861 bytes.
• Expiry: 2026-11-05T12:13:30Z. Recheck live identity/availability before execution and acceptance. An expired/deleted original is not a usable candidate.
• Pre-upload manifest SHA-256: df25b11556bbf21210cfc33ef02f3d0841af6316a20ece69422c7b8143a11820. Original envelope fields: schema: 1, published: false, retention_days: 30, retrieved_at: 2026-10-06T12:13:47Z. The verbatim original envelope file has SHA-256 ef5e772020b151089b64b90b819d36ff371ed5e65212f7fdc7b2934d9860ddda.
• Bind the separate accepted post-upload envelope and pre-upload manifest hash from [Task] Prepare a nonpublishing consolidated 3.10.0 candidate #8631; preserve the original envelope as historical retrieval evidence and record each new live retrieval observation separately. Do not fabricate, relabel or replace the original archive or envelope.

Scope

1. Refactor only the necessary shared matrix runner seams to accept an explicitly validated target identity, rather than classifying target provenance by equality with the old PROOF_VERSION. Keep the current proof constants, verifier, default command, original archive pins and workflow behavior intact. Baseline package versions, NuGet.org origin/source-commit checks and lifecycle assertions remain strict.
2. Add a thin stable-candidate entrypoint using the existing candidate envelope/archive/file verifier. Consume the accepted identity above and original bytes; never invoke restore/build/pack for Elsa source packages, repack/relabel them, or use a source-project fallback. Building the isolated package-only fixture is expected.
3. Reuse the C# suspend → normal migration/resume → fresh-process terminal verification fixture. Retain separate clean baseline/candidate caches, explicit NuGet source mapping, parent-import isolation, SDK pinning and disabled implicit SDK feeds. Reuse package/cache/DLL hash corroboration at this two-package fixture's actual scope; do not copy the unrelated five-package representative fixture requirement.
4. Add a dedicated nonpublishing workflow following the accepted retrieval split: repository-write push/manual authority and trusted workflow review; fixed token-bearing live metadata/archive retrieval without checkout or repository-code execution; same-run ID-only transport download with verified layout; actions: none for package verification and execution. Verify source/run/attempt/artifact/name/digest/size/expiry and manifest/file hashes before restore. Bind the original accepted producer identity separately from the later matrix fixture SHA/run/attempt.
5. Extend focused contract/negative tests and the fixture runbook. Retain allowlisted synthetic database bytes, immutable baseline snapshots, portable receipts and sanitized command outcomes, including failures. Do not upload credentials, arbitrary raw state or host paths.

Acceptance

• The stable adapter verifies the exact accepted candidate identity and original downloaded bytes before extraction/restore. The original proof adapter and its negative contracts still pass unchanged; wrong/mixed proof/stable identity, source/run/artifact/manifest mismatch, deleted/expired inputs and changed package/DLL bytes fail closed.
• All six unique released-baseline/framework cells complete: 3.8.4 and 3.9.0 × net8.0, net9.0 and net10.0. All 18 suspend/resume/verify lifecycle processes pass; required restore/build commands exit successfully. No filtering, incomplete matrix or skipped cell can yield a passing result.
• Each cell uses normal migrations and preserves original definition, instance, correlation, typed input, sentinel and bookmark identities. Resume uses the original saved bookmark; fresh verification proves durable typed output, terminal status and bookmark removal. Original baseline snapshots/hashes remain intact. No migration bypass, rebuilt workflow state or swallowed deserialization fallback is accepted.
• Typed preservation means exact JSON primitive values, unchanged declared metadata and recorded CLR materialization. Preserve the established fixture scope: its declared Int32 input materializes as Int64; do not invent a new boxed-Int32 requirement or silently change the baseline.
• Package-only provenance records baseline release origins and candidate 3.10.0 archive/runtime hashes, versions and source identity. Retained fixture inputs demonstrate no ProjectReference fallback; effective caches/sources/imports are checked during execution. Candidate producer identity and matrix fixture/run identity are distinct explicit fields.
• Hosted exact-head evidence and retained database hashes are independently audited by the lead using disposable copies; original retained SQLite files must not be opened directly. A fresh original-artifact availability check accompanies acceptance. Review, repository CI and Greptile gates pass before merge.
• Documentation and closeout state the scope: SQLite, default tenant and built-in fixture activities. This Task does not certify every provider/activity or paired server/Studio behavior, publish packages, approve release/cutover, replace the original [Task] Prove persisted workflow upgrades from 3.8.4 and 3.9.0 to consolidated 3.10 packages #8629 evidence, or close [Feature] F3.3: Published-package compatibility validation #8219/[Feature] F3.4: Artifact provenance, release notes, and recovery procedures #8220.

Verification order and boundaries

Review coherent changes and run cheap contracts first, then exercise a focused real stable-byte cell if it resolves an implementation risk, followed by one complete final-head hosted matrix and repository gates. Reuse the canonical fixture and hash/isolation helpers; do not create another package inventory or duplicate migration implementation. Preserve current user work by using an isolated worktree. The lead owns final QA, merge and board state.

No publication, deployment, publisher credentials/cutover, product/runtime/schema changes or changes to the original upstream repositories, npm ownership, dependency upgrades or stable candidate rebuilding are in scope. Core fixture/workflow changes are in scope. Any genuine compatibility defect remains a failure requiring a reviewed correction; do not weaken the fixture to obtain a pass.

Hosted verification and closeout

Both exact-head six-cell matrices and all repository gates passed before merge. Independent artifacts and lead disposable-database audits verify the retained evidence; final acceptance records reviews, CI, skips and live original-candidate availability. This Task is accepted only for SQLite, default tenant and built-in lifecycle activities. It does not certify all providers/activities or paired browser behavior, approve publication/cutover, or complete #8219/#8220 or the program. Final integration of the program branch into main remains pending.