Gunjit Chopra

That's the ownership gap I was glossing over. A date boundary can be internally consistent and still use the wrong business timezone, and the person editing the test isn't always the one allowed to change that call. I'll start keeping the rule version or ticket decision next to the expected dates so a later change doesn't require reverse-engineering the old implementation. Then the adjacent case is protecting a documented agreement, and a real spec update has an explicit place to say why the expectation moved.

Lockfile + CI + auth as a forced human-read set is exactly right. Green CI on a new dependency tree is the trap. I don't keep a formal counter yet. Informally the ones that fire most for me are mixed concerns in one "quick fix," and the public surface moving while the PR claims no behavior change. Lockfile bumps usually show up inside those, not as a clean standalone stop. Secrets are rare, but non-negotiable when they appear. Curious what your ranking looks like on the auth side.

Agree on pinning the expected result to the same written rule. Before/after midnight in the stated timezone plus a nearby unchanged instant makes the adjacent case actually check something, not just pad coverage. The three-object check (rule, expected dates, implementation) is the bit I'll keep. If the rule moved, that should show up as an intentional review note, not as a quiet side effect of a greener test suite.

That's a sharper frame than mine - treating the changed expectation as a claim about the specification that needs an independent oracle (fixed instant, explicit business timezone, expected calendar date), not just "matches the new code." The adjacent boundary case is the part I want to steal. A regression that fails on the old code can still bless an overcorrection if nothing nearby pins the behavior the ticket never asked to change. Pairing those two checks is better than either alone.