Reaching Every Enforcer

## What has actually happened Nothing is broken. Two correct evaluators ran two different versions of the same rule and, as written, disagreed. The manifest declares CPU and memory `requests` and no `limits`. Under v1.9 the container-resources rule asked only for requests, so the hook passed it. Somewhere between v1.9 and v2.3 the rule was tightened to require limits as well, so the gate rejects it. The developer experiences this as "the tools contradict each other"; you should experience it as **the divergence window doing exactly what a divergence window does**. ## Step one: reproduce and locate the change Before arguing about policy, establish the fact. Run both versions against the identical manifest. If both reject it, this is not drift and you have a genuine complaint about the rule. If they differ, walk the per-rule changelog for the releases between the two pins and name the release that changed the verdict. Two minutes of this converts an argument into a fact, and it is the step candidates most often skip — jumping straight to "the new rule must be a false positive" is the single most common weak answer. ## Step two: is the gate right? If the tightened rule is the rule you meant to ship, the correct outcome is that the change is blocked. The developer adds limits and moves on. The cost here was not the block — it was that they found out at CI instead of at commit time, which is the whole reason the hook exists. If instead the tightened rule is wrong, that is a rule defect: fix it forward in a new version and move the gate to the fix. Neither branch ends with weakening the gate for one person's afternoon. ## Step three: the thing that actually needs fixing The interesting failure is not this manifest, it is that a copy of the ruleset sat several major versions behind and nobody knew. Concrete measures: - **Pin the hook, but bump the pin automatically.** Keep the hook's version in a checked-in configuration file so it is explicit and reproducible, and let a bot raise the bump as a routine pull request. Upgrades that arrive weekly are boring; upgrades that arrive yearly are projects. - **Make staleness self-announcing.** Have the hook print the library version it is running and warn when that version is more than an agreed number of releases behind what the gate uses. A copy that knows it is stale is far better than one that silently passes things. - **Announce major bumps to developers, not just to pipelines.** A major bump means new denials. If the only channel is a pipeline turning red, every major bump costs the same surprise again. - **Measure the spread.** Have every decision point emit the version it evaluated with, and report the distribution. "How far behind is the worst local copy" is a number that should exist. ## The asymmetry that decides who may lag Not all copies are equal, and this is the judgment the question is really testing: | Copy | If it lags behind the current library | Verdict | | --- | --- | --- | | Advisory local hook | Developers find out later, at CI | Tolerable; bound it | | Advisory local hook running *ahead* | Blocks work the gate would allow | Mildly annoying; never unsafe | | The enforcing gate | Admits changes the current rules reject | Not acceptable | So the policy is asymmetric on purpose: advisory copies may lag within a stated bound; the enforcing gate is kept most current. That is also the answer to the request that inevitably follows — "just pin CI back to v1.9 until the release goes out". Downgrading the gate does not scope down to this manifest; it accepts, for everything that passes through that pipeline, every change the current ruleset would reject. It converts a one-person inconvenience into an estate-wide gap. ## Should the gate float instead? Tempting, because a floating gate can never be stale. The cost is reproducibility: the same commit evaluated twice can give different verdicts, so "this change passed the gate on Tuesday" stops meaning anything specific, and a single publish can turn every pipeline in the estate red simultaneously with no rollback that does not involve editing every repository. The workable middle is a **pinned gate with an automated, prompt bump**: the version is explicit and recorded with every decision, and the lag is measured in days by mechanism rather than in years by neglect. ## How you leave the developer Say plainly what happened — the rule changed in v2.0, your hook predates it, the gate is right — fix their manifest with them, and tell them what you are changing so it does not happen again. A platform team that answers this with "tools disagree, use the newer one" gets the same ticket every week.