I read this as authorized strict-rerun execution - I’ll inspect the sealed candidate and existing launch machinery, then create one append-only controller, dry-run it, and execute it only if every fail-closed gate passes.


The sealed candidate and service baseline are present. I’m now tracing the existing supported deployment, bootstrap, membership, observer, and cleanup contracts so the controller composes proven interfaces rather than inventing a parallel launch path.


The supported APIs can satisfy the requested pre-claim state without impersonating the customer: create one disabled registry draft, prepare one unclaimed bootstrap session, let gateway startup arm the membership epoch, then call the candidate’s read-only membership evidence primitive for actor `8527916639`. I’m implementing that exact composition with a durable “attempted, never retry” invite boundary.


The boundary test exposed a real state-machine bug in the duplicate-send guard; I fixed it before sealing. I’m running the corrected deterministic suite and zero-mutation live dry-run now; execution remains locked until both pass.


The final v3 source seal is `70e11e0f...`; 25 deterministic boundary tests pass and the sealed live dry-run reports `PASS_ZERO_MUTATIONS`. I’m executing the one-use controller once now; any pre-invite mismatch will stop the service and archive generated live authority without sending.


The single execution failed closed before deployment, service start, membership probes, or invite: the sealed controller process was launched with system Python, which lacks the Telegram runtime dependency needed while importing the candidate API. The one-use marker is consumed, so I will not repair or rerun it; I’m verifying the required clean rollback and zero-invite stop state.


I read this as strict-rerun execution - exactly one sealed controller ran and stopped at a hard blocker with clean rollback.

**Outcome: `HARD_BLOCKER_CLEAN_ROLLBACK`**

- Controller: `.omo/evidence/task26/task26-strict-launch-controller-st_01a00f53/launch_controller.py`
- Controller SHA: `70e11e0f44e58245701d525b51314189226b648806f7e619266de0bfcbd00fa5`
- Controller seal: `SEAL-v3.json`
- Controller seal SHA: `2e6ba8fb71d34d766082a08f59b8d8d704523fd3671cda29eb97aee8fb00be44`
- Run root: `run-20260817-strict-a-v3`
- Run seal SHA: `227de3df3854d8a2867a50697c21b405539d13edc1f27931024f97e1109154ec`

Verification:

- Tests: `25 passed`
- Dry-run: `PASS_ZERO_MUTATIONS`
- Candidate verifier after rollback: `PASS`
- Service: `inactive/dead`, `MainPID=0`
- Observer and journal monitor: stopped
- Live customer authorities: zero
- Invite API invocations: `0`
- Invite message ID: none
- Customer claims: zero
- Activation/delivery/owner/coaching actions: none

Prepared then archived lineage:

- Customer: `task26_strict_a_20260817105246_b7ece5e4`
- Session: `cb_RctzSPC_1shJlARXNjNp_g`

Exact commands:

```bash
python3 '.omo/evidence/task26/task26-strict-launch-controller-st_01a00f53/launch_controller.py' dry-run --root '.omo/evidence/task26/task26-strict-launch-controller-st_01a00f53/run-20260817-strict-a-v3'
python3 '.omo/evidence/task26/task26-strict-launch-controller-st_01a00f53/launch_controller.py' execute --root '.omo/evidence/task26/task26-strict-launch-controller-st_01a00f53/run-20260817-strict-a-v3'
```

Blocker: the one-use controller was launched with system Python, which lacked the `telegram` dependency after gateway startup. It aborted before membership evidence, provider probing, or invite intent. The one-use marker is consumed, so no repair or rerun was attempted.

No first-user instruction was issued because `READY_CUSTOMER_CLAIM` was not reached.


I read this as an authorized v4 successor rerun - I’ll leave v3 immutable, build and seal a new interpreter-bound controller, prove all interpreter failures are pre-mutation, then dry-run and execute it once only if every gate passes.


The environment now proves the venv interpreter imports Telegram and both exact candidate wheels from site-packages, with systemd `ExecStart` on the same interpreter. I’m creating v4 as a separate successor with this proof as an absolute pre-mutation gate and with child-monitor cleanup fixed.


V4 is sealed independently: controller `ea11d20b...`, seal `99c23436...`, permission `50e5a8c...`; 32 tests and both diagnostics are clean. I’m recording the real `/usr/bin/python3` zero-mutation rejection, then running the sealed venv dry-run.


The sealed dry-run passed with zero profile mutation and recorded exact interpreter, venv, systemd parity, expected import paths, and byte-for-byte wheel equality for all six authoritative modules. I’m now consuming v4’s new one-use marker with the required venv interpreter; any new blocker will trigger v4 clean rollback and no retry.


V4 encountered a new post-start blocker at the read-only membership gate: the authoritative config has no literal `platforms.telegram.token` key (`KeyError: 'token'`), while the service obtains credentials through its supported secret path. Per the sealed policy I will not patch or rerun v4; I’m verifying its automatic rollback, zero invite attempts, stopped children, and restored clean baseline before sealing the blocked run.


I read this as completing v4 once - it failed closed at a new blocker and was sealed after clean rollback.

**Outcome: `HARD_BLOCKER_CLEAN_ROLLBACK`**

- V4 controller SHA: `ea11d20bb4fc76b8775bdda8644970a758ee21a50fb31e15e484982f44a06d54`
- Controller seal SHA: `99c2343645e5238568d1263a347587461d48edead1f3ce30aa9d804cee9b7c0e`
- Permission SHA: `50e5a8c6f647459ff24987dfc27e9aaff538281cff230927ca4e0a06717cf384`
- Run seal SHA: `8f9111b2ac21ac1ae1fb3f0af50bd1ff9b522e3db14cf1cf886b13cb2ab9f4b0`
- Tests: `32 passed`
- Diagnostics: clean
- Dry-run: `PASS_ZERO_MUTATIONS`
- `/usr/bin/python3` rejection: `PASS_ZERO_MUTATIONS`; requested root was never created

