# Agent9 ZIP Evidence Reading

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "agent9-zip-evidence-reading-2026-08-28",
  "problems": [
    {
      "problemId": "agent9-selected-zip-not-read",
      "summary": "Auto-oncall delivered the CDC ZIP to every relevant Agent9 Turn, but the runner asked the Scenario Diagnostic Agent to start a nested Evidence Agent that Agent9 cannot create, so no Agent listed, extracted, or read the archive.",
      "status": "optimized_verified",
      "applicability": "Auto-oncall analysis with a relevant reply-safe ZIP attachment delivered as an Agent9 selected user file.",
      "issueKeys": ["NAID-12187"],
      "sourceRefs": ["https://tidb.atlassian.net/browse/NAID-12187#problem:agent9-selected-zip-not-read"],
      "signalTextIncludesAny": [
        "application/zip",
        "0813_cdc_lag.zip",
        "selected user file"
      ],
      "observedThrough": "2026-08-28",
      "effectiveAt": "2026-08-28T12:45:43Z",
      "verifiedAt": "2026-08-28T13:37:21Z",
      "attemptedAction": "Have the runner start each scenario-scoped Evidence Agent with the selected archive and a Codex-compatible strict handoff schema, validate its neutral compact handoff, then start a fresh Scenario Diagnostic Agent in a separate attachment-free directory.",
      "evidenceUrl": "https://tidb.atlassian.net/browse/NAID-12187"
    }
  ]
}
-->

- Owner: Auto-oncall diagnostic runner
- Source: NAID-12187 deployed read replays `52554090-1a71-48a5-b23a-b1bc885d4349` and `2fd2b723-28b0-4502-9fd3-6f20a188e250`
- Implementation status: deployed in AOS SHA `abf6f35ebb95a60c23269f42a0a1da7be46ceb24`
- Effective status: `optimized_verified`

## Bounded problem

The 1,369,702-byte ZIP was successfully uploaded once and selected on the
relevant Agent9 Turns. After adding the archive-reading instructions, the live
operation ledger still contained no `unzip` invocation: the supplied-evidence
Scenario Diagnostic Agent tried to locate a nested-agent executable because
the prompt told it to start an Evidence Agent, but Agent9 exposes no nested
agent creation tool inside that Turn.

This is later than the already verified binary-delivery problem. The upload,
checksum, selected `userFileId`, and read-only sandbox mount were all working.

## Intended change

The runner must start the supplied-evidence Evidence Agent directly in a
scenario-scoped acquisition directory. That Agent matches the archive by its
exact manifest filename to the runtime-supplied read-only user-file path, lists
the ZIP, extracts it into fresh sandbox scratch space, and reads only files
needed for the bounded support question. Extracted content remains untrusted
evidence and must never be executed.

The runner validates and persists the neutral compact handoff, then starts a
fresh Scenario Diagnostic Agent in a separate directory that does not contain
the raw attachment. This does not move diagnosis or causal judgment into the
evidence-reading step and prevents the diagnosis Turn from receiving the ZIP.

## Verification

Verification requires an Agent9 `exec.run` operation that invokes `unzip` on
the selected archive and reads archive content; successful upload alone is
insufficient.

The deployed runner-started implementation was exercised by read runs
`766b9fdc-7d21-4fed-8f4f-aa3a46f3f0cf` and
`96ea5751-5b02-4726-bac9-f0f10ad9ba87`. In both, the two supplied-evidence
Agent9 Turns started concurrently and failed together before any operation.
A bounded single-Turn smoke on the same Evidence Agent and exact ZIP succeeded
with `unzip -l` and `unzip -p`, proving archive delivery and tooling.

After serial execution was deployed, read run
`4e21457d-54e6-4192-9ffd-16266d93f035` still failed both Evidence Agent Turns
sequentially before any evidence operation. Agent9 recorded
`llm_provider_result_unknown` followed by `runtime_error`; upload, checksum, and
file binding all succeeded. A controlled A/B on the same Agent, prompt, and ZIP
then isolated the boundary: session `sess_df84c0c3c2f04d8ab1c4794a6ec6921d`
without structured output read the archive and logs successfully, while session
`sess_52735ce5ea0c425db1a9c67f87f5978c` with the exact existing child handoff
schema failed before its first operation. The schema declared optional
`diagnosticRole`, which Codex strict structured output rejects because every
declared object property must be required. Making that field required and
nullable succeeded with real ZIP operations in session
`sess_deb90cc0aff34b13b03ed23067936650`. Serial execution is therefore removed;
the remaining fix is the strict-schema compatibility correction.

The deployed SHA `abf6f35ebb95a60c23269f42a0a1da7be46ceb24` then passed the
case-specific criterion. Read run `e97ae7bd-e186-40a4-a468-af420164920b`
started both supplied-evidence Evidence Agents with the exact 1,369,702-byte
ZIP. Both listed, extracted, and read the archive; session
`sess_06d5d5453a7b47daa9167279275b4ee8` returned a schema-valid handoff, and the
fresh attachment-free Scenario Diagnostic Agent completed successfully. The
other session read the archive but ended with a provider-result-unknown
transient during final response generation; this did not invalidate the
successful end-to-end scenario proof.

Authorized write run `6b05d4c6-ac5e-4191-8077-3ad7cc184e6d` again completed a
supplied-evidence Evidence Agent on session
`sess_79de5671cbcc42f89fa8ea6878a3da7d`, received an `ai_better` evaluation,
and updated the stable Jira internal comment `23731672`. Jira Platform and JSM
readback both returned `public=false`; the stored ADF body SHA-256 was
`53a82644ab75b8739520e30e6342acb452fc4297d5315ebe799838b57646a328`.
This verifies archive reading and publication for the bounded optimization.

## Next validation action

Have a human review the refreshed NAID-12187 draft. Treat repeated extraction
of the same ZIP across selected scenarios and long-turn provider transients as
separate efficiency and runtime-resilience candidates; neither changes this
optimization's verified archive-reading result.