[teamleaderleo]

Picking Dev in cmux NEXT's Update Channel does nothing today: every item on the cmux NEXT feed is tagged cmux-next, which every ring accepts. With this change and repository variable NIGHTLY_NEXT_DEV_RING=on, each new nightly-next build goes out as cmux-next-dev first, so only apps on Dev get it right away (same app, com.cmuxterm.app.nightly.cmux-next, updating in place). It moves to cmux-next (Nightly) once the canary passes it. Unset or off keeps every item on cmux-next, which is today's behavior, so merging this changes nothing until someone sets the variable.

How a build moves from Dev to Nightly

• Published: build-sign-notarize-nightly, the recovery path and generate-nightly-deltas tag new items cmux-next-dev when the variable is on.
• Qualifies: the durable canary verdict verdicts/<build>.json is pass. It's the signal that already exists, and the train already uses it for its base. I didn't add a soak timer: nothing in the workflows has one, and a timer would promote builds the canary never saw.
• Promoted: nightly-next-verdict.yml sets every feed item's channel from the verdicts after it writes each verdict. The write is If-Match on the bytes it read, like the rollback. republish-nightly-deltas, which lists earlier builds again, tags them from the same verdicts before publishing. The verdict documents are the only source of truth, so any later writer corrects a missed promotion. Turning the variable off puts every item back on cmux-next at the next verdict or publication.
• Old feed: legacy-identity-target (the cmux NIGHTLY-identity feed for pre-NEXT installs) copies only builds already on cmux-next.
• Logic: all of it lives in scripts/ci/nightly_next_ring.py (channel, retag, select).

Old builds never see an unpromoted item

Builds from before rings allow only cmux-next: UpdateFeedResolver.Channel.allowedSparkleChannels is allowedSparkleChannels(ring: .nightly), and UpdateDriver+SPUUpdaterDelegate.allowedChannels(for:) returns it to Sparkle. Sparkle drops an item whose sparkle:channel isn't in allowedChannels, and the app's own model of this (AppcastItem.isOffered(allowing:) on the release-rings branch: an untagged item is always offered, a tagged one only when allowed) works the same way. Main's builds allow no channel at all. The new test test_nightly_and_older_builds_never_see_an_unpromoted_build checks that rule for Dev, Nightly, pre-ring and main updaters on a retagged feed.

The guard

nightly-next-guard.py appcast used to require exactly [cmux-next]. It now requires exactly one tag per item, from the four ring tags (cmux-next-stable, cmux-next, cmux-next-canary, cmux-next-dev). An untagged item, a second tag or a foreign tag is still refused. A test checks that the guard, nightly_next_ring.py and UpdateRing.swift/UpdateFeedResolver.swift name the same four tags. Nothing publishes canary or stable items yet.

How much faster Dev is

Not much, in the best case:

• Build cadence: builds landed about every 21 minutes on 2026-10-21 (30 builds, 11:59 to 22:09 UTC).
• Canary latency: the canary runs at :03/:18/:33/:48 (15 minutes apart) and has a 25-minute job timeout. The one durable verdict so far came 9 minutes after its build published. So promotion trails publication by about 10 to 40 minutes.
• App check interval: the app checks hourly (UpdateSettings.scheduledCheckInterval = 60 * 60). For a Mac checking hourly, Dev is ahead of Nightly by less than one check interval.
• Builds the canary skips: the canary checks only the newest build at each tick. A build that's superseded before its tick never gets a verdict and stays on Dev; Nightly moves on with the next build that passes.

Right now, on would freeze Nightly. The only verdict written so far is a fail (build 3968001295301, 22:18 UTC). Every scheduled canary run I opened that actually ran the canary failed (6 of them between 17:25 and 22:13 UTC); the others skipped already-checked builds. That's why the switch defaults to off and the doc says to turn it on only while the canary passes.

A Nightly app can be offered a promoted build only while that build is on the feed. The first publication writes a single-item feed with only the new build, and the delta republish adds up to 5 earlier builds back. Between those two writes, Nightly is offered nothing new. That's safe, but it's a delay.

Risk

risk:high: release/updater publication. Mitigations:

