A-H-911 Boundary semantics before comparison changes
The operator in a boundary comparison is a semantic decision, not a typo. Fixing it without deciding the semantics can silently flip the boundary the other way.
Before changing any predicate on a date/number boundary:
- Pin down what the spec says the boundary case means (e.g. is a task due TODAY overdue?). If the spec is silent, get the decision recorded — do not pick the operator that makes the visible case pass.
- State the intended inclusive/exclusive semantics explicitly in the requirement or in the test name.
- Add the exact-boundary test case first, and watch it fail against the current comparison.
- Only then fix the comparison to match the decided semantics, and let the boundary test prove it.
Followed, boundary fixes land once, with a test that fails if the semantics regress. Skipped, the comparison gets flipped to whatever makes today's symptom disappear, re-breaking the opposite boundary later.
Distilled from LL-001 in package package.