A layout wrapper that owns spacing plus a child that also applies it silently doubles it
A shared screen scaffold applied padding to everything it wrapped, and individual screens applied their own container padding inside it, so each affected screen rendered with the two combined — visibly narrower content, with neither component doing anything wrong on its own.
Resurfaces when
- one screen has more padding than its siblings
- introducing a shared layout wrapper
- content is narrower on one page than others
- migrating screens into a scaffold component
- fixing the same layout bug repeatedly
- gaps between elements are twice as large as the design
- spacing looks doubled
- changing how an existing list is laid out
- adding a horizontal carousel row inside a padded screen container
- converting a single-column list into grouped rows or sections
The lesson’s retrieval contract, weighted three times heavier than its body. A lesson that states when it applies doesn’t need a semantic search to find it.
The lesson
Spacing has to be owned by exactly one layer, and a shared wrapper is the natural owner because it is the thing guaranteeing consistency. When children also apply it, the result is additive and looks like a design inconsistency rather than a bug — nobody sees double padding, they see one screen that is slightly tighter than the others. It spreads by copy-paste: the screens that have it are the ones cloned from a pre-wrapper original, which is why fixing them one at a time keeps missing instances.
The failure that taught it
A screen rendered with noticeably more side padding than its siblings. The shared scaffold already applied padding to its body, and the screen added its own on an inner scroll container. The identical fault had been found and fixed on three sibling screens the previous evening; this one was simply not among the files opened that night, so it survived a fix that was otherwise complete.
How to apply it
Decide which layer owns padding and remove it everywhere else — then grep for the container style name across sibling screens rather than fixing the reported one. When a shared wrapper is introduced, the screens migrated into it are exactly the ones still carrying their old spacing, so sweep them as part of the migration rather than waiting for reports.
Where this claim comes from
- Lessonmedium confidence
A layout wrapper that owns spacing plus a child that also applies it silently doubles it
- Distillationmechanism stated
Written from the mechanism, not the incident — which is what lets it transfer to code sharing nothing with the original.
- Scar2 occurrences
2 separate failures, recorded independently at the time. A clustering pass found they shared one cause.
- Evidence2 records
Referenced by content hash, never by path: entry slugs carry client and ticket names, so a lesson storing them could not be published at all. Resolving a hash needs a map that never leaves the machine. An agent running locally traces it with scar_evidence; nothing on this site can.
What happened when it was used
- 12
- retrieved
- 0
- acted on
- 0
- held up
- 0
- did not hold up
Retrieved but never acted on — a demotion, not a neutral result. A lesson that keeps winning the search and never changes a decision is noise.