# noCV engineering task library

Content version 5

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

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

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

## BAPIPAGE — Consistent query and pagination API

A fictional logistics platform lists shipments for partner dashboards. Offset pagination duplicates records during updates, while unrestricted filters create expensive database queries.

**Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL.

**Engineer value:** Practice cursor design, query contracts, and consistency/performance tradeoffs.

**Company value:** Provide predictable list APIs that remain bounded and preserve tenant scope.

**Delivery agreement:** Deliver a local versioned listing endpoint and documented client iteration behavior.

### Setup prerequisites

- Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

### Define query semantics

Specify supported filters, sorting, and authorization.

#### BAPIPAGE-101 — Define supported shipment filters and their exact semantics

**Task · Medium priority · Foundational**

noCV practice brief v5 · BAPIPAGE-101 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Define query semantics. Depends on: No preceding ticket.

Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional.

Estimated field mix: API design 100%.

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

Different clients interpret date ranges and empty status lists differently.

Acceptance criteria

- Specify inclusive and exclusive boundaries.

- Distinguish absent from empty filters.

- Reject unsupported filter properties.

Implementation constraints

- Use UTC instants for timestamp filters.

Verification

- Exercise a boundary timestamp.

- Reject an empty status list if the contract declares it invalid.

Deliverables

- Filter contract.

Rollout and recovery: Publish explicit examples before replacing legacy behavior.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-102 — Validate bounded sort options instead of accepting SQL fragments

**Task · High priority · Intermediate**

noCV practice brief v5 · BAPIPAGE-102 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Define query semantics. Depends on: BAPIPAGE-101.

Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Database engineering 40% · Security 40% · API design 20%.

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

Clients can pass arbitrary sort expressions into query construction.

Acceptance criteria

- Allowlist sort fields and directions.

- Use parameterized query construction.

- Append a stable unique tie-breaker.

Implementation constraints

- Never concatenate untrusted SQL.

Verification

- Sort equal timestamps deterministically.

- Reject an expression-shaped sort value.

Deliverables

- Safe sort parser.

Rollout and recovery: Adopt on the new endpoint first; keep unknown sorts rejected.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-103 — Enforce tenant scope before applying user filters

**Task · High priority · Advanced**

noCV practice brief v5 · BAPIPAGE-103 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Define query semantics. Depends on: BAPIPAGE-102.

Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Security 70% · Database engineering 30%.

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

An optional organization filter can replace the caller's tenant predicate.

Acceptance criteria

- Derive tenant from authenticated context.

- Apply scope in repository queries.

- Keep client filters unable to widen authority.

Implementation constraints

- Unauthorized records must not influence totals.

Verification

- List owned shipments with several filters.

- Attempt foreign-tenant filtering and verify non-disclosure.

Deliverables

- Scoped query repository.

Rollout and recovery: Gate all listing variants on cross-tenant denial checks.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

### Implement stable traversal

Bind cursors and handle concurrent data changes.

#### BAPIPAGE-104 — Encode opaque cursors bound to the normalized query

**Task · High priority · Advanced**

noCV practice brief v5 · BAPIPAGE-104 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Implement stable traversal. Depends on: BAPIPAGE-101, BAPIPAGE-102, BAPIPAGE-103.

Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional.

Estimated field mix: API design 50% · Security 30% · Database engineering 20%.

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

A cursor from one status filter is reused with another and skips records.

Acceptance criteria

- Bind cursor to tenant, sort, filter digest, and position.

- Validate schema, size, integrity, and expiry.

- Return a stable invalid-cursor problem.

Implementation constraints

- Opaque encoding alone is not integrity protection.

Verification

- Continue a matching query.

- Reject tampered, expired, and cross-query cursors.

Deliverables

- Cursor contract.

Rollout and recovery: Version cursors and retain support only for declared compatible versions.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-105 — Use keyset traversal for shipments sharing timestamps

**Bug · High priority · Advanced**

noCV practice brief v5 · BAPIPAGE-105 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Implement stable traversal. Depends on: BAPIPAGE-104.

Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Database engineering 70% · API design 30%.

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

Pagination drops shipments when several rows have the same update timestamp.

Acceptance criteria

- Compare the complete sort tuple.

- Use the unique tie-breaker consistently in both directions.

- Avoid duplicate boundary rows.

Implementation constraints

- Indexes must match the declared ordering.

Verification

- Traverse a fixture with many equal timestamps.

- Verify no omission or duplication at page boundaries.

Deliverables

- Keyset query implementation.

