Read the diff before you read the page

Imagine handing a new tester the keys to an online store and saying "find bugs." No ticket, no release notes, no idea what changed this morning.

They'd do something reasonable. Click around the homepage, try search, add a few things to the cart, maybe check out. They might find something. More likely they'd spend an hour confirming that the parts nobody touched still work, which the regression suite already knew.

Now imagine you hand them the same keys plus two sentences: "We changed how discounts are calculated for bundles. The ticket mentions the cart and the order summary." That tester goes straight to bundles, tries a bundle with a discount, removes one item, adds it back, applies a coupon on top. Same person, same hour, completely different value.

Exploring agents are no different, except that they're a lot more expensive per hour of wandering.

So the first thing that happens after a deploy in Testomatica, once the deterministic gate has passed, is that a planner reads. It looks at the diff between this deploy and the last one, and at the tickets linked to it. Then it writes a short plan for the explorers: which areas changed, what the change was supposed to do, and what might plausibly break nearby.

A plan for that bundle change might look like this:

focus:
  - cart with bundle items, discount applied
  - order summary totals vs cart totals
  - removing one item from a discounted bundle
nearby:
  - single-item discounts (shared pricing code)
  - coupon codes stacked with bundle discount
skip:
  - search, account pages, footer content (unchanged)

The "skip" list matters as much as the "focus" list. Agents have a budget, and every step spent re-reading an unchanged footer is a step not spent on the cart.

There are a few things the planner is not allowed to do. It doesn't decide what's a bug; that stays with code and the referee. It doesn't skip the deterministic tests; those run on every deploy no matter what the diff says. And it doesn't get to decide that a change is "too small to explore." A one-line change to a pricing helper can touch every product in the store.

Diffs are also only part of the picture. A ticket might say "fix rounding on bundle discounts" while the diff touches a file called utils.ts. The planner needs both to understand what the change meant. And sometimes neither is enough, which is why we're starting to sketch an impact map that connects files to the pages and rules they affect. That's later work.

There's a fair objection here: if exploration only looks at what changed, won't old bugs in untouched areas hide forever? Two answers. First, regression and the universal rules still cover every page they visit, every deploy. Second, the coverage map tracks when each area was last explored in depth. Areas that go a long time without a visit slowly rise in priority, so even the footer gets its turn eventually.

Mostly, though, the planner is about respect for the tester's time, even when the tester is a model. Read the diff. Read the ticket. Then go look at the page.