When behavior changes without an error message, the answer already exists: it lives in your git history, at the intersection of the diff that changed the behavior and the intent of the commit carrying it. The hard part is reaching it by asking in plain language — "why did this behavior change?" — and getting a sourced answer without opening the repository or interrupting the one person who holds the context in their head.
The question rarely shows up on its own. It arrives as a ticket, the day after a release, and nobody is sure it's a bug.
The mystery ticket: the product works, just differently
The mystery ticket: a ticket opened after a deploy that reports no outage, only new behavior. Nothing crashes, no log turns red: the product simply does something different from what it did last week.
An illustrative example: a customer writes "since yesterday, my CSV exports come sorted by date instead of alphabetically." Is it a bug? A deliberate fix? A side effect of unrelated work? The ticket can't say, and that's where everything hinges: the right reply depends entirely on the why. Apologizing for a deliberate choice costs as much as defending a regression.
The question family is always the same: what changed? when? why? does anything break? A changelog covers a fraction of it. It lists what someone chose to announce, not the side effects. The mystery ticket lives, by definition, in the part nobody announced.
Before: the investigation by interruption
Here is the path this ticket takes in most teams. The support agent can't decide, so they escalate to the PM. The PM checks the release notes: export sorting isn't there. They ask the team channel ("did anyone touch exports?"), a developer raises a hand, opens git log, finds the commit, reads the diff and remembers the context: sorting changed while fixing a pagination issue.
Count what that path consumes. Three people, two round trips, one interruption in the middle of something else — for information that has existed, in writing, since the moment of the push. Every step in the chain works from memory and goodwill; none of it is on the record for the next, identical ticket. And the path doesn't hold in any direction: not when tickets pile up after a big release, not when the person who "knows" is on vacation, and not when the asker is an AI support agent replying to the customer in real time, with nobody it can interrupt.
After: the same question, asked of the product itself
The same ticket, with a product expert plugged into the repository, takes one step: ask the question as written. "Why are CSV exports sorted by date since Tuesday?" The answer comes back sourced: the commit that introduced the change, the diff where the sort clause was modified, and the intent readable from the change's context — a pagination fix, not a product decision about sorting.
That is what DeployIt does: it reads your real code (resynced on every push), your git history (commits and diffs) and your customer data through its own MCP servers, and checks the code before asserting anything. The support agent gets the why without repository credentials; the PM replies to the customer citing the change instead of guessing at it. "What changed in the product this week?" runs on the same mechanism — the mystery ticket is its emergency case.
Ready to see what your team shipped?
What metadata tools can't see
Most tools that promise to "track changes" read metadata: PR titles, commit messages, changelog entries. A behavior change doesn't live in any of those layers. It lives in the diff.
The export sorting from our example shows the gap. The commit was called "fix pagination edge case": a tool reading commit messages will answer "nothing about exports this week." The right answer required reading the modification itself, the sort clause changed in the same file. Metadata records what the author thought they did; the diff records what the codebase does now.
This is also what separates the approach from documentation MCP servers: Context7 and DeepWiki cover libraries and public repositories, Mintlify generates an MCP server from written docs. Documentation, however good, has the same blind spot as a changelog: it contains what someone put into it.
"A well-equipped dev does this with git blame"
True, and worth saying plainly: a developer with repository access, git blame, git bisect and the official GitHub MCP server can walk from symptom to commit without us. With disciplined commit messages, the intent reads at a glance. For that profile, DIY works.
The limit is double. First, DeployIt's answers come from diffs: they hold even when the commit is named "wip" or "fix", which is the actual state of most histories. Second, the person holding the mystery ticket is almost never that well-equipped developer: it's a support agent, a PM, a support bot giving outdated answers after every release — askers without repository credentials, for whom "run a git bisect" is not an answer.
"So DeployIt reads my whole repository"
It does — through a read-only GitHub connection, one server per project, revocable at any time. Answers are sourced from commits and diffs, never raw source dumps: when the expert says "sorting changed in this commit, here is its intent," it cites the change, it doesn't paste the file. Cutting access takes one action, and affects only that project.
Frequently asked questions
What if the change came from a dependency, not our code? The lockfile lives in the repository, and a lockfile change is a diff like any other. The version bump that changed the behavior is dated and attributable like the rest — which matters, because "we didn't touch anything" is the most common opening line of a mystery ticket investigation.
How fast is the answer? As fast as asking an agent a question. The expert is resynced on every push: the context is already there when the ticket lands.
Does this replace the changelog? More like the reverse: it answers the questions the changelog didn't anticipate. The changelog announces what you chose to say; the history can answer the rest.
Symptom, diff, intent
A mystery ticket is a causality question: walk back from a visible symptom to the diff that explains it, then to that diff's intent. That chain already exists in every repository. What's missing is plain-language access for the people who will never open git log.
The DeployIt MCP server is in early access / design partner program, free during early access. If your mystery tickets keep ending as developer interruptions, yours is the case we want to design with you: join the design partner program.
Continue reading
How to Let AI Work on Client Code Without Breaching the NDA
Contractors, AI agents, and support teams need answers about a client's product under NDA, not its code. How to split the two flows.
AI Release Notes Generator: What These Tools Actually Read
What release notes generators actually read — git-cliff, release-please, AI layers — and the approach that derives notes from real diffs.
Connect Claude to Your GitHub Repo — and What It Can't See
A step-by-step guide to Claude's GitHub connector, its documented limit — no commit history — and how to still answer "what changed this week?".