Distillation

Date: Sep 16, 2026

• 🔴 (21:57) User required recall-recovery overflow to synchronously route through the fixed recall failure, preserve only previously validated accounting, and never convert failure into completion.
• 🔴 (21:57) User required OpenAI Responses recall to use transformed full-history replay with store:false and never rely on client state or previous_response_id.
• 🔴 (21:57) User required recall handling to accumulate events internally, expose only finalized authoritative text, and never leak recall data, ciphertext, diagnostics, references, or synthetic lifecycle events.
• 🔴 (21:57) User required createRecallDiagnostics() fingerprints and recall content to never leave its request-local closure; diagnostics use request-local SHA-256 sets, bounded aggregate counters, a 64-round limit, and clear input, result, pair, and coverage sets on finish().
• 🔴 [restricted-environment-access] (21:57) User reiterated: “Never access/touch/restart server or production DB.”
• 🟡 (21:57) Recovered accounting design: request-owned cumulative usage and ordered Codex quota accumulators were chosen instead of mutating each response, because failed-continuation metadata must survive recovery without escaping the rollback boundary. Failed-terminal and recovered metadata are merged only after validation inside the recovery try.
• 🟡 (21:57) Recovered continuation usability rules: recovery requires a protocol-complete envelope containing identity, model, usage, assistant role, content, and allowlisted successful terminal semantics. OpenAI Chat accepts exactly one choice with finish reason stop, tool_calls, or length, but length remains unusable for recovery. Malformed JSON, failure aliases, blank tools, private reasoning-only output, repeated recall, exhaustion, or cancellation must produce the fixed public failure without persistence or partial output.
• 🟡 (21:57) Recovered OpenAI Responses requirements: validate protocol identities, roles, usage, terminal reasons, sequencing, limits, and recovery envelopes; require parseSSE before forwarding recall follow-ups and assert an actual SSE response.
• 🟡 (21:58) Candidate-wide diff from parent spyyzvyy / 3f3ae768fde5 contains 10 files with 1,086 insertions and 54 deletions: added packages/gateway/src/codex-rate-limits.ts (120 lines); modified packages/gateway/src/pipeline.ts (136-line diff), packages/gateway/src/recall.ts (6-line diff), packages/gateway/src/stream/openai-responses.ts (74-line diff), packages/gateway/src/translate/openai-responses.ts (5-line diff), packages/gateway/test/codex-usage-metadata.test.ts (162-line diff), packages/gateway/test/openai-responses-recall-aware-stream.test.ts (168-line diff), packages/gateway/test/pipeline-streaming.test.ts (126-line diff), packages/gateway/test/recall-buffered-transaction.test.ts (302-line diff), and packages/gateway/test/recall.test.ts (41-line diff).
• 🟡 (21:58) Investigation located recall implementation symbols in packages/gateway/src/recall.ts: hasRecallToolUse() at line 916, executeRecall() at line 1061, isUsableRecallContinuation() at line 1191, buildRecallRecoveryRequest() at line 1334, and runRecallRecovery() at line 1769.
• 🟡 (21:58) packages/gateway/src/recall.ts defines the recovery instruction at line 1331: “Continue the user's task using the accepted recall results and the context already available. Give your best supported answer or use an available non-recall tool. Do not request recall and do not mention recovery or provider failures.”
• 🟡 (21:58) Investigation found OpenAI Responses usage validation in packages/gateway/src/stream/openai-responses.ts, including validateResponsesUsage() around lines 258 and 780, an unsuccessful-terminal accounting type around line 575, and a recovery-synthesis completeness requirement for identity, usage, and item state around line 1907.
• 🟡 (21:58) Investigation found packages/gateway/src/translate/openai-responses.ts uses safeTokenSum in responsesUsage() to detect Responses usage overflow, emits cached_tokens and cache_write_tokens, and sanitizes quota metadata through sanitizeCodexRateLimitEvents() before emitting codex.rate_limits.
• 🟡 (21:59) Investigation located buffered recovery flow in packages/gateway/src/pipeline.ts: recall loop begins around line 18314; recoveryRequestBase is captured around line 18442; makeJSONRecallCtx(recovery) disables cacheTools and systemTTL during recovery and sets requireSuccessfulCompletion; runRecallRecovery() executes around line 18481; failed recovery routes to failRecall(category, false); recovered output is rejected if it contains another recall tool use or fails isUsableRecallContinuation(); remaining recall at line 18649 routes to failRecall("depth_exhausted").