# Suite proposal failure diagnosis The real job `ca6290e71cb14bd1af64864f7c3ea256` failed in `proposal_a` after 30.264 seconds, with no completed model pass. Only stored operational metadata was inspected. No real case content was read or resubmitted. ## Established failure `parse_claude()` rejected the terminal CLI result in its `cli_final_result` branch because `is_error` was true. The subtype was `success`, which alone does not establish successful generation. The process exited with code 1. The final result event and initialization event were both present. The CLI reported one of six turns, `stop_sequence`, zero input/output/cache tokens, zero API duration, and no runtime model-usage entry. There was no structured result, structured tool input, or JSON text candidate. The job did not reach schema extraction or assignment validation. There is no evidence of a turn limit, structured-output retry limit, explicit context/output exhaustion, process signal, cancellation, or subprocess timeout. The subprocess allowance was 1799.965410697274 seconds. The provider timeout and reasoning-token limit remain unknown. The configured output cap was 64000 tokens; no observed output-limit entry was returned for this job. Zero reported usage does not prove that no content reached the provider. The original CLI/provider cause is unknown. CLI output and temporary files were deleted by normal cleanup; the old diagnostics did not preserve the assistant error category. There is no complete answer to recover. The 61-case count is not an established cause. ## Server-only diagnostic correction Execution revision `suite-multipass-v8-20260929` preserves the prompt revision `implementation-proximity-multipass-v4-20260929`, compatibility revision `suite-v6-20260929`, selected model, effort policy, authentication, routing, timeouts, six-turn limit, and strict output/coverage checks. It adds `assistant_error_code`, `assistant_api_error_seen`, and `cli_transport_error` to safe CLI diagnostics. Categories use fixed allowlists; transport signatures use exact CLI-marked error messages, without retaining the message. Recognized upstream failures receive specific existing error codes. Unknown failures remain explicit errors. No retry or fallback is added. The previous hardcoded `reasoning_effort: medium` diagnostic was incorrect. The real job selected `high`; v8 reports the actual invocation configuration. ## Validation - 149 focused tests pass, including terminal error flags, category mapping, privacy canaries, process exits/signals/timeouts, turn limits, and coverage. - Kustomize render and client dry-run pass for `services/hermes`. - Isolated native Claude CLI 2.1.285 tests with a loopback mock returned `subtype: success`, `is_error: true`, exit 1, one turn, zero usage for HTTP 400/401/429/503 failures. A refused loopback connection produced the same pattern with no HTTP status and assistant category `server_error`. - These reproductions establish the adapter/envelope behavior, not the specific historical upstream failure. They used fake credentials and no hosted inference. The separately recorded live synthetic check exercises one complete 61-case proposal, not the full multi-pass workflow. It must not be represented as a rerun or recovery of the failed real job. ## Client handling and rollback No client request/schema change is required. Reusing the old idempotency key returns the old failed job. A user-initiated retry requires a fresh attempt and idempotency key; the prepared source can be reused. Do not automatically resubmit the real suite. Rollback by reverting the v8 diagnostic commit in Git and reconciling the `hermes` Flux Kustomization. This restores v7 diagnostics; it does not recover deleted output or change any completed/failed job record.