[dustywusty]

What this changes

A desktop app built from main cannot install the latest release, v0.2.0. Every new install stops at "Installing OpenBot":

That did not finish
Finish installing OpenBot's local software before signing in or starting. Return to Install and try again.
shared/package.json: No such file or directory (os error 2)

This PR:

• reads shared/package.json and toolkit/package.json only when the release has them (preparation::packages), for both the dependency fingerprint and the installed-package check;
• keeps the four manifests every release has (root, server, app, worker) required, so a damaged download still fails Install;
• adds a_release_from_before_the_toolkit_needs_no_shared_or_toolkit_manifest, which lays out the v0.2.0 shape and the current shape and checks both.

Root cause

• Where it entered: Move the turn engine into @openbot/toolkit, and split the largest server files #784 (6fb38c8, "Move the turn engine into @openbot/toolkit") changed preparation::PACKAGES from ["", "server", "app", "worker"] to add "shared" and "toolkit", because on main both are now workspace packages with their own package.json.
• How: the desktop app installs the latest published release, not the checkout it was built from (deployment_release::resolve_version reads releases/latest). v0.2.0 was tagged before Move the turn engine into @openbot/toolkit, and split the largest server files #784: in it shared/ is plain source with no package.json, and there is no toolkit/. dependency_fingerprint and package_files read every manifest in PACKAGES and fail on the first missing one.
• Evidence: reproduced on a clean desktop install (Apple silicon) of a desktop built from main at 74051c1: the install folder has shared/ with source files and no manifest, no toolkit/, and the stamp reads {"version":"v0.2.0",…}. git cat-file -e v0.2.0:shared/package.json and v0.2.0:toolkit/package.json both fail; both exist on main. With this change the same install completes.
• Why it went undetected: the preparation tests build their fixture from PACKAGES itself, so the fixture always has every manifest the code asks for. Nothing installs the real latest release with a desktop built from main, and the next release will contain both packages, so the gap only exists between Move the turn engine into @openbot/toolkit, and split the largest server files #784 and that release.
• How this prevents recurrence: the new test pins the v0.2.0 layout, so a later change that again requires a package an older release lacks fails here. Packages added from now on can be listed in LATER_PACKAGES the same way.

Where it runs

• New state that outlives a request? None. Desktop-only; nothing new is stored.
• What happens on the second replica? Not applicable: desktop install step; no server code touched.
• Anything serialised? No.
• Anything fanned out to a browser? No.
• New listener, port, or schedule? No.

Boundary and audit

• Every acting call still goes through the gateway: unchanged, no server code touched.
• New refusals and new failures each write a row: not applicable (desktop install check).
• Nothing new is trusted from the client: unchanged.

Changelog

• A line in CHANGELOG.md under Unreleased ("A new desktop install of v0.2.0 gets past Install again").

[chatgpt-codex-connector]

Codex Review Summary

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

Review	Status	Commit	Review trigger
📝 Code Review	🔄 Running since 2026-10-22T07:43:30.038835Z	1a69d24	PR opened

ℹ️ 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.

[guidovizoso]

Unblocks installs from main. Fine to land even though it goes moot after the next release.

[dustywusty]

@guidovizoso merged main to clear a CHANGELOG conflict with #822 (kept both entries, no code change). The push dismissed your approval under the stale-review rule, could you re-approve?

[guidovizoso]

Re-approving: the merge only resolved the CHANGELOG conflict with #822; the preparation.rs change is identical to what I approved.