Interpreter proof:

```text
/home/cube/projects/richard/hermes-agent/.venv/bin/python
```

It matched:

- `sys.executable`
- virtual environment
- service `ExecStart`
- service `VIRTUAL_ENV`
- all expected Telegram, Hermes, and profile import paths
- loaded bytes against both sealed wheels

V3 bindings were verified unchanged:

- Controller seal: `2e6ba8fb71d34d766082a08f59b8d8d704523fd3671cda29eb97aee8fb00be44`
- Clean-run seal: `227de3df3854d8a2867a50697c21b405539d13edc1f27931024f97e1109154ec`

V4 lineage:

- Customer: `task26_strict_a_v4_20260817110035_478d9934`
- Session: `cb_vo7kRkbf-J-jWVlOGMXjYw`

New blocker: after exact deployment, observer startup, gateway startup, and membership subscription arming, the read-only membership probe encountered `KeyError: 'token'`. The authoritative service resolves credentials through its supported secret path; no literal `platforms.telegram.token` exists.

Final state:

- One-use marker consumed; no retry
- Membership evidence not created
- Provider probe not attempted
- Invite API calls: `0`
- Invite message ID: none
- Claims/activation/owner/delivery actions: zero
- Service: `inactive/dead`, `MainPID=0`
- Observer and monitor stopped
- Live customer authorities: zero
- Candidate clean-state verifier: `PASS`
- No source, candidate, or config repair performed

Evidence root:

```text
.omo/evidence/task26/task26-strict-launch-controller-v4-st_01a00f53/run-20260817-strict-a-v4
```


I read this as an authorized v5 successor rerun - I’ll bind v4 immutably, use the deployed adapter’s credential resolver without exposing the token, move identity/admin transport checks ahead of all live writes, seal and dry-run v5, then execute it once.


The authoritative production path is confirmed: `hermes_cli.env_loader.load_hermes_dotenv(...)` followed by `gateway.config.load_gateway_config()`, whose environment override supplies `Platform.TELEGRAM.token`; admin readiness is the candidate’s `verify_subscription_readiness`. I’ll bind those exact APIs and keep the resolved credential memory-only.


V5 is sealed independently: controller `6092ac02...`, seal `04611ded...`, permission `ccf34963...`; all 35 deterministic tests and diagnostics pass. I’m running its network-free resolver-contract dry-run now, with profile mutation detection still enforced.


The v5 dry-run is `PASS_ZERO_MUTATIONS`: it proved the deployed resolver/bootstrap functions and hashes, confirmed no literal config token, and performed no network. I’m executing once now; credential resolution and bounded `get_me`/bot-admin checks occur before v5 creates its marker or any customer/service authority.


V5’s sealed pre-mutation credential and Telegram identity/admin preflight passed, but the subsequent baseline gate found a newly present profile `sessions` authority before customer preparation or service start. V5 failed closed and consumed its marker; I will not retry. I’m verifying rollback, zero customer lineage/invite, and secret absence before sealing the blocked run.


I read this as completing v5 once - it passed credential/network preflight, then failed closed before customer preparation.

**Outcome: `HARD_BLOCKER_CLEAN_ROLLBACK`**

- Controller SHA: `6092ac021c73987f8d0b065ff6e98cf32296aa72b7bf37ff7aed71c19e831e84`
- Controller seal SHA: `04611ded095935757c829f1e2785e3b671489178b6b0052c97931f0b1d727c44`
- Permission SHA: `ccf3496361ad4b591de3405a77b3e69323a0653070fd036bfee81176fd53ec88`
- Run seal SHA: `ba8226e9e7cc036560070d43e2d90a4c7bd56345fc0dc2148ea1a69ba986b1f9`
- Tests: `35 passed`
- Diagnostics: clean
- Dry-run: `PASS_ZERO_MUTATIONS`

V4 bindings verified:

- Controller seal: `99c2343645e5238568d1263a347587461d48edead1f3ce30aa9d804cee9b7c0e`
- Run seal: `8f9111b2ac21ac1ae1fb3f0af50bd1ff9b522e3db14cf1cf886b13cb2ab9f4b0`

Secret resolution and network preflight:

- Resolver: `hermes_cli.env_loader.load_hermes_dotenv`
- Bootstrap: `gateway.config.load_gateway_config`
- Literal config token: absent
- Credential resolved: `PASS`
- Credential stored or printed: no
- Secret-absence proof SHA: `1d67beea46c574c7ba99863c8574787ff71ebdc35c08ae4cf48131af1a0bafdd`
- Bot identity: `8869235296` / `dual_coach_pilot_test_bot`
- `get_me` and bot-admin membership checks: `PASS_READ_ONLY`

New blocker: the authoritative gateway configuration bootstrap created a profile `sessions` authority before baseline/customer preparation. The strict baseline rejected it and archived it during rollback.

Final state:

- V5 one-use marker consumed
- Customer/session lineage: not created
- Service never started
- Observer never started
- Membership/provider checks not reached
- Invite API calls: `0`
- Invite message ID: none
- Service: `inactive/dead`, `MainPID=0`
- Live customer authorities: zero
- Candidate verifier: `PASS`
- No source, candidate, or config repair performed

Evidence root:

```text
.omo/evidence/task26/task26-strict-launch-controller-v5-st_01a00f53/run-20260817-strict-a-v5
```

No READY handoff exists because `READY_CUSTOMER_CLAIM` was not reached.