latent-premiseslisted

# latent-premises An unguarded premise is an undeclared allergen. The dish is fine for most diners, every night, until the wrong one orders it, and nothing on the menu warned anybody. Code carries the same hazard: a premise that holds on every input the system produces today, enforced by nothing, documented nowhere, that fails silently the day the premise breaks. **Core principle:** a premise is only a finding when it is genuinely unenforced AND you can name what concretely breaks when it fails. Enforced premises are fine. Consequences you cannot name are hypotheses, not findings. **Read-only.** This is a review lens. Fixing is a separate engagement. ## The taxonomy Hunt in five categories. Each finding gets exactly one. | Category | The code assumes | Examples | |----------|------------------|----------| | input | boundary or external data is well-formed, with nothing upstream guaranteeing it | a non-empty array (`[0]`), an existing key, a successful parse, a non-null string, an in-range number | | contract | callee behavior the signature or types do not promise | a result is sorted, a call is idempotent, a value the type says is nullable is never null, a specific error type | | environment | the world outside the process is arranged | an env var is set, a path exists, a service is reachable, a timezone or locale, an OS behavior | | ordering | events happen in one sequence | init-before-use, single-threaded access to shared state, no interleaving between read and write