Rollout and recovery: Compare full traversal against a fixed fixture before replacing offsets.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-106 — Define how mutable shipment updates affect an active traversal

**Task · High priority · Expert**

noCV practice brief v5 · BAPIPAGE-106 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Implement stable traversal. Depends on: BAPIPAGE-105.

Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional.

Estimated field mix: System design 40% · API design 40% · Database engineering 20%.

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

A shipment changes status between pages, and partners expect a snapshot the endpoint never promised.

Acceptance criteria

- Compare live traversal, snapshot boundary, and export-resource options.

- Choose explicit consistency semantics for this endpoint.

- Document duplicate or omission risks that remain.

Implementation constraints

- Do not claim snapshot consistency without implementing its data boundary.

Verification

- Update a shipment between pages under the chosen model.

- Verify observed behavior matches the documented guarantee.

Deliverables

- Pagination consistency decision record.

Rollout and recovery: Introduce the consistency contract before clients depend on stable exports.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-107 — Bound total-count work independently of result pagination

**Task · Medium priority · Intermediate**

noCV practice brief v5 · BAPIPAGE-107 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Implement stable traversal. Depends on: BAPIPAGE-103, BAPIPAGE-105.

Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Performance engineering 50% · Database engineering 30% · API design 20%.

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

A fast first page still waits for an expensive exact count.

Acceptance criteria

- Make count behavior explicit and optional if appropriate.

- Bound count execution time.

- Distinguish unavailable or estimated totals from exact totals.

Implementation constraints

- Never label an estimate as an exact count.

Verification

- Return a page without optional count work.

- Timeout count calculation without misreporting zero results.

Deliverables

- Count contract.

Rollout and recovery: Default to the least expensive contract satisfying the use case.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

### Review contract limits

Measure query plans and document consistency.

#### BAPIPAGE-108 — Review query plans for supported high-cardinality filters

**Task · High priority · Advanced**

noCV practice brief v5 · BAPIPAGE-108 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Review contract limits. Depends on: BAPIPAGE-105, BAPIPAGE-107.

Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Database engineering 60% · Performance engineering 40%.

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

A permitted filter scans every shipment despite bounded page size.

Acceptance criteria

- Capture plans against a declared synthetic dataset.

- Check indexes for supported filter/sort combinations.

- Report dataset size, cache state, and machine limits.

Implementation constraints

- Local query plans are evidence for the fixture, not production latency guarantees.

Verification

- Measure a selective and broad query.

- Identify a missing-index case and compare the corrected plan.

Deliverables

- Query-plan review.

Rollout and recovery: Add indexes through migrations; retain a rollback plan for index changes.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-109 — Provide a resumable iterator that stops on cursor expiry

**Story · Medium priority · Intermediate**

noCV practice brief v5 · BAPIPAGE-109 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Review contract limits. Depends on: BAPIPAGE-104, BAPIPAGE-106, BAPIPAGE-108.

Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional.

Estimated field mix: Developer tooling 60% · API design 40%.

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

The client SDK retries invalid cursors forever instead of telling callers to restart.

Acceptance criteria

- Expose bounded async iteration with cancellation.

- Stop on terminal and invalid-cursor responses.

- Document restart behavior under the consistency contract.

Implementation constraints

- Do not silently restart and merge potentially duplicated records.

Verification

- Iterate a complete synthetic result set.

- Expire a cursor mid-run and surface the documented error.

Deliverables

- Client iterator example.

Rollout and recovery: Release with explicit cursor-lifecycle documentation.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.

#### BAPIPAGE-110 — Document list versus export guarantees for partner dashboards

**Chore · Low priority · Foundational**

noCV practice brief v5 · BAPIPAGE-110 · Consistent query and pagination API

Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.

Phase: Review contract limits. Depends on: BAPIPAGE-109.

Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional.

Estimated field mix: API design 100%.

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

Partners use an interactive list endpoint as if it were a financial or audit export.

Acceptance criteria

- State ordering, freshness, and traversal guarantees.

- List unsupported snapshot assumptions.

- Show the appropriate restart and bounded export approach.

Implementation constraints

- No legal or financial completeness claims.

Verification

- Follow the guide for a changing dashboard list.

- Identify a use case requiring a separate snapshot export.

Deliverables

- Query API usage guide.

Rollout and recovery: Keep examples aligned with implemented consistency behavior.

Project prerequisites: Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures.

Engineer value: Practice cursor design, query contracts, and consistency/performance tradeoffs.

Company value: Provide predictable list APIs that remain bounded and preserve tenant scope.

AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.

Planning status does not create Outcome Evidence or Ownership Evidence.
