# 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. ## AMERGE — Synchronize offline equipment inspections without silent overwrites A fictional field team inspects equipment with intermittent connectivity. Two tablets can edit the same checklist and an old upload may restore a deleted finding. **Field:** Distributed systems. **Suggested stack:** TypeScript, PostgreSQL, HTTP. **Engineer value:** Practice offline synchronization, causal revisions and conflict resolution. **Company value:** Review whether field work survives disconnection without hiding conflicting observations. **Delivery agreement:** Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup. ### Setup prerequisites - Create two local client-state simulators and a synthetic inspection API. - Use fabricated notes and local attachment bytes. ### Define change identities Represent offline edits and authority boundaries. #### AMERGE-101 — Define offline change envelopes with stable client operation IDs **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-101 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · API design 30% · Mobile 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 tablet retries saved edits with new request IDs, so the server creates duplicate inspection findings. Acceptance criteria - Include operation ID, inspection ID, base revision and change type. - Keep device display name separate from identity. - Reject unknown envelope versions before mutation. Implementation constraints - Use generated disposable client identities. Verification - Replay the same synthetic change envelope twice. - Change content under the same operation ID and return conflict. Deliverables - Offline operation contract Rollout and recovery: Publish the envelope before enabling sync retries; keep incompatible operations in local pending state. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-102 — Require current inspection access before applying a queued offline change **Task · High priority · Intermediate** noCV practice brief v5 · AMERGE-102 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: AMERGE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Distributed systems 30% · Mobile 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 contractor loses project access while offline, then reconnects with a batch of previously authorized edits. Acceptance criteria - Reauthorize each target at synchronization time. - Reject revoked or cross-organization changes without partial hidden writes. - Return safe per-operation outcomes under the declared batch policy. Implementation constraints - Offline possession of data is not continuing write authority. Verification - Apply a queued edit for a still-authorized actor. - Revoke access before reconnect and verify no inspection mutation. Deliverables - Sync authorization boundary Rollout and recovery: Enable scope checks before bulk sync; retain rejected local operations for user review. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-103 — Distinguish independent checklist edits from conflicting edits **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-103 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Define change identities. Depends on: AMERGE-101, AMERGE-102. Difficulty: Foundational. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · System 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. The sync service treats every concurrent change as either a blanket overwrite or a blanket conflict. Acceptance criteria - Define fields that can merge independently. - Require explicit conflict when the same protected value diverges. - Document attachment and deletion conflict rules separately. Implementation constraints - Use a small fixed checklist; avoid a general-purpose merge language. Verification - Merge edits to two independent checklist items. - Edit the same item differently and preserve both proposed values as a conflict. Deliverables - Merge policy table and worked examples Rollout and recovery: Review the policy before automatic merging; keep unresolved fields on manual resolution. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. ### Synchronize and resolve Handle duplicates, conflicts and deletion safely. #### AMERGE-104 — Apply offline operations with a durable deduplication record **Story · Medium priority · Advanced** noCV practice brief v5 · AMERGE-104 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-101, AMERGE-102, AMERGE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 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 server applies a change, loses the response, then reapplies it after the tablet reconnects. Acceptance criteria - Commit operation identity and inspection mutation atomically. - Return the original safe outcome for identical retries. - Keep rejected authorization separate from accepted-operation history. Implementation constraints - Scope deduplication to the authorized client and operation identity. Verification - Drop the response after commit and retry to one revision. - Force transaction rollback and verify the operation remains retryable without a partial edit. Deliverables - Idempotent sync transaction Rollout and recovery: Canary one synthetic client; pause replay when canonical operation identity is inconsistent. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-105 — Preserve concurrent inspection findings as explicit conflicts **Task · Medium priority · Advanced** noCV practice brief v5 · AMERGE-105 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-103, AMERGE-104. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. Two inspectors change a safety finding from different base revisions and last-write-wins hides one observation. Acceptance criteria - Detect divergence from the declared base revision. - Persist both proposals and their operation identities. - Block authoritative resolution until a permitted resolution command chooses or combines them. Implementation constraints - Do not infer which observer is correct from arrival time. Verification - Submit conflicting changes in both arrival orders and retain equivalent conflict facts. - Attempt ordinary edit completion over an unresolved conflict and reject it. Deliverables - Conflict record model and order-invariance tests Rollout and recovery: Enable conflict capture before automatic reconciliation; leave existing ambiguous cases unresolved. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-106 — Resolve an inspection conflict against its current proposal set **Story · Medium priority · Intermediate** noCV practice brief v5 · AMERGE-106 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-105. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 30% · 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. A reviewer resolves a conflict while a third offline proposal arrives, silently discarding the new observation. Acceptance criteria - Bind resolution to the expected conflict revision and proposal identities. - Record resolution as an append-only fact. - Reject stale resolution without deleting proposals. Implementation constraints - Require the reviewer's current inspection permission. Verification - Resolve an unchanged two-proposal conflict. - Add a third proposal before commit and verify stale resolution conflicts. Deliverables - Guarded conflict resolution command Rollout and recovery: Canary synthetic review; reopen by appending a new conflict fact rather than editing history. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-107 — Keep deleted findings deleted when an old tablet reconnects **Task · High priority · Expert** noCV practice brief v5 · AMERGE-107 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Synchronize and resolve. Depends on: AMERGE-103, AMERGE-104, AMERGE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 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. A tablet that missed a deletion resubmits its old finding and recreates content the team intentionally removed. Acceptance criteria - Represent deletion with an ordered tombstone. - Reject stale recreation under the declared merge policy. - Define tombstone retention and resnapshot requirements. Implementation constraints - Avoid using wall-clock time alone to order deletion and recreation. Verification - Delete a finding and replay an older update. - Expire supported replay history in the simulator and require resnapshot rather than guessing. Deliverables - Tombstone protocol and stale-client cases Rollout and recovery: Deploy tombstones before cleanup; halt tombstone removal until the resnapshot contract is available. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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 interrupted synchronization Reconcile attachments and explain remaining conflicts. #### AMERGE-108 — Finalize offline attachments by verified content identity **Task · Medium priority · Advanced** noCV practice brief v5 · AMERGE-108 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-104, AMERGE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 50% · Distributed systems 30% · Mobile 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 inspection references a photo before its interrupted upload completes, producing broken evidence links in the field report. Acceptance criteria - Stage attachment uploads separately from finding references. - Finalize only exact verified object generation and content hash. - Keep incomplete attachments visible as pending without public links. Implementation constraints - Use synthetic images or byte fixtures; no personal photographs are needed. Verification - Complete a valid synthetic attachment and resolve its stable identity. - Interrupt upload or alter bytes and verify the finding cannot publish an invalid link. Deliverables - Attachment finalization contract Rollout and recovery: Canary local attachments; keep staged objects private and resume or discard only exact generations. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-109 — Resume inspection synchronization from a server-confirmed cursor **Task · Medium priority · Expert** noCV practice brief v5 · AMERGE-109 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-104, AMERGE-106, AMERGE-107, AMERGE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 60% · Mobile 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 tablet stores a local cursor before receiving server confirmation and skips updates after a crash. Acceptance criteria - Advance the local acknowledged cursor only after durable server outcome. - Bind cursor to inspection scope and sync generation. - Require resnapshot when the server cannot honor the retained history window. Implementation constraints - Use two client simulators with controlled interruption points. Verification - Crash during a sync page and resume without missing confirmed operations. - Use an expired or cross-scope cursor and reject incremental sync safely. Deliverables - Cursor recovery protocol and crash harness Rollout and recovery: Enable incremental sync after the resnapshot path passes; retain local pending operations until acknowledged. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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. #### AMERGE-110 — Show sync completion separately from resolved inspection conflicts **Task · Medium priority · Foundational** noCV practice brief v5 · AMERGE-110 · Synchronize offline equipment inspections without silent overwrites Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Recover interrupted synchronization. Depends on: AMERGE-106, AMERGE-108, AMERGE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Mobile 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. A tablet says all synced even though uploaded changes contain unresolved conflicts and a pending attachment. Acceptance criteria - Report transport acknowledgement, conflict state and attachment state separately. - Keep rejected operations visible with safe reasons. - Never equate uploaded data with an approved inspection. Implementation constraints - Use a local status projection with accessible plain-language labels. Verification - Display a fully acknowledged conflict-free synthetic inspection. - Acknowledge a conflicting batch and retain unresolved status. Deliverables - Sync status contract and state examples Rollout and recovery: Publish precise status labels; restore prior layout without collapsing distinct states. Project prerequisites: Create two local client-state simulators and a synthetic inspection API. Use fabricated notes and local attachment bytes. Engineer value: Practice offline synchronization, causal revisions and conflict resolution. Company value: Review whether field work survives disconnection without hiding conflicting observations. 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.