Why Gates Fail Closed All Tiers

The problem this solves

A "gate" is a hook that runs before a task can complete — architecture checks, contract-break checks, budget checks, containment checks. The naive way to write one is: try to run the check, and if anything goes wrong (an exception, a timeout, a missing module), just let the task through. That sounds harmless, but it means a broken gate and a passing gate look identical from the outside. A gate that silently stops working is worse than no gate at all, because it keeps the appearance of protection without the substance.

PairCoder's gates do the opposite: any failure of the gate itself — not the check it's enforcing, but the gate's own execution — blocks the task. This is called fail-closed, and it applies uniformly. There is no fail-open gate category.

What counts as "the gate itself failing"

It's worth being precise about this, because it's not the same as "the check found a problem." A gate fails closed when:

• The gate handler throws an exception
• The gate exceeds its timeout (30 seconds by default, configurable per-gate)
• The gate returns something malformed — not a dict, or a dict missing the expected result key
• The hook name isn't recognized at all (a typo in config, or a module that failed to import)

In every one of these cases, the honest answer is "I don't know whether this would have passed" — and the system treats "don't know" as "blocked," not as "assume it's fine."

What you'll see when it happens

A fail-closed gate tells you which gate broke, what went wrong, and that it blocked you for safety — not because your work violated a rule:

Gate "arch_check_modified" failed closed: ImportError: No module named '...'
  The gate could not execute and blocked this task for safety.
  To bypass: bpsai-pair task update <id> --status done --skip-gates
  To fix: ensure the gate module is installed and accessible.

No retry happens automatically — retrying a crashed gate rarely helps and just adds latency. You have two real options: fix the underlying issue (usually a missing dependency or a config typo) and re-run, or bypass deliberately.

Bypassing responsibly

Bypasses exist because sometimes you genuinely need to move past a broken gate — and PairCoder's philosophy is not "never let the operator override," it's "never let an override happen invisibly." Every bypass is audited, not silent:

• task update <id> --status done --skip-gates or --force — both write an entry to bypass_log.jsonl
• ttask done --no-strict skips acceptance-criteria verification, also logged
• task update --local-only --reason "..." requires you to state why, also logged

This is the same idiom repeated everywhere in the tool: the consequence is enforced mechanically, and the escape hatch is audited rather than forbidden. The underlying principle is to enforce at the point where state actually changes and route everything else around it — the thing that actually changes state (a task completion, a commit) is where the hard check lives, while conversational shortcuts are only ever a convenience layer on top of it, never a way around it.