Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/core/execution_plan.go`:
- Around line 27-65: CapabilitiesForEndpoint currently switches on raw
EndpointDescriptor.Operation strings (function CapabilitiesForEndpoint, type
EndpointDescriptor) which duplicates literals from internal/core/endpoints.go
and risks silent mismatches; fix by centralizing operation identifiers into
typed constants (e.g., define an Operation type and consts in
internal/core/endpoints.go) or by adding a method on EndpointDescriptor (e.g.,
EndpointDescriptor.Capabilities() or EndpointDescriptor.OperationType()
returning a typed enum) and then update CapabilitiesForEndpoint to switch on
that typed constant or simply delegate to the new
EndpointDescriptor.Capabilities() so capability logic is derived from a single
source of truth.

In `@internal/responsecache/simple.go`:
- Around line 59-60: The cache middleware computes the cache key using
hashRequest(path, body, core.GetExecutionPlan(c.Request().Context())) before
calling next(c), which lets ExecutionModeTranslated requests with a partial plan
(plan.Resolution == nil) produce incomplete keys and poison cache entries;
update the middleware to detect the execution plan via
core.GetExecutionPlan(...), and if the plan is a translated request with
plan.Resolution == nil (i.e., ensureTranslatedRequestPlan has not run yet), skip
computing the key and skip cache reads/writes—simply call next(c) and return;
apply the same guard to the second occurrence of this logic (the block around
the other hashRequest use).

In `@internal/server/model_validation_test.go`:
- Around line 237-241: The test is instantiating ModelValidation(provider) but
the server registers ExecutionPlanning(provider); update the test to construct
the same middleware used by the server by replacing ModelValidation(provider)
with ExecutionPlanning(provider) so the test exercises the actual entrypoint;
ensure the created middleware variable (currently named middleware) and the
wrapped handler that captures core.GetExecutionPlan(...) remain unchanged so the
test semantics are preserved while using ExecutionPlanning.

---

Outside diff comments:
In `@internal/server/handlers.go`:
- Around line 571-590: Extract the duplicated logic that derives providerType
and model from the ExecutionPlan into a single helper (e.g.,
ResolveProviderAndModelFromPlan) and use it from the handlers that currently
reapply plan overrides (the providerType assignment using GetProviderType(c) and
the usageModel assignment using plan.Resolution.ResolvedSelector.Model); the
helper should accept the context, Echo context or request, the plan and the
ChatRequest (to handle stream-specific cloning via
cloneChatRequestForStreamUsage when req.Stream and
shouldEnforceReturningUsageData() apply) and return the final providerType and
model (and optionally the modified request for streaming). Replace the inline
overrides in the current handler block and the other two occurrences with calls
to this new helper so all paths use
ensureTranslatedRequestPlan/execution_plan_helpers.go as the single source of
truth.

In `@internal/server/request_model_resolution.go`:
- Around line 57-68: When you clone and replace the ExecutionPlan in context
(core.GetExecutionPlan / core.WithExecutionPlan) and update whitebox hints
(core.GetWhiteBoxPrompt), also update the in-flight live audit entry so streamed
handlers see the resolved model/provider: after setting cloned.ProviderType and
cloned.Resolution, look up the active live audit entry (use the auditlog
middleware's live-entry accessor used by streaming handlers) and set its
Provider and Model from resolution.ResolvedSelector.Provider and
resolution.ResolvedSelector.Model (no-op if entry missing), ensuring the updated
entry is stored/visible to downstream streaming logging the same request
context.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/aliases/batch_preparer.go`:
- Around line 29-30: The rewrite currently allows an alias inside a native batch
to resolve to a different provider and only fails at submission; in
PrepareBatchRequest (which calls rewriteAliasBatchSource) ensure the resolved
selector/provider for every alias is validated against the enclosing batch's
providerType and reject the batch with a clear error if any resolved provider
does not match providerType. Update rewriteAliasBatchSource (and any sibling
alias-rewrite paths used for single requests) to accept the enclosing
providerType or context and compare it to the resolved selector/provider before
constructing the provider-specific request, returning an error on mismatch so
mixed-provider alias resolutions inside a native batch are rejected early.

