I read this as a focused Python debugging and fix task - I’ll establish runtime evidence with the required failing harness test, fix only the confirmed seam, then run the full disposable E2E to `DISPOSABLE_E2E_PASS`.


I’ve completed the environment and flow assessment. The first change will be the required harness RED: a real short-lived subprocess must beat the never-completing polling signal, expose only a bounded sanitized failure, remain in the lifecycle registry, and already be reaped.


The harness regression is now GREEN. I’m entering the decisive runtime phase: one disposable run through the update-4 normal restart, which will now stop on the child’s exact completion signal and report a sanitized exception type instead of timing out.


The decisive runtime evidence contradicts the three permitted production hypotheses: the child exits `1` with `ProfilePackageResolutionError -> NutritionOnboardingRuntimeError -> RuntimeError` before readiness. Per the explicit stop condition, I’m not editing publication, locking, or fake-API code; I’m closing verification and cleanup around the harness fix and reporting the exact blocker.


I read this as a focused restart fix - I stopped at the mandated contradiction gate rather than editing an unconfirmed production seam.

Blocked, not `DISPOSABLE_E2E_PASS`.

- Harness RED confirmed missing child ownership: unexpected `children` contract.
- Harness fix now immediately registers/reaps children, races polling against exact process exit, and reports bounded sanitized stderr.
- Harness GREEN: `4 passed in 0.14s`; Ruff and `py_compile` pass.
- Decisive runtime result:

```text
normal-restart child exited with return code 1:
ProfilePackageResolutionError > NutritionOnboardingRuntimeError > RuntimeError
DISPOSABLE_E2E_BLOCKED
```

This contradicts all three authorized hypotheses, so no publication, membership-lock, or fake-API production edit was made.

Cleanup is authoritative: all eight cleanup fields are `true`; no disposable child, temporary profile, authority directory, or port remains. Evidence is under `.omo/evidence/v1.1.1-stability/disposable-e2e`.

Basedpyright still reports 26 pre-existing errors across the parent’s untracked runner; the new harness lines introduce no type errors, only the expected private-seam test warning.


I read this as harness-only diagnostic refinement - I’ll add RED coverage for exact resolver-detail allowlisting, minimally sanitize those fixed categories, then run one update-4 reproduction and stop without production edits.


The resolver-detail allowlist is GREEN and retains no arbitrary stderr text. I’m running the single update-4 reproduction now; the harness should terminate at normal-restart and emit one fixed resolver cause if present.


I read this as diagnosis-only completion - reporting the single allowlisted update-4 result.

- Cause marker: `profile module is outside configured profile`
- Child return code: `1`
- Last process event: `{"event":"child_adapter_stopped"}`
- Result: `DISPOSABLE_E2E_BLOCKED`
- Cleanup: all eight fields `true`; no processes or temporary directories remain.
- Verification: `10 passed`; Ruff and `py_compile` passed.
- Sanitization test confirmed tokens, customer text, arbitrary text, and paths remain hidden.

No production code was edited.


I read this as a confirmed harness-only import-order fix - I’ll prove the child environment precedence RED, change only `_child_environment`, verify the update-4 toggle, then run the literal disposable E2E and stop at its concrete outcome.


The import-order test toggled RED to GREEN with a one-line `_child_environment` change; the focused suite, Ruff, and `py_compile` are clean. I’m now running the literal disposable E2E, which will also prove whether normal-restart reaches ready/polling.


I read this as harness-only implementation - completed and stopped at the next concrete boundary.

- RED confirmed repository-only `PYTHONPATH`.
- Fix: disposable package root now precedes repository root; inherited paths are excluded.
- GREEN: `11 passed`; Ruff and `py_compile` passed.
- Toggle proof: normal restart emitted `child_adapter_ready` and resumed `getUpdates`; resolver failure disappeared.
- New boundary:

```text
DisposableHarnessError: timed out waiting for customer delivery transport
DISPOSABLE_E2E_BLOCKED
```

- Last event: `{"event":"child_adapter_stopped"}`
- All eight cleanup fields are `true`; no child processes or temporary directories remain.
- Production resolver and other production code were untouched.


I read this as a harness-only operator-authority integration - I’ll pin the missing capability step with a failing production-controller test, add a private synthetic authorization fixture, invoke the real issuance CLI, record sanitized evidence, and rerun the literal crash/restart E2E without touching production behavior.


I’ve traced the real issuance contract and its authority inputs. The focused RED will use an approved durable draft, prove `delivery_capability_required`, then invoke the production controller with a disposable launch authorization and prove transport readiness with zero Telegram/model actions.


The focused controller test is GREEN: the approved card returns `delivery_capability_required` before issuance, then the real controller issues `draft-delivery-capability-issue-v2/ISSUED`, performs zero provider/Telegram actions, and makes transport ready. I’m running the literal E2E with the original delivery crash/replay proof intact.


The literal run exposed a harness regression before capability issuance: creating `auth.json` during initial profile preparation makes the real admin activation fail. I’m pinning the intended lifecycle boundary now—no launch auth before approval; the private auth fixture is created only when the operator authorization is issued—without production edits.


The literal E2E now reports `DISPOSABLE_E2E_PASS`. I’m performing the final evidence audit: capability receipt, crash/restart events, exactly-once delivery and duplicate count, file privacy, loopback isolation, and authoritative cleanup.


I read this as completed harness-only capability integration - implemented and fully verified.

Implemented:

- Private mode-0600 launch authorization created only after draft approval.
- Real `issue-delivery-capability` controller CLI invoked.
- No direct delivery-row injection or production changes.
- Sanitized capability hashes recorded in evidence.

Verification:

- Focused RED → GREEN: `13 passed`
- Ruff and `py_compile`: passed
- Literal E2E: `DISPOSABLE_E2E_PASS`
- Capability: `draft-delivery-capability-issue-v2 / ISSUED`
- Provider actions: `0`
- Telegram actions: `0`
- Customer deliveries: `1`
- Restart duplicates: `0`
- Delivery fault reached update `43`; replacement child became ready.
- Evidence directory: `0700`; all 15 artifacts: `0600`
- All eight cleanup fields: `true`
- No remaining child processes or temporary directories.