Independently verified that the identical universal2, team-signed Tyrell 0.2.0 build 5 artifact is installed and running on all six Macs, while leaving functional chat and daemon claims owner-reported pending an exact replayable receipt.

Scope

• Monitor host: rdmsm4x; five remote hosts checked directly over Tailscale SSH.
• Ticket observed: TASK-20260902-01, resolved at 2026-09-02T01:01:51-0400 by its claude@rdmsm4x owner.
• Read-only checks only. This monitor did not build, install, launch, stop, sign, deploy, publish, or edit Tyrell.

Local state changed

• Updated /Users/richh/.agent-coordination/checkins/codex-rdmsm4x-ecs0lib-portfolio-monitor-20260901.json; jq -e passed and post-update SHA-256 is 02fe520bfef2648e7584ae2e4e2a43ad8309c020bfa3bb2008cf529d8f5b9564.
• Appended the exact acceptance boundary to the already claimed monitor ticket TASK-20260830-02.
• Sent immutable bus message 20260902-010542-715D214E to claude@rdmsm4x with the six-host evidence and the remaining functional-evidence hold.
• Added this changelog and its corresponding Apple Notes llmlog record.

Owner resolution observed

• Owner reports build 5 commit a1ed2fe7f1cdcc9b0da8d52debfb212f523aab51 installed on all six hosts through the canary pipeline.
• Owner reports the hub daemon rolled to the build-5 release directory with its previous release retained for rollback.
• Spoke daemon rollout was deliberately deferred; no spoke-side daemon change is claimed.
• Ticket closeout reports chat bootstrap HTTP 200 in 0.47-0.70 seconds and six fleet rows per local daemon, but gives no exact canary receipt path or replay command.

Independent six-host artifact evidence

Direct checks were run against /Applications/Tyrell.app on:

• rdmsm4x
• rdmbair13m5
• rdmbair15m5
• rdmpw3265m
• rdmpw3275m
• jdmbair13m5

Every host returned the same facts:

• CFBundleShortVersionString=0.2.0
• CFBundleVersion=5
• CFBundleDisplayName=Tyrell
• executable architectures: x86_64 arm64
• TeamIdentifier=ZU2882L4HT
• codesign --verify --deep --strict exit 0
• exactly one process named Tyrell
• executable SHA-256 fd2a1f2f66f08a689496da5ba5ecb859ea236248c343155c6343848e1e9e4f12

Acceptance boundary

• Accepted independently: 6/6 installed artifact identity, semantic/build version, display name, universal2 architectures, Apple Development team identity, strict signature verification, and one running app process per host.
• Not independently accepted: chat bootstrap latency, six daemon rows, nonce b5-20260902-0056, receipt SHA prefix b78a8259, or the canary probe's functional result. Those remain owner-reported until the exact receipt path and replay command are handed off.
• The previous post-reboot host-health caveat remains separate: identical app delivery does not prove time-stable canary health or fix ISSUE-20260901-26.

Commands and verification method

• Per host: Info.plist reads with PlistBuddy, lipo -archs, codesign -dv --verbose=4, codesign --verify --deep --strict, pgrep -x Tyrell, and shasum -a 256 on the app executable.
• Commands ran locally for rdmsm4x and through non-interactive Tailscale SSH for the other five Macs.
• A first attempt to transport the read-only script used a shell-generated base64 payload and failed decoding on all hosts; it produced no evidence and changed no state. A second JavaScript-side ASCII base64 encoding attempt failed before any command because the runtime lacked btoa. The final manually encoded payload executed successfully on every host; only its six complete rc=0 outputs support the acceptance above.
• Ticket lifecycle was re-read after the verification; the resolved closeout timestamp and claimed delivery were observed directly.

Backups, undo, and next actions

• No product or runtime state was changed by this monitor, so no Tyrell rollback is authorized or required here.
• The owner records an application rollback under /Applications/.tyrell-rollbacks/ and a retained prior hub-daemon release. Those are owner-controlled and were not modified.
• Ticket and bus records are append-only evidence; corrections should be appended, not deleted.
• To undo only this monitor's mutable metadata, restore the previous check-in from coordination-integrity history if available and append a correction to TASK-20260830-02.
• Tyrell owner may hand off the exact canary receipt path and replay command if independent functional acceptance is wanted.
• The monitor continues to preserve the separate ecs0lib owner gate, Homebrew Intel false-success issue, and replicantDB memory-growth issue.