In `@internal/core/semantic.go`:
- Around line 265-273: The code retrieves a cached pointer via
CachedPassthroughRouteInfo(), then mutates its Provider/Model and re-caches it
which breaks the immutability contract for PassthroughRouteInfo; instead, make a
shallow copy of the returned PassthroughRouteInfo (e.g., new := *passthrough)
and perform any assignments on that copy before calling
CachePassthroughRouteInfo(env, &new), referencing CachedPassthroughRouteInfo,
PassthroughRouteInfo, selectors.Provider, selectors.Model and
CachePassthroughRouteInfo to locate the spot to change.

In `@internal/guardrails/executor.go`:
- Around line 105-115: processGuardedChat currently calls chatToMessages before
checking whether any guardrail pipeline is present, which can cause unnecessary
decoding and false rejections (e.g., via NewRequestPatcher(nil)) when pipeline
is nil or empty; move the nil/empty check for pipeline (the same check used in
processGuardedResponses) to run before chatToMessages so the function returns
the original req unchanged when pipeline == nil or pipeline.Len() == 0, and only
call chatToMessages and subsequent patching when a non-empty pipeline is
present.

In `@internal/guardrails/provider.go`:
- Around line 26-29: PrepareBatchRequest currently always calls
processGuardedBatchRequest which causes inconsistent behavior versus the direct
CreateBatch* paths that respect EnableForBatchProcessing; update
PrepareBatchRequest to check the EnableForBatchProcessing flag and skip calling
processGuardedBatchRequest when the flag is false so it matches the CreateBatch*
behavior. Specifically, in PrepareBatchRequest (and any other entry points that
currently invoke processGuardedBatchRequest), add a guard: if
EnableForBatchProcessing is true then call processGuardedBatchRequest, else
bypass guardrail rewriting and proceed as the CreateBatch* paths do; ensure the
same conditional is applied to all locations that previously unconditionally
invoked processGuardedBatchRequest (including the other call sites roughly
corresponding to the blocks around 353-399 and 583-587) so behavior is
consistent across PrepareBatchRequest, CreateBatchRequest/CreateBatchResponses,
and related methods.

In `@internal/providers/anthropic/passthrough_semantics.go`:
- Around line 28-31: The fallback audit path currently uses info.RawEndpoint
which can produce non-canonical audit paths; instead build enriched.AuditPath
from the normalized upstream endpoint used elsewhere in this enricher (e.g., the
variable holding the canonical/normalized endpoint value), trimming leading
slashes and joining with "/p/anthropic/". Replace the use of info.RawEndpoint
with that normalized endpoint variable so `/p/anthropic/v1/foo` and
`/p/anthropic/foo` collapse to the same audit path.

In `@internal/providers/openai/passthrough_semantics.go`:
- Around line 31-34: The fallback AuditPath construction in the default branch
currently uses info.RawEndpoint which causes divergences; change it to build
enriched.AuditPath from the normalized upstream endpoint (use the normalized
endpoint field on info instead of info.RawEndpoint) so both alias-normalized
routes map to the same audit key—i.e., replace the
strings.Trim...(info.RawEndpoint) usage when setting enriched.AuditPath with the
normalized endpoint value.

In `@internal/server/native_batch_service.go`:
- Around line 79-95: On any failure after calling CreateBatch (including the
upstream==nil path, missing providerBatchID path, and the batchStore.Create
failure path), perform a best-effort rollback: if
s.cleanupPreparedBatchInputFile != nil call s.cleanupPreparedBatchInputFile(ctx,
providerType, batchPreparation.RewrittenInputFileID) to delete the rewritten
input file, clear any hint/state that points to the prepared batch (invoke your
existing hint-clear method or add one and call it for the same
RewrittenInputFileID), and if an upstream ID was already returned (upstream.ID
or upstream.ProviderBatchID != ""), attempt to cancel the upstream batch via the
provider client (add a helper like s.cancelUpstreamBatch(ctx, providerType,
upstream.ID) that calls the provider cancel API and ignores errors). Apply this
rollback logic both around the upstream==nil/providerBatchID checks and where
batchStore.Create fails after receiving the upstream response.

