[teamleaderleo]

Follow-up to #31410. It placed all three light jobs on the dedicated nightly Macs. The two small ones belong there. prepare-nightly-variant-primary doesn't: it downloads the whole unsigned app, scans every file for the browser-data import proof, and uploads the prepared app. On a dedicated nightly Mac that cost more than the 3-minute placement wait #31410 removed.

metric	before (Blacksmith route, run 41358657711)	with #31410 (dedicated Mac, run 41360732074)	after this PR	delta	harness
prepare-nightly-variant-primary duration	57 s	4 min 45 s (download 59 s, browser-data proof 99 s, upload 62 s)	about 57 s (Blacksmith route, no placement wait)	about -3.8 min against #31410	job and step timings
light-job placement	186 s	under 15 s	under 15 s	none	step timings

Change: the placement step's JOBS drops prepare-nightly-variant-primary, so it is never offered and its runs-on takes its Blacksmith route at once. Its placement-aware runs-on is unchanged.

Tests: tests/test_nightly_trusted_routing.py (updated), tests/test_ci_portable_job_placement.py, tests/test_ci_nightly_off_blacksmith.py and tests/test_runner_routing_table.py pass.

Agent session: agent session

🤖 Generated with Claude Code

---

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

---

Summary by cubic

Keeps prepare-nightly-variant-primary off the dedicated nightly Mac placement so it takes its faster Blacksmith route.

#31410 put all three light jobs on dedicated nightly Macs. That made prepare-nightly-variant-primary take 4.8 min (download, browser-data import proof, upload) versus 57 s on its Blacksmith route, wiping out the 3-minute placement wait the placement removed. This PR drops it from the placement step's JOBS list — it's no longer offered, so it neither waits nor lands on a Mac — while the two small jobs stay on the reservation and its placement-aware runs-on is unchanged. Updated the placement test to match.

^{Written for commit 974d7b2. 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 974d7b2: 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=pr31463 -f ref=lane/nightly-prepare-primary-linux -f platform=macos -f backend_mode=local

red: cmux-next checks (god files, concurrency, crash safety, l10n); no finished base run on 73f6764 to compare; do not merge until green; see lane-rules

Shipped in:

• cmux NEXT nightly 1.0.0-nightly.4136544032801 (f0aa500e6c)
• cmux NEXT nightly 1.0.0-nightly.4136730821001 (c0b3866c7e)
• cmux NEXT nightly 1.0.0-nightly.4136829527301 (828f905fb8)

[teamleaderleo]

Review (subagent claude-opus-5-5 medium): SHIP at 974d7b2

• The primary's runs-on can no longer match a placed job, so it resolves to its Blacksmith route, and the wait loop no longer waits on it.
• prepare-nightly-variant's fallback leg is unchanged.
• Passing: nightly_trusted_routing (44), nightly_off_blacksmith (21), runner_routing_table (33), portable_job_placement.
• test_ci_self_hosted_guard.sh fails the same way on base.

Follow-ups:

• [follow-up] The primary's runs-on still has a light_mini term it can no longer reach, so test_ci_nightly_off_blacksmith counts it as having a fleet route. Add it to BLACKSMITH_LINUX_ONLY_DEBT, or make the test check that the job is actually offered in place-light JOBS.
• [follow-up] When the primary fails, a fallback prepare placed on a mini runs the full slow preparation there.
• [follow-up] Once a fleet Linux runner exists, re-measure the primary there. The 99 s browser-data proof is worth speeding up on its own.