I read this as an exact successor certification-and-deployment run - I’ll replay the established predecessor workflows unchanged where required, fail closed on any gate failure, and deploy only after all three gates pass.


The successor is internally sealed and its profile source already matches the candidate wheel byte-for-byte. I’m starting the append-only certification root now, with Gate18 and Gate19 isolated from each other and Gate20 using the predecessor’s corrected normal-host environment rather than the invalid temporary-home/network sandbox.


The first Gate18 attempt did not execute the golden tests: its parity precheck incorrectly treated `tests/test_customer_admin.py` as a wheel member, which Python wheels do not ship. This is an authored harness-configuration failure, not a candidate result; I’m preserving that failed root and rebinding a fresh append-only root to the established package-module-only parity semantics.


Gate18 now completed on the corrected, fully configured harness: verifier and package parity passed, and all 43 token-rotation golden cases passed. I’m moving to the independently isolated predecessor/successor Gate19 matrix.


Gate19 passed independently: predecessor overlay 85/85 and successor matrix 128/128. I’m starting corrected Gate20 now, including the full gateway suite plus both source and isolated installed-wheel package suites.


Gate20’s authoritative full gateway suite passed 8,159/8,159 (59 skipped). The profile source suite then failed during collection because the Hermes service interpreter intentionally lacks the profile wheel’s test dependency `typer`; no candidate test ran. This is the same class of environment/harness failure the task requires separating from candidate causality. I’m preserving it and running the package suites with the candidate author’s established normal-host Python dependency environment, while retaining the already-passed authoritative gateway result.


The corrected package suite exposed a non-certifiable Gate20 result: 676 passed, but three tests failed (two because the sealed read-only source was copied with non-writable modes by an in-test wheel build, and one unchanged adaptive journal inode-replacement assertion failed). These are outside the successor delta, but Gate20 is not all-pass, so I am stopping fail-closed without installing or restarting anything.


I read this as certification/deployment execution - Gate20 failed, so I stopped fail-closed without installation or restart.

## FAIL_CLOSED_UNDEPLOYED

**Evidence root**

`/home/cube/projects/richard/traning coach/.omo/evidence/task26/task26-certification-deployment-4a8627af8f9b931d537e17dbd3e357b7a0f2b2abffdbf28f6ad19a8d32893ec0-v3-st_01a00b39`

### Gates

- Gate18: **PASS**
  - 43 passed, 85 deselected
  - Receipt SHA-256: `5eb76f15fd09f3599341ff46f189d834944a85b08d13c63cafa987916d51a805`
  - JUnit SHA-256: `19153cc6e20d045066e41c8f7781ef2b9dba92eeb07696b229882d2c5c85820f`
- Gate19: **PASS**
  - Predecessor: 85 passed
  - Successor: 128 passed
  - Receipt SHA-256: `75fe11d12b15a54d4f1d8fcbe3f04656540c3e6fbb8e2ec425775eb1e2b72c10`
- Gate20: **FAIL**
  - Full gateway: 8,159 passed, 59 skipped
  - Corrected source package: 676 passed, 3 failed
  - Receipt SHA-256: `73fad5e0fc2c5cedd579db4584652c3cebb85b9b02551628e5121eaa49d4ea65`
  - Full-gateway JUnit SHA-256: `39b063136b6af676639f5ee90b071fadcdfc087e0c65ea7d17e29deca5d07aad`
  - Package JUnit SHA-256: `d54ee72e06c89ff020a7c12bd9d3f097395fd1d14300c60bed573b65873bf9f1`

Failed nodes:

- `test_overlay_recovery_rejects_symlink_and_data_inode_replacement`
- `test_wheel_contains_exact_policy_and_installed_resource_bytes`
- `test_installed_resource_loader_rejects_missing_and_mismatched_bytes`

The latter two encountered sealed-source permission behavior; the adaptive journal assertion is outside the successor delta but remains a real failing test and was not adjudicated away.

### Deployment

