# REF-TASK-013 — Consolidate named order-transition plumbing

**Status:** Implemented  
**Kind:** Semantic production refactor  
**Depends on:** REF-TASK-010

## Problem and evidence

Five fulfillment operations repeat the same shape across `order-service.ts`, `order-http.ts`, and
frontend order API code: a named allowed transition, UUID/query/auth checks, one service call,
`OrderTransitionRejectedError` mapping, CSRF acquisition, and extraction of `{ transition }`.
`order-http.ts` already uses a local `registerTransitionRoute` for two correction routes while three
forward routes retain separate copies. This is genuine plumbing duplication, but the route names and
allowed state changes are deliberate domain vocabulary and must not become a public arbitrary “set
status” endpoint.

## Proposed change

Use one private, typed registration helper for all five backend named routes and one private typed
frontend request helper for all five calls. Keep each exported function and endpoint explicit. In
the application service, consolidate only the repeated delegation/error interpretation while
retaining named methods that select constants from `domain/order.ts`.

## Constraints and sequence

Characterize every endpoint response/error and service call first. Consolidate backend registration,
validate, then frontend requests, validate, then optional service delegation. Never accept a target
status from a client, collapse forward/correction terminology, or change route names, statuses,
history, authorization, CSRF, or concurrency semantics.

## Validation

Run focused service and HTTP tests for every transition (success, invalid UUID, wrong state/not
found, query rejection), frontend API tests for every path and CSRF behavior, real-PostgreSQL order
transition/history tests, KDS component/E2E fulfillment tests, coverage, OpenAPI contract tests, and
`pnpm quality`.

## Guidance / ADR

REF-TASK-018 should explain explicit public operations backed by private shared plumbing. No ADR.