In `@internal/server/native_batch_support.go`:
- Around line 561-572: The current isNativeBatchResultsPending function (used
when handling gateway errors) treats any 404 from providers listed in
batchResultsPending404Providers as "results pending"; change this to avoid false
positives by either checking a provider-specific error code/message on
gatewayErr (e.g., examine gatewayErr.Code() or gatewayErr.Message() for the
non-terminal indicator for that provider) before returning true, or perform a
follow-up GetBatch call for the given batch ID and only return true if that call
reports an active/non-terminal state; update isNativeBatchResultsPending to
reference gatewayErr.Provider and gatewayErr.Code()/Message() (or to call
GetBatch) so real upstream 404/expired cases are not considered pending.

In `@internal/server/native_file_service.go`:
- Around line 137-140: The code uses io.ReadAll(file) in the native file upload
path which reads the entire file into memory; replace this with a streaming
approach so large uploads don't exhaust memory — for example, change the logic
around the variable file in the same handler to stream the file to the
downstream provider or to a temporary file using io.Copy (or pass the io.Reader
directly) and return errors via handleError/core.NewInvalidRequestError as
before; ensure any downstream call that previously accepted content (the content
variable) is updated to accept an io.Reader or the temp file reference so you no
longer allocate the whole file in memory.

In `@internal/server/passthrough_semantic_enrichment.go`:
- Around line 38-40: The code swallows normalization errors from
normalizePassthroughEndpoint and continues to set info.NormalizedEndpoint,
causing invalid passthrough endpoints to be enriched/cached; change the logic in
passthrough_semantic_enrichment.go so that when
normalizePassthroughEndpoint(info.RawEndpoint, allowPassthroughV1Alias) returns
a non-nil error you return early (or at minimum skip all enrichment and caching
for that request) instead of proceeding—use the returned error to decide not to
set info.NormalizedEndpoint and to abort further processing of that info object.

In `@internal/server/passthrough_service.go`:
- Around line 33-40: The code currently prefers the client X-Request-ID header
over the existing context value; instead call the existing helper
requestIDFromContextOrHeader to obtain the authoritative request ID and updated
context, then set that context back onto the incoming request so downstream code
sees the server-assigned ID (use c.SetRequest(c.Request().WithContext(ctx))
after you obtain ctx and requestID). Ensure you still call core.WithRequestID or
otherwise preserve the request ID in context as the helper expects.

In `@internal/server/passthrough_support.go`:
- Around line 224-261: The proxyPassthroughResponse function currently forwards
provider responses verbatim; modify proxyPassthroughResponse to check
resp.StatusCode and, for any non-success status (>=400), do not write the
provider headers/body but instead construct a core.GatewayError (with
OpenAI-compatible shape: error.type, error.message, error.param=null,
error.code=null and a typed client-facing category) and return it via
handleError so clients always receive a normalized GatewayError; keep existing
streaming path (isSSEContentType, audit log wrapping) intact but ensure
streaming errors still map to core.GatewayError on non-success; use the existing
symbols proxyPassthroughResponse, handleError, core.GatewayError,
copyPassthroughResponseHeaders, isSSEContentType and passthroughAuditPath to
locate where to add the status check and normalization.

In `@internal/server/request_model_resolution.go`:
- Line 38: The parameter named resolver is being shadowed by the short-variable
declaration in the if statement; change the inner variable name to avoid
shadowing (for example, assign effectiveRequestModelResolver(provider, resolver)
to a new variable like resolvedModel or res and use that in the if check) so the
function parameter resolver remains unshadowed; update any subsequent uses
inside the block to reference the new variable. Reference: the function
parameter resolver and the call effectiveRequestModelResolver(provider,
resolver).

In `@internal/server/request_support.go`:
- Around line 36-37: Guard against a nil Header on the incoming *http.Request
before calling req.Header.Set("X-Request-ID", requestID) by checking if
req.Header == nil and initializing it (req.Header = make(http.Header)) when nil;
update the request_support.go location around the req.Header.Set call to perform
this defensive initialization so future call sites that omit headers won’t
panic.

---