- Deployment receipt SHA-256: `3f082ea9ca35dd50518c7473944bb5a514df709a2654f97f3a08f1c3f58e9dc9`
- Receipt index SHA-256: `def6e4d98386d11ad88067d1fd81a56c00d90cc1484a062d92f2c6a70d9d285f`
- Wheel installation: **not performed**
- Service restart: **not performed**
- Direct URL / installed-wheel proof: **not produced**
- Loaded-byte health proof: **not produced**

### Live invariants

Before and after state SHA-256:

`bc7040208399c785f30afd48841b3628dfde451466e973bf1127a22efd834edb`

State remained:

- customer enabled: `false`
- adaptive activation: `false`
- adaptive delivery: `false`
- bootstrap generation: `5`
- bootstrap state: `AWAITING_ACTIVATION`

Authority, customer tree, and profile package inventories were byte-identical before/after.

### Service

- `MainPID=0`
- `ActiveState=failed`
- `SubState=failed`
- No loaded module process exists to certify.

**Blocker:** Gate20 package suite is not all-pass; therefore `PASS_CERTIFIED_DEPLOYED` cannot be issued.


I read this as read-only Gate20 failure diagnosis - I’ll reproduce only in disposable `/tmp` copies, compare predecessor and successor surfaces, inspect state/order effects, and make no adjudication or deployment changes.


The code path shows the adaptive assertion is structurally suspicious: the test itself atomically replaces the pathname after reading, while production correctly detects the inode change but does not restore an attacker-supplied replacement. I’m now testing that observation across isolated, file-level, reordered, and predecessor-overlay runs.


I read this as Gate20 root-cause diagnosis - I reproduced failures only in disposable writable copies and made no source, evidence, live-state, service, or Git changes.

## Exact Gate20 paths

Relative to project root:

- Receipt:
  - `.omo/evidence/task26/task26-certification-deployment-4a8627af8f9b931d537e17dbd3e357b7a0f2b2abffdbf28f6ad19a8d32893ec0-v3-st_01a00b39/receipts/gate20-receipt.json`
  - SHA-256: `73fad5e0fc2c5cedd579db4584652c3cebb85b9b02551628e5121eaa49d4ea65`
- Full gateway:
  - `.../artifacts/gate20-full-gateway.junit.xml`
  - `.../artifacts/gate20-full-gateway/stdout.txt`
  - `.../artifacts/gate20-full-gateway/stderr.txt`
- Initial source-package collection failure:
  - `.../artifacts/gate20-source-package.junit.xml`
  - `.../artifacts/gate20-source-package/stdout.txt`
  - `.../artifacts/gate20-source-package/stderr.txt`
- Corrected dependency-environment package run:
  - `.omo/evidence/task26/task26-certification-deployment-4a8627af8f9b931d537e17dbd3e357b7a0f2b2abffdbf28f6ad19a8d32893ec0-gate20-corrected-v2-st_01a00b39/artifacts/corrected-source-package.junit.xml`
  - `.omo/evidence/task26/task26-certification-deployment-4a8627af8f9b931d537e17dbd3e357b7a0f2b2abffdbf28f6ad19a8d32893ec0-gate20-corrected-v2-st_01a00b39/artifacts/corrected-source-package/stdout.txt`
  - `.omo/evidence/task26/task26-certification-deployment-4a8627af8f9b931d537e17dbd3e357b7a0f2b2abffdbf28f6ad19a8d32893ec0-gate20-corrected-v2-st_01a00b39/artifacts/corrected-source-package/stderr.txt`
  - JUnit SHA-256: `d54ee72e06c89ff020a7c12bd9d3f097395fd1d14300c60bed573b65873bf9f1`

## Reproduction results

Disposable root: `/tmp/task26-gate20-debug-r1`

### Correctly writable successor copy

The two wheel tests both passed after copying the exact source and applying `chmod -R u+rwX`:

- Three-node run, normal umask: **3 passed**
- Reversed order: **3 passed**
- Under `umask 077`: wheel nodes passed; adaptive node failed
- Result under `umask 077`: **2 passed, 1 failed**

