# 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. ## PMIGRATE — Replace an account service one tenant at a time A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic. **Field:** System design. **Suggested stack:** TypeScript, Node.js, PostgreSQL, Vitest. **Engineer value:** Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. **Company value:** Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. **Delivery agreement:** Ten tickets in three migration phases. An individual ticket needs a minimal local reproduction of its legacy behavior; the full project ends with a rehearsed synthetic tenant cutover and retirement checklist. ### Setup prerequisites - REST contracts - Tenant authorization - Transactions - Dependency injection ### Establish a stable boundary Capture old behavior and remove hidden tenant state before routing changes. #### PMIGRATE-101 — Put legacy account lookups behind a contract the replacement can keep **Task · High priority · Foundational** noCV practice brief v5 · PMIGRATE-101 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: No preceding ticket. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 50% · System 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. Pattern topics: Facade (apply). Facade — Apply: Give callers one stable account-read contract while containing legacy row translation and keeping the boundary deliberately narrow. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Three HTTP handlers each translate a legacy account row differently. One returns an absent timezone as null, another inserts UTC, and a third exposes an internal migration flag. Acceptance criteria - Create a narrow account-read facade with explicit tenant and account identifiers and one documented public response shape. - Capture the intended null, not-found, and permission behavior before routing the three handlers through it. - Keep legacy storage columns and migration flags out of the public response while preserving required client fields. Implementation constraints - Use the facade to bound a specific compatibility surface; do not add a generic wrapper around every repository method. Verification - Exercise all three handlers against synthetic missing, configured, and null-timezone accounts and compare their response contracts. - Request another tenant's account and assert denial with no internal migration metadata in the response. Deliverables - Account-read facade and legacy response characterization cases Rollout and recovery: Move one local handler at a time through the facade and compare response snapshots; revert a handler without changing stored account data. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-102 — Remove the process-wide current-tenant account client **Bug · Urgent priority · Advanced** noCV practice brief v5 · PMIGRATE-102 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: PMIGRATE-101. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: Security 50% · Backend 30% · 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. Pattern topics: Singleton (remove). Singleton — Remove: Remove singleton-held tenant state while preserving safe shared connection infrastructure, using an interleaved request failure to justify the lifetime change. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The legacy account client is a singleton with a mutable currentTenant field. Two overlapping requests can overwrite that field between authorization and the database query, selecting the wrong tenant's settings. Acceptance criteria - Remove mutable request or tenant context from the process-wide client and pass authorized scope explicitly into the service/repository boundary. - Every account query constrains both tenant and account identity, including background lookups and the not-found path. - Connection pooling may remain shared, but tests and request handlers cannot alter another operation's tenant context. Implementation constraints - Distinguish safe shared infrastructure lifetime from unsafe shared request state; replacing the singleton with a different global container is insufficient. Verification - Interleave two tenant requests with barriers at authorization and lookup; assert each receives only its own settings. - Omit tenant scope and use a cross-tenant account identifier in direct service calls; verify rejection before data is returned. Deliverables - Explicit-scope account access change and deterministic overlap reproduction Rollout and recovery: Block further migration until the scope checks pass; revert optional routing changes if needed while retaining the tenant-isolation fix. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-103 — Separate account policy from legacy SQL and replacement storage **Story · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-103 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Establish a stable boundary. Depends on: PMIGRATE-102. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. Pattern topics: Ports and Adapters (refactor). Ports and Adapters — Refactor: Move account policy above concrete storage and give both adapters the same explicit authorization, revision, and transaction obligations. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The rule that a suspended account cannot enable a new booking channel lives inside a legacy SQL helper. The replacement adapter would bypass that rule if handlers called it directly. Acceptance criteria - Place the account policy in an application operation depending on explicit read/write ports instead of concrete database helpers. - Run the same operation against old and new storage adapters with identical authorization and suspended-account behavior. - Keep transaction and expected-revision requirements explicit in the port contract; adapters cannot report success after a failed commit. Implementation constraints - Introduce ports for the needed use case only; do not create a universal repository abstraction or change the application into microservices. Verification - Run a shared contract suite for both adapters over active, suspended, and missing accounts. - Inject a stale revision and commit failure in each adapter and verify no enabled channel or success response is produced. Deliverables - Account operation, two local adapters, and shared behavior contract Rollout and recovery: Keep the legacy adapter selected while introducing the boundary; enable the replacement only after parity cases pass. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. ### Compare and route deliberately Introduce the replacement without duplicate effects or unexamined abstractions. #### PMIGRATE-104 — Shadow account reads without duplicating booking-channel writes **Task · High priority · Advanced** noCV practice brief v5 · PMIGRATE-104 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-103. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Backend 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. Pattern topics: Strangler Fig (apply). Strangler Fig — Apply: Replace a bounded read surface gradually while keeping command ownership singular and making shadow failures independent of served responses. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The migration proposal mirrors every request to the replacement and compares responses. Some apparent reads update lastSeenAt, and write mirroring would enable a booking channel twice through different storage paths. Acceptance criteria - Define an allowlist of side-effect-free reads that may run against both implementations for synthetic tenant comparison. - Return the active implementation's response without letting shadow timeouts or failures change client behavior. - Record bounded field-level parity differences without account content, and route every command to exactly one active implementation. Implementation constraints - Use the migration boundary to incrementally replace routes; do not call a mutating operation just because its HTTP verb is GET. Verification - Inject a replacement timeout and mismatched timezone; verify the active result remains correct and a bounded mismatch is recorded. - Run an enable-channel command and a last-seen update; assert one write owner and zero shadow side effects. Deliverables - Safe shadow-read routing, mismatch report, and side-effect inventory Rollout and recovery: Enable shadow reads for one synthetic tenant with an independent off switch; disable comparison without changing command ownership. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-105 — Preserve tenant scope and conditional reads through the migration proxy **Bug · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-105 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-104. Difficulty: Intermediate. Estimated focused work: 150 minutes; setup and prerequisite tickets are additional. Estimated field mix: API design 40% · Security 40% · 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. Pattern topics: Proxy (refactor). Proxy — Refactor: Keep access control and delegation transparent to the account contract while ensuring proxy forwarding cannot weaken tenant or cache semantics. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A local migration proxy forwards the account identifier but drops the authorized tenant context and If-None-Match value. The new path both loses cache semantics and trusts a tenant header supplied by the caller. Acceptance criteria - Forward server-derived tenant scope and conditional-read metadata through a typed proxy boundary without trusting caller-supplied scope. - Preserve documented ETag, not-modified, not-found, and error behavior for both active implementations. - Reject missing authorized scope before forwarding and keep proxy diagnostics free of credentials and full account bodies. Implementation constraints - The proxy controls access and delegation; keep storage mapping in adapters rather than accumulating business rules in the proxy. Verification - Send matching and stale ETags through old and new routes and compare their public conditional responses. - Spoof a tenant header, omit authorized context, and force an adapter error; assert denial and sanitized error output. Deliverables - Proxy context contract and conditional-read/tenant regression cases Rollout and recovery: Exercise the proxy with local synthetic clients before enabling tenant routing; route back through the corrected legacy boundary on failure. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-106 — Decide whether a separate account summary read model earns its lag **Task · Medium priority · Expert** noCV practice brief v5 · PMIGRATE-106 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-103, PMIGRATE-104. Difficulty: Expert. Estimated focused work: 300 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Database engineering 30% · 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. Pattern topics: CQRS (compare). CQRS — Compare: Compare command/query separation with an indexed query using freshness, rebuild, and write-cost requirements rather than assuming a projection is necessary. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. The account summary joins five tables and is the slowest synthetic endpoint. A CQRS proposal introduces a projection, but support must see a just-disabled booking channel immediately after issuing the command. Acceptance criteria - Compare an indexed transactional query with a separate projection using a declared synthetic dataset and equivalent authorization boundaries. - For the projection option, expose freshness/version semantics and define a read-after-write path that cannot show a disabled channel as enabled after an acknowledged command. - Document latency, write cost, rebuild behavior, and operational complexity; implement the selected option and justify rejecting the other. Implementation constraints - CQRS does not require separate services or event sourcing here; evaluate command/query separation within the existing local application. Verification - Measure both options with identical account counts and query mix, reporting warmup and repeated-run variability. - Pause projection updates, issue a disable command, and exercise the declared freshness strategy; test an interrupted rebuild without cross-tenant reads. Deliverables - Read-model comparison, selected implementation, and freshness/rebuild contract Rollout and recovery: Canary the selected read path for one synthetic tenant; retain the transactional path until freshness and rebuild failure checks pass. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-107 — Delete account facade layers that only rename the same call **Chore · Low priority · Foundational** noCV practice brief v5 · PMIGRATE-107 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Compare and route deliberately. Depends on: PMIGRATE-101, PMIGRATE-103. Difficulty: Foundational. Estimated focused work: 90 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 60% · Backend 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. Pattern topics: Facade (remove). Facade — Remove: Remove redundant facade layers with no compatibility or policy responsibility while retaining the one boundary that protects callers from the legacy model. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. A timezone field now crosses AccountFacade, AccountGatewayFacade, AccountServiceFacade, and AccountAccessFacade. Three wrappers have one consumer, add no behavior, and make a one-field change touch twelve files. Acceptance criteria - Trace the timezone read and identify which boundary owns compatibility, policy, authorization, and persistence responsibilities. - Remove pass-through facades that add no independent responsibility while retaining the public compatibility boundary and storage port. - The timezone response, authorization behavior, and adapter substitution remain unchanged with fewer forwarding sites to maintain. Implementation constraints - Do not replace deleted facades with a dynamic service locator or merge authorization checks into controllers only. Verification - Run the same response and adapter-substitution cases before and after the simplification. - Exercise cross-tenant denial and a storage failure through the simplified path; verify neither is swallowed by forwarding code. Deliverables - Focused simplification patch and a before/after responsibility map Rollout and recovery: Land the forwarding cleanup separately from routing changes so a regression can be traced and reverted without changing migration state. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. ### Cut over and retire Prove write ownership, compatibility, and recovery before removing legacy paths. #### PMIGRATE-108 — Transfer tenant write ownership without accepting commands on both sides **Story · High priority · Expert** noCV practice brief v5 · PMIGRATE-108 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-105, PMIGRATE-106. Difficulty: Expert. Estimated focused work: 330 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 40% · Distributed systems 40% · 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. Pattern topics: Strangler Fig (apply). Strangler Fig — Apply: Make incremental replacement include durable write ownership and a data-aware rollback boundary, rather than treating tenant routing as a cosmetic flag. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Two local application instances cache the tenant migration flag at different times. During cutover, one writes the legacy table while another writes the replacement, leaving two conflicting account revisions. Acceptance criteria - Represent write ownership with a durable tenant migration revision and reject commands using a stale ownership revision at the write boundary. - Backfill replacement data and reconcile it through the final legacy revision under the ownership fence; do not open the new writer while any committed legacy change remains unapplied. - Define a cutover sequence that drains or rejects in-flight old-owner commands before the new owner accepts writes. - Document and rehearse how rollback handles writes already accepted by the new owner; switching a read flag alone cannot declare rollback complete. Implementation constraints - Keep the exercise in one local database and explicit transactions; do not claim cross-database atomicity or solve stale ownership with cache TTL alone. Verification - Copy tenant data, commit a later legacy write, then interleave commands from two instances around cutover; assert the new owner includes that write and a single accepted ownership lineage loses no successful writes. - Crash after ownership transfer and attempt rollback after a new-side write; verify the recovery procedure detects and reconciles that write before reopening old ownership. Deliverables - Tenant cutover command, stale-owner rejection checks, and write-aware rollback drill Rollout and recovery: Rehearse with one synthetic tenant and a paused writer; expand only after cutover and rollback counts reconcile. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-109 — Catch replacement-adapter drift before declaring tenant parity **Task · High priority · Intermediate** noCV practice brief v5 · PMIGRATE-109 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-103, PMIGRATE-105, PMIGRATE-107. Difficulty: Intermediate. Estimated focused work: 180 minutes; setup and prerequisite tickets are additional. Estimated field mix: Quality engineering 50% · System design 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. Pattern topics: Ports and Adapters (apply). Ports and Adapters — Apply: Use the shared port as a behavioral contract for interchangeable adapters, testing semantic parity without binding the contract to either storage implementation. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. Both adapters pass the happy-path tests, but the replacement sorts equal-name accounts differently and rounds stored revision values when decoding a database result. Parity dashboards currently compare only HTTP status codes. Acceptance criteria - Extend the shared port contract to stable sort tie-breakers, null handling, exact revisions, and documented domain error mapping. - Run a fixed synthetic corpus against each adapter and compare normalized semantic results rather than timestamps or implementation-only columns. - A mismatch report identifies the contract case and differing public fields without dumping tenant data or silently accepting expected failures. Implementation constraints - Keep adapter-specific SQL assertions separate from the shared behavior contract so the suite does not require identical internal implementations. Verification - Use equal-name accounts, null settings, and large valid revision values to verify exact contract parity. - Inject a deliberate order reversal and stale-revision acceptance into one local adapter; confirm the comparison fails with an actionable case identifier. Deliverables - Expanded adapter contract suite and sanitized parity report Rollout and recovery: Require a clean contract report before moving the next synthetic tenant; keep mismatched tenants on their current owner until the discrepancy is resolved. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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. #### PMIGRATE-110 — Retire the legacy account path only after the last caller is accounted for **Chore · Medium priority · Advanced** noCV practice brief v5 · PMIGRATE-110 · Replace an account service one tenant at a time Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included. Phase: Cut over and retire. Depends on: PMIGRATE-108, PMIGRATE-109. Difficulty: Advanced. Estimated focused work: 210 minutes; setup and prerequisite tickets are additional. Estimated field mix: System design 50% · Site reliability 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. Pattern topics: Strangler Fig (apply) · Proxy (remove). Strangler Fig — Apply: Complete the replacement by accounting for background callers and rollback data, with explicit criteria for retiring the old implementation. Proxy — Remove: Remove migration-only routing branches after the transition ends so temporary delegation machinery does not become a permanent maintenance layer. Pattern topics identify design choices to practice. Read the ticket's acceptance criteria and justify the simplest suitable approach. Tags are not capability or ownership evidence; an untagged ticket has no curated pattern topic assigned. All interactive tenants use the replacement, but a weekly synthetic export still imports the legacy repository directly. Deleting the old table based on request traffic would break that job and erase the only rollback copy. Acceptance criteria - Inventory HTTP, scheduled, and direct module callers and migrate remaining accesses through the supported contract. - Define observable retirement criteria including zero old-owner tenants, a complete job cycle, reconciled data, and an explicit rollback-retention decision. - Separate code-path removal from any destructive schema change and provide a rehearsed restore path for the retained synthetic snapshot. Implementation constraints - Remove obsolete migration facades and proxy branches once their responsibilities end; keep the public account contract independent of temporary migration machinery. Verification - Run the weekly export and interactive contract suite with legacy routing disabled; assert no code path queries the retired repository. - Leave one synthetic old-owner tenant or omit a scheduled caller and confirm retirement validation blocks removal; rehearse restoring the retained data snapshot. Deliverables - Caller inventory, retirement checks, cleanup patch, and synthetic restore report Rollout and recovery: Disable legacy routing, observe one full synthetic job cycle, then remove unused code; schedule schema deletion separately after the retention decision. Project prerequisites: REST contracts Tenant authorization Transactions Dependency injection Engineer value: Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change. Company value: Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone. 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.