Outside diff comments:
In `@internal/core/batch_semantic.go`:
- Line 15: Change DecodedBatchItemRequest.Operation from string to the typed
Operation and update any call sites that currently cast it with string() (these
are the spots around where items are decoded and used). Update
canonicalOperationCodecFor to accept an Operation instead of string and adjust
its usage and tests accordingly. Also update the error formatting that builds
messages from the operation (previously using string()) so it formats the
Operation value directly. Ensure all places constructing/reading
DecodedBatchItemRequest are updated to use the Operation type.

In `@internal/server/handlers.go`:
- Around line 292-307: Update the Swagger comment above the Handler.Responses
function to document the streaming variant: add "@Produce text/event-stream"
alongside the existing "@Produce json", and add a streaming success annotation
(e.g., an additional "@Success 200 {string} string \"SSE stream
(text/event-stream) when stream=true\"") or otherwise clarify the 200 response
for streaming. Reference the Handler.Responses handler and the
translatedInferenceService.Responses behavior (stream=true) so API docs and
generated clients include "text/event-stream" and the streaming success
description for /v1/responses.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/aliases/provider.go`:
- Around line 310-314: PrepareBatchRequest currently always rewrites batches via
rewriteAliasBatchSource, bypassing the DisableNativeBatchPreparation option;
update Provider.PrepareBatchRequest to check the Provider option
(DisableNativeBatchPreparation) and short-circuit (return nil, nil or
appropriate no-op/forward result) when the option is set so behavior matches
CreateBatch/CreateBatchWithHints, or alternatively prevent exposing this method
when that flag is enabled; locate the Provider struct and its
DisableNativeBatchPreparation flag and modify PrepareBatchRequest to honor that
flag before calling rewriteAliasBatchSource.

In `@internal/guardrails/executor.go`:
- Around line 62-102: processGuardedBatchRequest should short-circuit when
pipeline is nil or empty to match processGuardedChat/processGuardedResponses:
before calling core.RewriteBatchSource, check the pipeline (e.g., pipeline ==
nil || len(pipeline.Stages) == 0 or the same emptiness test used by
processGuardedChat/processGuardedResponses) and if empty return the original req
as an unmodified *core.BatchRewriteResult (or the same "no-op" result used
elsewhere) with nil error; otherwise proceed to call core.RewriteBatchSource as
currently implemented. Ensure you reference processGuardedBatchRequest,
processGuardedChat, processGuardedResponses and core.RewriteBatchSource so the
change mirrors the existing fast-path behavior.

In `@internal/server/native_batch_service.go`:
- Around line 177-214: The GetBatch handler uses requestContextWithRequestID to
derive ctx but then calls s.batchStore.Update with c.Request().Context(),
causing inconsistent context propagation; change the Update call to use the
previously derived ctx (from requestContextWithRequestID) so any request-scoped
values/tracing are preserved, i.e., replace c.Request().Context() with ctx when
invoking s.batchStore.Update inside GetBatch (and ensure any other calls in
GetBatch that use c.Request().Context() instead use ctx as well).
- Around line 274-311: The CancelBatch handler extracts ctx via
requestContextWithRequestID but then calls s.batchStore.Update with
c.Request().Context(), causing inconsistent request contexts; change the Update
call (and any other uses of c.Request().Context() in CancelBatch) to use the
previously created ctx so the same request-scoped context
(requestContextWithRequestID) is propagated through
nativeBatchService.CancelBatch, including the call to s.batchStore.Update and
any cleanup calls like cleanupStoredBatchRewrittenInputFile.

In `@internal/server/native_batch_support.go`:
- Around line 134-246: The logBatchUsageFromBatchResults function is doing too
many things; extract smaller helpers to improve readability and testability by
splitting validation/early returns, per-item processing, and totals
accumulation. Create a helper like processResultItem(resultItem, storedBatch,
fallbackRequestID) (or processBatchResultItem) that encapsulates the payload
parsing (asJSONMap), usage extraction (extractTokenTotals),
provider/model/providerID resolution, raw usage building
(buildBatchUsageRawData), pricing lookup (h.pricingResolver.ResolvePricing),
usage entry creation (usage.ExtractFromSSEUsage) and setting entry.ID via
deterministicBatchUsageID, returning the entry plus per-item token/cost values;
create another helper accumulateUsageTotals(aggregate, entry, inputTokens,
outputTokens, usageTotal) to update loggedEntries, inputTotal, outputTotal,
totalTokens and cost totals and hasAnyCost; keep the top-level
logBatchUsageFromBatchResults to handle initial validation, loop over
result.Data calling processResultItem and accumulateUsageTotals, write entries
with h.usageLogger.Write, and finally mutate stored.RequestID,
stored.UsageLoggedAt and stored.Batch.Usage from the accumulated totals.

In `@internal/server/native_file_service.go`:
- Around line 70-76: The audit entry currently clears provider attribution via
auditlog.EnrichEntry(c, "file", "") and then returns on the first successful
candidate without restoring the provider; update the loop so that before
returning on success you set the provider attribution to the chosen candidate
(e.g., call auditlog.EnrichEntry(c, "file", candidate) or whichever key/value is
used to record provider) so GetFile/DeleteFile/GetFileContent are audited with
the resolved provider, and ensure any previous value is restored or only cleared
where intended; modify the success path inside the providers loop around
callFn/respondFn to set the provider attribution before calling respondFn.
- Around line 201-224: The merged listing incorrectly queries each provider with
after="" which hides items when a client supplies an older cursor; update the
providers loop to forward the request's after cursor to nativeRouter.ListFiles
(use the existing after variable instead of the empty string) so each backend
pages from the same cursor, continue fetching limit+1 per provider to detect
extra item, and keep the post-merge applyAfterCursor call to trim/normalize
results and handle deduping; reference nativeRouter.ListFiles, applyAfterCursor,
providers, limit+1 and after when making the change.

---

Outside diff comments:
In `@internal/providers/file_adapter_openai_compat.go`:
- Around line 81-114: The upload goroutine can block if the HTTP request returns
early because the pipe reader (pr) is never closed; to fix, ensure pr is closed
when the request path exits by adding a defer to close pr after starting the
writer goroutine but before calling client.Do. Specifically, after spawning the
anonymous goroutine that writes to pw (and before invoking client.Do with
RawBodyReader: pr), add a defer that calls pr.Close() (ignore the error) so the
writer goroutine is unblocked on early client.Do returns and cannot leak; keep
existing pw.CloseWithError usage in the goroutine as-is.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/server/model_validation.go`:
- Around line 73-80: The code stores a passthrough plan while leaving
passthroughRouteInfo().Provider potentially empty because
providerPassthroughType(c) can recover the provider separately; fix by
populating the passthrough object with the resolved provider before assigning it
to plan. Concretely: call passthroughRouteInfo(c) into a local variable, call
providerPassthroughType(c) to get providerType (and the provider identifier),
set passthrough.Provider = <resolved provider> (or otherwise copy the provider
value returned by providerPassthroughType) then set plan.Mode =
core.ExecutionModePassthrough, plan.ProviderType = providerType and finally
plan.Passthrough = passthrough. Apply the same change in the other similar block
that currently repeats this logic.
- Around line 237-245: Update the GoDoc for GetProviderType to reflect that it
reads the provider type from the request's execution plan via
core.GetExecutionPlan and is part of the ExecutionPlanning flow (not
ModelValidation); replace the outdated "set by ModelValidation" phrasing with
wording that says the value is read from the request execution plan
(ExecutionPlanning) so callers understand the source and context of the provider
type.

In `@tests/e2e/release-e2e-scenarios.md`:
- Around line 369-396: The tests are nondeterministic because steps keep
rediscovering resources with list&limit=1; instead, capture and reuse IDs
returned by the create/upload calls (e.g., parse the create responses in S35,
S39, S42 into variables like BATCH_FILE_ID, ASSISTANT_FILE_ID, and whatever ID
S42 returns) and reference those variables in dependent steps (S38, S40, S46,
etc.) rather than re-querying with limit=1; update the create/upload commands to
extract the .id from their JSON responses into shell variables and replace
subsequent curl list/delete calls to use those variables so
deletion/cancellation targets the exact created resource.
- Around line 107-110: The AUDIT_ID extraction using jq -r on the admin audit
endpoint can yield null on a clean gateway causing a later query to use
log_id=null; update the S11 scenario to either perform a guaranteed audited
request before reading the audit log (e.g., send a simple request that creates
an audit entry) or change the jq call that sets AUDIT_ID (the line assigning
AUDIT_ID and the jq invocation) to use jq -er so it fails fast on empty results;
ensure the subsequent AUDIT_ID usage and the curl to
/admin/api/v1/audit/conversation keep the same variable name and handle failure
accordingly.
- Around line 13-27: The happy-path curl calls that currently use patterns like
"curl -sS | jq" or "curl -sS | sed" must detect HTTP errors: update those
positive-probe invocations to either use curl --fail (or -f) so curl returns
non-zero on 4xx/5xx, or capture the HTTP status with curl -w "%{http_code}" -o
<respfile> and explicitly check the status before piping to jq/sed; apply this
change to the probes that reference the BATCH_FILE and UPLOAD_FILE uploads and
any other success-path curl invocations so a 4xx/5xx causes the script to error
rather than produce null/partial JSON output.
- Around line 252-259: Update the S26 "Latest GPT reasoning on chat (negative)"
scenario (and the other listed negative scenarios 405-410, 443-445, 473-475,
515-518) to perform explicit pass/fail assertions instead of dumping raw
responses: invoke the same curl request but assert the HTTP status is the
expected failure code and verify the response body uses the OpenAI-compatible
error shape with fields error.type, error.message, error.param, and error.code
and that the server-side error maps to a core.GatewayError category (so the
client-facing fields reflect the typed category); reference the scenario title
"S26 Latest GPT reasoning on chat (negative)" and the request payload keys
"model","messages","reasoning" to locate where to add the checks and add the
normalized error assertions to each corresponding negative test block.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@tests/e2e/auditlog_test.go`:
- Around line 621-652: After posting to serverURL+"/p/unknown/responses" and
asserting StatusBadRequest, decode resp.Body as JSON and assert the
OpenAI-compatible error envelope fields: ensure the top-level has "error" object
and that error.type equals "invalid_request_error" (or matches entry.ErrorType),
error.message is the client-facing message, error.param is null (or the expected
param), and error.code is null (or expected code); update the subtest around the
http.Post call and resp handling (variables: resp, closeBody, serverURL) to
parse the body and add assertions for error.type, error.message, error.param,
and error.code to satisfy the GatewayError/OpenAI shape requirement.

In `@tests/e2e/release-e2e-scenarios.md`:
- Line 31: The markdown headings like "### S01 Health endpoint" violate MD022 by
lacking a blank line before each "###" heading; fix this by inserting a single
blank line immediately above every "###" heading (e.g., above "### S01 Health
endpoint" and the other listed "### ..." scenario headings) so each heading is
separated by one empty line from the preceding content; ensure you update all
occurrences referenced in the comment.

---

Duplicate comments:
In `@internal/server/model_validation.go`:
- Around line 73-80: The stored ExecutionPlan can end up inconsistent when
passthroughRouteInfo(c) returns a RouteInfo with an empty Provider but
providerPassthroughType(c) recovers provider from the path; fix by populating
plan.Passthrough.Provider with the recovered provider before storing the plan:
after calling providerPassthroughType(c) and setting plan.ProviderType, set
plan.Passthrough.Provider = provider (or the recovered provider value) so
plan.Passthrough and plan.ProviderType remain consistent for any direct
ExecutionPlan readers.
- Around line 237-238: Update the GoDoc for GetProviderType to reflect that the
provider type is derived from the execution plan via core.GetExecutionPlan
rather than being "set by ModelValidation"; locate the GetProviderType function
and change its comment to describe that it returns the provider type read from
the execution plan (obtained from core.GetExecutionPlan) for the current
request, including any relevant context about execution-plan precedence or
fallback behavior.

In `@tests/e2e/release-e2e-scenarios.md`:
- Around line 369-370: Replace the nondeterministic list-and-pick-first pattern
that sets FILE_ID by querying the list endpoint with a deterministic reuse of
the ID captured when the resource was created (referenced as create steps
S35/S39/S42); update the scenarios that currently run "curl ...
/v1/files?provider=openai&purpose=batch&limit=1" and the subsequent GET to
instead reference the variable populated at create time (the original create
response's ID) so dependent scenarios reuse the exact created resource ID rather
than rediscovering with limit=1.
- Around line 108-110: The AUDIT_ID extraction can produce "null" and let the
scenario continue; update the AUDIT_ID assignment (the command that sets
AUDIT_ID=$(curl ... | jq -r '.entries[0].id')) to use jq -er (or otherwise
assert non-empty) so it exits non-zero when no entry exists, or proactively
create/seed an audit entry before querying; ensure the subsequent curl that uses
log_id=$AUDIT_ID only runs when AUDIT_ID is valid (i.e., fail fast on missing
audit entries).
- Around line 35-36: The positive HTTP probe calls like curl -sS
"$BASE_URL/health" should be fail-fast so 4xx/5xx are not treated as valid
output: update these invocations (e.g., the health check and the other probes
referenced) to use curl -f -sS (or replace with an explicit HTTP status check
using curl -sS -o /dev/null -w "%{http_code}" and assert the code) and preserve
any subsequent jq/sed parsing; ensure all listed occurrences (the lines around
the health probe and the ranges noted in the comment) are updated consistently.
- Around line 256-259: The E2E probe using the curl POST to
"$BASE_URL/v1/chat/completions" currently only prints the raw response; change
it to assert expected HTTP status and normalized error fields by capturing HTTP
status (e.g., via curl -w "%{http_code}" or using jq) and parsing the JSON body
to check error.* fields (error.message, error.type, error.code) are
present/normalized when an error is expected, and that a successful call yields
200 and the expected response token (e.g., validate body for
"QA_GPT5_REASONING_OK"); update the curl invocation and the following validation
logic so each probe fails non‑zero when assertions fail, using the same curl
command and payload from the diff as the target to modify.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/aliases/provider_test.go`:
- Around line 297-315: The test currently only checks inner.fileCreates, which
won't fail if PrepareBatchRequest still reads the source file; update the mock
"inner" to either (a) have its GetFileContent method call t.Fatalf (or return an
error) when invoked, or (b) record calls (e.g., inner.fileGets) and assert
len(inner.fileGets)==0 after calling provider.PrepareBatchRequest; change the
test around NewProviderWithOptions/PrepareBatchRequest to fail if
inner.GetFileContent is invoked so the opt-out guarantees no native
batch-preparation I/O.

