# 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. ## AMIGRATE — Migrate customer identifiers without breaking old clients A fictional support platform stores a mutable external account code as its primary relationship key. Renames and imports now break references in several tables. **Field:** Database engineering. **Suggested stack:** PostgreSQL, Prisma, TypeScript. **Engineer value:** Practice migration ordering, compatibility and referential integrity. **Company value:** Review a reversible schema transition with measurable completeness checks. **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 database with synthetic customers and dependent records. - Apply real migration files; never use production db push. ### Expand the schema safely Add stable identities without breaking current reads. #### AMIGRATE-101 — Inventory every reference to the mutable customer code **Task · Medium priority · Foundational** noCV practice brief v5 · AMIGRATE-101 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · System design 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 customer rename updates its main row but leaves case and attachment references pointing to the old code. Acceptance criteria - List database foreign keys and application lookup boundaries. - Classify direct, denormalized and external references. - Record unresolved references before migration design. Implementation constraints - Use repository search and catalog queries against synthetic schema. Verification - Trace a customer through cases and attachments. - Add one hidden denormalized fixture reference and ensure the inventory method finds it. Deliverables - Reference inventory and discovery queries Rollout and recovery: Review the inventory before migration; keep unknown dependencies as explicit blockers. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-102 — Add immutable customer IDs through an additive migration **Task · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-102 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: AMIGRATE-101. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. The migration needs stable customer identity while current clients continue using external codes. Acceptance criteria - Add an opaque unique customer ID with a safe creation path. - Keep legacy code uniqueness under its current scope. - Do not remove or rename existing columns yet. Implementation constraints - Use a migration file and inspect generated SQL. Verification - Apply the migration to a populated synthetic database. - Attempt duplicate immutable identity and verify a database rejection. Deliverables - Additive migration and schema assertions Rollout and recovery: Apply to a disposable copy first; rollback additive consumers before considering column removal. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-103 — Add nullable customer-ID references to dependent tables **Task · Medium priority · Foundational** noCV practice brief v5 · AMIGRATE-103 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Expand the schema safely. Depends on: AMIGRATE-102. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Case rows need the new relationship without requiring a single locking rewrite of the entire dataset. Acceptance criteria - Add the new foreign-key columns without changing current reads. - Index the intended lookup boundary where needed. - Document the later validation and non-null steps. Implementation constraints - Keep migration operations explicit and bounded to the selected tables. Verification - Insert an old-client case after the additive migration. - Insert an invalid non-null customer ID and verify the intended foreign-key behavior. Deliverables - Dependent-table expansion migration Rollout and recovery: Deploy schema before bridge writers; remove unused new columns only before any consumer relies on them. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. ### Bridge old and new writers Backfill and preserve mixed-version compatibility. #### AMIGRATE-104 — Backfill customer IDs with resumable keyset batches **Story · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-104 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-103. Difficulty: Advanced. Estimated focused work: 240 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 70% · Performance 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 single UPDATE holds locks too long and cannot explain where to resume if the migration job stops. Acceptance criteria - Use a stable cursor and bounded batch size. - Persist progress and count matched, missing and conflicting references. - Update only rows still lacking the new identity. Implementation constraints - Create a synthetic dataset with deliberately unmatched legacy codes. Verification - Interrupt and resume the backfill without rewriting completed rows. - Encounter an unmatched code and report it without guessing a customer. Deliverables - Backfill command and progress report Rollout and recovery: Dry-run matching first; pause between batches and retain the checkpoint on errors. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-105 — Bridge legacy customer writes to the new identity transactionally **Task · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-105 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-102, AMIGRATE-103, AMIGRATE-104. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Old clients create cases using a code while new clients use IDs; both must produce equivalent relationships during rollout. Acceptance criteria - Resolve legacy code within organization inside the write boundary. - Write matching legacy and immutable identity fields together. - Reject contradictory code/ID pairs. Implementation constraints - Do not let controllers bypass the shared repository method. Verification - Create equivalent cases through old and new local client contracts. - Supply code for one customer with another ID and verify no row is inserted. Deliverables - Compatibility writer and contradiction tests Rollout and recovery: Deploy bridge writers before enabling new-client reads; revert client routing while retaining dual fields. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-106 — Protect customer-code renames during the backfill window **Bug · High priority · Expert** noCV practice brief v5 · AMIGRATE-106 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-104, AMIGRATE-105. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 80% · 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 rename races a batch lookup and attaches a legacy case to the wrong customer when the old code is reused. Acceptance criteria - Resolve against a stable captured mapping or guarded revision. - Prevent ambiguous code reuse during transition. - Keep committed references bound to immutable customer identity. Implementation constraints - Document the locking or mapping-version strategy. Verification - Race rename with backfill using two database clients. - Reuse an old code after the allowed boundary and preserve earlier references. Deliverables - Rename/backfill concurrency guard Rollout and recovery: Temporarily constrain code reuse under the migration policy; pause backfill on mapping conflicts. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-107 — Verify relationship completeness before making customer IDs mandatory **Task · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-107 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Bridge old and new writers. Depends on: AMIGRATE-104, AMIGRATE-105, AMIGRATE-106. 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. The team wants to mark new references non-null, but missing mappings are hidden by a dashboard that counts only completed batches. Acceptance criteria - Count null, orphan and contradictory references separately. - Check rows created during and after backfill. - Fail the readiness check unless every required relationship is valid. Implementation constraints - Use SQL assertions against the actual synthetic schema. Verification - Complete valid mappings and pass the readiness query. - Create a late legacy-only row and verify readiness fails. Deliverables - Completeness gate and SQL assertions Rollout and recovery: Run repeatedly before constraint changes; leave new columns nullable while gaps remain. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. ### Contract after verification Remove legacy assumptions only with complete checks. #### AMIGRATE-108 — Validate and enforce the new customer relationship constraints **Task · Medium priority · Advanced** noCV practice brief v5 · AMIGRATE-108 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-107. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 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. Application checks pass, but a direct import can still create a case with an absent new customer identity. Acceptance criteria - Add or validate foreign-key and non-null constraints after readiness. - Document database lock expectations for each migration step. - Reject writes violating the new relationship invariant. Implementation constraints - Use PostgreSQL-supported staged validation where appropriate; inspect actual SQL. Verification - Apply the constraint migration after a clean backfill. - Attempt orphan and null references through direct SQL and observe rejection. Deliverables - Constraint migration and direct-write checks Rollout and recovery: Apply in a controlled synthetic window; abort on lock contention and preserve the bridge schema. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-109 — Switch customer reads to immutable IDs with a compatibility fallback plan **Story · Medium priority · Intermediate** noCV practice brief v5 · AMIGRATE-109 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-105, AMIGRATE-108. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 50% · API design 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. The new writer is deployed, but detail routes still resolve mutable codes and can display the wrong record after a rename. Acceptance criteria - Use immutable IDs for internal relationships and new detail routes. - Keep documented legacy lookup behavior at the API boundary. - Record fallback use without leaking customer payloads. Implementation constraints - Fallback must remain tenant-scoped and reject ambiguous codes. Verification - Rename a customer and keep its ID-based detail route stable. - Request an ambiguous legacy code and reject rather than selecting a row. Deliverables - ID-based read path and compatibility cases Rollout and recovery: Canary new routes; restore bridge reads if client compatibility fails. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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. #### AMIGRATE-110 — Retire legacy customer references only after a rollback rehearsal **Chore · High priority · Expert** noCV practice brief v5 · AMIGRATE-110 · Migrate customer identifiers without breaking old clients Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Contract after verification. Depends on: AMIGRATE-108, AMIGRATE-109. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: Database engineering 60% · Platform 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. Dropping old columns would end binary rollback to old readers, but the release checklist does not mention that boundary. Acceptance criteria - Inventory remaining legacy reads and writes before contraction. - Rehearse the last reversible rollback with compatible code. - Document the point after which forward repair is required. Implementation constraints - Do not drop columns merely because the backfill command completed. Verification - Run the old-compatible build against the expanded schema. - Attempt the contraction readiness check with one legacy writer and verify it blocks. Deliverables - Contraction migration plan and rollback evidence Rollout and recovery: Apply contraction only after reviewed readiness; preserve a tested backup and forward-repair procedure. Project prerequisites: Create a disposable database with synthetic customers and dependent records. Apply real migration files; never use production db push. Engineer value: Practice migration ordering, compatibility and referential integrity. Company value: Review a reversible schema transition with measurable completeness checks. 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.