Scenarios
The CLI release that pinned itself back
v2.4 of the developer CLI — a new auth flow riding the update channel. Outcome: re-pinned in 51 s · then shipped. 1 tripwire fired · 0 users stranded · reshipped in a day
one control point a woven topology
“a one-line bugfix” ●shipped · 41 min“a CLI release to every laptop” ↶re-pinned in 51 s · then shipped“a mobile feature stuck behind store review” ●shipped · one binary“a rewrite that claims it’s 10× faster” ●proven · 2.1M comparisons“a risky change to a feature most orgs ignore” ●verdict · 5 h“a new skill for your agent fleet” ●fleet-wide · 0 broken sessions“a feature that spans API and UI” ●shipped · 3 days“one contract across three services” ●zero drift · one 40-min hold“a feature built on another feature” ●2 ships · 1 graph“the change that looked safe” ↶reversed · 43 s
cli-staged-binary
RE-PINNED · 51sThe CLI release that pinned itself back
v2.4 of the developer CLI — a new auth flow riding the update channel.
The plan — drafted before anyone saw it
Strategy Binary staged through rings — internal fleet, then 5% of update checks
Control points One control point gating the update-channel manifest
Gates smoke suite on 3 OS targets · crash-free ≥ 99.9%
Guardrails crash-free rate · auth success · support pings
Rollback failure spike → manifest re-pins the previous version
Ramp — planned outline, actual fill
ring 0
5%
50%
100%
The run — from the decision log
T+0m read: diff touches auth flow + update manifest — every laptop is productionheld
T+1d ramped: internal ring clean for 24 h — 5% of update checks openheld
T+2d saw: token refresh failing behind corp proxies at the 5% ringtripped
T+2d reversed: manifest re-pinned to v2.3 in 51 seconds — the long tail never saw ittripped
T+3d resumed: proxy fix verified against the same ring, then rings reopened to 100%adapted
1 tripwire fired · 0 users stranded · reshipped in a day
learnedcorp-proxy machines saved as the standing early ring for CLI auth changes.