Agents maximise win rate, so they will find and use any server bug that helps them win. For a fixed set of spells, getting the game right is a finite problem, and the project works it systematically rather than bug by bug. Terms are in the glossary.
How a bug is judged#
A bug's severity is whether an agent could exploit or learn from it, not how visible it is to players:
| Severity | Meaning | When it must be fixed |
|---|---|---|
| High | Changes who wins, or can be exploited deliberately | Before training on the mechanic |
| Medium | Distorts some matchups or maps | Before the affected comp trains |
| Low | Small or rare in effect; the judgement is recorded with its reason | Tracked |
Checking follows what training uses. The mechanics a drill or a scripted bot relies on, and those recorded matches show agents leaning on, are checked live, the exploitable ones first; a value slightly off is recorded as a known error rather than holding training back. If agents win by leaning on a mechanic whose rule is weakly sourced, training stops until it is checked.
Where questions come from#
Every place the server may differ from the real game is a lead, kept in one catalogue with every source that raised it and how far it has got: raised, judged, sourced or tested. Leads come from open families of source, not a fixed list: emulator projects' bug trackers and fix histories, private servers' trackers and changelogs, Blizzard's patch notes and hotfixes, community arena knowledge, reading the server's own code, and the project's own tests.
A lead is not evidence of the rule. A forum post or a bug report says where to look; what the real game did is settled by the evidence ladder and a live test.
The tools#
- A spec. Game-rule claims kept as data: a cooldown, a coefficient, a range, a diminishing-returns category. Each claim has a source from the evidence ladder and a confidence, and many carry a recipe that tests them live.
- Data diffs. The server keeps its own copy of much of the game's data. A tool compares it field by field with the data files of the 3.3.5a client and of the WotLK Classic client, and lists every difference.
- Code reading. Every place the server treats one of the pool's spells specially is read and asked: what does it change, and is that the rule?
- Live tests. Headless 3.3.5a clients log in, queue, fight on random arenas and check the outcome, through the real protocol. A fixed bug keeps the test that failed before the fix.
What has been checked, with its source and status, is on checked mechanics.
Checking the checks#
- Evidence. A test that asserts a game rule cites its source.
- Shown failing. Every new check is shown failing on a broken setup, and that failing case is kept with it: a check that can't fail proves nothing. For the live tests, the full gate also re-applies every kept failing case once a run would otherwise pass, not only when the test was written, and refuses to pass if one has quietly stopped failing the way it was shown to. Outside the live tests, the unit programs, the code checkers and the shell tools each keep their failing cases as tests run among the default checks, and a separate check fails any default check that declares no failing case, or doesn't run the ones it declares. That check holds only that each declared failing case is run, not that its command runs a step of the check it is declared against: some failing cases run a narrower command by design, so a failing case can show that narrower command failing rather than the check itself, and nothing catches it when it does; the project tracks that as an open gap. Whether a declared failing case exercises the check it is attached to, rather than another guard the same command runs, is judged by hand.
- Refutation. Before a fix for a high-severity bug goes in, a second agent tries to prove the claim behind it wrong.
- Calibration. Confident claims later found wrong are counted. If they recur, the bar for a high-severity claim rises to two independent strong sources that agree.
- Invariant monitors watch rules that hold whatever the details (resources in bounds, nothing before the gates open, diminishing returns respected) over recorded matches, and a surprising win is checked for a bug before it counts as good play.
- Flaky tests are reported with both runs and measured over repeated runs, never re-run until they pass. A red or flaky check is fixed first, or removed.