# REF-TASK-015 — Decide ownership of duplicated order contracts and limits

**Status:** Implemented  
**Kind:** Decision / question  
**Depends on:** REF-TASK-008, REF-TASK-010

## Problem and evidence

Order concepts are repeated across boundaries: queue-number/note limits are exported by
`backend/src/application/order-service.ts` but repeated as 20/500 in `KdsPage.tsx`; fulfillment mode
and order projections appear in backend domain types, frontend API wire types, OpenAPI, and database
schema constraints; status operation maps occur in page and queue-card presentation. Some
duplication is necessary because backend `Date` values become JSON strings and OpenAPI is the
external contract. There is no existing shared runtime-contract package, and adding one solely to
remove repeated literals may increase coupling.

## Required decision

Inventory each repeated concept and classify it as: same invariant needing one owner, deliberate
boundary representation needing parity tests, or merely similar presentation logic. Present the
smallest options to the user. Recommended default unless contrary evidence appears: keep backend
domain validation authoritative, keep frontend wire types local, retain OpenAPI as the external
contract, and add/strengthen contract/parity tests for limits rather than introducing a new shared
package or code generator. If a shared contract mechanism is chosen, document why its operational
cost is lower than drift risk.

## Constraints

This task makes no production change until the user approves a materially new ownership mechanism.
Do not infer that identically named types are interchangeable, change public fields/enums, or make
the frontend import backend source. Provider contracts remain separate.

## Validation

The decision record must cite concrete declarations and existing drift checks. Any subsequently
approved implementation must have its own focused unit/contract tests, OpenAPI contract checks,
frontend/backend type checking and builds, coverage, and `pnpm quality`.

## Guidance / ADR

Add an ADR only if establishing a new cross-workspace contract/code-generation architecture. A
decision to retain current boundary ownership needs a concise development-guide rationale, not an
ADR unless it resolves a recurring architectural dispute.

## Open question for the user

Should cross-boundary drift be controlled by explicit parity tests (recommended from current
evidence), or is the team willing to own a shared generated/runtime contract mechanism?