Therefore, both wheel failures disappear under the corrected writable-copy harness.

### Adaptive node

| Run | Result |
|---|---:|
| Alone, normal umask | 1 passed |
| Entire containing file, normal umask | 76 passed |
| Reversed after wheel nodes, normal umask | 3 passed |
| Alone, `umask 077` | 1 failed |
| Entire file, `umask 077` | 75 passed, 1 failed |
| Reversed, `umask 077` | 2 passed, 1 failed |

This is **umask-dependent, not test-order-dependent**.

Exact failed assertion:

- Expected: 537 bytes, SHA-256 `c155aac2b0ee1e9411b011b86981f4106103d1e2306461d6492c5bb2147c1ce3`
  - Canonical overlay row + newline + `b'{"torn":'`
- Actual: `b'replacement'`
  - 11 bytes
  - SHA-256 `95713e9cbdd1dfcb2d4080c2537f418d43ca0da25f0d7d6631f4f7c97b89dc47`

Under normal `umask 022`, recreated files are mode `0644`; validation raises `"overlay journal file is unsafe"` before `os.replace` executes, so the assertion passes vacuously.

Under `umask 077`, files are mode `0600`; the injected `os.replace` executes, production detects the inode change and raises `"overlay journal file was replaced"`, but the pathname correctly remains bound to attacker-supplied `b'replacement'`. The test then incorrectly expects the original bytes to have been restored.

### Predecessor versus successor

Minimal predecessor overlay:

- old `customer_admin.py`
- old `test_customer_admin.py`
- new rotation-policy module absent

Relevant adaptive and diagnostic files were byte-identical between copies:

- `adaptive_nutrition.py`: `d3020f3a7a2eb3c639410c3912b5bd573decf78f889eb39a451b457626342bcb`
- `test_adaptive_nutrition.py`: `9d323da1fb01e3b05df6557795d87b6e26b8d0e7c8ca83f03b3287a237929369`
- `test_diagnostic_policy_package.py`: `4c18e9406edd809b83cdde913598530fd31e7fc0171212c3d049cb9a7e267a9c`

Under `umask 077`, predecessor and successor both produced exactly:

- wheel tests: 2 passed
- adaptive test: 1 failed with identical assertion

## Hypotheses

1. **Wheel failures came from sealed source modes propagating through `shutil.copytree`.**
   - Confirmed: original files are mode `0400`; in-test copies remained unwritable.
   - Both tests pass in writable copies.
   - Confidence: **99%**.

2. **Adaptive failure is caused by successor token-rotation changes.**
   - Refuted: relevant source/tests are byte-identical and predecessor/successor outcomes match.
   - Confidence it is not successor-caused: **99%**.

3. **Adaptive failure is shared-global or test-order contamination.**
   - Refuted: alone, containing-file, and reversed-order outcomes are identical for a fixed umask.
   - `_active_overlay_lock_token` was `None` before and after; each run used a fresh process and unique `/tmp` paths.
   - Root cause is launcher `umask`, exposing a mode-dependent test expectation.
   - Confidence: **99%**.

No adjudication or deployment was performed. Service remains `MainPID=0`, `failed/failed`.


I read this as a fresh immutable-candidate certification and conditional deployment - I’ll baseline live state, rebind all three gates to `6aaef77d…`, stop on any failure, and install/restart only after complete pass evidence.


Gate18 is fully rebound and passed: candidate verifier, all 46 wheel/source members, 43 token-rotation cases, and the strict-umask inode regression. I’m running the independent Gate19 predecessor/successor matrices now.


Gate19 passed: 85 predecessor tests, 128 successor tests, and the inode discriminator failed on the preserved predecessor but passed on the new successor exactly as required. I’m starting corrected Gate20 under writable-copy `umask 077`, followed by installed-wheel tests and the authoritative full gateway suite.


All three gates are now PASS and sealed to the new full/core digest. I’m entering the conditional deployment phase: exact wheel reinstall with the service interpreter, direct-url and module-byte proofs, then a user-service restart and immediate invocation/PID health validation.


