# 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. ## BAPIVER — Public API version transition A fictional inventory platform must replace a legacy availability response. Existing partners upgrade on different schedules, and the team needs a versioned transition. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, HTTP. **Engineer value:** Practice public-contract design, compatible evolution, and client lifecycle management. **Company value:** Provide a predictable migration that keeps supported integrations inspectable and recoverable. **Delivery agreement:** Deliver local versioned contracts, compatibility checks, and a deprecation packet. ### Setup prerequisites - Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. ### Design version semantics Identify changes and supported compatibility. #### BAPIVER-101 — Inventory breaking and additive availability-contract changes **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIVER-101 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Design version 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. The proposed response renames fields and changes unknown stock from null to zero. Acceptance criteria - Classify each request and response change. - Preserve unknown versus zero semantics. - Identify supported legacy behavior explicitly. Implementation constraints - Use actual local contract examples rather than general compatibility slogans. Verification - Classify an optional additive field. - Flag a meaning-changing null-to-zero conversion. Deliverables - Contract change inventory. Rollout and recovery: Review the inventory before choosing a versioning approach. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-102 — Define version selection and unsupported-version errors **Task · High priority · Intermediate** noCV practice brief v5 · BAPIVER-102 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Design version semantics. Depends on: BAPIVER-101. Difficulty: Intermediate. Estimated focused work: 120 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. Clients cannot tell which contract a request will receive. Acceptance criteria - Choose one explicit version selection rule. - Document a deterministic default only if retained intentionally. - Return structured errors for unsupported versions. Implementation constraints - Keep routes under /api/v1 and /api/v2 in the scenario. Verification - Request each supported version. - Request an unknown version and inspect its documented problem response. Deliverables - Version selection contract. Rollout and recovery: Introduce explicit selection before changing existing defaults. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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 coexistence Serve explicit contracts and safe migration behavior. #### BAPIVER-103 — Keep legacy and new projections over one domain authority **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-103 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System design 30% · Backend 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. Separate version handlers duplicate inventory rules and begin disagreeing. Acceptance criteria - Share domain availability calculation. - Map into distinct immutable transport schemas. - Preserve version-specific unknown-state semantics. Implementation constraints - Controllers cannot bypass tenant-scoped service reads. Verification - Project one domain result into both versions. - Deny cross-tenant reads through either route. Deliverables - Versioned projection boundary. Rollout and recovery: Ship the new projection alongside the old; retain identical domain invariants. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-104 — Use Problem Details for versioned validation failures **Task · High priority · Intermediate** noCV practice brief v5 · BAPIVER-104 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-103. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · Security 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. Partners parse changing human messages to detect invalid warehouse filters. Acceptance criteria - Publish stable problem types and field paths. - Keep instance and request identifiers safe. - Version any materially changed error semantics. Implementation constraints - Exclude stack traces and internal database details. Verification - Validate a malformed filter in both versions. - Verify cross-tenant denial reveals no private identifiers. Deliverables - Error contract examples. Rollout and recovery: Add structured fields compatibly and document client handling. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-105 — Preserve idempotency semantics across client version upgrades **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-105 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-103, BAPIVER-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Distributed systems 30% · Backend 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 client retries an inventory reservation with the same key after upgrading its API version. Acceptance criteria - Define whether keys bind to normalized domain intent or transport version. - Reject conflicting reuse consistently. - Prevent duplicate domain effects across supported routes. Implementation constraints - Document the chosen scope rather than silently translating incompatible requests. Verification - Replay equivalent supported requests under the chosen policy. - Reject a changed reservation under the same key. Deliverables - Cross-version idempotency contract. Rollout and recovery: Retain original operation facts during migration. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-106 — Generate SDK migration examples from packaged client versions **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIVER-106 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Implement coexistence. Depends on: BAPIVER-104, BAPIVER-105. 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. Migration documentation uses methods not present in the released client archive. Acceptance criteria - Compile old and new examples against local packaged clients. - Show equivalent availability and error handling. - Document changed optional and nullable fields. Implementation constraints - Use local archives and mock servers only. Verification - Run both documented examples. - Detect a snippet importing a removed method. Deliverables - Executable SDK migration examples. Rollout and recovery: Publish examples with the matching contract revision. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. ### Manage deprecation Verify client migration and retirement conditions. #### BAPIVER-107 — Expose deprecation signals without breaking successful responses **Story · Medium priority · Intermediate** noCV practice brief v5 · BAPIVER-107 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-106. Difficulty: Intermediate. Estimated focused work: 120 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 need machine-readable notice that the old version has a planned sunset. Acceptance criteria - Document deprecation metadata and dates. - Keep response behavior compatible during support. - Link a versioned migration guide. Implementation constraints - Dates are fictional scenario inputs and must be labeled in fixtures. Verification - Read a legacy response with deprecation metadata. - Verify the new version does not carry an incorrect retirement notice. Deliverables - Deprecation response contract. Rollout and recovery: Enable notice before any retirement gate. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-108 — Measure version adoption using bounded non-sensitive metadata **Task · High priority · Advanced** noCV practice brief v5 · BAPIVER-108 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-107. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Privacy engineering 30% · Site reliability 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. The team wants to know whether supported clients still use the old version without collecting request bodies. Acceptance criteria - Count requests by declared client class and API version. - Track unknown client versions separately. - Exclude tokens, payloads, and personal identifiers. Implementation constraints - Do not equate no observed traffic with confirmed migration. Verification - Report synthetic mixed-version traffic. - Show an inactive client as unknown rather than migrated. Deliverables - Adoption report. Rollout and recovery: Use counts as one input to retirement review; preserve explicit client support records. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-109 — Decide retirement with client obligations and rollback constraints **Task · High priority · Expert** noCV practice brief v5 · BAPIVER-109 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-105, BAPIVER-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · System design 20% · Site reliability 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. The old API has little traffic but one supported partner still relies on its unknown-stock behavior. Acceptance criteria - Define retirement criteria beyond traffic volume. - Compare support cost, partner migration risk, and data compatibility. - Rehearse restoring legacy routing after a failed retirement. Implementation constraints - Keep unsupported assumptions visible; no actual partner notifications are sent. Verification - Retire a fully migrated synthetic client set. - Block retirement when a supported dependency remains unresolved. Deliverables - API retirement decision record. Rollout and recovery: Use a staged local retirement and retain tested legacy artifacts through the rollback window. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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. #### BAPIVER-110 — Write the partner migration checklist with observable completion **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIVER-110 · Public API version transition Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Manage deprecation. Depends on: BAPIVER-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 70% · Developer tooling 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. A checklist saying 'upgrade the SDK' misses changed error and unknown-state handling. Acceptance criteria - List client-code, error, and data-semantic changes. - Include local verification commands. - Define completion through exercised operations. Implementation constraints - Do not claim a partner migrated without recorded confirmation. Verification - Migrate the synthetic client using the checklist. - Catch a client still treating unknown stock as zero. Deliverables - Partner migration guide. Rollout and recovery: Version the guide and retain legacy instructions for supported clients. Project prerequisites: Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic. Engineer value: Practice public-contract design, compatible evolution, and client lifecycle management. Company value: Provide a predictable migration that keeps supported integrations inspectable and recoverable. 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.