# Isolated full replay

Use a one-off runner for full ticket replay so AOS Deployment releases do not
terminate the analysis. This is real Provider execution, not an offline mock.
The script invokes the same `analyzeTicketRequest` function and read dependencies
as the HTTP server, without starting its autonomous background runtime.

```bash
npm run replay:isolated -- --issue TCID-13132
npm run replay:isolated -- --collect aos-replay-tcid-13132-01234567
```

For an explicitly requested quality-first diagnostic test, use
`npm run replay:isolated -- --issue TCID-13132 --no-diagnostic-timeout`.
This passes the optional API input `noDiagnosticTimeout: true` to the production
`mode=read` request. Normal diagnostic time budgets become logged thresholds
rather than termination points; the default remains unchanged. Provider and
network timeouts still apply, as do the Job's one-hour lifetime and the
collector's one-hour wait limit. This option does not permit unbounded Provider
queries, additional refinement rounds, retries, or publication.

The Job records its selected diagnostic timeout policy. `--collect` reads that
original setting and continues collecting the same run; do not repeat the flag
with `--collect` or submit another replay after a client disconnect. Ctrl-C stops
the local collector without cancelling the Job. Collect its artifacts before
the one-hour Job deadline.

Requires Node 20+, kubectl, tar, and authorized access to the staging cluster.
`--context` selects the cluster (default: current context, frozen at startup).
The source namespace and Deployment default to `auto-oncall-services-agent9`;
`--namespace` and `--deployment` can select another explicitly authorized source.
`--output` must name a new directory; by default a private temporary directory is
created. Outputs contain internal ticket evidence: do not publish them as public
CI artifacts. No new dependencies or local build are required.

The script pins the Ready Pod's actual image digest and inherits configuration
and credential references from the source Deployment. Environment is resolved
when the Job starts. It shares the existing auth PVC on its current node; no new
PVC is created. It does not copy Service labels or run an HTTP server, poller,
worker, report scheduler or notification loop. The one analysis still runs the
normal Judge. `mode=read` does not publish Jira/DB/Base changes.

The Job has no automatic retry, a one-hour lifetime, and keeps its process alive
after analysis so the caller can retrieve artifacts. The script exports:

- `job.json` on initial creation: pinned image and configuration references;
- `summary.json`: run/fingerprint, execution and completion status;
- `pod.log`, `runs.tar.gz` and `runs/<runId>/`: full inputs, trace, output and frozen
  publication. The compressed archive is verified before extraction and cleanup.

After successful export the script deletes only its own Job. On interruption,
use the printed `--collect` command before the one-hour deadline; collection
never starts another analysis. A failed copy leaves the Job intact. `--keep-job`
retains it for inspection; its caller must delete that exact Job after exporting
evidence. If the Pod itself is lost, retain available logs and report the lost
result before deciding whether a fresh replay is necessary. This isolates AOS
rollouts, not node failures or changes in external Agent9/Provider services.

Inspect the case's actual acceptance criterion; `status=completed` means the
analysis function returned, not that all evidence or diagnostic findings passed.
When separately authorized to publish a verified read, copy the exact exported
`runs/<runId>` directory into the current AOS service's configured runs root,
verify the issue key/run ID/fingerprint, then call `/v1/tickets/publish-read` with
that issue key and read run ID. This trusted operator transfer must preserve the
frozen artifact byte-for-byte. Never regenerate or edit it, and never fall back
to a second write-mode analysis. Re-exported local files are not a public upload API.

Keep the script as the implementation owner. A future GitHub workflow can invoke
it after acquiring cluster access, then upload private artifacts and collect the
same Job on interruption. The automatic optimizer's existing HTTP integration
is unchanged; moving it to this lifecycle is separate work. Start with bounded
concurrency when integrating it, since real Provider and Agent9 capacity is shared.