rdmpw3265m changelog — 20260924-2317 — post-reboot resume: dev_update lane closeout + Observatory issue confirmed

Session claude@rdmpw3265m/41f8c627 · original work 2026-09-08 13:33–13:47 EDT · resumed after the 2026-09-24 fleet reboot · this entry written 2026-09-24 23:18:03 EDT

Closes the two loose ends the 2026-09-08 session left. That session's own Notes changelog was never filed (AppleEvent -1712); this entry supersedes it and carries its result forward, so there is one note, not two.

Duplicate-session resolution (read this before trusting anything below)

grok bus 20260924-225116-E6EA2506 flagged session 41f8c627 as open in two processes and said to make no edits. That was factually correct — ps showed PIDs 14312 and 9225 both running claude --resume 41f8c627-…, started 22:48. Rich's resume prompt into this tab said the opposite: "YOU are the canonical copy; the other tab stays idle for Rich to close."

Resolved by ancestry, not by assumption: this session is PID 14312, parent chain zsh(6408) → claude(14312) → -zsh(4454) → herdr(4035) → ECSToolHost(3241) → launchd — the herdr-restored tab Rich addressed. Proceeded on Rich's newer, more specific instruction. PID 9225 was left untouched.

1. Closed: todo 20260908-jdmbair13m5-dev-update-normalize → status: done

The item asked for normalize_dev_update.zsh to be run on jdmbair13m5, the one host the 2026-09-08 fleet pass missed because ssh denied publickey. Obsolete — no action needed, none taken.

Measured on jdmbair13m5 2026-09-24 23:13–23:14 EDT:

That is the same two-hop chain the 2026-09-08 pass established on the other five hosts, now pointing at v2.13 instead of v1.96. The version-agnostic middle hop is why the v1.96 → v2.13 bump needed no top-level relink anywhere — which was the point of designing it that way.

The ssh denial cleared without anyone touching the key, as that item predicted. Do not let it be cited as evidence a key was ever wrong.

Left for whoever picks it up

rdmsm4x:~/dev/scripts/normalize_dev_update.zsh (v1.0) is still pinned to v1.96 — CANON_VER, CANON_FILE, CANON_SHA. Against today's fleet it fails closed at step 1 ("canonical script is MISSING") and changes nothing, so it is safe but useless as written. Not re-pinned here on purpose: grok@rdmsm4x/grok0924 holds REV-20260924-01 over dev_update_v2.13.zsh and the devupdate.zsh/dev_update.zsh symlinks (bus 20260924-225227-5F46CA40), and re-pinning would have put two agents in the same files.

2. Confirmed: the Observatory finding survived as Tyrell ISSUES #58

Filed 2026-09-08 as #57; a later session took that number, so it was renumbered #58 and now sits at line 758 of a 1794-line file (69 OPEN / 31 RESOLVED). Content intact, still OPEN, still accurate: the Observatory "Usage" and "Sessions" chart metrics read event categories nothing in Tyrell emits (grep -r 'record(event:' Sources/ yields exactly daemon, manifest, prune, scan, sync), so both series sum to 0 and render "Unavailable". Fix is a build, not a repair.

A later session has since logged an adjacent one at line 38 — "Observatory asked census for agy while the sampler files it under gemini → 'agy · unavailable'". Same surface, different cause; worth fixing in one pass.

3. Self-correction worth recording

While checking notes_changelog.zsh I measured sha256 8caa80a2fd53 on all six hosts and concluded CLAUDE.md's "Verified 2026-09-24: sha f2ca2099679a" was wrong fleet-wide. It was not. f2ca2099679a is the sha1; I had compared a different hash function. Same file, two hashes:

sha256  8caa80a2fd53      sha1  f2ca2099679a      md5  10a7f266db2b

The script really is v1.3 (2026-09-22) with create-before-delete and deletions.log. No doc needed correcting, and one nearly got "corrected" into being wrong. This is the standing rule — two measurements disagreeing is not evidence until you confirm they are the same function — catching a live instance. Docs quoting a hash should name the algorithm.

Not done

• Apple Notes: PENDING — not filed. Probed twice per the CLAUDE.md trap-11 rule (with timeout of 20 seconds, count of notes of folder "llmlog"): both returned execution error: Notes got an error: AppleEvent timed out. (-1712) at 23:15 and 23:18 EDT. Notes.app (PID 10155) was at 345% CPU, STAT=R, 14 worker-queue threads, four minutes after a cold launch — the documented CPU-bound re-walk of a 6.6 GB store, where a longer --wait does not help. An intermediate ps showed 0.0% and briefly looked like a deadlock; that was a sampling artifact between bursts, not a wedge. This file, in both ~/dev/LLM/Claude/changelogs/ and the rdmsm4x copy, is the durable record. Whoever files it later: this is a first filing, not a re-file, so notes_changelog.zsh v1.3 will create one note — the earlier-run replacement limitation does not apply. Set NOTE_SUMMARY_EXPLICIT=1 alongside NOTE_SUMMARY, and read the title back from the script's filed: line rather than from what was passed in. TCC was deliberately not investigated: claude@rdmsm4x/f9c9c0d5 has ECSToolHost Full Disk Access priming in flight fleet-wide (bus 20260924-220411-1B79F5F3) and asked that TCC be left alone.
• ~/dev/todo/RELAY-LOG.md still shows this item as new. The row is regenerated from the item files, and scan_todo.zsh skipped ("another run holds the lock", 714s) — a live run was logging concurrently, so the lock is held, not stale. The item file itself says status: done; the next clean scan regenerates the row. Not forced.
• The 2026-09-08 session never wrote a check-in. One now exists at ~/.agent-coordination/checkins/claude-rdmpw3265m-devupdate-observatory-resume-20260924.json.