I read this as a read-only audit of message146 approval state and provenance - I’ll inspect the sealed journal, callback, preflight, schema-fix evidence, and token derivation, then verify whether c01e or 350b was the durable binding at click time.


I found the task log trail; now I’m reading the exact sealed artifacts and the token-derivation sources to verify click-time binding, reseal history, and whether anything changed after publication.


I have the audit trail locations; now I’m pulling the exact lines that mention the competing child IDs, the published receipt, and the derivation/reseal code so I can classify the mismatch without guessing.


I’ve got the candidate evidence set; now I’m reading the sealed receipts and verifier outputs directly so the answer can pin the exact child tokens, journal state, and whether any post-publication mutation happened.


The first verifier set is a different run (update 629525075, child 01e3...), so I’m now locating the specific 629525077 click path and the c01e/350b reseal lineage to avoid mixing separate consumptions.


I’ve isolated the click-time evidence now; next I’m reading the derivation function itself and the publication/republication receipts so I can say whether c01e was a fresh deterministic recompute or a later replacement.


The 629525077 block is now clearly the exact click path, so I’m reading the sealed blocker file itself plus the reseal manifest/history to tie c01e, 350b, and the current journal into one chain.


I have the two conflicting states pinned; I’m now checking whether the reseal actually replaced the journal artifacts or just recomputed the child deterministically, because that decides whether this is a reporting error or a later mutation.


I’ve confirmed the later block evidence file exists and is newer; now I’m reading the verifier code that computed the child token so I can separate deterministic recomputation from any journal swap.


I’ve got the verifier code paths; now I’m checking the live profile files themselves for the exact current journal/card/callback bytes, timestamps, and whether the sealed journal file was rewritten after the earlier publication.


I found the live profile files and the replay archive set; now I’m extracting the exact current owner callback and generation records so I can compare pre- and post-reseal bytes instead of inferring from summaries.


I’ve got the two authorization snapshots; I’m now pinning their on-disk hashes and modification times so the conclusion can distinguish the original publication from the later replacement cleanly.


I’ve pinned the file replacement chain; I’m grabbing the remaining evidence-file hash for the live block snapshot so the final verdict can quote the exact artifact set without gaps.


I read this as a provenance audit of message146’s live approval binding - current authenticated state is c01e, and I’m treating the earlier 350b report as stale/replaced.

SAFE_CONSUME_C01E_EXISTING_APPROVAL

- Current authoritative journal: `/home/cube/.hermes/profiles/dualcoachtest/data/owner-actions/task23-coach-schema-repair-authorization-v1.json`
  - sha256 `bf22d5da5706793562027f2e3694542b8b41ad5a136822401495dcbe731df96d`
  - mtime `2026-08-14 00:10:28.593745849 +0900`
  - `state=owner_authorized`, `update_id=629525077`, `message_id=146`
  - `card_id=628e91aacce1e48ebd8c6638`
  - `prospective_child.token=c01ec26a0a5f6a1e`
  - `parent.token=01e3b5d1739a5c49`, `parent.generation=3`, `parent.record_digest=619183a93ab76b440cc7acf6b4b8be22a658dcf3ebc0dea7406ab2603a0612c2`
  - `seal_digest=638be6d4be234c3e8467617f10dbd4f5d5e2c1795cebade53b1e509425ae1613`
  - `schema_candidate_sha256=28a712ef32ce69008c460beeee6cc11da042bda05c0f343b849ae65cfe03407b`

- Previous journal: `/home/cube/.hermes/profiles/dualcoachtest/data/owner-actions/task23-codex-compatibility-repair-authorization-v1.json`
  - sha256 `7b3c183184b0f989a330f732a6cb75bd48ee39613e80fcfd1bbedac45fdbb67b`
  - mtime `2026-08-13 22:02:03.366953460 +0900`

- Live change after publication:
  - `draft-generations.json` sha256 `64eaec7cd3a2dae567f0091de18a4ce81956bc5ed63192aeb1e92a091528f796`, mtime `2026-08-13 22:03:25.223796958 +0900`
  - ingress receipt file sha256 `3e946f64ac09d2bba824037e1ef634fa3cec725fc07ab2382326aab1ff2c58be`, mtime `2026-08-14 00:10:39.823850137 +0900`
  - evidence file: `.omo/evidence/task23-st_019ffbad/2026-08-14T001200+0900-terminal-precondition-block.redacted.json`
    - sha256 `ee7f39c8056511de52659aa0e39dc887cac095806b7b07b0a04c282e57e81844`
    - mtime `2026-08-14 00:14:57.399731001 +0900`

- Validation status:
  - `journal_unchanged_by_direct_verifier=true`
  - `live_preflight=passed`
  - `direct_verifier=passed`
  - `focused_callback_consume_generation_restart_tests=84 passed`
  - `ruff_and_compile=passed`

- Exact reason the earlier completion said 350b while live journal says c01e:
  - journal replacement / republishing after reseal, with a deterministic new child token
  - not tamper
  - not a mere reporting typo
  - the old 350b-bound completion is stale relative to the newer sealed journal

- Relevant provenance file hashes:
  - `.omo/senpi-task/logs/st_019ffb40.jsonl` includes the earlier 350b completion summary
  - `.omo/senpi-task/logs/st_019ffbb1.jsonl` states the current audit target is c01e vs 350b
  - `.omo/senpi-task/logs/st_019ffbad.jsonl` records the stale-bound-contract stop