Support-ticket triage service

The problem

Support tickets landed in whatever project the reporter happened to be in, and telling an internal request from a customer one meant opening each ticket and recognising the name. The built-in automation handled the routing and could not do the classification.

What I built

• Two entry points, one pipeline: a webhook receiver for new and edited tickets, and a command-line backfill for the thousands already sitting there. Both call the same function, so they cannot drift apart.
• The internal-versus-customer call needs account type and group membership, which the platform's own automation does not expose. That is why this runs as a service rather than a no-code rule.
• Dry run is the default, and nothing gets written until you apply it. An explain flag prints the rule-by-rule trace for every ticket, so a wrong decision is something you read rather than guess at.
• The summary counts query results and prefix matches separately, because the query language cannot match a bracketed prefix and those two numbers never agree. Reporting one as the other would hide how much work the client-side filter was doing.
• Processed tickets carry a marker label so a re-run skips them, with a force flag for when reprocessing is the point.
• Concurrency-limited workers, a query override, and a smoke test that runs before any of it points at real tickets.