# 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. ## BBILL — Payment-provider reconciliation adapter A fictional software vendor changes payment providers. Its application must tolerate unknown outcomes, signed callbacks, refunds, and inconsistent settlement reports. **Field:** Integrations. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice idempotent integrations, state reconciliation, and provider migration. **Company value:** Provide a reviewable adapter design that protects order consistency and recovery. **Delivery agreement:** Deliver local provider contracts and reconciliation rehearsals; no live money or provider accounts. ### Setup prerequisites - Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. ### Define provider semantics Model identities and state transitions. #### BBILL-101 — Map provider payment states to explicit order transitions **Task · Medium priority · Foundational** noCV practice brief v5 · BBILL-101 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define provider semantics. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Backend 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. Two provider status names are currently treated as equivalent even though only one confirms collection. Acceptance criteria - List provider states and allowed transitions. - Represent pending and unknown separately. - Reject impossible terminal reversals. Implementation constraints - Keep provider status distinct from local order status. Verification - Map successful and pending examples. - Reject an unsupported state without marking an order paid. Deliverables - State mapping contract. Rollout and recovery: Review mapping before accepting callbacks. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-102 — Bind payment creation retries to one local operation **Task · High priority · Advanced** noCV practice brief v5 · BBILL-102 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define provider semantics. Depends on: BBILL-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 50% · Integrations 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 timeout prompts the application to create a second payment. Acceptance criteria - Persist operation identity before dispatch. - Reuse identity for identical retries. - Reject conflicting payload reuse. Implementation constraints - Synthetic amounts use integer minor units. Verification - Retry a timed-out accepted request. - Reuse a key with another amount and verify rejection. Deliverables - Idempotent payment command. Rollout and recovery: Keep uncertain operations pending for reconciliation. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. ### Handle asynchronous results Process callbacks and unknown outcomes safely. #### BBILL-103 — Verify callback signatures before trusting event fields **Task · High priority · Intermediate** noCV practice brief v5 · BBILL-103 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 70% · Integrations 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 adapter currently reads order IDs before validating callbacks. Acceptance criteria - Verify raw bytes with the configured test key. - Enforce timestamp tolerance and key identity. - Reject malformed or unsigned bodies before processing. Implementation constraints - Never log signing secrets or full callback bodies. Verification - Accept a valid signed fixture. - Reject modified bytes and an expired timestamp. Deliverables - Callback verification boundary. Rollout and recovery: Reject unverifiable callbacks; retain safe failure counts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-104 — Apply duplicate and out-of-order payment callbacks idempotently **Bug · High priority · Advanced** noCV practice brief v5 · BBILL-104 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-102, BBILL-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Distributed systems 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 delayed pending callback overwrites an already-confirmed payment. Acceptance criteria - Deduplicate provider event identity. - Apply only allowed state transitions. - Record ignored stale events for diagnosis. Implementation constraints - Commit state and processed-event record atomically. Verification - Replay a successful callback twice. - Deliver pending after confirmed and preserve confirmation. Deliverables - Callback transition handler. Rollout and recovery: Adopt per synthetic merchant; pause on unresolved transition conflicts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-105 — Reconcile unknown creation outcomes by operation identity **Task · High priority · Advanced** noCV practice brief v5 · BBILL-105 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-102, BBILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 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. The provider accepted creation but the application lost the response. Acceptance criteria - Query the provider using the original operation identity. - Adopt the matching remote payment once. - Keep missing or mismatched results unresolved. Implementation constraints - Bound query retries and elapsed reconciliation time. Verification - Recover a matching accepted payment. - Reject a remote result with different amount or currency. Deliverables - Unknown-outcome reconciler. Rollout and recovery: Stop new attempts for unresolved operations; retry reconciliation explicitly. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-106 — Represent partial refunds without rewriting original payment facts **Story · High priority · Advanced** noCV practice brief v5 · BBILL-106 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Handle asynchronous results. Depends on: BBILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Backend 30% · Integrations 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 partial refund currently changes the original collected amount. Acceptance criteria - Append refund operations separately. - Limit cumulative confirmed refunds to the collected amount. - Distinguish requested, pending, and confirmed refund totals. Implementation constraints - Run against the local double only. Verification - Confirm two valid partial refunds. - Race excess refunds and verify the invariant holds. Deliverables - Refund state model. Rollout and recovery: Enable after payment reconciliation; retain failed requests for investigation. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. ### Recover discrepancies Reconcile records and rehearse migration. #### BBILL-107 — Import settlement rows with source-file provenance **Task · Medium priority · Intermediate** noCV practice brief v5 · BBILL-107 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-105, BBILL-106. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data engineering 60% · Integrations 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. Repeated report uploads create duplicate reconciliation entries. Acceptance criteria - Bind imports to file digest and provider report identity. - Deduplicate exact rows without losing source references. - Reject conflicting duplicate settlement identities. Implementation constraints - Use synthetic CSV and sanitize spreadsheet formula prefixes in exports. Verification - Import the same report twice. - Detect a changed amount under an existing settlement identity. Deliverables - Settlement import pipeline. Rollout and recovery: Stage reports before matching; preserve original synthetic report digests. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-108 — Explain settlement discrepancies without automatic repair **Story · High priority · Intermediate** noCV practice brief v5 · BBILL-108 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Data 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. Finance staff see only a mismatch count and cannot identify its cause. Acceptance criteria - Classify missing, amount, currency, and timing mismatches. - Link each discrepancy to local and provider identities. - Keep disputed records unchanged. Implementation constraints - Do not infer fraud or automatically move funds. Verification - Explain a timing difference and an amount mismatch. - Verify unknown discrepancies remain unresolved. Deliverables - Discrepancy report. Rollout and recovery: Use reports for reviewed repair; keep reconciliation read-only by default. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-109 — Design a provider cutover with in-flight payment ownership **Task · High priority · Expert** noCV practice brief v5 · BBILL-109 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-105, BBILL-108. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Integrations 30% · Distributed systems 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. Switching all traffic at once would send old payment lookups to the new provider. Acceptance criteria - Pin each operation to its original provider. - Define new-operation routing and rollback conditions. - Rehearse callbacks and refunds crossing the cutover boundary. Implementation constraints - Compare adapter complexity and reconciliation burden explicitly. Verification - Complete an old-provider payment after cutover. - Roll back new routing without reassigning existing operations. Deliverables - Cutover decision record and rehearsal. Rollout and recovery: Change only new-operation routing; retain both adapters until old obligations finish. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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. #### BBILL-110 — Document a safe manual replay of a rejected callback **Chore · Low priority · Foundational** noCV practice brief v5 · BBILL-110 · Payment-provider reconciliation adapter Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover discrepancies. Depends on: BBILL-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Integrations 40% · 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. Support needs to retry a corrected callback without bypassing verification. Acceptance criteria - Require original event identity and verified source. - Use the normal validation and idempotency path. - Record replay operator and reason. Implementation constraints - No direct database status edits. Verification - Replay a previously failed valid event. - Reject a replay with altered signed content. Deliverables - Callback replay runbook. Rollout and recovery: Keep replay scoped and audited; stop on conflicting operation facts. Project prerequisites: Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions. Engineer value: Practice idempotent integrations, state reconciliation, and provider migration. Company value: Provide a reviewable adapter design that protects order consistency and recovery. 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.