Gate Restoration Needs No-Weakening Proof

When CI quality gates fail, the instinctive fix is to make the checks go green. But a fix that silently weakens the gate — by skipping tests, adding suppression comments, or narrowing the scope of what gets checked — is not a fix. It is a regression dressed as a resolution.

Gate restoration is a trust problem, not a green-check problem.

The problem under the surface

When CI checks start failing, the visible symptom is red status. But the real problem is usually that the quality gate contract has drifted: scripts are missing or misnamed, the CI workflow file does not match the accepted standard, type errors have accumulated under a configuration that previously hid them, or test expectations no longer reflect what the production code actually does.

Each of these is a different class of drift, and each requires a different class of fix. Treating them all as "make the check green" conflates the symptom with the problem.

The hidden failure mode

The dangerous fix is the superficially green one. It comes in several forms:

• Adding @ts-ignore or @ts-nocheck to silence type errors rather than resolving them
• Skipping or marking tests as .todo to clear the suite
• Narrowing glob patterns so the linter or type checker no longer sees problematic files
• Letting the build step substitute for the lint step in the CI configuration
• Adding exclusion rules that remove files from coverage

Each of these produces a green check. None of them restores the gate. In fact, each one degrades it: the contract now enforces less than it did before, and the degradation is invisible to future contributors who only see a passing pipeline.

What a trustworthy restoration looks like

A trustworthy gate restoration treats every proposed fix as a governance decision, not just a technical one.

For failing type checks: Establish a baseline first. Know how many errors existed before the fix. After the fix, the error count should be zero — not "fewer" — and no suppressions should be present. If a type error cannot be resolved without a suppression, that is a design decision that should be made explicitly, not silently.

For failing tests: Analyze each failure as either a production bug, a test expectation bug, a runner or configuration bug, or a dependency or type issue. The fix for each category is different. Changing a test's expected value is sometimes the right answer — but only after confirming that the production logic is correct and the test expectation was wrong. This is a judgment call, not a mechanical edit.

For missing or misaligned scripts: When the accepted engineering standard changes — which package manager, which runtime version, which script names the CI uses — the scripts, workflow files, and documentation must all change together. Stale documentation is part of gate drift.

For duplicate workflows: Parallel or legacy CI workflow files that can still be triggered are not neutral. They are sources of confusion and drift. A gate restoration that adds a correct workflow without removing the stale ones is incomplete.

The no-weakening checklist

After any gate restoration, verify the following before accepting the result:

• No new eslint-disable or @eslint-disable-next-line comments
• No new @ts-ignore, @ts-nocheck, or // @ts-expect-error (without resolution)
• No new .skip or .only in the test suite
• No narrowed glob patterns in lint, type check, or test configuration
• No files explicitly excluded from coverage that were not excluded before
• No build step substituting for a lint or type check step
• No configuration changes that cause any check to silently run on fewer files

This list is not just a code review note. It is the acceptance criterion for the fix.

The latent error loop

A common pattern in gate restoration is that fixing the first class of errors reveals a second class. Correcting the type check configuration, for example, may expose type errors in test files that were previously invisible because the test runner was not included in the type check scope. Fixing those in turn may require updating test utilities or mock types.

This is not a sign that the fix is expanding out of control. It is the gate doing its job: now that it runs correctly, it surfaces what it was always meant to catch. The important discipline is to treat each new class of errors explicitly — decide whether it is a production bug, a test artifact, a dependency issue, or a configuration gap — rather than absorbing it silently into the fix.

The broader principle

The same principle that applies to CI gates applies to any quality contract: a fix that makes the metric look better without restoring the underlying trust is not a fix. It is technical debt of a particularly dangerous kind, because it is invisible.

Gate restoration done well does not just return the pipeline to green. It returns the pipeline to trustworthy: the checks run on the right scope, suppressions are absent, test expectations are correct, and every fix can be explained and defended.

How to apply it

When you inherit failing CI gates, start with a baseline audit: what checks exist, what they currently cover, what the accepted standard says they should cover, and where the drift is. Write down the gap before writing any code.

Scope the fix explicitly. Decide upfront which failures require design decisions (test expectation changes, configuration consolidation, workflow file retirement) and which are mechanical (missing script aliases, stale README commands). Do not start fixing until both categories are clear.

Verify the result against the no-weakening checklist, not just against green status. A green pipeline with a narrowed scope is worse than a red pipeline with honest failures, because at least the red pipeline tells you the truth.