rdmpw3265m changelog — 20260908-1344 — dev_update v1.96 fleet normalization + Observatory usage/sessions diagnosis

_Session: claude@rdmpw3265m · started 2026-09-08 13:33 EDT · written

1. Requested: distribute dev_update_v1.93.zsh fleet-wide

Premise was stale. Shipped v1.96 instead — DEC-20260908-01.

dev_update_v1.93.zsh does not exist on the canonical root. A prior session archived it to rdmsm4x:~/dev/scripts/archive/ on 2026-09-04 along with v1.94 and v1.95. v1.96 (2026-09-05, 192032 bytes, sha256 f8dd54161554c73c271ef9c96d2c770880d2b5d2361310ce7bad8f152d3f8961) was already present and byte-identical on all five reachable hosts, and was already the target of ~/dev/scripts/dev_update.zsh on each. Pushing v1.93 would have rolled six Macs back three versions.

v1.93 was not the fix — it was the fault. The dangling ~/dev/dev_update.zsh symlinks on three hosts all pointed at ~/dev/scripts/dev_update_v1.93.zsh, which no longer exists. That is why dev_update.zsh failed from ~/dev on those Macs.

Alternatives discarded: restore v1.93 from archive (fleet-wide regression); pin the top-level link to a version filename (dangles again at every bump).

Link chain now standard on every normalized host

~/dev/dev_update.zsh -> ~/dev/scripts/dev_update.zsh -> dev_update_v1.96.zsh

The middle hop is version-agnostic on purpose: the next bump touches one link, and the top-level convenience link never dangles again.

Per-host result — all 0 FAIL, all verified

Archives are MOVES into ~/dev/scripts/archive/dev_update-superseded-20260908/. Nothing deleted.

Verified on each host after the change: link resolves to v1.96 · executable through the link · zsh -n parses clean · FU_VERSION=1.96 · command -v dev_update.zsh in a login shell resolves through to v1.96.

Out of scope, left in place (inclusion rule)

• rdmsm4x:~/dev/ai/agent-coordination -> ~/dev/codex/codex_agent_project_coop — broken, not dev_update-family, not touched. Someone should decide whether that target moved or died.

jdmbair13m5 — DO NOT "FIX" THE SSH KEY

Host pings (10.9 ms) and its tyrelld reported a manifest at 12:37:39 EDT, so it is up. ssh -vv shows Server accepts key: ... ED25519 SHA256:+3hb1Va3Z118IA2A2rR1fVGlgOPR4k7B6wmFiAd/FS8 and then Permission denied. The server accepting the key and then denying auth is the recorded FileVault/locked-home failure mode that reads exactly like a bad key. Check boot time vs console login time first. Queued as ~/dev/todo/items/20260908-jdmbair13m5-dev-update-normalize.md.

Reusable artifact

rdmsm4x:~/dev/scripts/normalize_dev_update.zsh (v1.0) — idempotent, DRY_RUN=1 supported, exit code = FAIL count, Blocks theme. Run it on jdmbair13m5 when ssh returns.

2. Reported: Observatory "usage" and "sessions" show unavailable

Filed as Tyrell ISSUES #57 OPEN. Not auth, not the daemon, not a stale build — the two Observatory chart metrics read event categories that nothing in Tyrell ever emits.

grep -r 'record(event:' Sources/ yields exactly five kinds: daemon, manifest, prune, scan, sync. ObservatoryModels.swift:373 maps .usage to kind "usage" and .sessions to "session"/"agent" — none of which exists. Both series sum to 0, so ObservatoryView.swift:589 returns "Unavailable". Structural and permanent, not a quiet window. Live feeds confirm: rdmpw3265m 24h = 333 events (manifest 218, prune 74, sync 39, daemon 2); rdmsm4x 24h = 259 (manifest 218, prune 40, daemon 1).

The source already says it is unbuilt (ObservatoryView.swift:385-388): "time-series retention is not installed yet" / "a fleet session-history feed is not installed yet".

Data itself is healthy — /api/usage 200 on 43117 and 43118; /api/fleet/usage 200 on 43118 and on rdmsm4x:43117; SessionsPanel reads jsonl directly. Only the trend charts are empty. Anthropic meter at the time: 5h 2%, 7-day 67%.

Also recorded in #57: /api/fleet/usage is server-only on 43117 (Daemon.swift:146) and 404s on client hosts; it serves on the 43118 control plane instead. The app tries 43118 first so it works, but anything assuming 43117 gets a silent 404 on five of six hosts.