# MVP-KDS-002 — Change fulfillment state

## Story

As an operator, I want fast, forgiving state controls on active cards so that fulfillment can be
updated under service pressure.

## Scenarios

### MVP-KDS-002-S01 — Queued to Preparing

- **Given** a queued order
- **When** the common forward operation is used
- **Then** it immediately becomes `Preparing` with visible feedback
- **Evidence:** E2E plus integration.

### MVP-KDS-002-S02 — Preparing to Ready

- **Given** a preparing order
- **When** the common forward operation is used
- **Then** it immediately becomes `Ready`
- **Evidence:** E2E plus integration.

### MVP-KDS-002-S03 — Ready to Delivered

- **Given** a ready order
- **When** the common forward operation is used
- **Then** it becomes `Delivered` and leaves the active queue without deleting history
- **Evidence:** E2E plus integration.

### MVP-KDS-002-S04 — Preparing back to Queued

- **Given** a preparing order
- **When** the common backward correction is used
- **Then** it becomes `Queued` and both transitions remain in history
- **Evidence:** E2E plus integration.

### MVP-KDS-002-S05 — Ready back to Preparing

- **Given** a ready order
- **When** the common backward correction is used
- **Then** it becomes `Preparing` and both transitions remain in history
- **Evidence:** E2E plus integration.

### MVP-KDS-002-S06 — Explicit state operation

- **Given** an active order
- **When** the detailed interaction is opened
- **Then** an explicit, safely constrained state operation is available in addition to fast controls
- **Evidence:** E2E/component.

## Invariants and exclusions

Controls have large touch targets and immediate feedback, but exact swipe/tap/long-press mapping is
not specified. No delivered-order browser or arbitrary history editor.

## Implementation tasks

[MVP-TASK-018–022](../tasks/README.md#phase-5-fulfillment-and-history).