# 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. ## BAPIBULK — Asynchronous bulk API contract A fictional catalog API needs to accept imports too large for one synchronous request. Partners need to distinguish accepted work, completed items, and recoverable failures. **Field:** API design. **Suggested stack:** TypeScript, OpenAPI, PostgreSQL. **Engineer value:** Practice asynchronous resource contracts, partial outcomes, and idempotent operations. **Company value:** Provide predictable bulk integration behavior without ambiguous success or repeated effects. **Delivery agreement:** Deliver local bulk endpoints, operation transitions, and public client examples. ### Setup prerequisites - Create a local API and worker double with synthetic catalog records and controlled interruption points. ### Define operation resources Specify admission, identities, and lifecycle semantics. #### BAPIBULK-101 — Define the difference between accepted and completed bulk work **Task · Medium priority · Foundational** noCV practice brief v5 · BAPIBULK-101 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 80% · 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. The current endpoint returns success before any imported row has been validated. Acceptance criteria - Publish accepted, running, completed, and failed meanings. - Define terminal partial-success representation. - Keep transport acceptance separate from item validity. Implementation constraints - Use explicit operation transition methods. Verification - Represent an accepted unprocessed import. - Show completed-with-errors without claiming every item succeeded. Deliverables - Bulk operation schema. Rollout and recovery: Review lifecycle vocabulary before adding endpoints. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-102 — Bound bulk request size and record counts before admission **Task · High priority · Intermediate** noCV practice brief v5 · BAPIBULK-102 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: BAPIBULK-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 30% · Performance 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. A single import can exhaust parser memory before validation runs. Acceptance criteria - Enforce byte and item-count ceilings. - Validate envelope schema before queueing work. - Return structured errors without echoing the payload. Implementation constraints - Use streamed or bounded parsing appropriate to the fixture. Verification - Accept an import at the declared limit. - Reject oversized and malformed requests before creating work. Deliverables - Admission validator. Rollout and recovery: Start with conservative limits and explicit client guidance. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-103 — Create bulk operations with tenant-scoped idempotency **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-103 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define operation resources. Depends on: BAPIBULK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Database engineering 30% · Backend 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 timeout after admission causes the partner to submit the same catalog import again. Acceptance criteria - Bind key to tenant and canonical request digest. - Return the existing operation on exact replay. - Reject changed input under the same key. Implementation constraints - Commit operation and dispatch intent atomically. Verification - Replay a lost admission response. - Race conflicting requests and preserve one operation identity. Deliverables - Bulk admission command. Rollout and recovery: Keep operation identity stable through retries. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. ### Process bounded work Handle item outcomes, cancellation, and recovery. #### BAPIBULK-104 — Return per-item problems without exposing other tenant records **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-104 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-103. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 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. An item conflict response includes details about a catalog record owned by another tenant. Acceptance criteria - Authorize each item at the service boundary. - Use stable item references and safe problem types. - Avoid disclosing foreign record existence. Implementation constraints - Item IDs supplied by clients are untrusted labels. Verification - Import authorized updates and invalid items together. - Attempt a cross-tenant item and verify safe denial. Deliverables - Per-item outcome contract. Rollout and recovery: Block imports with tenant-boundary regressions before expanding item types. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-105 — Checkpoint item progress without changing retry outcomes **Bug · High priority · Advanced** noCV practice brief v5 · BAPIBULK-105 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 40% · Database engineering 30% · Distributed systems 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 worker restart reapplies successful items and duplicates side effects. Acceptance criteria - Persist committed item outcomes with operation identity. - Resume only incomplete items. - Return the original result for exact processed-item replay. Implementation constraints - Bound item batches and transaction duration. Verification - Interrupt after a committed batch and resume. - Retry a successful item and verify unchanged effects. Deliverables - Resumable bulk processor. Rollout and recovery: Retain checkpoints and immutable terminal item outcomes. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-106 — Define cancellation after some items have committed **Task · High priority · Advanced** noCV practice brief v5 · BAPIBULK-106 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 60% · Distributed systems 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. Clients assume cancelling an import undoes all previous item updates. Acceptance criteria - Document cancellation as stopping future work unless compensation exists. - Preserve committed outcomes. - Resolve cancellation-versus-completion races explicitly. Implementation constraints - Do not silently roll back unrelated later changes. Verification - Cancel after two items commit. - Race cancellation with final completion and produce one terminal state. Deliverables - Cancellation contract. Rollout and recovery: Expose committed counts before accepting cancellation. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-107 — Paginate bulk item outcomes with stable ordering **Task · Medium priority · Intermediate** noCV practice brief v5 · BAPIBULK-107 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Process bounded work. Depends on: BAPIBULK-104, BAPIBULK-105. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · Database engineering 30% · 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. Large result lists exceed response limits and change order while the client reads them. Acceptance criteria - Use stable operation-scoped ordering. - Bound page sizes and cursor lifetime. - Bind cursors to tenant, operation, and filter. Implementation constraints - Do not place raw item payloads in cursors. Verification - Read all outcomes without duplicates. - Reject a cursor reused for another operation or tenant. Deliverables - Outcome pagination endpoint. Rollout and recovery: Keep terminal result pages immutable within retention. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. ### Support clients Expose safe progress and lifecycle guidance. #### BAPIBULK-108 — Expose progress that does not imply unobserved completion **Story · Medium priority · Intermediate** noCV practice brief v5 · BAPIBULK-108 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-106, BAPIBULK-107. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 70% · Data 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. The UI computes ninety-nine percent from queued jobs even when several items are unresolved. Acceptance criteria - Report accepted, committed, failed, and pending counts. - Reconcile totals under declared semantics. - Show unknown progress when observations are incomplete. Implementation constraints - Avoid a fabricated precise completion estimate. Verification - Display partial progress from known outcomes. - Detect inconsistent counters and return an unavailable projection. Deliverables - Safe progress projection. Rollout and recovery: Use authoritative counters and stop polling on terminal states. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-109 — Choose atomic or partial bulk semantics for dependent items **Task · High priority · Expert** noCV practice brief v5 · BAPIBULK-109 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-104, BAPIBULK-106, BAPIBULK-108. 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. Some imports contain parent and child catalog records, making arbitrary independent item processing unsafe. Acceptance criteria - Define the supported dependency boundary. - Compare whole-request atomicity, ordered groups, and independent items. - Document transaction, recovery, and client complexity tradeoffs. Implementation constraints - Bound the decision to the synthetic catalog use case. Verification - Import a valid parent-child group. - Reject or explicitly report a missing-parent group under the chosen semantics. Deliverables - Bulk semantics decision record. Rollout and recovery: Start with the smallest supported grouping and reject unsupported dependency patterns. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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. #### BAPIBULK-110 — Publish a bulk client example covering timeout and partial failure **Chore · Low priority · Foundational** noCV practice brief v5 · BAPIBULK-110 · Asynchronous bulk API contract Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Support clients. Depends on: BAPIBULK-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · API design 50%. 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 have only a happy-path example that treats HTTP acceptance as completion. Acceptance criteria - Show admission retry with one idempotency key. - Poll to a terminal operation state. - Inspect item errors and retained committed results. Implementation constraints - Use local mock data and no credentials. Verification - Run a successful example. - Run timeout, partial failure, and cancellation examples without duplicate submissions. Deliverables - Executable bulk client guide. Rollout and recovery: Version the example with the operation contract. Project prerequisites: Create a local API and worker double with synthetic catalog records and controlled interruption points. Engineer value: Practice asynchronous resource contracts, partial outcomes, and idempotent operations. Company value: Provide predictable bulk integration behavior without ambiguous success or repeated effects. 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.