I read this as a read-only root-cause proof task - I’ll inspect the retained plan, ledger, child-task evidence, schema/validator, adapter, and logs, then build and measure a disposable minimum valid fixture without calling providers or mutating state.


I read this as a read-only Task23 root-cause proof - I inspected retained evidence and ran only offline validators and mocked transport probes.

## Verdict

- **A 256-token completion can fit the strict 11-key response.**
- **The finalized grounding, IDs, targets, and validator are jointly satisfiable.**
- **The configured Codex adapter did not transmit either the 256-token limit or the native JSON Schema request.** This is a proven integration defect.
- The first response in both successor attempts was valid JSON with the exact key set and contract version, but failed an unspecified semantic predicate.
- Because raw responses, detailed predicate paths, finish status, and usage were discarded, **no clause-level cause of the semantic rejection can now be proven**.

## Exact grounding reconstruction

Rebuilding the production request from the finalized check-in reproduced the retained revision exactly:

```text
event:    wizard_995f04a3b8bc256fa13ff407
revision: f266949e05195d9a23c728264f84507e3edcea207126f501df0251924c117ae1
```

Current targets:

```json
{"calories":2760,"protein_g":160,"carbs_g":350,"fat_g":80}
```

Relevant allowed IDs included:

```text
Evidence:
checkin.current
approved-6ae32d168621ccdd
naver:seongdo1994:224189737338
safe-rewrite-3c26aadac3503c70
approved-1fb81ec4ce817ec3

Focus:
checkin.bodyweight
checkin.calories
checkin.condition
checkin.digestion
checkin.macros
checkin.sleep_duration
checkin.sleep_quality
checkin.training_summary
checkin.water
```

## Minimum accepted fixture

This compact, grounded Korean fixture passed the real `diagnose_coach_judgment` boundary:

```json
{"schema_version":"nutrition-coach-response-v2","customer_key":"task22_dm_rehearsal","revision_binding_digest":"f266949e05195d9a23c728264f84507e3edcea207126f501df0251924c117ae1","decision":"maintain","confidence":"low","evidence_ids":["checkin.current"],"interpretation":"유지","recommendation_unit_system":"kcal_and_grams","recommendation":{"calories":2760,"protein_g":160,"carbs_g":350,"fat_g":80},"next_checkin_focus_ids":["checkin.water"],"customer_draft":"유지해요."}
```

Measurements:

- UTF-8: **478 bytes**
- `o200k_harmony`: **140 tokens**
- `o200k_base`: **140 tokens**
- `cl100k_base`: **139 tokens**
- Legacy GPT/P50/R50 encodings: **180 tokens**
- Result: `accepted`

The literal validator floor, using one-character text values, is **461 bytes / 135 `o200k_harmony` tokens**. It also passes, exposing that Korean/naturalness is prompt-only rather than validator-enforced.

## Deterministic hypotheses

| Hypothesis | Result | Proof |
|---|---|---|
| 256 tokens are inherently insufficient | **Falsified** | Real validator accepted the 140-token fixture; every locally available OpenAI encoding measured below 256. |
| Native structured-output support mismatched the adapter | **Confirmed defect** | Caller supplied strict `response_format.json_schema`, but an offline Codex adapter spy emitted only `input`, `instructions`, `model`, `store`, `stream`, and `timeout`. |
| Grounding IDs, targets, or semantics make acceptance impossible | **Falsified** | Exact reconstructed revision and structural IDs produced an accepted response. |
| Validator is not enforcing strictness | **Falsified** | An unoffered evidence ID and changed target were rejected as `semantic_validation_failed`; an extra key was rejected as `invalid_shape`. |

## Proven failure evidence

Gateway logs retained this for both successor attempts:

```text
14:13:52 ... correction=1 diagnostic=semantic_validation_failed
15:50:31 ... correction=1 diagnostic=semantic_validation_failed
```

That diagnostic is assigned only after:

1. JSON parsing succeeds.
2. The root is an object.
3. Its key set equals all 11 required keys.
4. `schema_version` equals `nutrition-coach-response-v2`.

Therefore the initial failures were **not malformed/truncated JSON or missing-key failures**. At least one later semantic condition failed, such as binding, offered IDs, target/decision consistency, number grounding, copy consistency, or safety.

The correction responses also failed, but their diagnostic codes are only inside non-reversible audit hashes. The exact predicates cannot be recovered.

## Adapter and retained-metadata defect

The configured route was `openai-codex` / `gpt-5.6-terra`, which resolves through `_CodexCompletionsAdapter`.

An offline spy proved:

```text
response_format forwarded: false
token budget forwarded:    false
```

The adapter also synthesized `finish_reason="stop"` for a mocked incomplete provider result. Although it can expose usage to its caller, `_request_physique_coaching_stage` discards both usage and finish status and returns only text.

Consequently:

- There was no actual transmitted 256-token cap.
- There was no provider-side strict JSON Schema request.
- No trustworthy finish reason, incomplete reason, or token usage was retained.
- All generation-provider receipts remained null.

The smallest safe repair is to translate Chat Completions `response_format` into Responses API `text.format` when supported, otherwise fail closed or use a structured-output-capable provider. It should also preserve provider status/incomplete reason and privacy-safe token counts. This repairs a proven transport defect, but it does **not** prove or repair the unknown semantic predicate.

## Replacement eligibility and lineage

The current successor is terminal:

```text
token: 664046dbca210afc
generation: 6
attempt: 2/2
state: generation_failed
error: invalid_model_output, non-retryable
record digest: 9bc0920c5be80a312ab04f3cbb4f75a4d69cbee967ed9bddd402959ea7347454
draft revision: null
delivery/provider receipts: null
```

It is **not currently authorized for another replacement**:

- Retained evidence says `no_further_retry_authorized: true`.
- The existing one-purpose journal is already `replaced`.
- That authority was pinned only to predecessor `90f6df222e870e58`.
- The semantic cause has not been repaired.

If a future replacement becomes justified after repair and fresh owner authorization, exactly-once preservation requires:

1. CAS against token `664046dbca210afc`, generation `6`, and terminal digest `9bc092...7454`.
2. Append one deterministic new token with:
   - `lineage_parent_token = 664046dbca210afc`
   - `lineage_predecessor_digest = 9bc092...7454`
3. Preserve both existing histories byte-for-byte.
4. Copy the same customer/session/event/revision request binding.
5. Use a `prepared -> replaced` one-time journal under the delivery lock.
6. Reject multiple children; duplicate/restart execution must resolve to the same child.
7. Create no draft delivery or customer send.

No provider calls, model runs, edits, or live state mutations were performed.