# 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. ## BRESTORE — Backup restoration rehearsal A fictional reporting service has successful backup jobs but no recent restore rehearsal. Database rows reference objects with different retention schedules. **Field:** Site reliability. **Suggested stack:** PostgreSQL, S3-compatible storage, TypeScript. **Engineer value:** Practice recovery consistency, integrity validation, and honest recovery objectives. **Company value:** Replace backup-job optimism with a repeatable restoration assessment. **Delivery agreement:** Deliver a local restore harness and recovery report; change no production backup policy. ### Setup prerequisites - Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. ### Inventory recovery dependencies Define backup scope and consistency requirements. #### BRESTORE-101 — Inventory the data required to restore one report **Task · Medium priority · Foundational** noCV practice brief v5 · BRESTORE-101 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory recovery dependencies. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 50% · Storage systems 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. A database backup omits the object containing the actual report. Acceptance criteria - List database rows, objects, and configuration references. - Identify authoritative and rebuildable data. - Document retention mismatches. Implementation constraints - Use synthetic records and secret placeholders. Verification - Trace one report end to end. - Identify a missing object as an incomplete recovery dependency. Deliverables - Recovery inventory. Rollout and recovery: Review inventory before altering backup jobs. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-102 — Define a consistent backup manifest across stores **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-102 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inventory recovery dependencies. Depends on: BRESTORE-101. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage 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. Database and object backups represent different points in time. Acceptance criteria - Record snapshot boundary and object version digests. - Include schema and manifest versions. - Reject incomplete manifests. Implementation constraints - Do not equate wall-clock proximity with transactional consistency. Verification - Build a coherent synthetic manifest. - Reject a manifest referencing an unavailable object version. Deliverables - Backup manifest contract. Rollout and recovery: Version manifests and retain the prior complete backup set. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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 isolated data Reconstruct and validate a coherent snapshot. #### BRESTORE-103 — Guard restore commands against non-scratch targets **Task · High priority · Intermediate** noCV practice brief v5 · BRESTORE-103 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-102. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Site reliability 30% · 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 restore command can overwrite an existing developer database by mistake. Acceptance criteria - Require an explicit scratch target. - Reject nonempty or unapproved destinations. - Display sanitized target identity. Implementation constraints - No remote or production endpoints in this exercise. Verification - Restore into an empty named scratch database. - Reject an occupied or remote destination. Deliverables - Restore target guard. Rollout and recovery: Default to inspection-only until target validation passes. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-104 — Verify backup bytes before applying restored data **Task · High priority · Intermediate** noCV practice brief v5 · BRESTORE-104 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-102, BRESTORE-103. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Storage systems 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. A truncated object archive is discovered only after the application starts. Acceptance criteria - Validate declared sizes and content digests. - Reject missing or extra required archive members. - Stop before promotion on any mismatch. Implementation constraints - Bound archive expansion and reject traversal paths. Verification - Verify a complete backup set. - Reject corruption and an escaping archive entry. Deliverables - Backup integrity verifier. Rollout and recovery: Keep failed restores isolated and retain diagnostic metadata. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-105 — Restore database references before enabling object reads **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-105 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-104. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 40% · Database engineering 30% · Storage systems 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 application exposes restored metadata while referenced objects are still missing. Acceptance criteria - Keep restored service unavailable until coherence checks pass. - Reconcile every required object reference. - Report dangling references without inventing replacements. Implementation constraints - Public readiness must not imply partial data is complete. Verification - Restore a coherent report set. - Remove one object and keep readiness blocked. Deliverables - Restore readiness checks. Rollout and recovery: Promote only a validated restore; preserve the original scratch failure state. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-106 — Rebuild derived indexes from restored authoritative records **Task · Medium priority · Advanced** noCV practice brief v5 · BRESTORE-106 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Restore isolated data. Depends on: BRESTORE-105. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Data 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. The backup contains stale search indexes that disagree with restored reports. Acceptance criteria - Rebuild indexes from the restored authority. - Make rebuild restartable and bounded. - Verify index counts and sampled content bindings. Implementation constraints - Never treat an index as the source of truth. Verification - Rebuild after a complete restore. - Interrupt rebuilding and resume without duplicate entries. Deliverables - Derived-data rebuild command. Rollout and recovery: Keep search unavailable until its version matches restored data. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. ### Rehearse disruption Measure recovery and document unrecoverable gaps. #### BRESTORE-107 — Check application compatibility against restored schema versions **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-107 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-105, BRESTORE-106. Difficulty: Advanced. Estimated focused work: 180 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. The latest application cannot read a backup taken before a schema contraction. Acceptance criteria - Declare compatible application/schema pairs. - Run representative reads and writes after restore. - Identify migration requirements before promotion. Implementation constraints - Do not silently upgrade restored data without a reviewed path. Verification - Start a compatible build against the restore. - Reject an incompatible schema with clear guidance. Deliverables - Restore compatibility matrix. Rollout and recovery: Retain a compatible application artifact with each backup generation. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-108 — Measure recovery time and recoverable data loss separately **Task · High priority · Expert** noCV practice brief v5 · BRESTORE-108 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-107. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 60% · Performance 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. Management asks for recovery objectives, but a single successful local restore is being treated as a guarantee. Acceptance criteria - Measure each restore phase under stated dataset and machine limits. - Compute the gap between backup boundary and failure time. - Report untested scale and dependency assumptions. Implementation constraints - Local rehearsal establishes observations, not production RTO or RPO guarantees. Verification - Measure a complete synthetic recovery. - Expose an unrecoverable post-backup write explicitly. Deliverables - Recovery assessment. Rollout and recovery: Use results to propose objectives; repeat in the target environment before committing to them. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-109 — Rehearse recovery when the newest backup is unusable **Task · High priority · Advanced** noCV practice brief v5 · BRESTORE-109 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-104, BRESTORE-108. Difficulty: Advanced. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 70% · Storage systems 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 latest backup manifest is valid but one required object version is unavailable. Acceptance criteria - Select an older complete recovery set explicitly. - Report the increased data-loss window. - Preserve evidence of why the newest set was rejected. Implementation constraints - Never merge unrelated backup generations without a defined consistency rule. Verification - Recover from the previous complete set. - Reject an inconsistent mix of database and object generations. Deliverables - Backup fallback rehearsal. Rollout and recovery: Keep multiple complete generations until retention review permits removal. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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. #### BRESTORE-110 — Write a restore handoff with promotion and abandonment criteria **Chore · Low priority · Foundational** noCV practice brief v5 · BRESTORE-110 · Backup restoration rehearsal Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse disruption. Depends on: BRESTORE-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Site reliability 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. An operator needs to decide whether a long-running restore is safe to promote. Acceptance criteria - List required integrity and compatibility checks. - Document promotion authority and target identity. - Explain how to abandon the scratch restore safely. Implementation constraints - Avoid destructive cleanup commands outside the named scratch directory. Verification - Follow the handoff to promote a valid fixture. - Keep a restore with missing objects unpromoted. Deliverables - Restore runbook. Rollout and recovery: Store the runbook with backup manifests and compatible build references. Project prerequisites: Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples. Engineer value: Practice recovery consistency, integrity validation, and honest recovery objectives. Company value: Replace backup-job optimism with a repeatable restoration assessment. 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.