rdmbair15m5 — Tyrell Build 20 designated-canary launch

The exact signed and notarized Tyrell Build 20 app and daemon were installed only on this designated canary after a verified online database backup; a fresh fail-closed guard now owns the same-process runtime acceptance window.

Scope and files changed

• /Applications/Tyrell.app now contains Build 20.
• /Users/richh/Library/Application Support/Tyrell/bin/tyrelld now resolves to the exact hash-addressed Build 20 release.
• /Users/richh/Library/Application Support/Tyrell/tyrell.db received one additive last_seen_at column from the Build 20 migration.
• /Users/richh/.tyrell/build20-canary-20260912-96a5fc0/ contains the fresh guard, policy, evidence, exact candidate, and retained rollback snapshot.
• /Users/richh/.tyrell/app-staging/37a0081b06af970866e84877cc74524cdac750580d5fad22fb83d92d0eb0aa5c/ contains the pinned app lifecycle and probe tools.
• /Applications/.tyrell-rollbacks/20260912-011342-2c5ca2a674fe/Tyrell.app retains the exact Build 17 app.
• /Users/richh/Library/Application Support/Tyrell/backups/20260912-0110-build20-preflight-96a5fc0/ retains the pre-migration database and LaunchAgent plist.

Commands run

• SQLite online .backup, followed by read-only PRAGMA quick_check, schema, and row-count verification.
• canary_guard.py prepare to bind exact rollback artifacts and the database backup.
• Pinned redeploy_app_fleet.zsh --execute-canary and install_app_local.zsh for /Applications/Tyrell.app.
• canary_guard.py run under nohup, which installed the exact daemon and began the unchanged physical-footprint-v2 monitor.
• run_tyrell_app_canary_probe.zsh and issue_tyrell_app_canary_receipt.zsh with nonce build20-20260912-96a5fc0-canary1.
• Independent codesign, lipo, spctl, stapler, launchd, process-path, HTTP, SQLite, and hash checks.

Verification evidence

• App executable SHA-256: 423871cede8ae6313c486929f544dbee8d1085540b2d37896de6f2c2d4de90fd.
• App canonical arm64 full CodeDirectory hash: 37a0081b06af970866e84877cc74524cdac750580d5fad22fb83d92d0eb0aa5c.
• App designated-requirement hash: 9943c03ba47653aab0eacfd8fab8ea70d887d4392fd24832b96bffaa9c502aee.
• Daemon SHA-256: 71bf6122e453315205f3f0dfaf3f1a3a6cf2d99dfe901cda88e7ac79a8112c77; universal x86_64 arm64, strict Developer ID signature verified.
• Guard PID 86129; daemon PID 86219, start Sat Sep 12 01:14:35 2026; launchd runs 1 and never exited.
• Both status routes and both authenticated permission routes returned HTTP 200; initial guard evidence recorded 42 lsof rows and two TCP descriptors.
• Pre-migration database backup SHA-256: db29432be4fc962a18436f15f29d1677b10bc7c541d7f78eab6c00f7ecce3c8f; backup quick_check=ok, 152,805 file rows, no last_seen_at.
• Live database after launch: quick_check=ok, one last_seen_at column, 152,805 file rows.
• Fresh app usage/chat probe SHA-256: e7e54259bd325fac54578f6e3a1d130fa113369f1bced5c84648fc293fe45049.
• Host-issued app receipt SHA-256: eaad5865d2420aaeef18821919e3d90157fa5b5e5a6c54f322de6b5564886287.

Backup and undo

• Daemon rollback SHA-256: dbc440bd54b85a54dd6c4150b23b3e508bff7d8d8080687d81b9ba7ac2cbbcf0.
• App rollback SHA-256: 8693ebce3d474fed049597d11e3579bf1cd32f7a78acfd9544c78d77592da05e.
• The guard will restore those exact artifacts on a failed gate.
• Do not overwrite the live database with the pre-migration backup. Rollback deliberately retains the additive column and current data.
• For an operator rollback, verify and stop only the active guard before running /Users/richh/.tyrell/build20-canary-20260912-96a5fc0/canary_guard.py rollback; never run it concurrently with the guard.

Outstanding owner actions

• None now. The automated monitor owns the short, six-hour, and 24-hour gates.
• No fleet expansion is authorized. After the 24-hour memory gate, independent CPU review, a fresh app probe/receipt, and a controlled reboot stable-path proof remain required.