rdmsm4x — RTTy 0.3.831 Build 506 signed, notarized and deployed to all six hosts

Written 2026-09-10 on rdmsm4x by claude@rdmsm4x (Claude Opus 5, release executor). Work window 13:20:04 – 16:45 EDT.

One line: RTTy Build 506 is live on all six Macs — Developer ID, notarized, stapled — carrying four merged PRs and Rich's new app icon; two real defects were found and fixed on the way, and one of them now has a gate so it cannot recur silently.

Scope

Host that did the work: rdmsm4x (macOS 27.0 build 26A428, Apple Silicon). Hosts changed: all six (/Applications/RTTy.app replaced, Build 505 archived as rollback on each).

The build

Content: PR #42 (application-flows redesign, ten measured bandwidth defects), PR #44 (Directional Heatmap reachable again — the gate was 44 pt against 40 pt bands, a latent off-by-four since build 35), PR #45 (appearance, Space Blue, dashboard events rail), PR #46 (per-app coloured labels, chart continuity), and Rich's 2026-09-10 stitched icon on every icon surface with one source now feeding both appearance masters.

Commands run (repository)

git commit -> 73bc648  chore(release): prepare RTTy 0.3.831 build 506 candidate
git commit -> 8a2ddc3  feat(icon): Rich's 2026-09-10 app icon on every icon surface
git commit -> 9460db3  fix(standard): register the two PR #42 sources the App Store target never compiled
git commit -> 0930088  docs(state): Build 506 prepared and held
git commit -> 62472c0  chore(release): RTTy 0.3.831 build 506 candidate — register PR #45 sources, gate for unregistered Standard sources
git commit -> f5dacf9  docs(release): Build 506 — six-host evidence, history, changelog, session state
git tag v0.3.831-build506 62472c0 ; pushed main + tag to origin, backup, fleet
RTTY_CODESIGN_IDENTITY=1C07FCD8… RTTY_PROVISIONING_PROFILE=<a2b99f8b profile> bash script/qa_release.sh
zsh ~/dev/_handoff/rtty-build506-20260910/release/build506/tools/deploy_build506_fleet.zsh <host>   # x6
lsregister -f -R -trusted /Applications/RTTy.app ; open -a /Applications/RTTy.app   # hub

Gates — 10 of 10 PASS, 79 assertions

869 / 71 / 270 XCTest cases native and under Rosetta, 5 skipped, zero failures. That is Build 505's 778/71/270 plus 20 (PR #46) and 71 (PR #45) — nothing lost. Gate 7 read a live number, gate 8 measured 171 pt against a 100 pt minimum, gate 9 read real rates.

Gate 4 failed first, and it was the third occurrence of one trap

PR #45 added four files under Sources/RTTy and registered none in StandardSources.txt, while allowlisted sources reference all four (RTTyThemePalette, RTTyWindowSizing, DashboardEventRailPlacement, ApplicationFlowEndLabelLayout). PR #42's two files did the same thing this morning, and PR #47 repeated it.

Every existing check passed each time, and that is the interesting part. standard_project_test.sh asserts the Xcode project's Sources phase equals StandardSources.txt, and the pinned input counts are derived from that same allowlist — so the project and the list agreed with each other while both omitted the file. Those checks answer "does the project match the list?"; none of them asked "is the list closed under the references its own members make?". Only gate 4's real xcodebuild could answer that, minutes into a run, after the whole Swift suite.

New gate: Tests/ScriptTests/standard_source_reference_closure_test.py, wired into gate 4 before anything compiles. Verified both ways on the same tree — rc 1 before the registration, naming all four files and every referrer; rc 0 after. Pinned counts moved 128 → 132 and 159 → 163 in both standard_project_graph.py and standard_archive_validator.py, measured (68+55+8+1 = 132; 132+31 = 163) rather than copied.

Gate 5 failed with errSecInternalComponent, and it was a session-type block

Running the gates over ssh richh@rdmsm4x — the route a standing memory prescribes for gate 7 — failed at codesign. Isolated with a one-line control rather than by theorising: signing /bin/echo with the same identity returned rc 0 in the Aqua session and errSecInternalComponent over ssh, with the keychain search order unchanged (login first — never reordered), the identity present only in login, and login unlocked (no-timeout). sshd cannot get authorization for the key's ACL.