The deployment precondition stopped before installation because its receipt checksum check changed directories while the checksum file contains project-relative paths. No deployment action occurred. I’m preserving that precondition failure and rerunning a corrected append-only deployment launcher from the project root.


The wheel installed and the unit is active/running, but the real startup surface is not healthy: Telegram initialization deterministically rejects the installed `checkin_cli` because runtime policy requires that module to originate inside the profile workspace. I will not certify this as healthy or disguise the platform failure; I’m sealing the exact blocker and unchanged customer authority now.


I read this as final certification reporting - all gates passed and deployment completed, but runtime startup health failed, so I cannot issue `PASS_CERTIFIED_DEPLOYED`.

## FAIL_DEPLOYED_UNHEALTHY

Evidence root:

`/home/cube/projects/richard/traning coach/.omo/evidence/task26/task26-certification-deployment-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73-st_01a00b39`

Evidence inventory SHA-256:

`e44bc2add44ec4d5ccf2406c0345c22c72cabd7f262258236f30c21b3b67770f`

### Gate receipts

- Gate18: **PASS**
  - 43 token tests + 1 inode test
  - Receipt: `8932601bc802ab4e6eab33e51e263ee4119cbc66840fbb227b8b8da4688e1a62`
- Gate19: **PASS**
  - Predecessor: 85 passed
  - Successor: 128 passed
  - Inode discriminator: predecessor failed as expected; successor passed
  - Receipt: `db623abba4c8726a943a2954ee23188cd1afa1e9fc87cc8360038c03945716aa`
- Gate20: **PASS**
  - Writable-copy package suite: **679/679**
  - Gateway: **8,159 passed, 59 skipped**
  - Installed-wheel tests: **128/128**
  - Installed parity: PASS
  - Receipt: `07c83e57aabbe560f341d29d2a05be1c10ecef62ff5df9acff806f3b34212cbd`

### Deployment

Deployment receipt:

`receipts/deployment-receipt.json`

SHA-256:

`fbb302d0c3a53212a196b3d3995ec0f532e4ddacbad6bf36dc149dd6c09747eb`

The exact wheel was installed using the service interpreter with `--no-deps --force-reinstall`.

Direct URL:

`/home/cube/projects/richard/hermes-agent/.venv/lib/python3.12/site-packages/physique_checkin_cli-0.1.0.dist-info/direct_url.json`

Wheel SHA-256:

`f75856d6d986b64d3d2f083aec2f865c7aea19f5950b84ff06e519f2f6505af6`

Installed modules:

- `/home/cube/projects/richard/hermes-agent/.venv/lib/python3.12/site-packages/checkin_cli/customer_admin.py`
  - `6ed04abb8788108de88fc439ebf3a24352cc0657a69f2efc09b50e2897cddd5e`
- `/home/cube/projects/richard/hermes-agent/.venv/lib/python3.12/site-packages/checkin_cli/activation_token_rotation_policy.py`
  - `22533ac128f41c3b82a323394a9dad050985a8be0c8d498eb56eca9980a58b1f`

Profile workspace hashes matched the manifest, including fixed test hash:

`0831230dbebb27303a55d9ac2cb349adb217cd639d1db2981eab0974db527354`

### Service

- PID: `340522`
- Invocation: `86f07a1deb4b4a9ab310e793fc87159f`
- ActiveState: `active`
- SubState: `running`
- Process alive: `true`

Startup is **not healthy**:

```text
NutritionOnboardingRuntimeError:
nutrition onboarding module is outside configured profile
Gateway started with no connected platforms
```

The installed site-packages module conflicts with the runtime invariant requiring `checkin_cli` to originate inside the profile workspace. Telegram did not connect.

### Live state

Before/after state SHA-256:

`bc7040208399c785f30afd48841b3628dfde451466e973bf1127a22efd834edb`

Authority inventory remained identical:

`4f34ac1b47e854a948afc8dc26cfd9c9ceee80230a73c98d9a33b4291ae97041`

