noCV
PPOLICY-102 · Pin down the contract

Stop incomplete quote requests reaching the calculator

Practice briefBugFoundational

The batch caller sometimes omits the pricing revision and the web caller sends quantity as text. Both currently reach calculation through a partially populated options object.

Focused work estimate
1h 30m + prerequisites
Priority in the scenario
High
Engineering practice
Input validation · API design · Type modeling

Estimated field mix

  • Backend60%
  • API design40%

Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence.

Pattern topics

  • BuilderCompare

    Assess whether staged construction adds value for quote inputs, or a validated immutable constructor provides the same guarantees more clearly.

Your next step

Review it, then add it to your workspace.

The board opens an editable draft; nothing is saved until you confirm it. Sign-in and workspace permissions apply, and Demo boards remain ephemeral.

Project context

A fictional equipment-rental service supports direct customers and two reseller contracts. Pricing now lives in a long conditional with subclasses left over from a discontinued campaign. Build a local TypeScript quoting module and synthetic fixtures; no starter repository, real charges, tax advice, or payment connection is supplied. Amounts use integer cents and the exercise supports USD only.

Setup prerequisites

  • Pure functions
  • Object composition
  • Integer arithmetic

Preceding work

Complete these dependencies, or supply their agreed outputs before taking this ticket.

Acceptance criteria

  • A quote request requires tenant, contract revision, nonempty product identity, positive integer quantity, and a nonnegative integer unit price.
  • Construction fails with field-level errors before any pricing rule runs.
  • Compare a staged Builder with a validated constructor or factory; select the smallest interface that cannot expose an incomplete request.

Implementation constraints

  • Do not silently fill the contract revision from a mutable global default; runtime input validation remains necessary with TypeScript.

Verification to include

  • Construct equivalent valid requests from the synthetic batch and web inputs.
  • Reject missing revision, quantity 'ten', and quantity zero while asserting the calculator was not called.

Deliverables

  • Validated request construction API and invalid-input fixtures

Rollout and recovery

Route the two local callers through validation together; keep error mapping compatible with their declared response contracts.

Value of the work

For the engineer: Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation.

For the team: Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design.

Evidence boundaries

Outcome Evidence: Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.

Ownership Evidence: Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence.