I read this as a read-only incident audit - gather the transcript, source, and loaded-artifact evidence, then pin the exact failure branch and root cause.


I’m pulling the task transcript/evidence and the authorization code paths in parallel so I can tie the live failure to a specific branch, not just the message.


I have the task/evidence context; now I’m tracing the exact authorization code and the two live invocations to separate the failing branch from stale-artifact theories.


The source isn’t in the top-level grep, so I’m narrowing to the package paths and the recorded live verifier outputs that should contain argv, module, and file-origin details.


I’ve located the profile workspace and wheel metadata; now I’m reading the live launcher/runtime files and the failed-consume receipts to map the argv all the way into the specific module/function.


I found the actual source files in the profile workspace; next I’m reading the canonical launcher and authority module together with line numbers so I can point to the precise failing branch.


The module I needed is the older onboarding authority; I still need the exact `resolve_authorization`/`consume_authorization` implementation, so I’m locating that compatibility-repair store and its branch table now.


I have the code path now; I’m extracting exact line numbers and the two live attempt receipts so I can name the precise branch and the invocation that reached it.


The task logs don’t show shell arguments directly, so I’m reading the underlying session JSONL and the exact wrapper scripts to reconstruct the two live argv chains.


I have the code and logs; the only missing piece is the exact CLI argv from the live attempts, so I’m mining the session trace for the shell command lines themselves.


The session trace doesn’t expose bash argv directly, so I’m using the repository’s own generated receipts and runbook artifacts to recover the exact command shape.


The failure branch is now obvious; I’m pinning the deployment path and invocation shape that reached it, so the root cause can distinguish launcher/wheel drift from a live-guard failure.


I’ve pinned the dispatcher and source hash; the last thing to rule out is whether that exact error string appears anywhere else, or whether the live retry only hit the single live-registry guard.


I still need the loaded-origin proof, so I’m searching the generated provenance artifacts for the exact module path and digest the live retry actually loaded.


I still need to distinguish “repo script used” from “installed wheel used,” so I’m checking for the actual entrypoint binaries and their shebang/import targets.


I’m going one step further on a disposable copy so the audit can separate a transient live registry failure from a stable code-path failure.


I now have the live registry state; I’m reading the coordinator’s `_ensure_live_registry` implementation because that decides the exact guard that raised the error.


I need the exact failure mode inside `_ensure_live_registry`, so I’m checking `_configure_registry` for the specific exception path that would make the guard false even when the owner data itself is correct.


I’ve got the branch and the live-state evidence; I’m doing one last search for a provenance file that records the actual command-line argv, not just the logical operation.


I don’t have a durable shell transcript of argv, so I’m checking the runbook for the exact invocation convention that was used for this script family.


I read this as a read-only root-cause audit - pin the exact failing guard, prove which artifact was loaded, and give a safe redeploy path.

- Live attempts: `task23-codex-compatibility-repair consume` with the journal-pinned args from `task23-codex-compatibility-repair-authorization-v1.json`:
  `--expected-card-id c1b9da68e64b203818f98f3e --expected-callback-update-id 629525075 --expected-callback-message-id 144 --expected-callback-data-sha256 932e6d41956bdad3e8fedb6dc49950bc39255a93f788fe74265c648aa4ba5e5b --expected-seal-digest ccf8aac822ff1414cd935b7bc860749df95e6cdfeb9648bb14cf7af14d52da6b --expected-parent-token e2f07f9a41431ff1 --expected-parent-generation 3 --expected-parent-record-digest 429a45f63878ae3fa568077ea057a6195486c8d40e6b137df8c9cc5da671a9c1 --expected-checkin-event-id wizard_995f04a3b8bc256fa13ff407 --expected-checkin-revision f266949e05195d9a23c728264f84507e3edcea207126f501df0251924c117ae1 --expected-child-token 01e3b5d1739a5c49`
  - Entry path/function: `/home/cube/projects/richard/hermes-agent/scripts/task23-codex-compatibility-repair` → `main()` → `Task23CodexCompatibilityRepairStore.consume_authorization()` → `resolve_authorization()` → `_resolve_authorization()`
  - The script enforces isolated Python (`-I -B`).

- Exact branch hit:
  - `gateway/platforms/task23_codex_compatibility_repair.py:539-545`
  - Guard: `if (not coordinator._ensure_live_registry() or coordinator.owner.key != resolved_authorization.owner.key): raise ...`
  - Proven side: `coordinator.owner.key == resolved_authorization.owner.key` from `cli-authority-branch-comparison.stdout.json`
  - Therefore the failing predicate was the left side: `coordinator._ensure_live_registry()` returned false in the live consume process.

- Exact source location for the guard chain:
  - `resolve_authorization`: `gateway/platforms/task23_codex_compatibility_repair.py:458-483`
  - `consume_authorization`: `gateway/platforms/task23_codex_compatibility_repair.py:485-545`
  - `_resolve_authorization` has the other two error branches:
    - `:815-817` `"Task23 compatibility consume authorization is unavailable"`
    - `:845-847` `"Task23 compatibility consume authorization is invalid"`

- Loaded-vs-current hashes:
  - Loaded/current store source: `/home/cube/projects/richard/hermes-agent/gateway/platforms/task23_codex_compatibility_repair.py`
    - SHA256 `382b3b65f9d333e1ff8dfa690689436e3c586f67f00ce1aaffff6bba5031f07b`
  - Stale sibling build artifact: `/home/cube/projects/richard/hermes-agent/build/lib/gateway/platforms/task23_codex_compatibility_repair.py`
    - SHA256 `6521db9971116587bce1a4c133cdbd75ed51b5a4a896fec07237d2a28ede4927`
  - Launcher script: `/home/cube/projects/richard/hermes-agent/scripts/task23-codex-compatibility-repair`
    - SHA256 `d57b447a837a5547aae1c59c0bfa0e55b5716289ef5940c65ed4e758c3651dff`
  - Conclusion: the live attempt was not explained by a stale source load; the loaded store source matched current repo source.

