# Diagnostic Child Evidence Recovery

<!-- auto-oncall-optimization-record
{
  "schemaVersion": "auto-oncall-optimization-record-v1",
  "optimizationId": "diagnostic-child-evidence-recovery-2026-08-06",
  "problems": [
    {
      "problemId": "scenario-parent-returns-without-validated-child-evidence",
      "summary": "A provider scenario parent could return a final packet after stating that it would start an evidence child even though no validated provider batch or child handoff existed.",
      "status": "optimized_unverified",
      "issueKeys": ["ST-2865"],
      "sourceRefs": [
        "https://tidb.atlassian.net/browse/ST-2865#problem:scenario-parent-returned-without-child-evidence"
      ],
      "signalTextIncludesAny": [
        "scenario parent returned without child evidence",
        "parent claimed child start but no provider batch existed",
        "empty collaboration wait without validated handoff"
      ],
      "observedThrough": "2026-08-06",
      "effectiveAt": "2026-08-06T09:56:42Z",
      "verifiedAt": null,
      "attemptedAction": "When a Clinic or OP provider scenario returns without a validated runner-owned batch or child handoff, re-enter the same scenario parent exactly once with a bounded collaboration-state recovery instruction; accept the second result only if the artifact materializes, otherwise fail closed with an exact error.",
      "evidenceUrl": "https://pingcap.feishu.cn/docx/SDHAdVVOXoCCfJxpduOcX2hKnAh"
    }
  ]
}
-->

- Optimization ID: `diagnostic-child-evidence-recovery-2026-08-06`
- Owner: auto-oncall-services
- Source reference: post-deployment `ST-2865` run
  `1e7db950-7f57-4292-92b0-259ac243e659`
- Implementation status: merged in source PR #665 and deployed to staging in
  image `c481635f4b37b2f6e96c90d3615e13da9f138f8d`
- Effective status: `optimized_unverified`

## Bounded problem

The `ST-2865` scenario parent returned after describing a child start, but the
run had no validated Clinic batch or child handoff. The accepted packet then
contained only the supplied alert fact and evidence acquisition failed. A
prompt instruction that says "start exactly one child" is not a sufficient
runtime invariant.

## Implementation

- Apply the recovery only to Clinic, Wetech, and Manus scenarios whose evidence
  is materialized from a runner-owned provider batch.
- After the first parent response, resolve and validate the batch or handoff
  before parsing the parent packet.
- If the artifact is absent, re-enter the same parent thread once. The recovery
  must continue an existing child when one exists, or spawn exactly one child
  when none exists; it may not start a replacement child blindly.
- Keep the recovery inside the original scenario deadline and preserve the
  finalization reserve.
- If the artifact is still absent, fail closed with
  `diagnostic_scenario_child_evidence_missing_after_recovery`. Never mark the
  provider acquisition complete from parent prose alone.

## Local verification

- A focused runner test makes the first scenario turn return without a handoff,
  verifies one recovery on the same thread, materializes the handoff on that
  turn, and confirms complete evidence acquisition.
- A second test withholds the handoff from both turns and confirms exactly one
  recovery followed by the explicit fail-closed error.
- Prompt tests require collaboration-state reconciliation, forbid an empty wait
  before a successful child spawn, and require the exact provider batch path.
- TypeScript typecheck and the complete repository suite pass 668/668. Focused
  diagnostic-scenario, runner, and optimization-record coverage passes 98/98.

## Post-deployment replay

`ST-2865` replay `b28a225a-23df-4e65-9f84-ec470808e142` / DB run `120045`
completed evidence acquisition and materialized a validated Clinic batch plus
child handoff. It updated existing Jira internal comment `23432370` in place;
readback returned HTTP 200 and `public=false`.

This run did not exercise the recovery branch. The first scenario turn itself
eventually produced the batch. Its trace contains three collaboration `wait`
calls with empty agent state and no `DIAGNOSTIC_CHILD_RECOVERY` turn. The
successful evidence result proves the case recovered at outcome level and
independently verifies extrema compaction, but it does not prove the new
one-time recovery mechanism. This problem therefore advances only to
`optimized_unverified`.

## Unresolved gaps

- This candidate does not change the provider-prohibited gate or invent
  evidence when policy disallows acquisition.
- It does not make one-shot provider batches adaptive; it only guarantees that
  the selected batch gets one bounded opportunity to run.
- The deployed recovery branch still lacks case-specific execution evidence.
- The trace's empty agent-state waits despite a later batch are a separate
  observability ambiguity; do not infer a recovery turn from the artifact alone.

## Next validation action

Use the next naturally reproducing missing-artifact case, or a bounded staging
fault-injection that withholds the first-turn batch, to verify exactly one
`DIAGNOSTIC_CHILD_RECOVERY` turn on the same thread followed by either a valid
artifact or the explicit fail-closed error. Do not repeatedly replay a
successful case merely to force the branch.