rdmsm4x-changelog-20260830-1223-replicantdb-tyrell-fleet-deploy-verification

rdmsm4x — replicantDB and Tyrell fleet deploy verification

2026-08-30 12:12–12:24 EDT · rdmsm4x · session replicantdb-a1

One-line summary: both requested deploys turned out to be nearly no-ops — replicantDB was already current fleet-wide and only one host needed Tyrell — while the verification pass found a P1 defect that means replicantDB's background daemon has never actually run under launchd on any host.

Scope

Hosts touched: rdmsm4x (local), rdmbair13m5 (remote, Tyrell bundle replaced). Read-only probes: jdmbair13m5, rdmpw3265m, rdmpw3275m. rdmbair15m5 unreachable throughout.

What changed

Change	Host	Reversible how
Tyrell `/Applications/Tyrell.app` 0.2.0 (2) → 0.2.0 (3)	`rdmbair13m5`	rollback bundle preserved at `/Applications/.tyrell-rollbacks/20260830-121823-55bb35aaa0ed/Tyrell.app` (verified `CFBundleVersion=2`)
Cleared 3 stale 0-byte `.git/index.lock` files	`rdmsm4x`	none needed; locks were orphaned ~12 h, no holder
`launchctl kickstart -k` on the replicantDB daemon	`rdmsm4x`	job exited 0 on its own within 2 min; no residual state
Docs: `ISSUES.md`, `UPDATING.md`, `SESSION-STATE.md`	`rdmsm4x`	git-tracked, uncommitted
Reverted uncommitted sed in `docs/history/` (3 files)	`rdmsm4x`	`git checkout --` of that path

Locks cleared: ~/dev/apps/fileLabeler, ~/dev/apps/rdWORKBENCH, ~/dev/apps/LogTTY. All were 0 bytes with no holding process (pgrep 'git ' showed only fsmonitor daemons). Git writes confirmed working in all three afterwards.

Verification evidence

replicantDB v1.10.1 (14) "Quiet" — measured by execution on five reachable hosts, reading /Applications/replicantDB.app/Contents/Info.plist and ~/bin/replicantdb-cli, never dist/:

CLI self-report 1.10.1 (14) and app bundle 1.10.1(14) on all five
designated requirement a4761a82… identical on all five
lipo -archs = x86_64 arm64 on all five
MCP: pipelined two-message handshake, JSON parsed (not grepped), serverInfo version 1.10.1 on all five. Key order differs between hosts, which is exactly why it is parsed.

Tyrell 0.2.0 (3) on rdmbair13m5, read back over ssh after install: executable SHA-256 f92d93bd…, arm64 CDHash e52fe90b…, both matching the accepted artifact; DR 7467a4ae… identical before and after, so no TCC grant was invalidated. App left stopped, as it was before. codesign --verify --deep --strict passes.

Defect found — P1, filed in replicantDB `ISSUES.md`

The launchd daemon agent is a no-op. The LaunchAgent runs the app binary with --daemon, but only the CLI implements that flag; nothing in Sources/replicantDB/ reads --daemon or REPLICANTDB_DAEMON_MODE. The app takes the .app single-instance role, finds the menu-bar app holding it, and calls NSApp.terminate(nil) — exit 0, which KeepAlive: SuccessfulExit=false correctly declines to retry. Both log files stay 0 bytes because it never gets far enough to log.

Independent proof it never reaches its own role: Application Support contains app.lock only; no daemon.lock has ever been created.

Consequence, fleet-wide: the 300 s maintenance pass and FSEvents monitoring have never run under launchd on any host. "Daemon installed" has never meant "daemon working". Fix in progress in Sources/ by the other live replicantDB session; not written up as fixed until it lands.

Correction made during this session

I reported the daemon "kickstarted; now live" on the strength of a single immediate PID sample. It had exited two minutes later. SESSION-STATE.md now records that plainly rather than quietly dropping it.

Host context

rdmsm4x rebooted 01:53 EDT and no GUI (Aqua) session opened until 12:02. macOS LaunchAgents run in the gui/<uid> domain, so every per-user launchd job was dead ~10 h — not killed individually. They recovered on their own at login. Load average 61/75/87 on 16 cores from fileproviderd/FPCKService (iCloud Drive), sustained ~20 h, unrelated to agent work.

Outstanding owner actions for Rich

rdmbair15m5 needs you at the keyboard. It is UP and working (LAN ping 0% loss, agent still posting to the bus at 11:53) but refuses inbound SSH publickey; Tailscale is also down there. This is NOT the FileVault case its symptoms resemble. One command settles it, run on that machine: log show --predicate 'process == "sshd"' --last 1h. Do not reboot — that would lock the home for real.
LogTTY must not be deployed fleet-wide yet. The dev build's CFBundleIdentifier is com.eastcoastscience.logTTY (lowercase) while all five deployed instances are com.eastcoastscience.LogTTY. Shipping it would install a different app identity everywhere and lose TCC grants, Keychain items and lineage.
XEntropy / updateRoo / AINetNode are arm64-only and no universal build exists. They cannot go to the two Intel hosts without a universal2 rebuild.
_review-shared has ~2947 deletions pending in its working tree — disposition unclear.

Not done

Nothing pushed to any git remote (D-26 stands). No database opened read-write. No /Applications bundle deleted on any host. rdmbair15m5 untouched.