- Customer enabled: `false`
- Adaptive activation: `false`
- Adaptive delivery: `false`
- Bootstrap: generation 5, `AWAITING_ACTIVATION`
- No provider/token change or Telegram send/callback was performed.

**Blocker:** installed-wheel provenance and the profile-origin runtime invariant cannot both hold with the current package/runtime design.


I read this as fail-closed runtime rollback - I’ll stop the service first, prove the exact pre-install distribution from preserved artifacts/inventories, and restore only if that baseline is byte-verifiable.


The baseline is now proven: it was the editable `physique-checkin-cli 0.1.0` distribution whose finder mapped `checkin_cli` to the dualcoach profile workspace—not an older generic wheel. I’m restoring that exact preserved editable artifact and metadata with the service stopped, then I’ll run controlled origin/validation checks before any restart.


The restored editable distribution reproduces all baseline hashes, and controlled checks now pass with both adaptive validation and the nutrition runtime loading from the 6aa profile workspace. I’m arming the journal stream before starting the unit and will require the exact `telegram connected` event, not merely an active PID.


I read this as runtime recovery completion - report the proven baseline, restoration, and live health result.

## PASS_RUNTIME_RECOVERED

- Service: `active/running`
- PID: `343199`
- Invocation: `d70df38bad5444b38a7f836d2fe9d4a8`
- Telegram runtime state: `connected`
- Two established Telegram HTTPS sockets verified.

### Root cause

Hypothesis 1 confirmed:

- Pre-deployment distribution was an editable installation mapping all `checkin_cli` imports to the profile workspace.
- Force-installing `f75856...` removed that editable finder and installed a physical `site-packages/checkin_cli`, violating profile-origin enforcement.

Hypotheses 2 and 3 rejected:

- There was no older generic-only `physique-checkin-cli` wheel.
- Systemd unit hash and bootstrap ordering were unchanged.

### Exact restored baseline

Preserved editable artifact:

`/home/cube/.cache/uv/sdists-v9/editable/26f4e05a6940f816/DpY7iGZhz9eoH1wa/physique_checkin_cli-0.1.0-0.editable-py3-none-any.whl`

SHA-256:

`2d0208a3b9be9178a78097776c64568d9dc77c3530e3f04e24bf5c51827f4896`

Key restored hashes:

- Editable finder: `2dc57c797ed4b59b7a2d08a9bc1b241e1527d3dad2809b8b6b43a67a975b95fb`
- Editable `.pth`: `c469ba412e431af58b157129ad3e6e3e3229638eceab22baa09fdff155f4252c`
- `direct_url.json`: `498294b3c9066aae5f8cb07b5ba63a53d404cc2c03145f468cc79bf76317f92c`
- RECORD: `42f7a70f2ab1d42abcdd80af09a3ff20a0d49cde01db168ba8922154075033ce`

All `checkin_cli` modules now resolve from:

`/home/cube/.hermes/profiles/dualcoachtest/workspace/checkin_cli/checkin_cli`

Generic `hermes_cli` and `gateway` modules remain in the service venv.

### Health proof

Controlled validation:

- Adaptive review-space validation: PASS
- Nutrition onboarding runtime: PASS
- Nutrition module profile-local: PASS

Runtime log:

```text
[Telegram] Connected to Telegram (polling mode)
✓ telegram connected
Gateway running with 1 platform(s)
```

The journal monitor was armed before `systemctl start`; journald recorded the start without runtime errors. Connection evidence came from the application gateway log, `gateway_state.json`, and established sockets.

### Preserved state

Authority files remained byte-identical:

`4f34ac1b47e854a948afc8dc26cfd9c9ceee80230a73c98d9a33b4291ae97041`

- Customer enabled: `false`
- Adaptive activation: `false`
- Adaptive delivery: `false`
- Bootstrap: generation 5, `AWAITING_ACTIVATION`
- No customer send or callback occurred.
- No token/provider configuration, plan, todo, Boulder, Git, or unrelated profile changes.

### Recovery receipt

`receipts/runtime-recovery-receipt.json`

SHA-256:

