# REF-TASK-010 — Split order HTTP registration and frontend order API by capability

**Status:** Implemented  
**Kind:** Mechanical production refactor  
**Depends on:** REF-TASK-005

## Problem and evidence

`backend/src/order-http.ts` (about 397 lines) combines active queue, current-day sales, unresolved
checkout, metadata, finalization, and fulfillment transition endpoints. The matching
`frontend/src/app/api/order-api.ts` (about 358 lines) combines all wire types and operations. Their
names imply only “order” even where sales and checkout-attempt capabilities have distinct routes and
query keys.

## Proposed change

Retain stable top-level registration/composition while split modules group finalization, active
queue/fulfillment, sales, and unresolved checkout. Mirror those capability boundaries in frontend
API modules, with explicit type-only imports where a projection is shared. Keep query keys beside
their fetch function. Use re-exports temporarily only when needed for a mechanical two-step move,
then review them in REF-TASK-017.

## Constraints and sequence

Move exports and update imports without changing any URL, schema, status/body, query-key value,
TSDoc meaning, or OpenAPI contract. Validate the backend move before the frontend move. Do not
create a shared frontend/backend source package in this task; REF-TASK-015 decides contract
ownership.

## Validation

Run order HTTP/API unit tests after each module move, OpenAPI contract tests, KDS component tests,
backend and frontend typecheck/build/coverage, affected KDS E2E specs, and `pnpm quality`. OpenAPI
content should remain byte-for-byte or semantically unchanged; if it changes, treat that as scope
drift and stop.

## Guidance / ADR

REF-TASK-018 should record capability-based API module ownership. No ADR.