[EvilWeasel]

Problem

After a committed A→B update, runtime retention still protects A while the next update stages C. A normal update therefore fails under the existing 1-GiB limit even when B+C fit. A versioned Linux launcher or recorded CLI link can independently keep A referenced.

Change

The launcher now durably prepares the current, fully verified B runtime as the rollback baseline before downloading C. Preparation survives download failure, cancellation and restart; pending transactions, active process references, runtime hashes, profile compatibility, storage accounting and native preflight retain their guards. Commit acknowledgement follows the durable commit before post-commit qualification and cleanup.

Linux services use a stable launcher entry, and the persistent launcher hands its executable to the selected runtime at the existing update boundary. Service commands can select an exact custom unit and refuse another T3 home's unit; the stopped-update handler verifies the selected unit and base before invoking the updater. An explicit service update-stopped VERSION command lets an up-to-date CLI bootstrap older stopped installations through the same preparation, installer, profile preflight, database backup and trial path. It does not stop a running server.

Scope and approval

Owner-requested follow-up to #149 for the demonstrated successive-update budget blocker and the existing custom-unit installations that need the supported bootstrap path. Runtime limits, archive streaming, checksum verification and retention ownership remain unchanged.

Verification

• Existing retention regression failed on Main with a valid committed A→B and space for B+C but not A+B+C. The extended case now covers a failed download after durable preparation, two successive commits and a concurrent candidate.
• Boat vp run check:integration --exact-base …: format, lint and all 98 adjacent tests in seven existing files passed. Server package vp run typecheck passed. Existing cases cover custom-unit isolation, state preservation, preparation IPC and forward/rollback launcher handoff.
• Real published Linux-x64 115 installed through the actual checksum/tar-stdin/native-version path under the unchanged 1-GiB default. An attempted stopped update while its real server was active failed without changing its PID, executable, start identity or HTTP response. Real 115→119 and, after SIGKILL of durable preparation, resumed 119→121 both committed. Only 119+121 remained: 1,018,965,962 fully accounted bytes under the unchanged 1,073,741,824-byte default; no limit override. Actual tar stdin matched each published archive SHA, native versions matched and profile preflights returned ready/exit 0. A separate Node 24 execve probe into original121 preserved PID/start identity and reached HTTP 200; the old launcher SQLite lock was released while the active profile lock remained held. This checks the native exec/FD primitive; the new source handoff branches are covered by the focused regressions, without a new packaged candidate.

No new native or product build was made for these checks. Fixture regressions and real published-payload evidence are separate.

Model: GPT-6.1 Sol (ultra, priority), Codex harness through T3 Code.

[chatgpt-codex-connector]

Codex Review Summary: ✅ Completed

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-11-13T17:01:31.448045Z	61b03d5	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e3fc627e24

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".