`f6423c0dda1ce71a4339f43ef8e028f364c95d01396bc531482c1928dc4ccda0`

Recovery inventory SHA-256:

`4a31027cbdd20a7f1019e00ea8a25a67616545f474b8bb88112514e65572d6cd`


I read this as a read-only provenance lookup - I’ll trace each checklist item to sealed 6aa candidate evidence/JUnit nodes and confirm the live customer paths without touching runtime state.


I read this as a read-only provenance lookup - report sealed evidence, exact test nodes, and canonical live paths.

## `missend_test_passed`

The strongest direct behavioral evidence is the corrected Gate20 full-gateway JUnit:

- Path: `.omo/evidence/task26/task26-certification-deployment-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73-st_01a00b39/artifacts/gate20-full-gateway.junit.xml`
- SHA-256: `468c9af9ea209837f2e61f1329fa71c2979dbd1da960498bb3687785664fba7f`
- Result: 8,159 passed, 59 skipped, zero failures/errors.

Exact passing routing-safety nodes:

- `tests.gateway.test_diagnostic_isolation::test_role_route_rejects_every_wrong_identity_component[user_id]`
- `tests.gateway.test_diagnostic_isolation::test_role_route_rejects_every_wrong_identity_component[chat_id]`
- `tests.gateway.test_diagnostic_isolation::test_role_route_rejects_every_wrong_identity_component[topic_id]`
- `tests.gateway.test_diagnostic_isolation::test_role_route_rejects_every_wrong_identity_component[generation]`
- `tests.gateway.test_nutrition_coaching::test_customer_consent_decline_replay_and_wrong_route_are_safe`
- `tests.gateway.test_nutrition_coaching::test_customer_pause_state_corruption_and_wrong_route_fail_closed`
- `tests.gateway.test_telegram_activation_notice::test_activation_notice_fails_closed_before_provider[wrong-route]`

These prove that a wrong user/chat/topic/generation or customer route is rejected before provider delivery, directly addressing mis-send prevention.

The package-side checklist contract also passed in:

- Path: `.omo/evidence/task26/task26-certification-deployment-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73-st_01a00b39/artifacts/gate20-source-package.junit.xml`
- SHA-256: `97d0e08313ab64da00726a85080d2cd37c190499ac084eecf175cdafda5ddc88`
- Nodes:
  - `tests.test_customer_admin::test_activation_accepts_all_g1_through_g5_evidence`
  - `tests.test_customer_admin::test_activation_rejects_g5_false_checklist_item`

There is no test literally named `missend_test_passed`; the first group is the behavioral evidence, while the second group proves activation consumes and fails closed on the checklist contract.

### Candidate binding

The Gate20 receipt binds both JUnit files to:

- Full candidate: `6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73`
- Core candidate: `f759460a42155925ef68d75a03f4c86cffe6d1b6ec774bd61efb73174e10b60c`
- Wheel: `f75856d6d986b64d3d2f083aec2f865c7aea19f5950b84ff06e519f2f6505af6`
- Receipt: `.omo/evidence/task26/task26-certification-deployment-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73-st_01a00b39/receipts/gate20-receipt.json`
- Receipt SHA-256: `07c83e57aabbe560f341d29d2a05be1c10ecef62ff5df9acff806f3b34212cbd`

## `retention_backup_doc`

Preferred sealed document:

`.omo/evidence/task26/task26-inode-test-fix-successor-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73/historical/predecessor-candidate/historical/predecessor-candidate/historical/e2f-candidate/historical/e788-candidate/historical/30b-candidate/historical/runbook/task26-golden-path-2e0894ea-v6.md`

SHA-256:

`8416cd7c83cab5540af2e1e01dbcc5b1bdfd49a59d8ef21ea49512c28d749218`

Why it satisfies the item:

- G11 defines hash-pinned retained-archive verification.
- Section 3 specifies archive-first reset, atomic archive publication, rollback boundary, and preservation of historical archives.
- Section 14 specifies post-lifecycle archival, including byte-exact retention of the bootstrap ledger before cleanup.
- Section 15 defines the required archive manifests, receipts, and digest inventory.

