# Evidence Mismatch Clarification

## Current Design

- `src/skills/support-reply-format.ts` is the canonical customer-draft style
  contract shared by dry-run and live analysis.
- The analysis prompt requires focused clarification for ambiguous tickets, but
  it does not define how to reply when diagnostics are healthy in the assumed
  window while the customer reports a real incident.
- In APID-29178 the automatic analysis assumed the reported 02:50-03:30 window
  was UTC+8. The later human reply first checked whether the customer meant a
  different timezone-converted window, then reported that the inspected window
  did not show the claimed server-side symptom.

## Risks

- Saying "no problem" from one healthy metric/window can incorrectly reject a
  valid customer observation.
- Listing every possible cause is vague and shifts the investigation burden to
  the customer.
- Hard-coding one APID ticket, timezone, or offset would not generalize and
  would create a competing behavior path.
- Turning every evidence mismatch into `human_required` would unnecessarily
  disable safe L1 clarification.

## Target Contract

- Observed evidence remains factual: say that the inspected scope did not show
  a matching anomaly, not that the customer is wrong or that no issue occurred.
- Before concluding, identify the smallest plausible scope mismatch, prioritizing
  timestamp timezone/offset, exact window, cluster, component, instance, or
  client/server measurement boundary.
- Ask one focused confirmation question. Include an explicit converted absolute
  time range when timezone is the likely mismatch.
- If a plausible alternative scope exists, offer to check it after confirmation.
  Do not dump a generic troubleshooting tree or claim a new root cause.
- Keep the rule in the shared reply skill; do not change scenario classification,
  evidence providers, Jira write behavior, or production configuration.

## Implementation Steps

1. Add an Evidence Mismatch And Clarification section to the shared reply skill.
2. Add explicit good/bad shape examples covering timezone conversion and
   customer-respectful uncertainty.
3. Add prompt contract assertions so the behavior cannot silently regress.
4. Run typecheck, focused tests, and the complete test suite.

## Verification Checklist

- [x] Contract says a healthy inspected window does not disprove the incident.
- [x] Contract prioritizes timezone/window conversion as a plausible mismatch.
- [x] Contract requires one focused question and an alternative check offer.
- [x] Contract forbids direct customer negation and generic cause dumping.
- [x] Focused and full tests pass.

## Non-Goals

- Do not overwrite APID-29178's existing Jira comment in this change.
- Do not expose later human/support replies as model input.
- Do not hard-code GMT+0, GMT+8, 03:00, 11:00, or a specific ticket key.
- Do not change classifier, gate, diagnostic, retry, or notification behavior.
