frijoles-en-el-tupperlisted

# Dice helado, pero son frijoles The next person will believe the label. ## Rule A name is a promise about its contents. Every identifier, field, file, key, and comment must let a reader predict what is inside without opening it. When the label and the contents disagree, one of them changes — you do not get to keep both and rely on the reader knowing better. ## Procedure 1. **List the labels in play.** Every name introduced, renamed, or touched in this change: functions, parameters, variables, types, struct fields, files, schema columns, API fields, config keys — plus every comment or docstring attached to code you edited. This is a bounded list from the diff, not a tour of the repository. 2. **Write what each name predicts, before reading the body.** One sentence: what it returns, what it changes, what unit it is in, what it holds. 3. **Read the actual contents** — the body, the value, the file — and compare against your sentence. 4. **Check each name against the known lies.** These are the ones that survive review because everyone in the codebase has already adapted to them. | The label | What is actually inside | The fix | | --- | --- | --- | | `get*`, `is*`, `find*`, `format*`, `parse*` | It also writes, sends, caches, mutates an argument, or throws where a miss is normal | Rename to the verb that dominates (`fetchAndCacheUser`), or move the effect out of the function | | A comment or docstring | Behavior the code stopped having; a parameter that n