The file is inside the immutable 6aa candidate inventory rather than a mutable source-doc location.

## `manual_fallback_doc`

Preferred sealed document:

`.omo/evidence/task26/task26-inode-test-fix-successor-6aaef77de87489c3be493978645781b24b55ab07513ff1f880164741d0bd3c73/historical/predecessor-candidate/historical/predecessor-candidate/historical/e2f-candidate/historical/e788-candidate/historical/30b-candidate/historical/runbook/task26-recovery-runbook-2e0894ea-v6.md`

SHA-256:

`a2e15845764e7041957ae4518096fe73f87ec35b57021980cdd4df3ea18ac00d`

Why it satisfies the item:

- Defines the supported operator command set.
- Provides explicit abort rules and bounded deadlines.
- Contains decision-complete recovery procedures R1-R16 for startup, route, activation, provider, delivery, archive, and cleanup failures.
- Defines evidence capture, escalation, and fail-closed behavior.
- Explicitly prohibits unsafe hand edits, replay, duplicate sends, and undocumented recovery shortcuts.

Both documents are pinned by:

- `.../historical/runbook/runbook-binding-receipt-v6.json`
- SHA-256: `6fa1e309e0e0f663ca82131a393fcbaa189338ec4c29a1140d3003bece66e18c`

They are also listed with matching hashes in the 6aa candidate’s `hash-inventory.json`.

## Live canonical paths

Registry path required by `customer_admin`:

`/home/cube/.hermes/profiles/dualcoachtest/customers/registry.json`

Current registry SHA-256 observed read-only:

`26602b034c85260b07692c4b91681eb80852dd5923c79d693bb4e1c357bda5be`

Customer key:

`task26_live_2e_r2_20260815_8527916639`

Canonical derived `data_root`:

`/home/cube/.hermes/profiles/dualcoachtest/data/customers/task26_live_2e_r2_20260815_8527916639`

The registry intentionally does not store a mutable `data_root` field. `load_customer_registry` derives it as:

`<profile_root>/data/customers/<customer_key>`

`customer_admin._registered_customer` then requires any supplied `data_root` to resolve exactly to that registered root and rejects symlinks or mismatches. No files or runtime surfaces were modified.


I read this as an authorized successor certification and conditional deployment - I’ll inventory-diff only the three declared files, seal append-only correction evidence, run Gates 18–20, and deploy the exact reproducible Hermes wheel only if every gate passes.


I read this as implementation and conditional deployment - I sealed the successor, passed Gates 18–20, deployed only the Hermes wheel, and verified live health.

Deployment status: **PASS_DEPLOYED_HEALTHY**

- Candidate: `f38d0373a58877806ff64a9cac54ab01e6e6e47f7101e3dcfd5ffbf05f8bb101`
- Core: `5620cf756b3f32901091475a5ed409c1757eeaf143ecb1e4a23a452d3d9e3e8e`
- Hermes wheel: `2110071bc2761e6cbd149de4694dd7328148ec7e5b2e3c7c10a2709082d5e161`
- Profile wheel remained unchanged: `f75856d6...f6505af6`
- Gate18: 46 passed
- Gate19: expected predecessor 2 failures; successor 183 passed
- Gate20: source 679 passed; gateway 8,161 passed, 59 skipped; installed profile 128 passed; installed-wheel parity passed
- Service: active/running, PID `535046`, Telegram connected
- Hermes imports: service `site-packages`
- Profile imports: preserved editable profile workspace
- Customer remained enabled; generation 6 remained `ACTIVE`
- Adaptive activation/delivery remained false; zero customer deliveries or callbacks
- Existing update `629525116` remained durably blocked and was not reprocessed

