PSA/docs/plans/2026-06-10-ticket-close-rules/SMOKE_TESTS.md

Manual Smoke Pass — Ticket Close Rules

Run this after implementation, before merge. It replaces the Playwright/UI entries trimmed from tests.json (board settings dialog, templates settings, checklist section, blocked-close dialog, override flow, bulk summary, auto-close banner, timeline rendering, job wiring, i18n) — automated coverage owns the logic; this pass owns the screens and the end-to-end business outcomes.

Steps below are derived from the plan and the existing screens it extends, not from a running build of the feature. Exact button/label copy may drift during implementation — treat the live screens as ground truth and update this file when they disagree.

Preflight

• Dev stack up for this worktree (alga-env-manager), logged in as an Admin and a second technician user without ticket:close_override.
• A test board with open statuses and a closed status; a client with a contact that has portal access; a way to see outbound email (e.g. the dev mail catcher).
• For the auto-close flows: a rule with small inactivity_days, and either wait out a 15-minute scan cycle or trigger the auto-close-tickets job manually; backdate the ticket's last comment in the DB to make it stale.

Risks this smoke is defending

1. Stranded revenue — tickets close with no time logged.
2. Accountability theater — checklist signoff doesn't durably record who/when.
3. Rules theater — bulk close or an unauthorized override smuggles tickets past enabled gates, or an override leaves no audit trail.
4. Auto-close kills a live conversation — the customer replies and the ticket closes anyway.
5. Silent auto-close divergence — auto-closed tickets skip the side effects manual closes get (customer email, automatic comment, audit attribution), or the engine never fires and stale tickets pile up unnoticed.
6. Audit-history mutation — editing a template rewrites checklists already signed off on tickets.
7. Cross-board bleed — one board's gates or auto-applied templates leak onto another board's tickets.

Flows

Flow 1 — stranded revenue: the time-entry gate blocks, then yields (risks 1, 3)

1. Settings → Ticketing → Boards → edit the test board → Close Rules section: enable the time-entry and resolution-comment gates. Save, reopen the dialog, confirm the toggles persisted.
2. Open a ticket on that board with no time logged → set status to the closed status.
3. Expect: closure is refused; the blocked-close dialog lists both unmet conditions (not just the first).
4. Use the dialog's quick actions: add a time entry and a resolution comment.
5. Close again. Expect: ticket closes; the client contact receives the normal ticket-closed email.

Flow 2 — accountability is durable and visible (risk 2)

1. On a ticket, add two checklist items (one required, one optional) as the technician user; check the required item.
2. Expect: the item immediately shows the technician's name and timestamp inline, and the progress chip near the status control reads "1 of 1 required done".
3. As the Admin, uncheck the item. Expect: the inline signoff clears, and the activity timeline shows both the original check (by the technician) and the uncheck (by the Admin) with the prior signoff preserved in the entry.

Flow 3 — overrides are permissioned and leave a trail (risk 3)

1. As the technician (no ticket:close_override), attempt to close a gated ticket with unmet conditions. Expect: the dialog shows the failures and offers no "Close anyway" control.
2. As the Admin, repeat. Expect: "Close anyway" appears; provide a reason and confirm.
3. Expect: the ticket closes and the activity timeline shows an override entry listing the skipped conditions and the reason.

Flow 4 — bulk close can't smuggle tickets past gates (risk 3)

1. From the ticket list, select one ticket that satisfies the gates and one that doesn't; bulk-set both to the closed status.
2. Expect: a summary like "1 closed, 1 blocked by close rules" with the blocked ticket's reasons; the blocked ticket is still open afterward.

Flow 5 — auto-close never kills a live conversation (risk 4)

1. Configure an auto-close rule (trigger status, short inactivity, 1-day warning) on the board; put a stale ticket in the trigger status and let the scan run.
2. Expect: the ticket shows the banner "Will close automatically on unless there's new activity", and the contact receives the warning email once (not again on the next scan).
3. Reply as the customer from the client portal.
4. Expect: after the next scan, the banner is gone and the ticket does not close at the originally scheduled time.

Flow 6 — an auto-close is a real close (risk 5)

1. Let a stale ticket pass its scheduled close time and let the scan run.
2. Expect: the ticket is in the rule's target closed status with an automatic comment ("Closed automatically after N days of inactivity"); the contact receives the standard ticket-closed email; the activity timeline attributes the closure to the system (no human user); if the board had gates enabled, a bypass entry (source: auto-close) appears rather than a gate failure.

Flow 7 — template edits don't rewrite signed history (risks 6, 2)

1. Settings → Ticketing → Checklist Templates: create a template with two ordered required items; apply it to a ticket; check both items.
2. Back in settings, rename one template item, delete the other, and add a third.
3. Expect: the ticket's checklist is byte-for-byte unchanged — original names, order, and signoffs intact. Re-applying the same template to the same ticket adds nothing (idempotent).

Flow 8 — rules and templates stay on their board (risk 7)

1. With gates, an auto-close rule, and a board-scoped auto-apply rule all configured on Board A only: create a ticket on Board B in the same category.
2. Expect: the Board B ticket gets no auto-applied checklist, closes freely with no gate dialog, and never grows an auto-close banner.
3. Move the Board B ticket to Board A. Expect: the matching template attaches now (once), and closure is now gated.

Pass criteria

• No ticket can be closed by hand past an enabled time-entry/comment gate without satisfying it or leaving an audited override (risks 1, 3 — Flows 1, 3, 4).
• Every checklist signoff and its removal is attributable on the ticket forever (risk 2 — Flows 2, 7).
• A replying customer is never auto-closed on, and a fired auto-close is indistinguishable from a careful manual close in side effects and audit (risks 4, 5 — Flows 5, 6).
• Template maintenance can't alter past signoffs (risk 6 — Flow 7).
• Nothing configured on one board observably touches another board's tickets (risk 7 — Flow 8).
• Incidental: no raw translation keys or layout breakage on any new screen visited during the pass (board dialog, templates settings, checklist section, blocked-close dialog, banner).