The gates then ran locally and passed all ten including gate 7 — because the memory that sent them to ssh recorded its own expiry condition ("Rich can make the local path work by allowing the pending Terminal → System Events prompt"), and he did that at 13:16 EDT today. Re-measured before relying on it: osascript → System Events returned 142 processes, rc 0, instantly. The block expired; the refusal had outlived it.

Gate 3 wedged once — ISSUE-20260910-07

57m50s elapsed on 1:27.89 of CPU with an identical sample stack 13 minutes apart, inside ColorSync (evaluate_headroom → ColorSyncProfileGetTag) from PR #42's render audit. Wedged, not slow. Not reproduced: the suite alone under Rosetta passed in 180.789 s and every later gate 3 was normal. Hub load was 38–49 with 1Password at 164–339% and three CGPDFService helpers.

Deployment — six hosts, canary first, hub last

All six: PING_CHILDREN=4, NETTOP_CHILDREN=0, advancing statistics. rdmpw3275m, which produced a false rc=1 on Build 505 inside a 90 s window, accepted in 56 s under the fixed installer's 180 s window. The installer is the FIXED 505 template — the EXIT trap assigns install_rc, not zsh's read-only status, so the rollback path is live rather than inert.

Verified per host by execution: version/build, x86_64 arm64, Developer ID authority, stapler validate rc 0, spctl = Notarized Developer ID, embedded profile a2b99f8b…, the running executable read from lsof -p <pid> txt, and ICNS 7bd033da. Live values after the hub relaunch: hub 15 ms, canary 31 ms.

CloudKit — promotion took effect; published, with the boundary stated

The Production schema was promoted at ~14:57 EDT. The evidence is not that failures stopped, it is that the failure changed shape:

• before: Cannot create new type RTTyFleetProjection in production schema
• after (still Build 505): client oplock error updating record, CAS failed

The record type now exists and writes reach it — six Macs are contending on one recordName=latest. Filed as ISSUE-20260910-08.

Under Build 506 all six hosts log nothing: 0 RTTy-process CloudProjection lines since each host's 506 launch (uptimes 4:31 to 11:46 at the check). A zero needs a positive control and this one has three — the same query returns lines over 6 h on every host, captured xctest failures at 16:20:43 during this very gate run, and captured Build 505's own failures minutes before each upgrade.

Read as published, and here is what it is not. The publisher logs only on the unavailable path, one notice per distinct reason, and logs nothing on success (ObservationStore.swift:3908-3923); nothing renders CloudKitFleetProjectionState. So this is failure-absence over windows shorter than the 15-minute backoff ceiling, not a proven round trip. A read-back on a second device is the missing proof.

Working query (lines are Df; a default-level log show returns nothing and reads as silence):

log show --predicate 'subsystem == "com.eastcoastscience.rtty" AND category == "CloudProjection"' \
  --info --debug --last 6h

Not verified

• Dock artwork. This session cannot see the screen. lsregister -f -R -trusted was run on the hub before relaunch and the running app carries the new ICNS, but whether the Dock still paints the old icon from its cache is a visual check. killall Dock was deliberately NOT run — the rule is to run it only when the running app clearly shows the old icon.
• CloudKit round trip (above). No App Store or TestFlight publication.

Backups / how to undo

Every host holds /Applications/.RTTy.app.rollback-build505-62472c0 (Build 505, 00dcb4b7…). To revert one host: quit RTTy, sudo mv /Applications/RTTy.app /Applications/.RTTy.app.rejected, sudo mv /Applications/.RTTy.app.rollback-build505-62472c0 /Applications/RTTy.app, relaunch. Nothing was deleted anywhere; superseded icon masters are present under dated -superseded- names.

Owner actions

1. Look at the Dock icon; say whether it needs killall Dock.
2. Prove CloudKit with a read-back on a second device, and decide ISSUE-20260910-08 (one shared latest record for six Macs, plus the absence of any success signal).
3. The auto-populated-apps / cloud-settings-apply restoration was not started — budget was at hold (Anthropic 7d 87 %). My archaeology found no evidence of removal: 78a8d3f is an ancestor of main and its code is intact; what is missing is the explicit "Apply cloud settings" action. Confirm the premise before that work begins.