Evidence:
- Candidate root: `.omo/evidence/task26/task26-live-dm-checkin-fix-successor-f38d0373a58877806ff64a9cac54ab01e6e6e47f7101e3dcfd5ffbf05f8bb101`
- Certification root: `.omo/evidence/task26/task26-certification-deployment-f38d0373a58877806ff64a9cac54ab01e6e6e47f7101e3dcfd5ffbf05f8bb101-st_01a00b39`
- Deployment receipt SHA-256: `8cd6edb7775804302703e20153f23127dd709adbcc24fe81bffb89e5f33f7136`
- Evidence inventory SHA-256: `097c2f6e4493d81008998853c468758803adb238ac4c844d3f872036a8491a19`

Append-only evidence retains the corrected Gate20 network-namespace diagnostic and the two non-deploying/deployment-monitor launcher corrections.


I read this as implementation and conditional deployment - I’ll bind the two-file successor to f38d0373, reproduce and certify the fix through Gates 18–20, then deploy only if every gate and live precondition passes.


I read this as completed certification and conditional deployment - all gates passed, so I deployed the exact successor wheel and verified live bootstrap behavior.

**Status: PASS_DEPLOYED_HEALTHY**

- Full digest: `4a6c7ee54cf9526a30de8bb576c1d71b411938beba33a04914738f6e1b6ed1cb`
- Core digest: `3374be765c7e53fc431b0c6e48cacbacb09618f77f13ef87016cb0ad2575d060`
- Hermes wheel: `9d22e89a0b1a14d4eb7f1c2005fc01860bec5f3b4eda6e01bb1390542a90b875`
- Candidate inventory digest: `0119beeb46a15ab25a78550da4c432b4cc52e0dc816822d2688dc9009df89d90`
- Candidate root: `.omo/evidence/task26/task26-customer-service-state-bootstrap-successor-4a6c7ee54cf9526a30de8bb576c1d71b411938beba33a04914738f6e1b6ed1cb`

**Gates**

- Gate18: 46 passed
- Gate19: predecessor 1 expected failure; successor 335 passed
- Gate20:
  - Source package: 679 passed
  - Full gateway: 8,162 passed, 59 skipped
  - Installed-wheel behavior: 1 passed
  - Installed profile: 128 passed
  - Wheel parity: 982 members equal

Receipt hashes:

- Gate18: `755b10c0cbbbb2db47dc3f15d499ae236ba9b62e68d37fa75175f2211cbe93fa`
- Gate19: `04edcf0e713986b66e9a675eed837357a02adb7bb6338b9c31e1e4b69d9382c5`
- Gate20: `85d221807ca653a72279d1ba9d8f04ab66f96755cdb8f69fefbfd0ba3c8a6de2`

**Live deployment**

- Service: `active/running`
- PID: `576011`
- Invocation: `b6e0ef44fded4872b0bb3fa115485532`
- Telegram: `connected`
- Exact customer transport gate: `true` for user/chat `8527916639`, topic `0`, KST date `2026-08-17`

Service-state proof:

- Path: `/home/cube/.hermes/profiles/dualcoachtest/data/owner-actions/customer-service-state.json`
- Mode: `0600`
- SHA-256: `81c1e581cb84aac6f44044747e0e8e77a2d7498c71d626f1f9b5ec2f9d09a261`
- Schema: `customer-service-state-v1`
- State: canonical empty `{}` and unpaused
- Payload digest: `fbb526e57506141f686cd56dd75c6375c78b974452b985c0737f25230060994d`

Customer remained enabled, bootstrap generation 6 remained `ACTIVE`, adaptive activation/delivery remained false, and delivery count remained zero. Profile editable mapping, source, ledger, provider/token configuration, systemd unit, prior polling recovery seal, and observer v6.3 seal remained unchanged. No customer send, callback, provider request, or token mutation occurred.

Certification root:

`.omo/evidence/task26/task26-certification-deployment-4a6c7ee54cf9526a30de8bb576c1d71b411938beba33a04914738f6e1b6ed1cb-st_01a00b39`

- Deployment receipt: `fe65b634396aaae2818719d1b34fdaad148b2547290d3a66b3af7803bf93dfca`
- Evidence inventory: `b6552df04b498cecc4b9cb2baf7fea4b90dc6d879f7a67b394df92edf4ad313d`