In `@internal/auditlog/middleware.go`:
- Around line 169-193: The audit enrichment misses copying the execution plan's
canonical request ID into the log entry; update enrichEntryWithExecutionPlan to
set entry.RequestID = plan.RequestID (when plan != nil and plan.RequestID is not
empty) so the audit log uses the same canonical request ID derived by
requestIDFromContextOrHeader; keep the existing nil checks and only overwrite
entry.RequestID when plan.RequestID is non-empty to avoid clobbering any
pre-existing value.

In `@internal/server/model_validation.go`:
- Around line 100-115: When the model registry is uninitialized (the
modelCountProvider branch) we currently return core.NewProviderError before
populating the plan, losing provider/model context; fix by assigning
plan.ProviderType = resolution.ProviderType and plan.Resolution = resolution and
calling auditlog.EnrichEntryWithExecutionPlan(c, plan) prior to returning the
error so the audit trail and response retain the resolved provider/model
information (references: plan, resolution, provider, modelCountProvider,
core.NewProviderError, auditlog.EnrichEntryWithExecutionPlan,
ensureRequestModelResolution).

In `@internal/server/native_file_service.go`:
- Around line 103-117: The code currently calls s.providerTypes()
unconditionally in CreateFile which breaks routers that implement
core.NativeFileRoutableProvider but not core.NativeFileProviderTypeLister;
change the logic so s.providerTypes() is only invoked when fileReq.Provider
(providerType) is empty: move the providers, err := s.providerTypes() call and
its error handling inside the providerType == "" branch (the branch that checks
len(providers) == 0/1/>1), leaving the path that has a provided providerType to
proceed directly to nativeRouter.CreateFile without consulting provider
inventory; keep references to providerType, fileReq.Provider, handleError, and
nativeRouter.CreateFile unchanged.

