noCV
ADRIFT-103 · Define effective rights

Reject negative and fractional seat allowances consistently

Practice briefBugFoundational

An administrative import accepts 2.5 seats, while the runtime truncates the value differently from the billing preview.

Focused work estimate
1h + prerequisites
Priority in the scenario
Medium
Engineering practice
Validation · TypeScript

Estimated field mix

  • Backend80%
  • API design20%

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

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 document service grants storage and collaboration rights from subscriptions. Support cannot explain why delayed events restore old limits.

Setup prerequisites

  • Create a local subscription API with synthetic accounts.
  • Understand transactions and UTC intervals.

Preceding work

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

Acceptance criteria

  • Accept only nonnegative safe integers for seat limits.
  • Use one validation rule for import and API commands.
  • Return the offending field without echoing the entire import.

Implementation constraints

  • Represent unlimited explicitly rather than with negative sentinels.

Verification to include

  • Create zero-seat and unlimited synthetic plans.
  • Reject fractional, negative and unsafe integer limits.

Deliverables

  • Shared seat schema and import regression

Rollout and recovery

Deploy validation before new imports; quarantine rejected rows for correction.

Value of the work

For the engineer: Practice temporal rules, concurrency and explainable API decisions.

For the team: Review whether entitlement changes preserve customer access and produce supportable decisions.

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.