"Works on my machine" is rarely stubbornness. It means the developer's machine differs from the user's in some way the report did not mention. The fix is not a better argument. It is a report that carries the difference.
Where machines differ
- The data. The user has an account, a cart or a record the developer does not.
- The response. The server returned something different for that user.
- The environment. Browser, viewport, locale, an extension.
- The sequence. The user did something before the bug that nobody wrote down.
What a report should carry
| Evidence | Which difference it covers |
|---|---|
| The element the user pointed at | Which part of the page, so nobody guesses |
| Requests with request and response bodies | The data and the server's answer for that user |
| Console errors with file and line | What threw, and where |
| Repro steps and a short replay | The sequence |
| Browser, OS, viewport and URL | The environment |
What changes for the developer
Instead of asking and waiting, the developer opens the report and sees the response that came back, the error and the steps. Often the bug is visible in the first minute, and when it is not, the report says what to try. Your coding agent can read the same report over MCP by key.
When it still will not reproduce
Some bugs depend on state that a report cannot carry. The report still helps: it narrows the search, and get_related_history shows whether something like it has been fixed before. See related reports and history.
Michaela