rdmsm4x — RTTy Build 506 prepared, gated, and HELD; icon adopted; App Store target unblocked

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

One line: RTTy 0.3.831 Build 506 was prepared, the new app icon adopted across every icon surface, and a real App Store build break found and fixed — then Rich held the release at 15:04 EDT, so nothing was notarized and nothing was deployed. All six hosts remain on Build 505.

Scope

Host that did the work: rdmsm4x (macOS 27.0 build 26A428, Apple Silicon, Xcode 27 beta 6 selected). Repository ~/dev/apps/RTTy. No other host was modified; no /Applications bundle on any host was replaced.

Commits (all pushed to origin, backup, fleet)

71eab80 (the lead's SESSION-STATE checkpoint) landed between mine and swept my staged git mv renames into itself; nothing was lost, the tree was verified file-by-file afterwards.

The icon (Rich, 13:37 and 13:39 EDT)

Source ~/Desktop/RTTy_stitched_091026_exec-e499c933-…png, retained verbatim as Design/icons/RTTy_app_icon_091026_stitched.png, SHA-256 fe9c78ce6b7047df82af7705dfa9c06b7f7d174ffbe3785882c714ff23b3ea18. The 1024 master is the repo normalizer's deterministic output, SHA-256 5b1ba56f1456cb615073bcd7fa6f317e4710f54601988143f18403a3910131be, identical across two runs. On Rich's "use it for all icon places within the app", ONE source now feeds BOTH appearance masters — the light/dark specialization was removed deliberately, at his instruction.

Nothing deleted: superseded files were MOVED to RTTy-light-1024-superseded-20260909.png, RTTy-dark-1024-superseded-20260902.png, RTTy-superseded-20260909.icns, RTTy-dark-superseded-20260902.icns, and every old normalizer case stays registered so the previous art regenerates byte-for-byte. Tests/ScriptTests/icon_pipeline_test.sh rc=0.

Deliberately NOT changed, with reasons: the menu-bar status item (it renders a latency chart and reads no icon asset — grepped); Web/rtty-site/public/icon.png (its own documented lineage in Web/rtty-site/ASSET-PROVENANCE.md, separate nested repo, not "within the app"); rtty-layered-chart-1024.png (a renderer reference, not app-icon art).

Release gate

Run over ssh richh@rdmsm4x (sshd holds the Automation grant that gates 7–10 need).

• Gates 1–3 PASS. Native 778 / 71 / 270, Rosetta 778 / 71 / 270, zero failures — no drop from the 778/71/270 baseline recorded after PR #44.
• Gate 4 FAILED, rc=65, and it was a real defect, not flake: PR #42 (2bafe37) added Sources/RTTy/Views/Graphs/ApplicationFlowSeriesPalette.swift and Sources/RTTy/Views/ApplicationFlowDisplayModePolicy.swift without adding either to Apps/RTTyStandard/Config/StandardSources.txt, while three files already in the App Store target reference them. 20 cannot find … in scope errors. Why every check still passed: standard_project_test.sh asserts the PBX Sources phase equals the allowlist, and the pinned input counts are derived from that same allowlist — so allowlist and project agreed with each other while both omitted the files. Those checks answer "does the project match the list?", never "is the list enough to compile?". Only gate 4's real xcodebuild can answer the second, and it did. Fixed in 9460db3; verified by running gate 4's exact command: ** BUILD SUCCEEDED **, lipo -archs = x86_64 arm64.

Gate 3 wedge — ISSUE-20260910-07

The first gate attempt sat in gate 3 for 57m50s with 1:27.89 of CPU, state S, 0.0% CPU. Two sample runs 13 minutes apart returned an identical stack: ApplicationFlowsRenderAuditTests.testEveryModeAndWindowDrawsSomethingAtEveryWidth → NSColorConvertColorToColorSpace → evaluate_headroom → ColorSyncProfileGetTag → -[__NSCFString isEqual:]. Wedged, not slow.

Not deterministic: the same suite run alone under Rosetta passed — 9 tests, 0 failures, 180.789 s — and the re-run cleared gate 3. Hub load averages were 38–49 with 1Password at 164–339% CPU and three CGPDFService helpers, i.e. heavy concurrent ColorSync use. Leading hypothesis, not proof.

What is NOT done, and why

Build 506 is HELD by Rich, 15:04 EDT — "I'd rather hold and get the labels back": the flows table lost its per-app coloured labels between cf15adc and main, and another worker is restoring them. Therefore:

• No notarization was submitted. No Apple submission id exists for 506.
• No host was deployed. All six still run Build 505 (0.3.830, exe 00dcb4b7…), verified today by execution: universal, stapler validate ok, spctl = Notarized Developer ID, one pid each.
• No docs/release-evidence/build-506/, no RELEASE_HISTORY or CHANGELOG entry, no tag. Per the convention (the build number counts deployed artifacts) 506 is still spendable, so the restored build stays 506.

A signed-but-unnotarized 506 bundle exists only at dist/RTTy.app on the hub. It is a working artifact, not a release: 0.3.831/506, x86_64 arm64, Developer ID, hardened runtime, timestamped, profile a2b99f8b…, no get-task-allow, ICNS 7bd033da…, commit 8a2ddc3, gitDirty false. It launched and drew: 1 window, 2 menu bars, "Overall average latency 20 ms" within seconds — the Build 505 launch-hang class is not present.

CloudKit — promotion not yet effective from this host

The Production schema was promoted at ~14:57 EDT. RTTy 505 on the hub was still logging, at 14:58:18 and 14:58:47 EDT:

Fleet projection unavailable: Error saving record <CKRecordID: …recordName=latest…> to
server: Cannot create new type RTTyFleetProjection in production schema; retrying in 30s

Working query (the lines are Df, which is why a default-level log show returns nothing):

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

There is no UI surface for the projection state — CloudKitFleetProjectionState is in-memory and only the unavailable path logs, once per distinct reason (ObservationStore.swift:3908–3923). Success is silent, so "no line" needs the positive control above to mean anything.

Feature archaeology (Rich, 15:11 EDT: "it existed prior and was lost")

Time-boxed, read-only. I did not find evidence of a removal for either item, and both look present-but-different rather than lost:

• CloudKit settings apply — 78a8d3f feat(macOS): add portable iCloud settings flow (2026-08-11) is an ancestor of main and its code still lives there: RTTyCloudSettingsStore and RTTySettingsTransaction are intact and Settings still says "RTTy automatically loads a newer portable settings record at launch…". What is missing versus Rich's description is the explicit "Apply cloud settings" action and prompt — the shipped design auto-loads silently. It has also been inert in practice because the Production schema did not exist until today.
• Auto-populated application rows — the bottom "automatic application checks" list exists and populates from BuiltInServiceCatalog.profiles gated by InstalledApplicationDiscovery (curated catalog × installed bundle IDs), not from the flows sampler's live per-process detections. git log -S found nothing for autoDetected, discoveredApplications or applicationTargets.

This wants Rich's confirmation before anything is "restored", because building to the wrong premise is the expensive mistake here.

Budget

usage_status at 19:06 UTC: advice hold — Anthropic 7-day at 87%, vendor-authoritative, resets 2026-09-11 13:59 UTC. No worker was spawned; everything above was done inline. OpenAI is at 3% and proceed if an external lane is wanted for the restoration work.

How to undo

Nothing on any host changed, so there is nothing to roll back operationally. To revert the repository work: git revert 9460db3 8a2ddc3 73bc648 (or reset main to 71eab80) and push. The superseded icon masters and ICNS files are present under their -superseded- names, so the previous artwork is recoverable without touching history.

Owner actions

1. Send RESUME 506 with the labels-PR merge sha when it lands.
2. Confirm the archaeology above — specifically whether the "Apply cloud settings" button and the flows-sampler-driven auto rows ever shipped, or were discussed and never built.
3. CloudKit: re-check that the Production schema promotion has taken effect; the hub was still refused at 14:58:47 EDT.