step-backlisted

# Step Back ## Overview Do not float a recommendation until the mechanism it depends on has been checked. Take the extra minute: read the code path, find where the value is actually consumed, run the probe, and *then* speak. This applies to plain advice, and especially to code and configuration changes. An unverified idea labelled as unverified is fine ("worth checking, I haven't confirmed X"). An unverified idea presented as a recommendation is not. Every retraction burns the user's time, erodes trust in every *other* claim made, and for config changes risks degrading a live, working system. Sanity check before sending any suggestion: **what would have to be true for this to be wrong, have I actually looked, and would a single cheap query settle it?** ## The traps Each of these produced a real, confident proposal that had to be retracted a turn later. | Trap | Discipline | |---|---| | **Coupled or derived values.** A "safe" threshold increase fed a second setting derived from it (budget = threshold × ratio); the change would have cut retained data 4x and fought an adjustment made an hour earlier. | Before recommending a setting, check what else consumes or derives from it. | | **Restart/reload semantics.** A config section was claimed to hot-reload; the values are read once at process init, so running instances silently keep old values. | Never state that a change takes effect without finding where the value is read. | | **"One-line fix" claims.** A bug called a one-l