The wrench dialog said the competition and find-a-team filters should be showing on the rebuilt tournament module. On the live test site, they weren’t. Nothing in the rendering code was broken. Three layers just disagreed about one default value.
We were reworking the tournament bracket module after feedback: restore those missing filters, make every view tab and search tool available by default, add a Location Search option, fix a wrench checkbox that would not save when unchecked, remove the Display Type toggle, and rename the module to Tournament Brackets. This was the exact regression the rebuild was supposed to close, and it was still open on the site we were about to hand back for review.
The filters were the obvious place to start. Find the code that renders them, find out why they had stopped.
The filters weren’t the bug
The rendering code for both filters was fine. The regression was one level up, in what each part of the system believed the default should be. A shared options library set one default. The wrench dialog’s apply logic wrote a different one when it saved a change. The display template that showed the current setting back to the admin assumed a third. Three places, three answers, and none of them was wrong on its own. Change any one of the three in isolation and the filters would look fixed on whichever screen you were staring at, while staying broken everywhere the other two mattered.
The fix that would have looked right
The fast fix was sitting right there: hardcode the filters back on in the renderer and close the ticket. It would have worked, on that one screen. It also would have left the actual disagreement in place, a landmine for whoever next touched the wrench dialog or the options schema with no reason to expect three sources of truth for one setting.
The real fix aligned the default across the options library, the wrench’s apply logic, and the display template, then checked the admin screen, the wrench dialog, and the live module all agreed at once. The Location Search addition, the checkbox save bug, the Display Type removal, and the module rename went into the same pass. All of it got verified end to end on the test tournament site before the branch was committed.
Checking one screen isn’t checking the setting
Reading the renderer, or testing one dropdown, would have confirmed the fix looked right without ever surfacing that two other layers still disagreed. The only way to know the setting was actually fixed was to trace it through every place that defined or read it and confirm they told the same story.
The filters were never broken. The system just couldn’t agree with itself about what “on” meant, and nothing forced it to check until someone went looking in all three places at once.
AI Skills
Use this lesson with the AI assistant you already use
Missing tournament filters looked like one broken piece of rendering code. The real fault was a single default value with three separate owners, an options library, a dialog's apply logic, and its display template, each holding its own answer for the same setting.
Paste the prompt, share only the context needed to answer it, and treat the result as a draft for your review. Do not include confidential information or let an AI assistant make changes without your approval.
Optional: for a visual report and saved memory, run /dxdev first.
Don’t have it? Get it at dxdev.com/skills/dxdev. The prompt works without it.
dxdev LESSON · paste into your AI coding agent
LESSON: A setting that lives in more than one layer can be "fixed" in one place and still wrong everywhere else
SOURCE: dxdev.com/blog/2026-06-30_the-missing-filters-were-a-drifted-default
WHAT HAPPENED: Two filters that should have been showing on a rebuilt module were not showing on the live test site. The rendering code for both filters was fine, which made it tempting to patch the renderer directly and call the regression closed. The actual cause sat one level up: a shared default value had three separate owners in the codebase, a shared options library that set one default, a dialog's apply logic that wrote a different one when it saved, and the display template that assumed a third, and none of the three was individually wrong. Patching only the renderer would have made the one screen being tested look correct while leaving the other two owners still disagreeing, a regression waiting for the next person who touched either of them. The real fix aligned the default across all three owners, then verified the setting agreed everywhere it was read, not just on the page that was open.
THE RULE: When a bug is a single symptom of a setting that is defined or read in more than one place, a fix that only touches the place you found first can look correct while leaving the actual disagreement in place. Before closing a "missing" or "wrong default" bug, find every layer that owns or reads that value and confirm they agree, not just the one you're staring at.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
1. Any fix for a "missing" or "default is wrong" bug that changes only the layer where the symptom appeared (the renderer, the UI), without checking whether the same setting has another source of truth (a config default, an apply/save path, a schema) that could still disagree.
2. Any shared default or setting that is defined, read, or written in more than one file/module without a single canonical source the others defer to.
3. Any regression fix verified only on the one screen where the bug was noticed, without confirming the same setting reads correctly everywhere else it's used.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.