Fleet changelogs · dev.ecs0.net
rdmsm4x-changelog-20260828-1524-tyrell-round2-release

rdmsm4x — Tyrell Round 2 release

Tyrell Round 2 was integrated to local canonical main, promoted as a signed private master runtime, accepted on the designated app canary, and deployed to every reachable app target. The result matters because Tyrell now has a cohesive Signal Glass fleet/usage interface, production chat authority and native clients, explicit evidence semantics, and fail-closed application lifecycle controls without overstating the two offline hosts or any later-phase research as shipped behavior.

Scope and lifecycle truth

Product work integrated

Key source and documentation paths

The canonical checkout's pre-existing /Users/richh/dev/apps/tyrell/.DS_Store modification was preserved and not staged, rewritten, or reverted.

Exact signed artifacts

Tyrell.app

tyrelld master runtime

Production backup and rollback

Designated-canary acceptance

Reachable-fleet rollout

The stale local repository-build app process at PID 37508 was verified by exact path, executable hash, and signing identity before it was terminated. The managed app remained running and the rollback copy was retained. No unknown-owner process was killed.

Only the master daemon was promoted. Client-daemon and TyrellBar fleet rollout remain separate pending states.

Final verification evidence

Primary commands run

replicantDB reuse handoff

Outstanding owner actions and next gates

Undo guidance

  1. Source: because canonical main was advanced only by fast-forward and no remote push occurred, create a named rollback branch at 42e9287a7d79548b7b41f61f3f9c3ce1099c731b before any requested source reversal; do not discard the preserved .DS_Store change.
  2. Master daemon: use the retained pre-cutover backup/release pointer and the project installer to restore the preceding signed release, then re-run both status probes and SQLite quick_check.
  3. App on one host: stop only the exact managed Tyrell executable, restore that host's timestamped .tyrell-rollbacks bundle, verify SHA/signature/bundle/Team identity, and relaunch exactly once.
  4. Fleet: roll back only hosts that accepted the candidate; leave the two offline/pending hosts untouched.
  5. Data: restore a database backup only with an explicit data-rollback decision; the source/app rollback does not require destroying current operational records.

No credential values, provider payloads, prompts, responses, memory bodies, private database contents, or secret-bearing URLs are included in this record.