rdmsm4x — Fleet Xcode rollout prep, reboot preparation, auto-resume, per-host handoff

Host: rdmsm4x · Window: 2026-08-31 19:05–20:47 EDT · Ticket: TASK-20260831-19 Summary: Confirmed Xcode 27.0 Beta 6 is out, surveyed all six fleet hosts, established that the two Intel hosts can never take Xcode 27, registered the work, prepared rdmsm4x for reboot with a verified auto-resume agent, and handed a per-host ticket to Claude on each of the other five Macs. No Xcode was installed — that step is blocked on one interactive Apple ID download.

Findings

• Xcode 27.0 Beta 6 = 27A5252f. Fleet is on Beta 5 (27A5237k). Confirmed via xcodes update.
• Xcode 27 is Apple Silicon only. xcodes list --architecture x86_64 tops out at 16.4 (16F6); --architecture universal tops out at 26.6 (17F113). The Intel pair's ceiling is 26.6, and they are one build behind it at 17F112.
• rdmsm4x was the only host still on macOS 27 beta 7 (26A5421a); the other three arm64 hosts already run beta 8 (26A5425a). Beta 8 was pending here and is the reason for the reboot.
• No Command Line Tools update is available anywhere — softwareupdate --list on every reachable host. arm64 on 27.0.0.0.1787197235, Intel on 26.6.0.0.1781586589.
• jdmbair13m5 has no Xcode 27 at all, only 26.6 — the fleet outlier.

Fleet state at handoff

Changes made

1. Ticket registration — TASK-20260831-19 (parent, claimed, status blocked), with five child tickets handed off with 24 h leases: -20 rdmbair13m5, -21 rdmbair15m5, -22 jdmbair13m5, -23 rdmpw3265m, -24 rdmpw3275m.
2. ~/dev/fleet/xcode-fleet-20260831/SESSION-STATE.md — the durable record, answering the six required questions. Copied to all five other hosts (verified by line count on each, not by scp exit status) so the handoff does not depend on rdmsm4x being up.
3. Auto-resume on restart — ~/dev/fleet/ops/resume/PINNED-SESSION-xcodefleet plus ~/Library/LaunchAgents/com.eastcoastscience.claude-resume-xcodefleet.plist, following the existing resume_pinned_on_login.zsh <slug> pattern rather than inventing a new one. Loaded and verified firing: the log shows it resolved the transcript (912 K) and dispatched at 20:42:46, exit 0.
4. xcodes CLI install attempted on the three hosts lacking it — all three failed, see below.

Verification

• Auto-resume: ~/dev/fleet/ops/resume/resume-xcodefleet.log — resuming 7b602c9b-… (transcript 912K) / dispatched (exit 0). launchctl list shows the agent loaded.
• State-file delivery: wc -l executed remotely on each host returned the file's line count — presence confirmed on the target, not merely a successful copy.
• Architecture ceiling: two xcodes list --architecture runs, quoted above.

Traps recorded (full detail in SESSION-STATE.md §6)

• An SSH timeout is not evidence a host is down. rdmbair15m5 and jdmbair13m5 were reported unreachable on port 22; both were active the whole time and reachable over Tailscale. The failure was LAN name resolution. Check tailscale status before calling a host down.
• rdmbair15m5 has a stale duplicate tailnet node (offline 10 d). The live node is rdmbair15m5-1 at 100.74.59.4; the bare name resolves to the corpse.
• brew install of a small CLI is not safe to assume on this fleet. xcodes has no bottle for these configurations, so brew builds from source, and that build fails on macOS 27 (unsupported pre-release, Error 71) and on Intel (Build failed). Three of six hosts cannot get it, so the rollout uses a manual xip -x path there instead.
• Homebrew's Xcode version gate blocks unrelated installs. On jdmbair13m5 a small CLI failed solely because the host's Xcode (26.6) is older than its macOS (27).
• SESSION-STATE.md is being written by more than one live session — it changed between a read and a write at 20:52. The write was refused rather than clobbering; the correction was then re-applied to the current content.

Blocked — owner action

xcodes has no stored Apple ID and prompts for Apple ID + 2FA inline (there is no signin subcommand). Rich must run, on rdmsm4x after reboot:

xcodes download "27.0 Beta 6" --directory ~/Downloads
xcodes download "26.6" --architecture universal --directory ~/Downloads

One download serves the whole fleet: the .xip is then distributed and installed locally, so no other host authenticates.

Not done / notes

• No fleet message bus. agent_msg.zsh does not exist on this host under any searched path (~/scripts, ~/bin, ~/dev/fleet/ops, ~/dev/lib). Handoff went through the ticket system instead. Delivery was not simulated.
• Loading the resume agent fired RunAtLoad immediately, opening a Terminal tab that resumed this same session — the likely source of the concurrent edit noted above. Harmless before a reboot.
• Nothing was deleted this session.