Trace displayed/stored data to its producer before fixing (no downstream masking) - #2198
Open
Userdebug wants to merge 1 commit into
Open
Trace displayed/stored data to its producer before fixing (no downstream masking)#2198Userdebug wants to merge 1 commit into
Userdebug wants to merge 1 commit into
Conversation
A wrong displayed or stored value (bad label, stale format) must be traced to its producer before any fix is proposed. Display bugs are data bugs until proven otherwise. systematic-debugging gains an explicit Phase 1 step (6. Trace Displayed/Stored Data To Its Producer) that requires locating the writer (SQL/service/seed) first and forbids compensating downstream with a UI formatter/parser that masks badly stored data. It documents the three-part real fix: canonical generator at the source, idempotent migration of existing rows, seeds aligned with production. Phase 4 now states that the root cause is the PRODUCER of the bad data and that fixes include migration when existing rows are wrong. Matching entries are added to Red Flags and Common Rationalizations. brainstorming's Bounded step 1 gets the same provenance check at design time, so a downstream-masking design never gets approved in the first place.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
While debugging a real application, a wrong stored value ("Mensualité 11" — a month number baked into a DB label by an old seed script) was surfaced in the UI. The agent's first "fix" was a display formatter that rewrote the label at render time. That masked the bug instead of fixing it: every other consumer of the stored value kept showing bad data.
The root-cause discipline already exists in
systematic-debugging(Phase 1 / Phase 4), but it didn't trigger because the symptom looked like a display concern. Nothing forces tracing a wrong value to its producer before designing or shipping a downstream transformation.Changes
skills/systematic-debugging/SKILL.mdskills/brainstorming/SKILL.mdTesting
Applied and exercised end-to-end in a production PyQt app: labels regenerated via a single canonical generator (
libelle_mensualite(mois)), ~60 legacy rows migrated by an idempotent startup migration, seeds aligned, band-aid formatter deleted. Test suite went from 20 failed / 112 passed → 12 failed / 140 passed on a fresh database (8 pre-existing failures fixed as a side effect of cleaning the data contract). The patched skills are also mirrored locally with a re-injection script to survive package updates.