- Safe repair/deployment procedure:
  1. Redeploy/restart the gateway service so `NutritionCoachingCoordinator._ensure_live_registry()` revalidates cleanly in-process.
  2. Re-run the same `consume` argv once, unchanged.
  3. If it still fails, inspect `_ensure_live_registry()`’s reload/configure path, not `resolve_authorization()` or the callback pins.


I read this as a read-only live-context fault isolation - trace `_ensure_live_registry()`, reproduce it in a disposable driver, and isolate the first false sub-gate without restarting or consuming.


I have `_ensure_live_registry()`; now I’m finding the committed-registry loader and the profile-side files it depends on so I can test the same path in a disposable driver.


I’ve got the loader symbol; now I’m reading the profile-local package copies and the loader itself so the temp driver can report exact path/digest mismatches.


I found the profile-local package copies; now I’m reading the exact registry loader and lock gate that `_ensure_live_registry()` calls.


I have the loader, and now I’m isolating the lock/registry helpers that can make `_ensure_live_registry()` flip false even when the owner and profile are otherwise correct.


I have the activation path; now I need the exact loader and profile-root validation around `load_runtime_customer_registry()` to see which sub-check fails in CLI but not in gateway.


I need the exact enabled-activation receipt gate, because that’s the likely place where a process-local gateway can stay healthy while a fresh CLI reload fails.


I have the main branches; now I’m reading the committed-receipt comparison and the “enabled entries must have receipts” gate that can fail even when the gateway process is already up.


I’m collecting the profile-side evidence set now: activation journal, readiness receipt, feature epoch, service-state ledger, registry, and the gateway process command/environment.


I have enough to run a disposable, no-write probe. I’m exercising the same imports the CLI uses and surfacing only gate booleans, paths, and digests.


The current snapshot passes, so I’m mining the failure receipts for the recorded `_live_registry_error`/reload reason rather than guessing from today’s healthy state.


I found an older gateway log saying “committed activation receipt is missing or stale”; I’m checking whether the st_019ffb07 failure line repeats that exact reason or a different one.


I’m checking for an actual stale-snapshot load path, because that would explain a healthy gateway and a rejecting fresh CLI without any current-state inconsistency.


I still need the failure-time reason, so I’m scanning the live logs around the st_019ffb07 window for the first explicit registry error, not the generic outer exception.


I’m pinning the exact module origin in the disposable probe, because if the CLI loaded the stale snapshot tree that is the only explanation consistent with a healthy current profile and a reject.


I’ve isolated a likely stale-snapshot tree; now I’m running the same no-write probe with that tree first on `sys.path` to reproduce the failure mode and capture the exact sub-gate.


I’ve reproduced the stale-import failure: the stale snapshot package rejects the current activation journal before registry load. I’m reading its exact branch and line numbers now.


I have the branch; I’m pulling exact numbered lines so I can give one rooted cause, not a vague package mismatch.


I’ve got the stale branch line; I’m confirming the outer consume throw site so the root cause maps cleanly from caller to failing subcondition.


I read this as a stale CLI package, not a live-data problem - here’s the proven root cause and repair path.

- **Throw site:** `gateway/platforms/task23_codex_compatibility_repair.py:536-545`
  - `consume_authorization()` raises `"Task23 compatibility consume owner authority is unavailable"` when `not coordinator._ensure_live_registry()`.

- **Exact false subcondition:** stale `checkin_cli` rejects the current activation journal at
  `.../workspace/checkin_cli.stale-snapshot-20260730/checkin_cli/customer_admin.py:1234-1236`
  - hard check: `if journal.get("version") != 1: raise CustomerAdminError("activation journal version is invalid")`
  - current journal value: **version = 2**
  - that makes `validate_committed_activation()` false, then `load_runtime_customer_registry()` fail-closed, then `_ensure_live_registry()` false.

- **Loaded vs expected module origins/hashes**
  - loaded by failing isolated CLI/probe:
    - `...stale-snapshot-20260730/checkin_cli/customer_admin.py` → `9b8a99703b0ab9dbd00db7e2330d7f8020b7a88909800bc9e1db48c2e44a05da`
    - `...stale-snapshot-20260730/checkin_cli/customer_coaching.py` → `5dad91c0c9b2d8740bd72cbc694cbddfff8ee8a54ff3d88788b44c091f54da3c`
  - expected/current workspace copies:
    - `.../workspace/checkin_cli/checkin_cli/customer_admin.py` → `68d8145e99534a6bc83e5147e5392e02ce88987c6560bea4da0674965fef89ca`
    - `.../workspace/checkin_cli/checkin_cli/customer_coaching.py` → `320cab3fbc114b9a8228aa489a51dc94949352af670a978165be4eb64cfbb63c`

- **Why gateway works while CLI rejects**
  - the gateway’s live diagnostic points at the current workspace module path and healthy registry state;
  - the rejecting CLI/probe resolved the stale snapshot tree first, so it enforced an older activation-journal schema (`version == 1`) against a current committed journal (`version == 2`).

- **Safe repair/deployment procedure**
  1. remove the stale snapshot package from the CLI/runtime import path,
  2. ensure the process resolves `.../workspace/checkin_cli/checkin_cli/*` (not `checkin_cli.stale-snapshot-20260730`),
  3. restart/redeploy the gateway,
  4. rerun the same consume argv unchanged.