# 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. ## SYNC — Inventory sync that survives a vendor outage A fictional retailer receives stock from two vendor warehouses. The vendor API paginates snapshots and emits change events, but retries and deleted products have caused unexplained stock drift. Work against a local vendor simulator. **Field:** Integrations. **Suggested stack:** TypeScript, NestJS, PostgreSQL, BullMQ. **Engineer value:** Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. **Company value:** Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. **Delivery agreement:** A simulated vendor connector, reconciliation workflow, drift report, and outage runbook. ### Setup prerequisites - Create a local vendor API simulator with cursor pages and stock events. - Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. ### Understand vendor identity and data Validate external records before affecting stock. #### SYNC-101 — Validate vendor stock records at the adapter boundary **Task · Medium priority · Foundational** noCV practice brief v5 · SYNC-101 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand vendor identity and data. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 75 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 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. Pattern topics: Adapter (refactor). Adapter — Refactor: Keep vendor payloads outside the internal stock model; compare a small mapping function with an object adapter while preserving boundary validation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The vendor sent quantity as an empty string and the importer stored zero, hiding a data problem. Validate a versioned stock response before mapping it into internal records. Acceptance criteria - Records require vendor item ID, warehouse ID, nonnegative integer quantity, revision, and updated timestamp. - Missing, empty, fractional, or out-of-range quantities are rejected with a safe record reference. - Unknown optional vendor fields do not silently become internal domain fields. Implementation constraints - Keep vendor DTOs separate from internal stock types. Verification - Accept a valid zero-stock record and a positive quantity record. - Reject empty-string, negative, fractional, and unsafe-integer quantities without writing stock. Deliverables - Vendor response schema and malformed-record fixtures Rollout and recovery: Start validation in the simulator; malformed records go to an inspection queue rather than defaulting to zero. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-102 — Map vendor items without assuming SKUs are globally unique **Bug · High priority · Intermediate** noCV practice brief v5 · SYNC-102 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Understand vendor identity and data. Depends on: SYNC-101. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Security 30% · Database 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. Two tenants both sell SKU CABLE-2M, and a mapping lookup updates the wrong stock row. Scope vendor mappings by tenant, connector, warehouse, and vendor item identity. Acceptance criteria - Mapping lookup always requires server-derived tenant and connector scope. - Unique constraints prevent duplicate mapping identities within that scope. - Unmapped or ambiguous items are quarantined and do not update a guessed SKU. Implementation constraints - Treat display SKU as mutable metadata, not a durable identity. Verification - Map identical SKU text for two tenants and verify each stock update stays in its own tenant. - Supply an unmapped vendor item and confirm no stock mutation and an inspectable mapping issue. Deliverables - Scoped mapping repository and cross-tenant tests Rollout and recovery: Backfill explicit mapping identities before enabling updates; pause connectors with unresolved mapping conflicts. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. ### Ingest changes safely Handle cursors, duplicates, disorder, and API limits. #### SYNC-103 — Resume a paginated snapshot from the last committed page **Story · High priority · Advanced** noCV practice brief v5 · SYNC-103 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-102. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Database engineering 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 importer crashes on page four and restarts from page one, occasionally skipping records because the cursor is saved before page writes finish. Couple the checkpoint to the page commit. Acceptance criteria - A page and its next cursor commit atomically within one tenant-scoped transaction. - Replaying a committed page is idempotent by snapshot and record identity. - Expired cursors leave the current attempt incomplete and start a separately identified snapshot rather than mixing pages. Implementation constraints - Store snapshot identity alongside opaque vendor cursors. - Do not infer cursor order from cursor text. Verification - Inject a failure between page writes and checkpoint and verify neither commits. - Resume after a successful page commit and assert no missing or duplicate stock records. Deliverables - Transactional snapshot checkpointing and restart scenarios Rollout and recovery: Run an initial snapshot in shadow storage; activate only a fully completed snapshot version. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-104 — Ignore stale stock events while retaining their delivery record **Bug · High priority · Advanced** noCV practice brief v5 · SYNC-104 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-102. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Data engineering 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. Stock revision 42 sets quantity to 7, then delayed revision 41 resets it to 12. Compare vendor revisions atomically and record the stale delivery without changing current stock. Acceptance criteria - A higher revision replaces the current quantity and records its source event. - Equal revisions with equal content are idempotent; equal revisions with different content create a conflict. - Lower revisions remain in delivery history and cannot overwrite current stock. Implementation constraints - Define revision ordering in the adapter contract; timestamps alone are insufficient. Verification - Apply revisions 41, 42, and 41 and verify final quantity from 42. - Race two updates and send conflicting content under one revision; verify monotonic state and a visible conflict. Deliverables - Revision-guarded stock updates and out-of-order fixtures Rollout and recovery: Enable revision checks before consuming events; quarantine vendors that cannot supply the required ordering contract. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-105 — Stop concurrent refreshes from multiplying vendor requests **Bug · Medium priority · Intermediate** noCV practice brief v5 · SYNC-105 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Distributed systems 30% · 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. Five scheduled jobs refresh the same connector after a restart and exceed the vendor limit. Add one active refresh identity per connector and bounded Retry-After handling. Acceptance criteria - Concurrent refresh triggers converge on one active connector job. - 429 responses follow capped Retry-After behavior within an overall refresh deadline. - A failing connector does not prevent another tenant connector from progressing. Implementation constraints - Use deterministic job IDs and an injected clock in timing tests. - Do not hold a database transaction during vendor waits. Verification - Submit five identical triggers and assert one vendor page sequence. - Throttle one connector and verify another completes while the first stops at its deadline. Deliverables - Refresh coordination and rate-limit simulator scenarios Rollout and recovery: Set conservative per-connector concurrency and expose pause/resume; rollback by pausing ingestion without clearing checkpoints. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-106 — Distinguish a discontinued item from an item missing on one page **Story · High priority · Expert** noCV practice brief v5 · SYNC-106 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Ingest changes safely. Depends on: SYNC-103, SYNC-104. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 50% · Data engineering 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. A transient missing page made hundreds of products look deleted. Apply absence-based tombstones only after a complete authoritative snapshot, while preserving explicit deletion events. Acceptance criteria - An incomplete snapshot cannot discontinue items through absence. - A completed snapshot marks only previously mapped items absent from that exact vendor scope as candidates for discontinuation. - A newer explicit stock event received during snapshot ingestion is not overwritten by an older absence decision. Implementation constraints - Record the snapshot consistency boundary and event watermark. - If the simulator cannot guarantee a consistency boundary, surface uncertainty and require review. Verification - Fail the final page and verify no absence-based tombstones are applied. - Deliver a newer event during snapshot ingestion and confirm finalization preserves it or reports a review conflict. Deliverables - Snapshot finalization policy and deletion/event race tests Rollout and recovery: Generate discontinuation proposals first; enable automatic tombstones only for connectors with the documented snapshot guarantee. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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 and operate Find drift and apply only reviewable corrections. #### SYNC-107 — Produce a stock drift report before applying corrections **Story · Medium priority · Foundational** noCV practice brief v5 · SYNC-107 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-103. Difficulty: Foundational. Estimated focused work: 90 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. Operations sees different stock in the vendor portal and local app but has no item-level comparison. Add a read-only report against a completed synthetic snapshot. Acceptance criteria - The report lists local quantity, vendor quantity, revision, warehouse, and difference for each mapped item. - Equal items can be hidden without changing discrepancy totals. - Unmapped items and incomplete snapshots are labeled separately from confirmed quantity drift. Implementation constraints - Include tenant and connector labels only within authorized operator scope. Verification - Compare a fixture with one equal, one mismatched, and one unmapped item. - Attempt a report from an incomplete snapshot and verify no discrepancy is presented as a confirmed correction. Deliverables - Read-only reconciliation report and comparison fixture Rollout and recovery: Expose reports before correction actions; disable report generation when snapshot authority cannot be established. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-108 — Apply an approved reconciliation plan only if stock is unchanged **Story · High priority · Expert** noCV practice brief v5 · SYNC-108 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-106, SYNC-107. Difficulty: Expert. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 40% · Database engineering 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. An operator reviews a drift report, but a fresh vendor event arrives before Apply. Bind corrections to the reviewed before-state so approval cannot overwrite a newer update. Acceptance criteria - A plan records each item before revision, proposed quantity, source snapshot, and a canonical plan digest. - Application verifies permission, plan digest, and every current before revision in one transaction. - Any stale item blocks the plan with a conflict; approved applications record an append-only actor audit. Implementation constraints - Choose all-or-nothing application for this bounded exercise. - Recovery creates a new reviewed plan; it does not rewrite the old approval. Verification - Apply an unchanged plan and verify exact proposed quantities and one audit record. - Advance one item revision before apply and confirm no item in the plan changes. Deliverables - Reviewable correction plan and stale-approval tests Rollout and recovery: Allow only explicitly authorized operators to apply plans; keep a read-only report mode available if conflicts spike. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-109 — Surface a stale connector without logging vendor payloads **Task · Medium priority · Intermediate** noCV practice brief v5 · SYNC-109 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-105. Difficulty: Intermediate. Estimated focused work: 105 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Integrations 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. A connector has not completed a refresh for six hours, yet its status is green because the last HTTP request succeeded. Define freshness from completed ingestion checkpoints. Acceptance criteria - Status exposes last complete snapshot, latest accepted event, current attempt, and safe failure category separately. - A configured freshness threshold marks stale data without claiming the connector is healthy from HTTP success alone. - Metrics and logs exclude tokens, raw payloads, and customer-specific product descriptions. Implementation constraints - Use UTC and an injected clock for freshness. - Keep metrics cardinality bounded; item IDs belong in scoped diagnostics. Verification - Advance the clock past the threshold after a partial refresh and verify stale status. - Cause a vendor error containing a token marker and confirm it is absent from all normal diagnostics. Deliverables - Connector health projection and safe diagnostic tests Rollout and recovery: Publish status before enabling notifications; reset health only after a complete qualifying ingestion checkpoint. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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. #### SYNC-110 — Rehearse recovery from a vendor schema change **Task · High priority · Advanced** noCV practice brief v5 · SYNC-110 · Inventory sync that survives a vendor outage Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover and operate. Depends on: SYNC-108, SYNC-109. Difficulty: Advanced. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Integrations 60% · Quality engineering 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 vendor replaces quantity with availableQuantity in its next API version. Demonstrate that the connector fails visibly, can resume with a new adapter, and preserves the old run history. Acceptance criteria - Unexpected required-field changes stop affected ingestion without defaulting stock values. - A versioned adapter can be selected per connector after contract fixtures pass. - Recovery resumes from a compatible checkpoint or starts a new snapshot with an explicit reason. Implementation constraints - Keep both schema fixtures local and versioned. - Do not reinterpret an old cursor under an incompatible API version. Verification - Switch the simulator schema mid-run and confirm no corrupt stock or silent success. - Upgrade the adapter, reconcile a complete new snapshot, and reproduce the documented recovery path. Deliverables - Schema-change contract cases and connector recovery runbook Rollout and recovery: Canary the new adapter on one synthetic connector; revert adapter selection and pause writes if contract errors recur. Project prerequisites: Create a local vendor API simulator with cursor pages and stock events. Use synthetic tenants, SKUs, and warehouse records; no vendor account is required. Engineer value: Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure. Company value: Inspect whether integration changes protect inventory correctness and give operators a clear recovery path. 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.