# 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. ## CHECK — Checkout regressions the team can reproduce A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage. **Field:** Quality engineering. **Suggested stack:** TypeScript, Playwright, HTTP, SQL. **Engineer value:** Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. **Company value:** Review whether a test suite catches business regressions and explains failures without creating noisy release gates. **Delivery agreement:** A local checkout fixture, regression suite, failure artifacts, and release-gate policy. ### Setup prerequisites - Create or provide a local checkout fixture application. - Model products, tax rules, inventory, and a payment-provider double using synthetic data. ### Define the checkout contract Establish realistic fixtures and observable expected behavior. #### CHECK-101 — Write the smallest cart fixture that catches a pricing regression **Task · Medium priority · Foundational** noCV practice brief v5 · CHECK-101 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the checkout contract. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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 only test product costs 100.00, so fractional-price bugs pass. Define a reusable fixture with 19.99 and 0.10 items, quantities, tax, and one promotion. Acceptance criteria - Expected totals use integer minor units with the rounding stage explicitly documented. - The fixture can reset to an identical starting cart between runs. - Expected values are stated independently of the checkout implementation. Implementation constraints - Use a fictional currency with two decimal places for this fixture. Verification - Check the documented two-item total by an independent integer calculation. - Change quantity from one to three and verify the expected amount changes without fixture state leaking between runs. Deliverables - Synthetic cart fixture and pricing expectation table Rollout and recovery: Add the fixture as a separate suite seed; reset by run ID instead of clearing shared environments. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-102 — Replace timing sleeps in the checkout happy path **Chore · Medium priority · Foundational** noCV practice brief v5 · CHECK-102 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define the checkout contract. Depends on: CHECK-101. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. Checkout passes locally but fails in CI after a fixed 500 ms sleep. Wait for user-visible readiness and assert the final receipt against the fixture. Acceptance criteria - The happy path contains no arbitrary timing sleeps. - Selectors use accessible roles and names where the interface exposes them. - The receipt order reference and charged amount match the created order. Implementation constraints - Wait on observable state transitions, not broad network-idle heuristics. Verification - Run with the payment double delayed by several deterministic values. - Keep the submit button disabled and verify the test times out at an actionable readiness assertion. Deliverables - Stable checkout browser test and selector rationale Rollout and recovery: Run beside the existing happy path for comparison, then remove the redundant sleep-based version. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. ### Exercise costly failure paths Cover money, duplication, inventory, and access boundaries. #### CHECK-103 — Cover discount and tax rounding at the documented boundary **Bug · High priority · Intermediate** noCV practice brief v5 · CHECK-103 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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 10% promotion on three 19.99 items produces a one-cent difference between the cart and receipt. Add cases that pin down order-level versus line-level rounding. Acceptance criteria - Tests use the agreed line-discount-then-tax rule and include a half-cent boundary. - Cart, order, and payment request totals must agree in minor units. - A discount greater than the eligible subtotal is rejected or capped according to an explicit contract. Implementation constraints - Do not reproduce the production rounding helper in expected-value code. Verification - Assert concrete expected totals for zero, one, and three eligible items. - Introduce a round-at-order-end defect in the fixture and show the relevant case fails. Deliverables - Pricing boundary matrix and regression tests Rollout and recovery: Gate pricing changes with these deterministic cases; update expectations only with a reviewed rule change. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-104 — Prove a lost payment response cannot create two orders **Story · High priority · Advanced** noCV practice brief v5 · CHECK-104 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. The payment double accepts a charge but drops the response. The customer clicks Try again. The regression must verify one charge and one order, not just a success banner. Acceptance criteria - The double can accept a payment and deterministically lose the first response. - Retry preserves the intended checkout idempotency identity. - Assertions inspect order count, charge count, amount, and final customer-visible status. Implementation constraints - Record provider requests in the local double; do not connect a real payment account. Verification - Run a lost-response-then-retry case and assert one durable charge and one order. - Use a fixture defect that rotates the idempotency key on retry and confirm the regression detects the duplicate. Deliverables - Lost-response payment scenario and durable-state assertions Rollout and recovery: Add to checkout gates with bounded local timeouts; keep provider behavior versioned with the test. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-105 — Test the last-item race without relying on lucky timing **Story · High priority · Expert** noCV practice brief v5 · CHECK-105 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-101. Difficulty: Expert. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 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. Two customers can both buy the last unit when the stock check and reservation are separate. Build a barrier-controlled concurrency case around a single remaining item. Acceptance criteria - Two isolated customers reach the reservation boundary before either proceeds. - Exactly one reservation succeeds and inventory never becomes negative. - The losing checkout receives a recoverable stock message and creates no captured payment. Implementation constraints - Use an explicit local test barrier, not sleep-based synchronization. - Assert final database and provider states after both requests settle. Verification - Repeat the controlled race with each customer released first. - Run against a deliberately non-atomic fixture reservation and demonstrate that the invariant assertion fails. Deliverables - Deterministic inventory race harness and invariant report Rollout and recovery: Keep the barrier available only in local test composition; add the regression before changing reservation code. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-106 — Check that one customer cannot open another receipt **Bug · High priority · Intermediate** noCV practice brief v5 · CHECK-106 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise costly failure paths. Depends on: CHECK-102. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Security 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 receipt screen fetches an order by URL ID. Add an authorization regression covering both the page and its backing endpoint with two synthetic customer accounts. Acceptance criteria - An owner can load their receipt with the expected line items. - Another customer and an anonymous session cannot retrieve receipt details by changing the order ID. - Denied responses and browser artifacts contain no customer address or item details. Implementation constraints - Treat order IDs as discoverable; obscurity is not the access rule. Verification - Open the same order using owner, second-customer, and logged-out contexts. - Attempt the direct receipt API request and inspect its body for leaked fields. Deliverables - Receipt access matrix and browser/API denial tests Rollout and recovery: Make the access checks a required checkout gate; quarantine artifacts if a regression exposes fixture-sensitive fields. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. ### Turn checks into a useful release gate Keep runs isolated, diagnosable, and honest about coverage. #### CHECK-107 — Verify checkout errors can be corrected using a keyboard **Story · Medium priority · Intermediate** noCV practice brief v5 · CHECK-107 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · Accessibility 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. An invalid postal code turns the field red but focus remains on the submit button and no message is announced. Add keyboard and semantic checks for error recovery. Acceptance criteria - Submission exposes a text error associated with the invalid field. - Keyboard users can reach the field, correct it, and complete checkout without pointer input. - The error summary links to the field and disappears or updates after correction. Implementation constraints - Record a short manual screen-reader check; automated role assertions alone do not establish full accessibility. Verification - Tab through a failed then corrected checkout and verify focus placement. - Remove the error association in the fixture and confirm the semantic regression fails. Deliverables - Keyboard regression and manual assistive-technology checklist Rollout and recovery: Include keyboard checks in the browser suite; retain manual accessibility coverage for release reviews. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-108 — Give each parallel test its own stock and customer records **Chore · High priority · Advanced** noCV practice brief v5 · CHECK-108 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-104, CHECK-105, CHECK-106. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · 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 suite passes alone but fails in parallel because every worker buys the same seeded SKU. Namespace mutable fixtures and make cleanup safe when a worker crashes. Acceptance criteria - Each test run receives unique customer, cart, inventory, and provider namespaces. - Cleanup deletes only records owned by that run and can be repeated safely. - A crashed run is discoverable by expiry metadata without clearing records from active runs. Implementation constraints - Use a controllable clock for expiry checks. - Avoid global truncate operations. Verification - Run two full suites concurrently and verify their record IDs never overlap. - Crash one run, expire it, and confirm cleanup preserves the other run and unowned sentinel data. Deliverables - Fixture lifecycle helpers and parallel-isolation tests Rollout and recovery: Migrate tests to namespaced seeds before increasing CI concurrency; disable expired-run cleanup if ownership metadata is missing. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-109 — Capture enough failure detail without storing checkout secrets **Task · Medium priority · Intermediate** noCV practice brief v5 · CHECK-109 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-108. Difficulty: Intermediate. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 60% · Privacy engineering 20% · 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 failure report has only a screenshot, while a trace includes full authorization headers. Define a bounded artifact bundle that helps reproduce a failure safely. Acceptance criteria - A failed case records fixture seed, run ID, safe request IDs, assertion, and application revision. - Authorization, payment tokens, and full address values are absent from stored artifacts. - Artifact filenames and retention rules are deterministic and scoped to the run. Implementation constraints - Use synthetic credentials but still prove the redaction boundary. Verification - Fail a payment case and reconstruct it from the recorded seed and revision. - Insert secret marker strings into headers and form fields and scan every produced artifact for them. Deliverables - Safe failure artifact bundle and retention policy Rollout and recovery: Replace unrestricted tracing with the safe bundle; disable unsafe artifact types until sanitization is verified. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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. #### CHECK-110 — Separate release blockers from tests awaiting investigation **Task · Medium priority · Advanced** noCV practice brief v5 · CHECK-110 · Checkout regressions the team can reproduce Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Turn checks into a useful release gate. Depends on: CHECK-103, CHECK-107, CHECK-109. Difficulty: Advanced. Estimated focused work: 135 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 80% · Platform 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 team reruns the whole suite until it turns green. Define a gate that retains the first failure, identifies explicit quarantines, and does not hide payment or access regressions. Acceptance criteria - Payment, inventory, pricing, and authorization regressions remain blocking even after a successful retry. - Quarantined cases require an owner, issue reference, reason, and expiry date. - Reports show first-attempt outcomes, retry outcomes, and omitted coverage separately. Implementation constraints - Use retries for diagnosis rather than rewriting the original result. Verification - Run a fail-then-pass fixture and verify its first failure remains visible and blocking when critical. - Use an expired quarantine and confirm gate evaluation fails with the owning issue reference. Deliverables - Release-gate evaluator and quarantine policy examples Rollout and recovery: Evaluate the new policy against recorded fixture runs before enabling enforcement; rollback policy configuration without deleting result history. Project prerequisites: Create or provide a local checkout fixture application. Model products, tax rules, inventory, and a payment-provider double using synthetic data. Engineer value: Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures. Company value: Review whether a test suite catches business regressions and explains failures without creating noisy release gates. 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.