# 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. ## BILL — Close the billing reconciliation gap A fictional subscription service invoices in USD and EUR. Finance currently compares a payment-provider CSV with database exports; late refunds and retried imports make the monthly close unreliable. Work on synthetic ledger entries only. **Field:** Backend. **Suggested stack:** TypeScript, NestJS, PostgreSQL, BullMQ. **Engineer value:** Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. **Company value:** Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. **Delivery agreement:** Ten bounded tickets over three phases; choose an individual issue or deliver the complete synthetic reconciliation service with a finance handoff. ### Setup prerequisites - REST APIs - SQL transactions - Integer money representation ### Reliable intake Make settlement imports inspectable and repeatable. #### BILL-101 — Reject ambiguous settlement amounts before import **Task · High priority · Foundational** noCV practice brief v5 · BILL-101 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 80% · 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. Finance received a row containing 12,34 EUR beside rows using 12.34. The importer currently guesses the separator and silently books the wrong amount. Acceptance criteria - Accept documented decimal-dot amounts and convert them to integer minor units. - Reject mixed separators, excess precision, and unsupported currency codes with row numbers. - A rejected file creates no settlement rows. Implementation constraints - The exercise supports USD and EUR, both with two minor digits; do not use floating-point arithmetic. Verification - Import 0.01, 12.34, and a negative refund amount exactly. - Reject 12,34 and 1.005 without partial writes. Deliverables - Settlement input contract and parser regression fixtures Rollout and recovery: Run validation against saved synthetic files before enabling persistence; revert the parser behind the importer flag. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-102 — Make repeated settlement uploads converge on one batch **Bug · High priority · Intermediate** noCV practice brief v5 · BILL-102 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: BILL-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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. An upload times out after committing. Finance retries the same file and sees every payout twice. Two browser tabs can also submit it together. Acceptance criteria - Identical bytes within one merchant resolve to the same batch identity. - Concurrent submissions create one committed batch and one set of rows. - A different file with a reused client request key returns a conflict. Implementation constraints - Scope deduplication to the merchant and retain the original content hash. Verification - Submit the same file concurrently and compare persisted counts. - Reuse a request key with a changed amount and assert conflict. Deliverables - Idempotent import command and concurrency reproduction Rollout and recovery: Enable for one synthetic merchant; rollback routing while preserving committed batch identities. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-103 — Add a finance-readable import rejection report **Story · Medium priority · Foundational** noCV practice brief v5 · BILL-103 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Reliable intake. Depends on: BILL-101. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Backend 30% · Security 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. Support currently pastes a stack trace into the finance channel when a file fails. Finance needs row-level corrections without exposure to provider tokens or infrastructure details. Acceptance criteria - Report row number, field, stable reason code, and a plain-English correction hint. - Cap the report at 100 errors and state the total omitted count. - Require merchant authorization before downloading a report. Implementation constraints - Do not echo complete source rows or payment instrument data. Verification - Show distinct corrections for missing reference and invalid currency. - Deny another merchant and confirm a token-like cell is absent. Deliverables - Bounded rejection report endpoint and example response Rollout and recovery: Expose reports for new imports first; disable downloads without deleting import audit records. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. ### Explain the balance Match settlements and preserve unresolved differences. #### BILL-104 — Match settlement lines without combining currencies **Story · High priority · Intermediate** noCV practice brief v5 · BILL-104 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-102. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Database 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. Provider reference pay_204 exists on a EUR invoice, but a malformed USD settlement row shares the reference. The current join marks the invoice paid. Acceptance criteria - Match only within merchant, reference, and currency boundaries. - Represent matched, unmatched, and conflicting lines separately. - Calculate batch totals independently for each currency. Implementation constraints - A reference match with a currency mismatch is a conflict, never an exchange-rate conversion. Verification - Match a complete EUR batch to its invoices. - Keep same-reference USD and cross-merchant rows unresolved. Deliverables - Reconciliation query and currency-conflict fixture Rollout and recovery: Compare dry-run classifications with the synthetic finance baseline before switching reports. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-105 — Carry partial refunds across settlement days **Bug · High priority · Advanced** noCV practice brief v5 · BILL-105 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 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. A 100.00 charge receives refunds of 20.00 on Monday and 15.00 on Thursday. The report subtracts only the latest refund, overstating net revenue by 20.00. Acceptance criteria - Net the charge against all distinct posted refunds in the selected cutoff. - Keep pending refunds visible but outside settled totals. - Flag cumulative refunds above the captured amount without silently clipping them. Implementation constraints - Preserve each provider refund identity and posting timestamp; never overwrite the original charge. Verification - Assert net 65.00 after both refunds and 80.00 at Monday cutoff. - Replay a refund and inject an excess refund; check deduplication and conflict. Deliverables - Append-only refund matching change and cutoff examples Rollout and recovery: Recompute a shadow report for one month; retain the previous report revision for comparison. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-106 — Record discrepancy decisions without editing source entries **Story · Medium priority · Intermediate** noCV practice brief v5 · BILL-106 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Explain the balance. Depends on: BILL-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Backend 60% · Security 20% · 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. Finance has confirmed that a 0.03 difference is a provider fee adjustment. They need to explain it without changing the settlement CSV or marking every mismatch resolved automatically. Acceptance criteria - An authorized reviewer can append a reason and decision to one discrepancy. - Concurrent decisions against the same revision produce one success and one conflict. - Reports show the original difference and complete decision history. Implementation constraints - A decision changes review state, not the immutable amounts or provider provenance. Verification - Resolve and reopen a discrepancy while preserving both decisions. - Reject stale revisions and an actor lacking finance-review permission. Deliverables - Discrepancy decision API and history contract Rollout and recovery: Gate the command to a test finance role; disable writes while keeping history readable on rollback. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. ### Close and recover Make runs reproducible and safe to operate. #### BILL-107 — Freeze a close report against a reproducible cutoff **Task · High priority · Expert** noCV practice brief v5 · BILL-107 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-105, BILL-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Backend 40% · Data 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. The April report changed after a late settlement arrived in May. Finance needs to explain what was known at close while still showing corrections in a new revision. Acceptance criteria - Freeze source identities, cutoff, calculation version, and report hash for a close revision. - Later imports cannot mutate the frozen report. - A correction creates a new linked revision with explicit differences. Implementation constraints - Distinguish provider effective time from system receipt time; document which governs inclusion. Verification - Regenerate a frozen revision and compare canonical hashes. - Import a backdated settlement after close and prove the old revision is unchanged. Deliverables - Versioned close report design, implementation, and correction walkthrough Rollout and recovery: Introduce revisioned closes in parallel with the current export; retain old readers until reconciliation agrees. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-108 — Recover an import after the queue acknowledgement is lost **Bug · High priority · Advanced** noCV practice brief v5 · BILL-108 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-102, BILL-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Backend 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. The database commits an accepted batch and the API process exits before enqueueing reconciliation. The UI remains on Processing until someone runs SQL manually. Acceptance criteria - Accepted batch and dispatch intent commit atomically. - Restarted dispatch delivers pending work with a deterministic job identity. - Repeated delivery produces the same reconciliation result without duplicate entries. Implementation constraints - Keep provider payloads out of queue metadata; use a durable batch identifier. Verification - Interrupt after database commit and recover through the dispatcher. - Deliver the same job twice and compare the ledger and audit counts. Deliverables - Transactional dispatch path and crash-recovery reproduction Rollout and recovery: Start dispatch in observe mode, then enable pending batches; pause dispatch to rollback without losing intent. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-109 — Alert when a merchant close is blocked by stale imports **Chore · Medium priority · Intermediate** noCV practice brief v5 · BILL-109 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · 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. Operations sees a healthy API while three accepted imports have made no progress for 45 minutes. Finance discovers the blockage at the end of the day. Acceptance criteria - Expose accepted-to-completed age and counts by bounded processing state. - Alert after the oldest accepted batch exceeds 15 minutes for two observations. - The runbook identifies the batch safely and distinguishes retryable from invalid input failures. Implementation constraints - Avoid merchant IDs, file names, and references as metric labels. Verification - Advance a controlled clock to trigger a stale-batch alert. - Confirm a rejected file does not trigger queue-lag paging. Deliverables - Metrics, alert rule, and import recovery runbook Rollout and recovery: Observe alerts for one synthetic close cycle before enabling paging; disable the rule if it pages on rejected files. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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. #### BILL-110 — Paginate the discrepancy export during a large close **Task · Medium priority · Advanced** noCV practice brief v5 · BILL-110 · Close the billing reconciliation gap Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Close and recover. Depends on: BILL-107. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Performance engineering 40% · Backend 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. A synthetic close with 250,000 discrepancies exhausts API memory because the export loads every row. Finance also receives spreadsheet formulas when a reference begins with an equals sign. Acceptance criteria - Stream a stable report revision in bounded pages without omissions or duplicate rows. - Neutralize spreadsheet formula prefixes in text cells. - Abort export promptly on client disconnect and preserve authorization on resume. Implementation constraints - Use a repeatable 250,000-row synthetic benchmark and report peak memory rather than assuming scalability. Verification - Compare streamed row identities with the frozen report count. - Export malicious-looking references and cancel halfway through; check escaping and cleanup. Deliverables - Bounded CSV export and benchmark report Rollout and recovery: Offer the streamed export alongside the old limit; rollback the route while retaining report revisions. Project prerequisites: REST APIs SQL transactions Integer money representation Engineer value: Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary. Company value: Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted. 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.