oasdiff gate fails open: fail-on ERR misses WARN-rated breaking changes

[rubenhensen]

The oasdiff gate landed in #201 with fail-on: ERR and no include-checks. Work on the pg-pkg equivalent (encryption4all/postguard#249 / #269) established that this setting fails open on several changes COMPATIBILITY.md forbids, because oasdiff rates them WARN rather than ERR:

• removing or renaming an optional response property
• removing a request parameter
• the constraint-narrowing *-set family

Plus two checks that rate ERR but are opt-in, so they never run unless named: response-non-success-status-removed (401 → 403) and response-property-enum-value-removed.

This spec is less exposed than pg-pkg's — it marks far more fields required (34 required: occurrences vs pg-pkg's one), and a required property's removal does rate ERR — but the optional-property and request-parameter gaps apply to any spec, and cryptify's routes are unversioned, so there is no /v3 escape hatch: a break here breaks pinned clients immediately.

Do the measurement before changing the setting. The pg-pkg work found exactly one WARN check that fires on something the compatibility rules do not forbid (response-property-enum-value-added), and resolved it by making a new response enum value explicitly non-additive in COMPATIBILITY.md. Repeat that for this spec rather than assuming the same answer: mutate the spec each way, record which verdict each setting gives, and only then flip fail-on and add include-checks.

Reference implementation and its reasoning: encryption4all/postguard/.github/workflows/api-diff.yml and pg-pkg/tests/api_gate.rs, which pins the verdicts as an executable record. An equivalent test here would be worth having — this repo has no tests/ dir, so it would go inline per the repo's convention.

Part of encryption4all/postguard#247 (workstream C).

[rubenhensen]

/dobby please pick this up — you did the equivalent measurement for pg-pkg in encryption4all/postguard#269, so this is that analysis repeated against cryptify's spec. Do the mutation table first (which settings catch which forbidden change), then flip fail-on and add include-checks accordingly, and note anything WARN blocks that the compatibility rules actually permit. Workflow YAML in a PR comment as usual — the App can't push .github/workflows/.

[dobby-coder]

On it! I'll redo the pg-pkg-style analysis against cryptify's compatibility spec — building the mutation table (which settings catch which forbidden change) first, then adjusting fail-on and include-checks to match, and flagging any WARN-level cases the compatibility rules actually allow. I'll drop the workflow YAML in a PR comment once it's ready, since the App can't push to .github/workflows/.

[dobby-coder]

Done — ran the mutation/settings analysis on cryptify#203 the same way as postguard#269, plus a rules sweep. All 5 findings from the first pass are confirmed fixed, and I caught and fixed one more nit myself: the settings check verified what the gate runs with but not whether it's ever triggered, so a later paths: filter could skip it silently on every non-spec PR. Added three targeted asserts for that (trigger present, no path filter, no job-level if:) — each one verified by actually breaking that condition and watching the test catch it.

Posted the review as a comment with VERDICT: approve and flipped the PR out of draft — it's red on purpose (cargo test --all-targets is 156/1 right now), since only a maintainer can push the workflow YAML from the PR comment to .github/workflows/ on this branch, and doing that is what turns it green (157/0 in my local check).

One open item from before: the types: [..., edited] trigger gap (the one that bit #201 on base retargets) is still unfiled — let me know if you want that opened as its own issue.

PR: #203