# 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. ## BDBMIG — Database migration review workbench A fictional subscription service has accumulated migration scripts with unclear lock risks and no consistent rehearsal output. **Field:** Developer tooling. **Suggested stack:** TypeScript, PostgreSQL, SQL. **Engineer value:** Practice migration tooling, lock reasoning, and clear developer feedback. **Company value:** Provide reviewers with repeatable migration checks and explicit recovery limits. **Delivery agreement:** Deliver a local review CLI and SQL rehearsals; do not connect to production databases. ### Setup prerequisites - Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. ### Inspect changes Make proposed SQL and risk assumptions visible. #### BDBMIG-101 — Add a migration inventory with checksums and sequence gaps **Task · Medium priority · Foundational** noCV practice brief v5 · BDBMIG-101 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 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 branches introduced migrations with the same sequence number. Acceptance criteria - List migration order and file digests. - Reject duplicate sequence identifiers. - Report missing predecessors without executing SQL. Implementation constraints - Read migration files as text only. Verification - Inventory a valid sequence. - Detect duplicate IDs and an edited historical file. Deliverables - Inventory command. Rollout and recovery: Adopt read-only checks first; resolve history discrepancies before applying migrations. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-102 — Flag table rewrites and long-held locks for review **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-102 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: BDBMIG-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Developer tooling 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 small-looking column change can block writes on a large table. Acceptance criteria - Identify a documented bounded set of risky SQL forms. - Explain potential lock or rewrite behavior. - Mark unrecognized forms as requiring manual review. Implementation constraints - This heuristic must not label arbitrary SQL safe. Verification - Flag a configured rewrite example. - Leave an unsupported statement explicitly unclassified. Deliverables - Risk annotations and limitations. Rollout and recovery: Run advisory checks; preserve manual review for unsupported SQL. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-103 — Prevent migration commands from targeting unapproved databases **Task · High priority · Intermediate** noCV practice brief v5 · BDBMIG-103 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Inspect changes. Depends on: BDBMIG-101. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 50% · Security 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. An engineer copied a connection string from another terminal. Acceptance criteria - Require an explicit local target allowlist. - Display sanitized target identity before rehearsal. - Reject missing, remote, or ambiguous target configuration. Implementation constraints - Never print passwords or complete connection URLs. Verification - Accept the named scratch database. - Reject a remote hostname and inspect sanitized errors. Deliverables - Target guard. Rollout and recovery: Default to no execution until a local target is configured. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. ### Rehearse locally Check application compatibility and interrupted execution. #### BDBMIG-104 — Capture lock waits during a synthetic concurrent workload **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-104 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-102, BDBMIG-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 40% · Performance engineering 30% · Developer tooling 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. Reviewers need observations of a migration while ordinary writes continue. Acceptance criteria - Run bounded synthetic writes against the local fixture. - Capture migration duration and sampled lock waits. - Record dataset size and workload parameters with results. Implementation constraints - Set statement and lock timeouts; avoid extrapolating local results to production. Verification - Observe a compatible migration under writes. - Force lock contention and verify timeout cleanup. Deliverables - Lock rehearsal report. Rollout and recovery: Use reports for review; stop rehearsal on timeout and reset scratch data. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-105 — Test old and new application queries during expand-contract changes **Task · High priority · Advanced** noCV practice brief v5 · BDBMIG-105 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Quality engineering 30% · Developer tooling 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 application rollback fails because the migration removed the column the previous build reads. Acceptance criteria - Define old and new query fixtures. - Run both after the expansion migration. - Reject contraction while the old-query support window is open. Implementation constraints - Limit scope to one renamed subscription column. Verification - Verify dual compatibility after expansion. - Demonstrate the old query failing after premature contraction. Deliverables - Compatibility rehearsal. Rollout and recovery: Ship expansion first; delay contraction until the documented rollback window closes. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-106 — Resume a chunked backfill after a process interruption **Bug · High priority · Advanced** noCV practice brief v5 · BDBMIG-106 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Rehearse locally. Depends on: BDBMIG-104, BDBMIG-105. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Developer tooling 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 backfill restarts from the beginning and repeatedly touches already-migrated subscriptions. Acceptance criteria - Checkpoint a stable key after committed chunks. - Skip completed rows without changing their meaning. - Bound batch size and transaction duration. Implementation constraints - Make derived values deterministic and record invalid rows separately. Verification - Interrupt after two chunks and resume. - Retry one committed chunk and verify unchanged final values. Deliverables - Resumable backfill command. Rollout and recovery: Start with small batches; pause safely and retain checkpoints on failures. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. ### Prepare deployment Package evidence and recovery steps for review. #### BDBMIG-107 — Distinguish reversible schema changes from irreversible data loss **Task · High priority · Expert** noCV practice brief v5 · BDBMIG-107 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-105, BDBMIG-106. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Developer tooling 20% · System design 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 deployment template says every migration can be rolled back, even when original values are discarded. Acceptance criteria - Classify schema reversal and data recovery separately. - Identify the exact point original data becomes unavailable. - Compare forward repair, backup restore, and application rollback for this migration. Implementation constraints - Do not invent recoverability beyond captured data. Verification - Rehearse the selected recovery with synthetic rows. - Show the unrecoverable case when no original data was retained. Deliverables - Recovery decision record. Rollout and recovery: Block contraction until recovery assumptions and retained-data lifetime are reviewed. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-108 — Produce a bounded migration review bundle **Story · Medium priority · Intermediate** noCV practice brief v5 · BDBMIG-108 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-104, BDBMIG-107. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Developer tooling 80% · Privacy 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. Reviewers currently receive terminal screenshots without the SQL version or workload context. Acceptance criteria - Include SQL digests, tool version, target class, and observations. - Exclude connection secrets and row contents. - Fail if referenced rehearsal output is missing. Implementation constraints - Use structured artifacts with documented size limits. Verification - Build a complete bundle. - Reject missing output and scan for seeded secret markers. Deliverables - Review bundle exporter. Rollout and recovery: Attach bundles to proposed changes; rerun if any migration digest changes. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-109 — Add migration drift checks for an already-applied history **Bug · High priority · Intermediate** noCV practice brief v5 · BDBMIG-109 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-101, BDBMIG-108. Difficulty: Intermediate. Estimated focused work: 120 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Developer tooling 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 historical migration was edited after one environment had already applied it. Acceptance criteria - Compare stored applied digests to local files. - Stop on missing or changed applied history. - Allow only append-only new migrations. Implementation constraints - Do not silently repair the migration ledger. Verification - Accept appended migrations. - Reject changed bytes in an applied migration. Deliverables - History drift guard. Rollout and recovery: Fail closed on drift; document a reviewed corrective migration instead of rewriting history. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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. #### BDBMIG-110 — Write the handoff checklist for a paused backfill **Chore · Low priority · Foundational** noCV practice brief v5 · BDBMIG-110 · Database migration review workbench Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Prepare deployment. Depends on: BDBMIG-106, BDBMIG-109. Difficulty: Foundational. Estimated focused work: 60 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · Developer tooling 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 different engineer must resume a backfill after the original author goes offline. Acceptance criteria - Identify the checkpoint and current migration version. - Show safe status, resume, and abort commands. - Describe who decides whether contraction can proceed. Implementation constraints - Keep operator instructions scoped to the local rehearsal. Verification - Resume using only the checklist. - Detect a mismatched migration digest before resuming. Deliverables - Backfill handoff guide. Rollout and recovery: Require the guide with the rehearsal bundle; retain expansion compatibility until completion. Project prerequisites: Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally. Engineer value: Practice migration tooling, lock reasoning, and clear developer feedback. Company value: Provide reviewers with repeatable migration checks and explicit recovery 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.