Backlog agent
Ticket in. Pull request out.
Point an agent at a ticket and it clones the repository, reproduces the problem with a failing test, writes the change, runs the suite, and opens the pull request.
The bug
It is in the seam, which is why the tests were green
The planted defect is not a broken function. It is a half-finished migration.
The promotions store holds the real list of codes, and the module that queries it works correctly. But checkout resolves shopper-typed codes against its own local record that was never populated, so every code, including valid active ones, comes back unknown.
Both halves test fine in isolation. The suite passes with the bug in place. That is exactly the kind of defect a run has to find for itself, and exactly why reproducing it before fixing it is the rule.
The run
What it produces
Seven steps, every one of them checkable afterwards.
- 01Reads the ticket the customer wrote, and clones the repository.
- 02Reproduces the bug with a test that fails for exactly the reason the ticket describes.
- 03Fixes the cause with the smallest change that does it.
- 04Runs the full suite. The new test passes, and all 19 that existed before still pass.
- 05Pushes a branch. Commits to main and other protected branches are refused, not merely discouraged.
- 06Opens a pull request with problem, cause, fix and verification.
- 07Comments the pull request URL back on the ticket, closing the loop to the shopper who filed it.
Safety
Guardrails, not good intentions
An agent with commit access is only as safe as what it cannot reach.
It never sees a credential
Git authenticates through a helper that reads the token from its own environment. The token appears in no tool argument, no tool result, no process arguments, and never lands in git config where the agent could read it back.
The tool surface is narrowed
The backlog and code-host integrations ship 52 and 44 tools between them. The agent gets four and three. Handing it a write-file-through-the-API tool invites it to skip the clone and commit blind, which is a different and much less trustworthy run.
Existing tests are untouchable
Never weaken, delete or rewrite an existing test to get a green run. If a pre-existing test fails after the change, the change is wrong and the change gets fixed, not the test.
Recovery
When the connection drops, it asks what actually landed
This is the durability argument in miniature.
If a run goes quiet, the recovery is not to ask the model what it thinks it did. It is to ask the code host what is actually open on the repository and report from the answer. What you read is the state of the world, not a model-authored account of it.
The storefront and its backlog are a demo environment. The repository, the failing test, the branch and the pull request are real.