• Default off: with the variable unset, the only changes are a guard that accepts four tags instead of one, a no-op select on the old feed, and an extra feed read in the verdict job that writes only if a channel differs (it won't).
• When on, the failure direction is safe: an unreadable verdict counts as none, so the item stays on Dev. Nightly is never offered a build early; at worst it gets one late.
• Concurrency: the feed write in the verdict job is If-Match. When it loses a race it writes nothing, and the next writer derives the same channels from the verdicts.
• Tooling version: republish-nightly-deltas now runs the guard and the ring script from the workflow commit (.publish-tooling, as publish-nightly already does), because the build ref can predate them.
• Not covered by this PR: a promoted build can drop off the feed (see above). The legacy feed waits while nothing is promoted.

Changelog

none

Observed / Not run

Observed, on c169198:

• python3 tests/test_nightly_next_ring.py: 17 tests OK. The workflow test for the verdict promotion was red before the verdict workflow change.
• python3 tests/test_nightly_next_guard.py: PASS. Against the base guard it fails on the three new ring-tag cases and the tag-sync check (red on base, green here).
• These neighbors pass: test_nightly_next_feed_rollback, test_nightly_next_recovery, test_nightly_next_post_publish, test_nightly_next_train, test_nightly_republish_delta_guard, test_ci_test_execution_registry, test_ci_workflow_guards_are_wired, test_ci_run_guards, test_ci_linux_guard_routing, test_cmux_next_guards_route, test_feat_ci_guard_group, test_pr_lane_coverage, test_ci_actionlint_covers_every_workflow, test_ci_workflow_run_sources, test_ci_reusable_workflow_permissions, test_ci_release_product_reuse.
• actionlint on the three changed workflows: the only finding is base's 17-input workflow_dispatch on nightly.yml, which is the same on base. Runner-label noise is ignored.
• python3 scripts/cmux-next/prepush-gate.py: no new violations.
• The live feed, verdict documents and canary run history quoted above were read on 2026-10-21.

Not run:

• No nightly or verdict workflow was dispatched, so the retag and promotion steps haven't run against the real feed or R2.
• test_ci_guard_workflow_structure.py and test_ci_change_areas.py failed only because files were missing from my sparse checkout (agent-chat/package.json, cmux.xcodeproj). CI runs them.
• No app build. The Swift claims come from reading the code.

Agent session: huge-blue

🤖 Generated with Claude Code

---

Summary by cubic

Picking Dev in cmux NEXT's Update Channel does nothing today: all items on the feed are tagged cmux-next, which every ring accepts. With this change, setting repository variable NIGHTLY_NEXT_DEV_RING=on publishes each new nightly-next build as cmux-next-dev (Dev ring only) and moves it to cmux-next (Nightly) once its durable canary verdict is pass. Unset or off keeps every item on cmux-next, so merging this changes nothing until someone enables the variable.

• Promotion happens in nightly-next-verdict.yml (retags the live feed with If-Match) and in republish-nightly-deltas; the verdict documents are the single source of truth.
• Nightly and pre-ring builds accept only cmux-next, so they never see an unpromoted build; the old cmux NIGHTLY-identity feed copies only Nightly items.
• The feed guard now requires exactly one of the four ring tags per item instead of exactly cmux-next; a test keeps the guard, the ring script, and UpdateRing.swift in sync.
• With on, Nightly gets nothing new while the canary passes no build, so the variable should be enabled only while the canary is green.

^{Written for commit c169198. Summary will update on new commits.}

[github-actions]

cmux status _{(one comment, edited in place; each line is updated by the job that owns it)}

Review c169198: HQ feed card · gallery before/after runs · checks

App of this head (app.zip, kept 1 day)

gh workflow run reload-build.yml -R manaflow-ai/cmux --ref feat-cmux-next -f tag=pr23835 -f ref=ci/next-dev-ring-publish -f platform=macos -f backend_mode=local

[blacksmith-sh]

Found 2 test failures on Blacksmith runners:

Failures

Test	View Logs
nightly cmux-tui resolve/nightly cmux-tui resolve	View Logs
test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)/ test_the_repository_highlights_validate (main.DigestTests.test_the_repository_highl ights_validate)	View Logs

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[teamleaderleo]

Review (independent subagent): SHIP at c169198

Off by default (NIGHTLY_NEXT_DEV_RING unset/off): the first publish, recovered build, delta republish, old-identity feed and verdict retag all leave every item on cmux-next. The reviewer ran select and retag on today's live feed: the output is byte-identical and changed: false. When on, the verdict retag writes with a real compare-and-swap (sha256-matched ETag plus If-Match; on a mismatch a newer writer wins). No new pull_request_target or workflow_run triggers, and no new secrets. The guard refuses untagged, doubled and unknown tags. tests/test_nightly_next_ring.py (17) and tests/test_nightly_next_guard.py pass. Fleet cmux-ci compile-check --app at c169198 passed.

Reds on this head that are not this PR's: release-notary on restored-terminals-come-back.md (also red on base), the fast tier (runner Swift 6.3.3 vs SDK 6.4, infrastructure), and the localization debt ratchet (base).

[teamleaderleo]

Bead cx-hakzz created for this PR by the cmux coordinator.

[github-actions]

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.3969943093301 (ee6f052ca5)