# Fail Fast Over Fallbacks

Shared reference for `post`, `build`, and `ship`. This is the canonical implementation-fallback
policy. The skills carry a one-line stance inline and defer the full rule here; they must not
restate a divergent version.

## Stance

Default engineering stance for `post`, `build`, and `ship`: prefer fail-fast over fallbacks.

This policy governs planned and implemented behavior. It does not turn an optional review finding or
a QA retry into approval authority.

## What counts as a fallback

A fallback is alternate behavior that lets execution continue past a missing or failed condition,
including:

1. alternate behavior after missing or failed required config, data, API response, or state
2. silent catch-and-continue that swallows an error
3. a compatibility shim that hides an unresolved incompatibility
4. a default value substituted for a missing or failed required input; pure functional defaults
   for genuinely optional inputs are not fallbacks
5. a retry or alternate route that masks a root cause
6. a redundant alternate navigation or data path where one path should be authoritative, which
   can mask which path actually runs

Fail-fast means surfacing the missing condition loudly: throw, return an explicit error, render
an explicit error state, or refuse to proceed, so the root cause is visible rather than masked.

## Authorizing User approval

Adding any implementation fallback requires explicit user approval. Before adding one, the
assistant must explain, in chat:

1. what failure or missing condition the fallback handles
2. why fail-fast is not acceptable here
3. why the fallback is necessary or preferred
4. how it will be tested and observed so a future failure stays visible

Until the user approves, plan and implement the fail-fast path. Do not add the fallback.

Record any proposed implementation fallback in Risks / Rules and obtain explicit Authorizing User
approval before Build adds it.

## Carve-outs

These are not implementation fallbacks under this policy and remain governed by their existing
rules: the documented database migration-backed QA exception; request-driven happy-path demo
accelerations that are already justified in the approved packet; and genuine
platform-required branching that still fails loudly on the unexpected case.