Customer Claims a Bug. It Was Fixed Three Sprints Ago. Support Has No Way to Check.

The customer says the export is broken — same issue they reported two months ago. Support logs a bug. Engineering triages it. Someone checks git log and finds the fix was merged six weeks ago and shipped in the release after the original report. The customer is on the current version. Something else is happening. The forty minutes of engineering time spent on triage were entirely avoidable if anyone could have checked whether the fix was in production before escalating.

This is a structural gap in most support workflows: the ability to verify "is this already fixed?" before routing a bug claim. Historical ticket searches are unreliable — the original bug may have been filed under a different description. The Jira backlog may not be connected to support. And even if the Jira ticket is closed, that doesn't tell you whether the fix shipped in the customer's version. The authoritative answer is in the codebase, and support doesn't have access to it.

Three scenarios that look identical at intake

A customer reporting a bug could be in one of three situations: the bug was fixed and is in production, the bug was fixed but regressed, or the bug was never fixed. Each of these requires a different response. The first might be a configuration issue. The second is a new P1 regression. The third is a known issue with an existing ticket. Without codebase access, all three look the same when they arrive — "export is broken."

The pattern of "developer pushes back saying 'I can't reproduce this, can you verify it with the latest version?'" without actually checking — documented as a common issue in Apple's bug tracker community — is the same failure mode. The question of whether the bug exists in the current code is answerable by reading the code. When nobody does that at intake, the investigation starts from scratch every time.

Three scenarios for "export is broken" — same ticket, different reality:

Scenario A: bug was fixed 3 sprints ago
  -> Fix is in production, customer is on current version
  -> Root cause: something else (config, permissions, session)
  -> Correct response: diagnostic questions, not a bug report

Scenario B: bug was fixed 3 sprints ago but regressed last sprint
  -> Fix existed, new code broke it again
  -> Correct response: P1, route to the team that owns export-service
  -> Agent finds: last commit to export-service introduced regression

Scenario C: bug was never fixed
  -> Still open in the backlog, no fix shipped
  -> Correct response: acknowledge known issue, provide ETA if available
  -> Agent finds: Jira PROJ-2341 is open, tagged as roadmap Q3

Without codebase access, all three look identical at intake.

What support needs before logging a bug

Before logging a new bug claim, support should be able to answer: is this a known issue, has it been fixed, and is the fix shipped? These are not engineering questions. They're codebase lookup questions. The answers determine whether to create a new ticket, link to an existing one, or frame diagnostic questions to identify why the fix didn't work for this customer.

Even QA leads need codebase context before filing a bug — the same principle applies to support. Filing a bug without verifying current code state creates noise in the engineering queue and burns triage time on issues that may not be issues anymore.

Questions support can't answer without codebase access:
  "Was this bug reported before?" → search historical tickets (unreliable)
  "Was it fixed?" → ask engineering (1–2 day delay)
  "Is the fix in the current release?" → ask engineering (1–2 day delay)
  "Did it regress?" → ask engineering (1–2 day delay)
  "Is it a known issue?" → check internal tracker (if it exists and is current)

  Every one of these questions has a definitive answer in the codebase.
  None of them require engineering judgment to look up.

The webhook agent that checks fix status at intake

Kognita's webhook fires on ticket creation. The managed agent parses the reported behavior, searches the codebase's commit history and Jira integration for related fixes, and determines whether the described issue matches a previously fixed bug, an open known issue, or a potential regression. This context is attached to the ticket before support routes it anywhere.

What a Kognita webhook agent does on a bug claim:
  Ticket: "Bulk CSV export is broken — same issue we reported last month"
  Agent queries codebase:
    -> Searches commit history for export bug fixes
    -> Finds: fix merged 6 weeks ago in PR #1847 for PROJ-1923
    -> Checks: current export-service — fix is present in main branch
    -> Checks: was export-service deployed since fix? Yes, v2.11 shipped 5 weeks ago
  Agent checks Jira: PROJ-1923 closed, PROJ-2341 open (different issue)
  Response attached to ticket: "PROJ-1923 was fixed in v2.11. If you are
  on v2.11+, this may be a different issue or a regression. Can you confirm
  your account version? If the fix regressed, routing to export-service owner @data-team."

  Result: diagnostic framed correctly at intake, no blind escalation.

When the agent finds that a relevant fix is in production, the support engineer can frame their customer response as a diagnostic conversation rather than a bug acknowledgment. If the agent finds signs of a regression — the fix existed but the service was deployed with changes since — it routes the ticket directly to the owning team as a potential regression rather than a new bug report.

The engineering queue that's already fixed

In most teams, a meaningful fraction of the bugs that reach engineering triage are duplicates or already-fixed issues. Engineers who have access to git history can identify this in minutes — but they shouldn't need to. That work should happen at intake, before the ticket reaches the engineering queue. When it does, the queue contains genuine new issues instead of noise, and the engineers who work on it spend their time on problems that actually need them.

Final take

"Is this bug already fixed?" is a question with a definitive answer in the codebase. It should be answered before the ticket reaches engineering. A webhook-triggered agent that checks fix status, regression indicators, and open known issues at ticket creation turns a multi-day escalation into a seconds-long lookup — and sends engineering only the bugs that actually need them.

Every bug claim that gets routed to engineering should be verified against current code first. A webhook agent does that automatically. The ones already fixed never reach the engineering queue.