I read this as an implementation and controlled execution task - I’ll inspect the launcher, package layout, tests, and task state, then make the smallest fail-closed fix and run the authorized workflow exactly as specified.


I read this as an implementation and controlled execution task - the repair and single authorized run are complete, with the required failure stop enforced.

DoneClaim:
- Launcher now pins the current package, verifies origins/digests/API, and rejects rebinding/symlinks/digest drift.
- Regression passed with stale snapshot lexically first and digest drift failing closed.
- Authorized message-144 consume ran once: child `01e3b5d1739a5c49` appended; journal consumed; reseal count 1; delivery count 0.
- Generation failed once with retained `provider_bad_request` (`400 invalid_json_schema`, `text.format.schema`); no provider receipt or draft; service stopped; no retry.
- Failure-status Owner card was published by the generation path; no customer delivery occurred.
- Verified: 22 focused tests, Ruff, Ty, compile, direct consumed-journal verifier.
- Redacted evidence: `.omo/evidence/task23-st_019ffb2e/final-execution.redacted.json`


I read this as a controlled restoration and investigation task - I’ll restore the gateway while snapshotting generation/delivery state, then inspect the retained request/schema evidence offline without issuing any provider or generation action.


I read this as a read-only investigation and health restoration check - I’ll inspect the retained failure and request shape, prove the smallest schema-only repair offline, and report current gateway health without triggering generation or delivery.


I read this as a completed read-only diagnosis with gateway recovery - the gateway is polling again; no generation or delivery state changed.

- **Health:** `hermes-gateway-dualcoachtest.service` is `active/running`, PID `3389958`, started `22:06:10 KST`, `NRestarts=0`. Gateway state is `running`; Telegram is `connected` with no platform error.
- **No mutation:** target child remains terminal `generation_failed` at generation 3, updated `22:03:25 KST` (before restart), with no provider receipt, draft, or delivery ledger. Generation/card hashes remain `64ea...f796` / `efd3...e937`.

**Retained failure**
- HTTP 400 `invalid_request_error`
- code: `invalid_json_schema`
- parameter: `text.format.schema`
- non-retryable `provider_bad_request`
- Sent shape was Codex Responses `text.format`, strict JSON Schema, with no `max_output_tokens`.

**Exact schema issue and minimal repair**
- The transmitted Coach V2 schema is SHA-256 `3743c9...c09ec`.
- Its only strict-schema violations are:
  - `$.properties.schema_version.const`
  - `$.properties.recommendation_unit_system.const`
- Both use `const` alone, which is unsupported by the strict profile and leaves the property without a `type`.

Replace only those two property schemas:

```json
"schema_version": {
  "type": "string",
  "enum": ["nutrition-coach-response-v2"]
},
"recommendation_unit_system": {
  "type": "string",
  "enum": ["kcal_and_grams"]
}
```

Offline strict-contract audit: current schema fails only at those two paths; the candidate has zero violations. Draft 2020-12 validation confirmed the replacements preserve the fixed-value constraints.

**Mock gap**
- The gateway tests replace `chat.completions.create` with `MagicMock`, so the Codex Responses adapter/backend never validates `text.format.schema`.
- One test explicitly asserts the invalid `{"const": ...}` schema, pinning the bad shape.
- Adapter wire tests use only `{"ok":{"type":"boolean"}}`; they cover serialization and budget handling, not the real Coach schema against strict-schema validation.

No retry, provider call, child/card action, or source edit was performed.