In `@tests/e2e/release-e2e-scenarios.md`:
- Line 542: The hardcoded "sleep 6" is environment-dependent and can cause flaky
E2E runs; replace each occurrence of "sleep 6" (the three spots including the
one shown) with "sleep $FLUSH_WAIT_SECONDS" and document or set a default at
environment setup by exporting FLUSH_WAIT_SECONDS=${FLUSH_WAIT_SECONDS:-6} so CI
can override it; ensure any README or environment setup block adds that export
and update the three lines (the exact token "sleep 6") to use the new variable.
- Around line 469-475: The test writes a fixed temporary file
/tmp/qa-mixed-provider-batch.jsonl which can collide across runs; update the
script that creates the file (the here-doc for
/tmp/qa-mixed-provider-batch.jsonl and subsequent FILE_ID/curl calls) to use a
unique temp filename (e.g., via mktemp or appending $$ or a timestamp) and
ensure the file is removed after use (use an explicit rm or a trap cleanup) so
FILE_ID and the curl -d steps operate on the unique file and no stale artifact
remains.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@internal/auditlog/middleware.go`:
- Around line 183-187: The audit entry isn't getting the canonical passthrough
path; when plan.Mode == core.ExecutionModePassthrough and plan.Passthrough !=
nil (the block that already sets entry.Model), also set entry.Path =
plan.Passthrough.AuditPath (after trimming/validating if needed) so the logged
entry uses the canonical passthrough audit path instead of the raw gateway
route; update the same conditional that references plan.Mode,
core.ExecutionModePassthrough, and plan.Passthrough to copy
plan.Passthrough.AuditPath into entry.Path.

In `@internal/server/native_file_service.go`:
- Around line 177-189: The ListFiles handler must normalize nil responses and
nil resp.Data to an empty slice so callers always see data: [] instead of data:
null; after calling nativeRouter.ListFiles (in the branch where providerType !=
""), ensure that if resp == nil you instantiate resp =
&core.FileListResponse{Object: "list", Data: make([]*core.FileMeta, 0)} and if
resp.Object == "" set resp.Object = "list", and if resp.Data == nil set
resp.Data = make([]*core.FileMeta, 0); keep existing error handling via
handleError and auditlog.EnrichEntry unchanged.
- Around line 204-223: The GetFile and DeleteFile success handlers currently
pass provider results directly to c.JSON, which yields a 200 null when the
provider returns a typed nil; update the anonymous result handlers passed into
fileByID (used by nativeFileService.GetFile and nativeFileService.DeleteFile) to
detect typed-nil results (e.g., result == nil or
reflect.ValueOf(result).IsValid() && reflect.ValueOf(result).IsNil()) and treat
them as a gateway/provider error instead of returning 200; return an appropriate
error response (same shape you use elsewhere for provider failures, consistent
with GetFileContent’s behavior) so typed-nil results become an error response
rather than 200 null.
- Around line 352-374: The ListFiles response handling can create an infinite
loop when a backend ignores the `after` cursor and returns the same last item
with `HasMore=true`; update the block that processes `resp` (after calling
nativeRouter.ListFiles) to detect a non-advancing cursor by comparing the last
item's ID to the current `state.after` (use `state.after`, `state.items`,
`resp.HasMore` and the last item ID), and if they are equal treat the page as
terminal (set `state.hasMore=false` and `state.exhausted=true`, optionally log a
warning) so `nextMergedFile` won't keep reloading the same page forever.

In `@internal/server/request_snapshot_test.go`:
- Around line 195-197: Rename the test function currently named
TestModelValidation_UsesSemanticEnvelopeWithoutReadingBody to match the
refactored middleware name by renaming it to
TestExecutionPlanning_UsesSemanticEnvelopeWithoutReadingBody; update the test
declaration (the `func
TestModelValidation_UsesSemanticEnvelopeWithoutReadingBody(t *testing.T) { ...
}`) and any references to that identifier so it reflects the middleware under
test (`ExecutionPlanning`) and keeps the test behavior unchanged.