You own frontend standards for an app whose global stylesheet grows every sprint and never shrinks. Which structural conventions and enforcement mechanisms actually stop that decay, and what does each one cost?

## Why stylesheets only ever grow Two properties of CSS combine badly. First, **adding is cheaper than understanding**. Given a page that looks wrong and a stylesheet you did not write, appending a new rule takes minutes and modifying an existing one requires knowing everything else it affects. Under deadline, everyone appends. This is rational behaviour at the individual level producing a bad outcome at the system level, which means exhortation will not fix it. Second, **nothing ever fails**. A rule that no longer matches anything produces no error, no warning, no test failure. The feedback loop that keeps dead code out of every other part of the codebase simply does not exist here. Any real intervention has to change one of those two facts. Conventions in a wiki change neither. ## Colocation: make deletion automatic The highest-leverage change is that a component's CSS lives with the component, in a file whose lifetime is the component's lifetime. Removing the feature removes its styles as a mechanical consequence — no audit, no proof, no courage required. This is the only mechanism that reliably makes a stylesheet *shrink*, because it removes the need for anyone to decide. *Cost*: the design becomes harder to see whole. Nobody can read one file and know what the app looks like, and without a strong token vocabulary the same shadow gets reinvented in four component files. Colocation only works when it is paired with shared tokens. ## The entry file as the contract One entry file containing nothing but ordered imports — reset, tokens, base, layout, components, utilities — turns the project's cascade order into a single reviewable artifact. A newcomer reads twenty lines and knows what may override what; a pull request that reorders two of them is visibly a change to override semantics rather than a formatting tweak. *Cost*: it is a chokepoint. Every feature branch touches it, so it collects merge conflicts, and the discipline of keeping actual rules out of it has to be enforced or the file quietly becomes another dumping ground. ## A closed global set with a named owner Reset, tokens and base should be a set that changes when the design system changes, not when a feature ships. Naming an owner for those files — a required reviewer — makes an addition a decision rather than a diff. The measurable goal is that the global layer's size stays roughly flat while component count grows. *Cost*: friction, and friction gets routed around. The predictable failure is people adding to a `utilities` file instead, because it is the unguarded door. Whatever you gate, watch what grows next to it. ## One source for raw values Colour and spacing literals belong in the token file; everywhere else consumes them through `var()`. This is what makes a theme change a one-file edit instead of a search-and-replace, and what stops eleven nearly-identical greys from accumulating. Crucially it is machine-checkable — a linter such as stylelint can forbid hex colours outside the token file (`color-no-hex`), which moves the rule out of reviewers' memory. *Cost*: token sprawl. If every design request mints a new token, you have moved the growth problem rather than solved it. Someone has to own saying no to `--color-blue-7`. ## Enforcement or it decays The general principle: **a convention that is not machine-checked is a convention that decays**, because review attention is finite and reviewers rotate. Anything you actually care about should fail in CI — lint rules for the value discipline, a check that the entry file contains no style rules, a required reviewer on the global folder. *Cost*: false positives on legacy code. Introducing a rule to a large existing sheet needs a baseline or a per-directory scope so the gate applies to new code without demanding a big-bang cleanup nobody has time for. ## Budgets as a signal, not a verdict A CI check on total CSS bytes turns growth into a visible number that moves. It is far more honest than periodic audits, because it reports the trend continuously. *Cost*: byte count is a proxy. It can be gamed, and it says nothing about whether the CSS is comprehensible. Use it as a conversation trigger — a sudden jump asks "what happened here?" — not as a pass/fail verdict that people learn to route around. ## What ties it together Every item above works by changing the economics rather than the intentions: deletion becomes free, the correct destination for a new rule becomes obvious, and the wrong choice fails in CI instead of surviving review. Announce a convention and it survives about a quarter. Encode it in the file structure and the pipeline, and it survives the people who wrote it.