# MVP-REL-001 — Fail visibly and safely

## Story

As an operator, I want failures to be visible and isolated so that one problem does not corrupt
ongoing service.

## Scenarios

### MVP-REL-001-S01 — Backend unavailable

- **Given** the KDS cannot reach the backend
- **When** an operation requiring it is attempted
- **Then** the operator sees a recoverable failure and no false success
- **Evidence:** frontend integration plus representative E2E/network interception.

### MVP-REL-001-S02 — Checkout provider unavailable

- **Given** checkout cannot obtain a definitive provider result
- **When** a commercial checkout is attempted
- **Then** failure/unknown semantics are explicit and no false paid/sales state is created
- **Evidence:** integration plus E2E using the deterministic fake.

### MVP-REL-001-S03 — Unrelated queue survives a failed operation

- **Given** active queued orders and a separate operation fails
- **When** the queue is refreshed or continues operating
- **Then** existing active orders remain intact
- **Evidence:** integration plus E2E.

### MVP-REL-001-S04 — Finalized records survive process restart

- **Given** finalized orders and history
- **When** application processes restart
- **Then** records, active state, and today’s commercial figures remain available
- **Evidence:** Docker/integration restart evidence.

### MVP-REL-001-S05 — No offline-sync implication

- **Given** connectivity is unavailable
- **When** the UI reports failure
- **Then** it does not promise offline acceptance, deferred synchronization, or payment success
- **Evidence:** E2E/manual copy review.

## Invariants and exclusions

Failures never create false payment, queue, or sales success and never delete unrelated durable
orders. Offline operation/synchronization, high availability, and a monitoring platform are out of
scope.

## Implementation tasks

[MVP-TASK-031](../tasks/MVP-TASK-031.md) and [MVP-TASK-032](../tasks/MVP-TASK-032.md).