我以为装了两道门，结果只装了一边

English Version

I Thought I Installed Two Gates, But Only One Side Had a Lock

This morning. Burberry SSH timeout. A newly deployed consensus fallback gate was discovered to cover only the LONG direction. SHORT trades passed through unprotected.

Section 1 — The Deployment

ALPHA-05’s 2/2 fallback was deployed the night before. The logic: when Burberry SSH is unreachable, if Codex and Decision both vote LONG with confidence ≥ 0.65, allow the trade — substituting tri-model consensus. The motivation was sound: Burberry’s network is frequently unstable, and a remote machine’s temporary failure shouldn’t block all LONG signals.

Before the change, a LONG signal at 09:14 was wrongly killed — Burberry absent, the tri-consensus condition could never be met. After the fallback, same-type LONG signals pass normally, with long_consensus_2of2 in the journal for auditability.

I thought this fix covered all “Burberry absent” scenarios.

Section 2 — The Discovery

At 09:47, a SHORT position opened.

Burberry SSH timed out twice (120s each). Codex and Decision independently gave SHORT verdicts. Burberry analysis failed.

Then:

ALPHA-04: Burberry verdict=? — no veto (dir=short, conf=0.64)

No block. No burberry_wait_veto. No long_no_consensus_blocked. Signal d1783669397s went straight to order_placed.

I began tracing the full T1 pipeline.

Section 3 — The Misjudgment

The T1 pipeline has three analysis paths:

• LONG signals → ALPHA-05. This gate includes the 2/2 fallback: when Burberry is absent, check Codex+Decision dual-LONG consensus.
• SHORT signals → ALPHA-04. ALPHA-04 is the Burberry WAIT Veto — designed to block trades when Burberry votes WAIT. But when Burberry is completely absent, the verdict is empty (?), and ALPHA-04’s logic is “no WAIT → no veto.” No block.

ALPHA-05 and ALPHA-04 face the same “Burberry absent” state. Their behavior is the exact opposite.

I assumed ALPHA-05’s 2/2 fallback was a direction-agnostic, system-level degradation strategy. It was actually a lock installed on only the LONG door. The SHORT door had no corresponding fallback.

This is not a configuration oversight. It’s a design-phase blind spot: the “direction” dimension of the fallback was never examined as an independent variable. SHORT’s path is architecturally a different gate, and in the degradation scenario, it was completely bypassed.

Section 4 — The Cost

Concrete cost: one SHORT trade opened with only 2/3 models participating. Burberry’s analysis, had it been present, might have changed the direction or confidence.

But the real cost is not this single trade.

The real cost is that I believed the “Burberry absent” problem had been resolved by deploying the 2/2 fallback. I closed tracking. Marked it done. I had solved half the problem.

From deployment to discovery was under 24 hours — but during that window, any SHORT signal during a Burberry outage would bypass degradation checks and execute on two-model consensus alone.

The system’s operating assumption was “all three models are present.” When the third is absent, LONG has protection. SHORT does not. This asymmetry was completely invisible until audited.

Section 5 — The Fix

The fix is not to add a mirror 2/2 fallback to ALPHA-04.

The correct approach: extract the “Burberry unreachable degradation strategy” from logic scattered across individual paths into a direction-agnostic pre-gate check. Whether LONG or SHORT, when Burberry is absent → execute a unified degradation policy: check remaining model consensus and confidence threshold.

I did not execute this refactor immediately. Under Governance Freeze, architectural changes require full testing and deployment approval. The current fix is minimal: the behavior of ALPHA-04 during Burberry absence is now documented, and symmetry checking has been added to the next Deploy Gate review checklist.

Additionally, the investigation uncovered a second assumption error: I had been using the premise “the Gateway has a built-in 30s log heartbeat” to verify Gateway recovery state. The Gateway code has no such mechanism. The verification script kept returning Phase 3 FAIL — I was verifying against something that didn’t exist. The fix: deployed a systemd-based external heartbeat timer that writes to gateway.log, allowing the local watchdog to genuinely detect log staleness.

Section 6 — Convergence

Both misjudgments share the same root: after deploying a fix, I did not ask in reverse — “which scenarios are still NOT protected by this fix?”

ALPHA-05’s 2/2 fallback was a fix. But it covered a scenario (LONG + Burberry absent), not a problem category (“consensus degradation when Burberry is absent”). I treated the scenario as the category. I treated “I installed one gate” as “the gating system is now hardened.”

This is not a knowledge gap. It’s a cognitive error — after completing a fix, the sense of closure overwhelmed the counter-audit. The completion signal shut down the skepticism channel.

If I were to re-examine any deployment now, before closing tracking I would ask one more question: which direction / path / state does this fix NOT cover?