# June Consulting Ticket Dry Run Plan

Date: 2026-07-02

## Current Design

`auto-oncall-services` runs one Jira ticket at a time through
`POST /v1/tickets/analyze`. The runner prepares a replay workspace, selects an
L1 reply target, and returns `replayContextMarkdown` plus
`simulatedL1ReplyMarkdown`.

Jira credentials are available through the service Kubernetes Secret. Bulk Jira
search and result aggregation are not yet a product API, so this run uses local
operator scripts and keeps raw Jira data outside the repository.

## Risks

- "Pure consulting" is not an explicit Jira field, so filtering must be
  conservative and auditable.
- Some config/how-to tickets include troubleshooting details and may be
  borderline.
- Batch dry-run can be slow or expensive because each ticket starts a Codex
  replay.
- Live web search and network access are enabled for the runner, so the output
  may include public docs discovered at run time.

## Target Contract

- Query 2026-06-01 through 2026-07-01 Jira issues in projects ST, TCID, APID,
  NAID, and EMID.
- Keep a candidate list with explicit include/exclude reasons.
- Dry-run only tickets classified as consulting/answer-style support questions.
- Produce a table with ticket id, Jira link, customer question summary, and
  simulated L1 answer.
- Record skipped and failed tickets separately.

## Implementation Steps

1. Fetch June Jira issues and selected fields/comments through Jira REST.
2. Classify candidates with conservative heuristics.
3. Start local `auto-oncall-services` and run selected tickets sequentially.
4. Save JSONL/raw results plus Markdown/CSV summary tables under `/tmp`.
5. Spot-check output quality and report failures or uncertain classifications.

## Verification Checklist

- Jira fetch returns all paginated results for the date range.
- Candidate classifier writes reasons for include/skip.
- Each dry-run response has HTTP 200 or a recorded failure reason.
- Final table contains ticket id, link, user question summary, and simulated
  answer.