support_backend/specs/009-problem-resolution/quickstart.md

Quickstart: Validating Problem Resolution

Prerequisites: migrations applied; a ticket created per 003-ticketing's own quickstart (this feature works against its problemId).

Scenario 1 — structured investigation, preserved across attempts (User Story 1)

1. POST /admin/problems/:problemId/investigations with findings/evidence/internalNotes. Expected: 201, retrievable via GET /admin/problems/:problemId/investigations with every field intact.
2. GET /problems/:problemId/investigations (customer-safe variant). Expected: same rows, internalNotes absent from every one.
3. Record a second investigation for the same problem. Expected: both rows remain, in order — the first is never overwritten.

Scenario 2 — root cause requires an investigation on file (User Story 2)

1. POST /admin/problems/:problemId/root-causes for a problem with no investigation. Expected: 409.
2. Repeat after Scenario 1's investigation exists. Expected: 201, type one of the five validated values.
3. Repeat with an invalid type. Expected: 400.

Scenario 3 — solution proposed, approved, implemented as distinct states (User Story 3)

1. POST /admin/problems/:problemId/solutions before any root cause exists. Expected: 409.
2. Repeat after Scenario 2's root cause exists. Expected: 201, approved: false.
3. POST /admin/solutions/:solutionId/implementation before approval. Expected: 409.
4. PATCH /admin/solutions/:solutionId/approve, then repeat step 3. Expected: 201.
5. Repeat step 3 again (a second implementation). Expected: 409.

Scenario 4 — verification, and what happens on failure (User Story 4)

1. POST /admin/solutions/:solutionId/verification with result: success. Expected: 201.
2. On a different solution (Scenario 3 repeated for a fresh problem), verify with result: failed. Expected: 201, but no Resolution can be recorded referencing it (Scenario 5, step 1).
3. On the failed-verification path, request a fresh investigation. Expected: a new Investigation row for the same problem, the original untouched.
4. On the failed-verification path, request escalation instead. Expected: the ticket transitions to HUMAN_ESCALATION, and (007) is automatically assigned from that transition alone — no separate escalation call needed.

Scenario 5 — resolution, customer confirmation, and auto-close (User Story 5)

1. POST /admin/tickets/:ticketId/resolution for a ticket whose problem has no successfully verified solution. Expected: 409.
2. Repeat once Scenario 4 step 1's successful verification exists. Expected: 201, ticket status becomes RESOLUTION_PENDING_CUSTOMER.
3. POST /v1/support/tickets/:ticketId/confirm-resolution with the customer's own token. Expected: 200, ticket status becomes RESOLVED.
4. Repeat steps 1-2 for a second ticket; instead of confirming, directly age the ticket's updatedAt past the configured waiting period and run the auto-close sweep. Expected: ticket status becomes RESOLVED without any explicit confirmation call.

Scenario 6 — reopen (User Story 6)

1. POST /v1/support/tickets/:ticketId/reopen on the RESOLVED ticket from Scenario 5. Expected: 200, ticket status becomes IN_PROGRESS (via REOPENED).
2. GET /tickets/:ticketId/resolution (or the admin equivalent). Expected: the original Resolution record is still present, unchanged.
3. If the ticket has an SLARun (008) from its original assignment, Expected: it is unchanged — no new run created, its status exactly what it was before the reopen.
4. POST /admin/tickets/:ticketId/reopen on a CLOSED ticket, as an agent. Expected: same REOPENED → IN_PROGRESS result, this time attributed to the agent, not "customer".

What "done" looks like

All six scenarios pass, together demonstrating every functional requirement and success criterion in spec.md — including SC-004's auto-close job cycle and SC-005's "reopen touches nothing else" guarantee, both of which need direct-DB-state manipulation (not just waiting) to verify without a multi-hour real-time test run.