rdmsm4x-changelog-20260831-1235-logtty-build21-capital-l-release

Session: claude@rdmsm4x (dev-bf) · 2026-08-31 12:28 → 12:35 EDT · host rdmsm4x Instruction: Rich — "use a capital L for LogTTY" (2026-08-30), then "approved complete this".

LogTTY 0.1.1 build 21 is built, signed, verified and ready. Nothing distributed yet.

The release

Seven gates, all pass

• universal2 — x86_64 arm64, so rdmpw3265m and rdmpw3275m are safe
• codesign --verify --strict — exit 0
• com.eastcoastscience.LogTTY — matches all five deployed instances, so no host loses TCC grants or Keychain items
• TeamIdentifier ZU2882L4HT, Apple Development: Richard Doty — not ad-hoc
• gitDirty:false — reproducible from a clean tree
• build 21 — fleet was on 19; the bad artifact was 18
• verify_product_identity.sh PASS · swift test 37/37 in 10 suites

Three things found on the way, each of which would have shipped a bad release

1. The uncommitted tree was a half-finished refactor that does not compile

I stashed the 45 files, built from clean HEAD — and the build failed: type 'OSLogSystemCollector' has no member 'loadRecordsFromSystemStoreDirect'. The WIP deletes that method (26 lines) while leaving two callers referencing it. That is why it was never committed.

I had briefly committed it before finding this. I reset to the known-compiling base and preserved the work on branch wip-identity-refactor-20260831 and tag logtty-wip-snapshot-20260830-2044. Finishing someone else's half-done refactor in order to cut a release is not a trade worth making — the minimal identifier change on a compiling base is.

2. PREVIOUS_BUNDLE_IDS listed the new identifier as retired

build_and_run.sh had PREVIOUS_BUNDLE_IDS=("com.eastcoastscience.LogTTY" "…Logstreamed"). Once capital-L became current, the migration path would have tried to migrate the app from itself.

3. The identity gate was enforcing the wrong direction

verify_product_identity.sh v2 scanned for com.eastcoastscience.LogTTY and failed the build with "retired mixed-case bundle identifier remains in current product files". Written for the 2026-08-24 lowercase migration, it would have blocked the correct identifier indefinitely. Inverted to v3 with the reasoning in its header. A gate pointed the wrong way is worse than no gate — it produces confident failures on correct work.

Why capital-L is right, not merely instructed

All five deployed instances already carry it. A changed CFBundleIdentifier is a new app to macOS — TCC grants, Keychain items and LaunchServices lineage do not carry over, and reinstalling does not restore them. The product name remains logTTY; an identifier is opaque plumbing users never see, so the 2026-08-22 product rename stands untouched.

It hid because the fleet runs case-insensitive APFS — /Applications/LogTTY.app and logTTY.app are the same file, so every filename check passes. Match removals on bundle identifier, never on filename.

Also this session

ECSCloudKit — stood down, correctly. A peer asked me to snapshot an "abandoned" uncommitted rewire in replicantDB past an agreed threshold. I printed state before touching anything and found it had landed 74 seconds earlier as 55f107a (v1.17.0 "Shared"). Their check at 12:31 was accurate; it was false by 12:34. The snapshot I took (ecscloudkit-rewire-snapshot-20260831-1235) therefore contains post-landing documentation work, not the rewire — said plainly to the peer rather than left as a trap in the tag name. Working tree untouched.

The sharpest instance of the day's pattern: state changed between the check and the act, three minutes apart, in a tree four sessions write to. Neither agent was careless. Re-verifying immediately before acting is not optional on shared state — it is the only thing that makes the action safe.

Scope deliberately not taken

The privileged helper's own identifier (com.eastcoastscience.logTTY.PrivilegedHelper), preference keys, and log-subsystem strings are untouched — separate identifiers, not required by this change.

Outstanding

• Distribution of build 21 to the five remaining hosts — awaiting Rich's word.
• CloudKit still needs ~20 min in the developer portal (~/dev/fleet/CLOUDKIT-UNBLOCK.md, SEC-20260830-04) — no macOS provisioning profile exists on rdmsm4x at all.
• wip-identity-refactor-20260831 needs its author to finish or abandon it.

No secrets appear in this record.

ADDENDUM — 12:47 EDT · The GH007 backup block was mine, and it is fixed

A peer relayed that a GitHub push of LogTTY would fail GH007 — "83 commits authored [email protected]", GitHub's protected private address — and put two options to Rich: rewrite history, or publish his personal address.

Both were unnecessary, and the number was wrong.

Measured in LogTTY: 95 commits [email protected], 33 [email protected], and 3 [email protected]. Not 83.

All three were mine, made today. The repo's pre-existing history was already privacy-safe — the 08-29 normalization did not "leave this repo behind". I reintroduced the problem by passing -c user.email='[email protected]' on every commit I made this session. Same in ObsidianFleetSync (1) and scripts (1).

None had been pushed anywhere, so this was not a shared-history rewrite — just my own unpushed tips:

apps/LogTTY             4b12731 -> d3968e9
apps/ObsidianFleetSync  920dc4e -> 49dc6e3
scripts                 721a67a -> aff277b
wip-identity-refactor   23a3397 -> dbb4230

gmail-authored commits remaining across all three: zero.

Artifact provenance restated — the amend changed the SHA BuildInfo pins

dist/logTTY-0.1.1-21.zip
sha256  d0e24bfd45ed3a9b7c3ba7b91e1e83371396fb1133136c1c88b5c7791a050112
commit  d3968e9 · BuildInfo gitCommit d3968e96218d5d5e13915eb3066f88226f0d3f1b · gitDirty:false

Supersedes fee653bc… at 4b12731, which is deleted. Do not distribute it. Rebuilt from a clean tree; all seven gates pass again.

Two things worth keeping

An aggregate hid the owner. "83 commits in LogTTY" and "3, all from this afternoon" are different problems with different owners and different fixes. The fleet-total framing turned a one-minute self-inflicted fix into a privacy-versus-history decision put to Rich. Per-repo measurement was the whole difference, and I asked for the correction to be relayed rather than just fixing my end.

I should not have used Rich's personal address as commit author at all. It is given for identifying the user, not for stamping into public git history — and GitHub treats it as protected precisely because publishing it is the harm. Going forward: [email protected], which is what these repos already used and what I should have read before writing.

The peer's framing — this blocks backup, not shipping — is what made me check rather than panic. Tailnet distribution was never affected. And they were right that a closeout reading "released and backed up" would have been false: the first is now true, the second is unblocked, not done, because LogTTY still has to actually push.