# 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. ## ARESTORE — Prove a PostgreSQL backup can restore usable application state A fictional case-management team has nightly backup files but has never tested application behavior after restore. Missing roles and external artifact references may make a successful database restore unusable. **Field:** Database engineering. **Suggested stack:** PostgreSQL, TypeScript, Object storage. **Engineer value:** Practice restore verification, provenance and operational recovery. **Company value:** Review evidence that recovery produces coherent usable state under declared limits. **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 a disposable synthetic database and local backup directory. - Never connect these drills to production or overwrite a shared database. ### Identify recovery inputs Record backup identity and application dependencies. #### ARESTORE-101 — Inventory database recovery inputs beyond the dump file **Task · Medium priority · Foundational** noCV practice brief v5 · ARESTORE-101 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Site reliability 20% · Storage 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 test restore contains tables but cannot start the application because expected roles and extensions are absent. Acceptance criteria - List schema, roles, extensions, migration version and artifact dependencies. - Separate secret configuration from backup contents. - Record unresolved dependencies explicitly. Implementation constraints - Use a disposable synthetic database with a minimal application. Verification - Start the application from a complete declared inventory. - Omit an extension in a fixture and identify the missing prerequisite. Deliverables - Recovery dependency inventory Rollout and recovery: Review inventory before claiming restore readiness; keep unresolved prerequisites visible. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-102 — Create a backup manifest that binds bytes to schema revision **Task · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-102 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: ARESTORE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Storage 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. Operators find three similarly named dump files and cannot tell which migration version or time each represents. Acceptance criteria - Record byte hash, size, UTC capture time and migration identity. - Bind the manifest to the exact backup artifact. - Reject a missing or mismatched manifest before restore. Implementation constraints - Use synthetic data and avoid credentials in command logs. Verification - Verify a backup and matching manifest. - Alter backup bytes and reject the restore plan. Deliverables - Backup manifest command and integrity checks Rollout and recovery: Create manifests for new backups; label unverified older files as uncertain. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-103 — Validate that a restore target is isolated before running destructive steps **Task · High priority · Foundational** noCV practice brief v5 · ARESTORE-103 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Identify recovery inputs. Depends on: ARESTORE-101, ARESTORE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Security 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 copied restore command could replace the development database instead of the disposable drill target. Acceptance criteria - Require an explicit disposable target identity and expected marker. - Resolve and inspect target connection metadata before mutation. - Reject shared, production-like or unmarked targets. Implementation constraints - Use exact database names and task-specific credentials; no wildcard cleanup. Verification - Plan a restore to a marked disposable target. - Point at an unmarked synthetic target and verify zero destructive calls. Deliverables - Restore-target guard and denial tests Rollout and recovery: Make the guard mandatory for drills; abort if target identity changes. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. ### Restore and verify Use isolated targets and validate relational/application state. #### ARESTORE-104 — Restore a verified backup into a new database generation **Story · Medium priority · Advanced** noCV practice brief v5 · ARESTORE-104 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-102, ARESTORE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · Site reliability 30%. Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence. The current procedure restores directly over the active database and leaves no usable environment if it fails halfway. Acceptance criteria - Create and restore into a distinct verified disposable generation. - Keep the prior target untouched until checks complete. - Record each restore stage and failure without exposing data contents. Implementation constraints - Use bounded local synthetic backups only. Verification - Restore a valid backup and inspect the new generation. - Fail mid-restore and verify the previous synthetic application still reads its original database. Deliverables - Generation-based restore script Rollout and recovery: Use a new target for every drill; remove only verified owned failed generations after review. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-105 — Check relational invariants after restoration **Task · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-105 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-104. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · Quality 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. A restore exits successfully but an earlier disabled constraint allowed orphan case assignments into the backup. Acceptance criteria - Check expected foreign keys, unique constraints and required indexes. - Run explicit orphan and duplicate queries on restored data. - Fail application activation when invariants do not hold. Implementation constraints - Compare actual catalog metadata with the declared migration contract. Verification - Validate a clean synthetic restored database. - Restore a deliberately inconsistent fixture and report exact invariant failures. Deliverables - Post-restore SQL verification suite Rollout and recovery: Run before connecting application traffic; retain the failed generation for bounded diagnosis. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-106 — Reconcile restored database references with external artifacts **Task · Medium priority · Advanced** noCV practice brief v5 · ARESTORE-106 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-101, ARESTORE-104, ARESTORE-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Storage systems 40% · 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. Case attachments point to objects created after the backup cutoff, and some objects referenced by restored rows are missing. Acceptance criteria - Compare immutable object versions and hashes for referenced artifacts. - Report missing, extra and mismatched objects separately. - Do not replace missing artifacts with similarly named current objects. Implementation constraints - Use a local object-store fixture and explicit backup cutoff. Verification - Restore matching database and object manifests. - Remove a referenced object and keep the application readiness result incomplete. Deliverables - Artifact reconciliation command Rollout and recovery: Keep artifact-dependent routes unavailable until their references verify; preserve missing-reference reports. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-107 — Prevent post-restore background jobs from repeating completed side effects **Task · High priority · Expert** noCV practice brief v5 · ARESTORE-107 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore and verify. Depends on: ARESTORE-104, ARESTORE-105, ARESTORE-106. Difficulty: Expert. Estimated focused work: 360 minutes; setup and prerequisite tickets are additional. Estimated field mix: Distributed systems 50% · Database engineering 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. A restored outbox contains delivery records whose external effects happened after the database backup but before the outage. Acceptance criteria - Document the database/external-side-effect recovery gap. - Reconcile provider identities before redispatching restored records. - Preserve unknown outcomes rather than asserting they were never sent. Implementation constraints - Use fake providers with durable synthetic request identities; send no messages. Verification - Restore a completed external operation and reconcile it without duplication. - Make provider status unavailable and keep redispatch blocked under the declared policy. Deliverables - Outbox recovery protocol and provider probe Rollout and recovery: Start restored workers paused; release only reconciled work and retain unknown cases. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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 recovery failures Measure local recovery and document missing guarantees. #### ARESTORE-108 — Measure local restore time with complete verification included **Chore · Medium priority · Intermediate** noCV practice brief v5 · ARESTORE-108 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-104, ARESTORE-105, ARESTORE-106, ARESTORE-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Database engineering 40% · Performance 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's restore-time figure measures only dump loading and excludes artifact checks and application readiness. Acceptance criteria - Record hardware, versions, dataset size and cache conditions. - Measure load, verification and readiness stages separately. - Repeat the same synthetic restore three times and report spread. Implementation constraints - These observations do not establish a production RTO. Verification - Run the declared complete restore drill and record all stages. - Fail an invariant check and report recovery incomplete despite dump success. Deliverables - Reproducible local restore timing report Rollout and recovery: Use measurements to improve the drill; revise targets only after representative environment testing. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-109 — Rehearse backup corruption and missing-manifest failure paths **Task · Medium priority · Expert** noCV practice brief v5 · ARESTORE-109 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-102, ARESTORE-103, ARESTORE-108. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Site reliability 30% · Storage 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. Operators need a practiced response when the newest backup is unusable rather than trying increasingly risky manual restore commands. Acceptance criteria - Reject corrupt artifacts before activating a generation. - Select an earlier verified backup with an explicit data-gap statement. - Record the cutoff and unresolved external effects. Implementation constraints - Create disposable corrupted copies rather than altering the retained good backup. Verification - Restore from the prior verified synthetic backup. - Present a missing manifest and corrupted newest artifact and keep both untrusted. Deliverables - Backup-failure drill and recovery decision trace Rollout and recovery: Run periodically in disposable targets; preserve good backups and stop when no verified candidate exists. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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. #### ARESTORE-110 — Write an application-level database recovery handoff **Task · Medium priority · Foundational** noCV practice brief v5 · ARESTORE-110 · Prove a PostgreSQL backup can restore usable application state Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Exercise recovery failures. Depends on: ARESTORE-107, ARESTORE-108, ARESTORE-109. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Site reliability 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 successful command transcript is handed to on-call staff without clear activation criteria or a statement of potentially missing data. Acceptance criteria - List verification gates and the selected recovery cutoff. - Include worker pause/release and artifact availability steps. - State measured local limits and unresolved production dependencies. Implementation constraints - Use fabricated case records in the worked example. Verification - Follow the handoff from verified backup to synthetic application readiness. - Follow the no-verified-backup branch and stop without claiming recovery. Deliverables - Recovery runbook and worked handoff Rollout and recovery: Review with a fresh local drill; update the runbook when schema or provider contracts change. Project prerequisites: Create a disposable synthetic database and local backup directory. Never connect these drills to production or overwrite a shared database. Engineer value: Practice restore verification, provenance and operational recovery. Company value: Review evidence that recovery produces coherent usable state under declared limits. 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.