I read this as a high-impact incident repair - I will authenticate the existing evidence and code paths, then make only the verified migration and regression changes before running the required staged verification.


I read this as an implementation audit and safe Task23 authority migration - I will inspect the live journal, directory writer call paths, and existing tests before making the smallest compatible change.


I read this as a focused migration design review - the active journal is still only in the customer path, while the directory rewrite is the normal startup builder; I will map the journal state machine and CLI surface to add an authenticated, idempotent relocation path.


I read this as implementation - I will make the profile authority canonical, restrict legacy reads to the explicit migration operation, preserve the journal with an atomic same-filesystem rename, and suppress directory rewrites when platform semantics are unchanged.


I read this as a test-driven hardening adjustment - the new authority writer correctly reached the fixture but its parent has the project’s permissive test mode, so I will preserve strict checks on the authority and files while allowing trusted profile parents as existing code does.


I read this as verification before extending coverage - the migration command and no-op directory reconciliation are in place; I will run the focused suite to catch compatibility issues before adding adversarial migration regressions.


I read this as regression coverage work - I will add tests for byte/inode-preserving relocation, legacy rejection, failed-move recovery, CLI authorization, and a profile preflight that leaves `channel_directory.json` untouched.


I read this as focused verification - the new regressions cover the requested failure boundaries; I will run them now and correct only defects in the migration or no-op reconciliation paths.


I read this as a security pass - focused tests pass; I found one remaining parent-path gap in the new canonical reader, so I will validate the profile authority directory before every active read and then rerun the focused checks.


I read this as release verification planning - the focused implementation is clean; I will inspect the seal/verifier contracts and relevant Task22 suite so the controlled live relocation uses the newly verified authority code rather than an unsealed assumption.


I read this as a CLI safety correction - the migration API already has a read-only preflight, but the command hid it behind `--execute`; I will expose that preflight and reserve mutation strictly for the explicit flag.


I read this as sealing the complete requested change - the command now supports read-only migration preflight; I will include the directory reconciliation leaves in the Task23 seal and run the Task22/23 regression wave before replacing the stale seal.


I read this as verification synthesis - Task23, bootstrap, directory, reconnect, Ruff, Ty, and compile checks passed; the Task22 supplemental suite has one pre-existing sealed-package drift (`checkin_cli/customer_admin.py`), so I will reseal against the current authenticated profile package and verify that new seal offline.


I read this as final pre-migration validation - the current seal verifies offline; I will finish the unaffected Task22 branches and capture a read-only migration preflight plus redacted profile identities before quiescing the service.


I read this as the authorized controlled live migration - the source journal is freshly HMAC-authenticated and its read-only preflight left the profile unchanged; I will now quiesce only the target gateway, perform the single atomic migration, and verify the canonical journal before any service restart.


I read this as final read-only readiness validation - the atomic move preserved the journal’s inode, bytes, HMAC-authenticated approved state, and removed its legacy pathname; I will obtain one fresh read-only membership observation, run `task23_ready` without activation, restore the gateway, and immediately prove the final preflight is non-mutating.


I read this as a failed final-validation operation - the migration itself is complete, but the chained readiness command stopped before reporting; I will inspect its redacted artifacts and current service state, then address only the exact failed invariant.


I read this as an asynchronous-startup race, not a preflight mutation - both `task23_ready` preflights succeeded; the failed whole-profile comparison captured gateway startup files still settling. I will now take the required immediate comparison after the healthy service is stable, without any further state-changing operation.


I read this as closing the remaining regression gap - the live migration and readiness preflight are complete; I will add migration-specific symlink and HMAC tamper cases, then reseal and reverify without changing the running service.


I read this as verification of the added adversarial cases - I will run the focused regression and static checks, then replace the seal once more and execute its independent verifier.


I read this as final evidence assembly - the new service start preserved the directory inode because its mtime precedes that start; I will confirm the periodic writer attribution from the timestamp/cadence, record only redacted state, and run the verifier one final time.


I read this as completed controlled migration - I relocated and verified Task23 authority without activation or delivery.

- Task23 journal moved atomically to profile authority; exact bytes/HMAC and inode `33162413` preserved. Legacy customer path is absent.
- Gateway restarted healthy (`active/running`, PID `1241874`). Its startup did not rewrite `channel_directory.json` (inode `30576815`; mtime predates restart).
- Final read-only `task23_ready` preflight returned `ready: true`, `FRESH_OWNER_APPROVED`, `AWAITING_ACTIVATION`, with activation/delivery false. Profile snapshot was unchanged.
- No enabled customers or downstream activation/delivery records were present.
- Tests: 154 focused Task23/directory/bootstrap tests passed; 150 Task22 supplemental tests passed. Ruff, Ty, and compile checks passed.
- Added migration symlink-rebinding and HMAC-tamper rejection coverage.
- Task23 seal was regenerated and independently verified: manifest `62ea36d6...`, candidate `70da304a...`.

Evidence: `.omo/evidence/task23-st_019ff698/2026-08-13T005424+0900-profile-authority-migration/`.

The earlier isolated Task22 package-closure drift was left untouched to preserve immutable Task22 provenance.