Recorded a new rdmbair15m5-to-canonical preservation intake and the final RTTy archive-policy evidence boundary that arrived after the primary 01:38 ecs0lib monitor checkpoint.

Scope and changes

• Execution host: rdmsm4x; monitor remains metadata-only under TASK-20260830-02.
• Read and acknowledged rdmbair15m5 reconciliation request 20260903-013736-8B4B03E2 and RTTy handoff evidence message 20260903-013803-0DF25836.
• Replied to the reconciliation owner in 20260903-013955-A3D21132 with exact current writer lanes, collision holds, and preservation-first intake routing.
• Changed no product/library source, canonical project root, live database, installed application, runtime process, signature, deployment, credential, or foreign ticket lifecycle.

rdmbair15m5 reconciliation intake

• Rich expanded the remote owner's scope to inventory meaningful work under rdmbair15m5:~/Documents/Codex and ~/dev/fleetbuild/rdev, preserve it, and reconcile it with canonical rdmsm4x:~/dev.
• The monitor instructed the owner not to write into any live canonical root and not to copy live .git, provider state, credentials, or task/session databases.
• Dirty/untracked material is to be preserved under /Users/richh/dev/_migration/conflicts/rdmbair15m5-20260903/<project>/ with source-host provenance, explicit file manifest, SHA-256 inventory, and secret scan. Clean committed history should arrive as host-labelled refs/bundles or per-project patches.
• Each project packet must name the source commit/ref, dirty paths, intended canonical destination, collision result, and requested current owner. Integration remains owner-gated.
• Active protected lanes supplied to the remote owner: ecs0lib's 14 ownerless files; ReplicantDB Build 35 rollout/cleanup discovery; Tyrell Build 13; Xentropy 9c317b5 re-review; RTTy Build 45 handoff; and the existing Tyrell root/chat claims. Lease expiry alone is not permission to write.
• The monitor offered bounded independent verification of exact packets after transfer, not direct integration.

RTTy handoff evidence correction

• The 1,054-second adversarial archive-policy matrix emitted all five expected PASS lines and its Codex command event reports exit code 0.
• The wrapper's printed ARCHIVE_POLICY_EXIT= value is blank because it used bash-style PIPESTATUS[0]; zsh uses the one-based pipestatus array. The semantic PASS evidence is strong, but it is not an independent direct status capture.
• The receiving goal correctly requested an unmasked direct exit status or corrected zsh capture before the owner seals the clean checkpoint and hands it over. Installed Build 44 remains protected and the monitor did not interrupt or duplicate the suite.

rdev canonical placement

• Follow-up request 20260903-014404-54E39AEC asked whether the complete but commitless rdmbair15m5:/Users/richh/rdev tree should become a new /Users/richh/dev/apps/rdev project and what remote it should use.
• Live canonical evidence resolves the collision: /Users/richh/dev/concepts/rdev already exists as the macOS/iOS rdev project at 87564ac95dc5f32410fbdf4105c4393eeb61555a, with main, origin/main, fleet/main, and backup/main aligned.
• Existing private remote https://github.com/richhdoty/rdev.git is already described as the canonical rdev macOS and iOS application. No new remote or /apps/rdev root should be created.
• Canonical tracked content is clean, but .codex/ and Codex Image Aug 4, 2026, 09_34_32 PM.png are untracked and of unknown ownership; they remain untouched.
• Reply 20260903-014607-738A0338 directs the laptop owner to create a values-free local recovery commit only after secret/build-junk checks, then deliver a Git bundle and manifest under /Users/richh/dev/_migration/conflicts/rdmbair15m5-20260903/rdev/ with comparison base 87564ac. Integration must use a new isolated worktree/branch after file-level collision review.
• The current project-registry decision preserving /Users/richh/rdev as the isolated control plane is now superseded by Rich's canonical-~/dev directive, but the registry should change only after the recovery delta is accepted.

Xentropy re-review and Aqua handoff

• Independent archive-only re-review of exact clean 9c317b5e74e7701a50cb719b125a947213ce5901 now returns ACCEPT for one rdmbair15m5 canary. Report /Users/richh/dev/_handoff/xentropy-vnext-review-9c317b5/CLAUDE-REVIEW.md has SHA-256 4c51c89f82a2e24c494e22d632a0612d69712fd87b73087d7f28b01af1423fce and reproduces 272/272 tests plus both product builds with ecs0lib 9f278679.
• The earlier two P1 findings are closed at the reviewed source boundary. Residual canary conditions remain operational: pin exact ecs0lib, run in an active GUI domain, use the verifier as the gate, and exercise both recovery layers before host two. The report explicitly notes verifier coverage is hand-verified rather than behaviorally tested and deployment recovery layer 2 remains a manual runbook.
• The background installer attempt failed closed before remote mutation with errSecInternalComponent; no ad-hoc signing fallback occurred. The owner then assigned the exact no-edit install to Claude's Aqua session in 20260903-014744-CBD6E3EE.
• Direct pre-Aqua readback of rdmbair15m5 still found the per-user XEntropy app at version 0.1.0 build 1 and no matching process. Therefore the canary is approved but not yet installed or accepted at the observed instant. Retirement, rollback proof, host two, and fleet expansion remain pending.
• Monitor acknowledgement 20260903-014817-EF274C80 preserves those boundaries and declines to duplicate the assigned install or touch catalogs, TCC, providers, Keychain, credentials, rollback generations, or live runtime.

Fleet audit integrity recurrence

• The 01:34 audit was internally consistent, but the next generated report, /Users/richh/dev/fleet/audit/audit-20260903-0149.md, SHA-256 3612fc4c1010894949bfa24b5d682a433aef39361e9bb7f8e7a3d7e836b3bd9e, reproduced the report-integrity defect.
• Its rdmsm4x row says 14 claimed versus 15 measured while assigning verdict ok, and the discrepancies section incorrectly says every host matched. All six hosts remained reachable and every monitored launchd job was reported healthy, so this is evidence of unreliable comparison/verdict generation rather than a fleet outage.
• The recurrence was routed high-priority to the fleet owner as immutable bus message 20260903-015005-2D26C74D and appended to the monitor ticket. The audit script remains owner-controlled and was not edited.

Recovery and outstanding actions

• Immutable bus messages are not rewritten. Correct them only with additive replies.
• The rdmbair15m5 owner should deliver one collision-checked packet at a time; current canonical owners decide integration.
• The rdev owner should target the existing /Users/richh/dev/concepts/rdev lineage and existing private remote, not create a second project or remote.
• The Xentropy owner should complete only the exact Aqua rdmbair15m5 install, verifier gate, and two-layer recovery proof; no second host should advance from source acceptance alone.
• The RTTy owner should capture the unmasked direct archive-policy result, then seal the exact commit, ancestry, changed paths, commands/results, retained logs, release-clone/artifact identity, limitations, and claim disposition requested by Rich.
• The fleet-audit owner should reproduce and repair the claimed-versus-measured comparison/verdict path; until that is independently verified, use the raw host/job observations but do not accept the generated ok/None summary as authoritative.