Distillation

Date: Sep 9, 2026

• 🔴 (10:18) User showed BYK/binpatch tags: 0.4.2 at commit 9ba6bbb8227fcbd2521852d2311c82afac5e9573, 0.4.1 at d0593cdd89eb720edddf9644e0753613e4a8e622, and 0.4.0 at 2446f4cbecca92eba775e8ef52dff01fd20a9326.
• 🔴 (10:19) User showed a search with exactly 84 matches across packages/cli/test/lib/delta-upgrade.test.ts, packages/cli/test/lib/delta-upgrade.mocked.test.ts, packages/cli/src/lib/version-check.ts, packages/cli/src/lib/upgrade.ts, packages/cli/src/lib/delta-upgrade.ts, and packages/cli/src/lib/release-notes.ts.
• 🔴 (10:19) User showed packages/cli/src/lib/delta-upgrade.ts exports fetchRecentReleases at line 155, resolveStableChain at line 270, resolveNightlyChain at line 278, resolveStableDelta at line 487, resolveNightlyDelta at line 505, attemptDeltaUpgrade at line 523, prefetchNightlyPatches at line 615, and prefetchStablePatches at line 622.
• 🔴 (10:19) User showed packages/cli/src/lib/version-check.ts imports prefetchNightlyPatches and prefetchStablePatches at lines 21–22 and invokes them at lines 237 and 239; packages/cli/src/lib/upgrade.ts imports attemptDeltaUpgrade and DeltaResult at line 43 and invokes attemptDeltaUpgrade at line 991.
• 🔴 (10:19) User showed delta-upgrade coverage in packages/cli/test/lib/delta-upgrade.test.ts: fetchRecentReleases begins at line 819, resolveStableChain at line 893, resolveNightlyChain at line 1080, resolveStableDelta at line 1625, resolveNightlyDelta at line 1651, attemptDeltaUpgrade at line 1812, prefetchNightlyPatches at line 1827, and prefetchStablePatches at line 1838.
• 🔴 (10:19) User showed mocked delta-upgrade coverage in packages/cli/test/lib/delta-upgrade.mocked.test.ts: resolveStableDelta begins at line 92, resolveNightlyDelta at line 198, and attemptDeltaUpgrade at line 315.
• 🔴 (10:20) User showed open issue getsentry/cli#1244, titled “toolkit merge: bridge CLI release + dual-source upgrade compatibility,” authored by BYK, created July 15, 2026, last updated September 8, 2026, with 1 comment; it is a sub-task of getsentry/cli#1248.
• 🔴 (10:20) User stated the repository merge has a hard prerequisite: ship one stable bridge CLI release from getsentry/cli before importing any CLI history into getsentry/sentry-mcp; it must remain usable before the Toolkit rename and discover Toolkit releases after the rename, while older binaries continue upgrading through legacy endpoints.
• 🔴 (10:20) User requires new binaries and the install script to always check this exact ordered source list: 1. getsentry/toolkit / ghcr.io/getsentry/toolkit; 2. getsentry/cli / ghcr.io/getsentry/cli.
• 🔴 (10:20) User requires falling through to the next upgrade source only on HTTP 404; network and fetch failures must remain transient errors and must never poison a source.
• 🔴 (10:20) User requires one shared source definition for TypeScript and the generated install script, with a check that fails if the two source lists or their ordering diverge.
• 🔴 (10:20) User stated old binaries know only getsentry/cli; therefore every migrated stable CLI release and nightly must be dual-published to Toolkit and the legacy CLI endpoints during the compatibility window.
• 🔴 (10:20) User’s implementation checklist is: 1. add UPGRADE_SOURCES across src/lib/binary.ts, ghcr.ts, upgrade.ts, and delta-upgrade.ts; 2. mirror the same ordered fallback in the install script; 3. add a check: script proving the install script and TypeScript resolver use one ordered source list; 4. preserve delta-patch chains (sha256-<binary> / from-version) and cleanup/keep-count parity across both GHCR packages; 5. configure the post-migration Toolkit release flow to dual-publish releases and nightlies to both repositories and keep getsentry/cli writable until the compatibility window ends.
• 🔴 (10:20) User’s pre-import bridge-release gate is: 1. cut the next stable CLI release from getsentry/cli with the dual-source resolver, using the release system’s computed version rather than manually pinning a target; 2. verify a pre-bridge binary upgrades to the bridge release through getsentry/cli; 3. verify the bridge binary handles a 404 from the not-yet-existing getsentry/toolkit source and upgrades through getsentry/cli; 4. verify the install script behaves identically; 5. record the released bridge version in getsentry/cli#1244, and only then begin getsentry/cli#1239.
• 🔴 (10:20) User’s post-rename compatibility matrix is: 1. publish one staging CLI release from Toolkit to both repositories; 2. verify a pre-bridge binary upgrades through getsentry/cli; 3. verify the bridge binary and a Toolkit-built binary upgrade through getsentry/toolkit; 4. simulate a Toolkit 404 and verify both new binaries fall back to getsentry/cli; 5. compare release assets, SHA-256 values, GHCR manifests, and delta-chain metadata between both repositories and require exact matches; 6. run the same matrix for the install script and one nightly.
• 🔴 (10:20) User requires dual-publishing for at least 2 stable CLI releases and roughly 90 days of nightlies; getsentry/cli may be archived only after telemetry and release evidence show the legacy endpoint is no longer required, and it must remain writable until then.