rdmsm4x — stale tracked backup removed; two verification traps recorded fleet-wide

2026-09-01 18:23–18:45 EDT · rdmsm4x · Claude Code (session tyrell-c5)

A wrong claim I made to a peer at 14:16 turned out to have a mechanism worth fixing rather than just a correction to issue. Tyrell was reported as having no script that builds universal2. It had one, and had had one for four hours.

What changed

Ticket TASK-20260901-10 filed and then amended with a correction.

The defect

790871d (10:26:23) rewrote make_app_bundle.zsh to v1.4: enumerate .executable() products from Package.swift, build each with --arch arm64 --arch x86_64, lipo-gate each, gate the bundled copies again. 03ba9a5 (10:27:48) then committed the pre-fix v1.3 as a tracked .bak, one minute later. A grep for the build behaviour hit the backup's line 13 — which only prints the universal command in an error path — and I quoted it as current.

Nothing in grep output says which of two files is live, and the quoted line genuinely existed in the repo, which is what made the claim survive.

Verification (artifact, not recipe)

zsh scripts/make_app_bundle.zsh → [PASS] all 5 declared products built universal2.

Signed Apple Development: Richard Doty (S65Q255HA8), TeamIdentifier=ZU2882L4HT, minos 15.0 (below the 26.7 ceiling, so the two Intel Mac Pros can load it).

swift test → exit 0, 244 + 65 + 51 + 0, 0 failures — no drop from the previous checkpoint. Recorded as a count, not as "green", per fleet rule 33.

Fleet-wide finding

58 backup files are tracked in git across 11 canonical ~/dev repos: fleet(24) ai/LLM(8) data(7) scripts/macos(5) scripts(4) RTTy(4) notes(2) issues(1) todo(1) LogTTY(1) sites/dev.ecs0.net(1).

Deliberately not swept. A divergent backup may be the only record of the other side of an open decision. RTTy is exactly that case: at HEAD its four pbxproj.bak carry net.dataroo.RTTy while the live files carry com.eastcoastscience.RTTy, so HEAD tracks both bundle-ID schemes at once — a team-permanent, unrenameable identifier still under Rich's decision. Those four are his call, not an agent's.

The correction inside the correction

I first recorded RTTy's backups as "measured clean". Peer session rtty-8f caught that this was scoped to two build settings in the working tree; the divergence is in a third field at HEAD. Verified independently here before amending the ticket.

Recorded as rule 16: "measured clean" is only clean on the fields measured, in the tree state measured. A correct reading generalised past its scope is more durable than a wrong one, because re-running the original check keeps confirming it.

Process notes

• The canonical Tyrell checkout now refuses direct commits (control from INCIDENT-20260901-04). Both commits went through linked worktrees and were fast-forwarded in; worktrees and branches removed.
• Cleared a stale .git/index.lock (0 bytes, 79 min old, no lsof holder, no index-writing git command). Moved to the session scratchpad, not deleted.
• Verified the login-resume change from dev-67: pin 20-tyrell.pin present, dispatcher loaded, old LaunchAgent gone. No action needed.

Undo

• git -C ~/dev/apps/Tyrell revert 043f9c1 restores the backup file (git history holds it).
• git -C ~/dev/lib/app-baseline revert d1019c5 removes rules 15–16.
• Stale lock copy: <session scratchpad>/index.lock.stale-1706.

Outstanding, owner action

• TASK-20260901-10 — 10 repos unmeasured. RTTy's four await Rich's bundle-ID decision.
• SEC-20260901-04 — rooDB's hardcoded customer name, still gating any App-Store-bound rooDB build.

No secrets recorded. No system settings, installed software, or fleet configuration changed.