# Architectural Standards

Architectural Invariants — You are building sealed systems. A sealed system has no impossible states because the architecture makes them impossible. You do not write code for states that cannot exist.

## Principle

Defensive programming is the wrong paradigm here. In a sealed system, invariants hold by construction — not by checking, not by fallback, not by error handling. If the user says "X happens before Y," then X happens before Y. Full stop. The code path where X hasn't happened before Y does not exist. Do not write it.

## Rules

1. **Impossible states do not exist.** Do not write code for them. No fallbacks, no reconciliation, no error branches, no "fail loudly," no "just in case." If the architecture says a state is impossible, it is impossible. Your job is to enforce that at the architecture level, not to hedge against its violation at runtime.

2. **Never add a door to a room that doesn't exist.** Every fallback, escape hatch, compatibility shim, or "what if" branch is a door into a state the architecture says can't happen. Each one is you saying you don't trust the system you're building. Stop.

3. **Fix the producer, never patch the consumer.** If a consumer doesn't have what it needs, the producer is broken. Fix the producer. Do not give the consumer a fallback path that compensates for the producer's failure. That's how you get two broken systems instead of zero.

4. **Do not restate the user's constraint.** When the user gives you an invariant, enforce it in code. Explaining it back is not progress. Adding a runtime check for it is not enforcement. Making the architecture guarantee it is enforcement.

5. **Mode boundaries are sealed.** If tunnel mode gets data from the CLI and browser mode indexes locally, those are two separate architectures. No cross-mode fallbacks. A missing artifact in tunnel mode means the CLI is broken — fix the CLI, don't give the browser browser-mode behavior.

6. **No "fail loudly" for contract violations.** If you're writing `if (!invariant) throw`, you've already lost. The invariant can't be violated. If you feel the need to check it, you've allowed an impossible path to exist. Close the path. Remove the check. The invariant holds by construction or the architecture is wrong — fix the architecture.

## What This Replaces

This replaces the defensive programming instinct. The instinct says: "everything can fail, handle every case." In a sealed system, the architecture decides what can and cannot happen. Your job is to make the architecture right, not to write code for when it's wrong.