{ "policy": { "version": 5, "patterns": { "version": 1, "method": "CURATED_PRACTICE_TOPIC", "notice": "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." }, "fieldMix": { "version": 1, "method": "CURATED_ESTIMATE", "notice": "Field percentages are editorial estimates of the ticket's engineering focus. They total 100%; they are not measured time, proficiency scores, or ownership evidence." }, "contentStatus": "PRACTICE_BRIEF", "assessmentStatus": "NOT_QUALIFIED", "evidenceUse": "NONE", "aiPolicy": "AI tools are welcome during implementation. Record assumptions, review the result, and verify its behavior.", "notice": "Fictional engineering practice briefs. Starter repositories, fixtures, automated grading, and verified ownership are not included.", "outcomeEvidence": "Tests, patches, and runbooks are requested deliverables. They become Outcome Evidence only through a qualified Mission and immutable Evidence IDs.", "ownershipEvidence": "Independent adaptation must be observed under a declared verification policy and cite immutable Evidence IDs. Completing a planning ticket establishes no Ownership Evidence." }, "patternTopics": [ { "id": "factory-method", "label": "Factory Method", "group": "Creational" }, { "id": "abstract-factory", "label": "Abstract Factory", "group": "Creational" }, { "id": "builder", "label": "Builder", "group": "Creational" }, { "id": "prototype", "label": "Prototype", "group": "Creational" }, { "id": "singleton", "label": "Singleton", "group": "Creational" }, { "id": "adapter", "label": "Adapter", "group": "Structural" }, { "id": "bridge", "label": "Bridge", "group": "Structural" }, { "id": "composite", "label": "Composite", "group": "Structural" }, { "id": "decorator", "label": "Decorator", "group": "Structural" }, { "id": "facade", "label": "Facade", "group": "Structural" }, { "id": "flyweight", "label": "Flyweight", "group": "Structural" }, { "id": "proxy", "label": "Proxy", "group": "Structural" }, { "id": "chain-of-responsibility", "label": "Chain of Responsibility", "group": "Behavioral" }, { "id": "command", "label": "Command", "group": "Behavioral" }, { "id": "interpreter", "label": "Interpreter", "group": "Behavioral" }, { "id": "iterator", "label": "Iterator", "group": "Behavioral" }, { "id": "mediator", "label": "Mediator", "group": "Behavioral" }, { "id": "memento", "label": "Memento", "group": "Behavioral" }, { "id": "observer", "label": "Observer", "group": "Behavioral" }, { "id": "state", "label": "State", "group": "Behavioral" }, { "id": "strategy", "label": "Strategy", "group": "Behavioral" }, { "id": "template-method", "label": "Template Method", "group": "Behavioral" }, { "id": "visitor", "label": "Visitor", "group": "Behavioral" }, { "id": "ports-and-adapters", "label": "Ports and Adapters", "group": "Architectural" }, { "id": "cqrs", "label": "CQRS", "group": "Architectural" }, { "id": "strangler-fig", "label": "Strangler Fig", "group": "Architectural" }, { "id": "saga", "label": "Saga", "group": "Distributed and reliability" }, { "id": "transactional-outbox", "label": "Transactional Outbox", "group": "Distributed and reliability" }, { "id": "circuit-breaker", "label": "Circuit Breaker", "group": "Distributed and reliability" }, { "id": "bulkhead", "label": "Bulkhead", "group": "Distributed and reliability" } ], "projects": [ { "id": "55c7d0ee-f9e3-4569-ab54-2b73b54f315c", "key": "AMIGRATE", "title": "Migrate customer identifiers without breaking old clients", "field": "Database engineering", "summary": "Replace a legacy customer key through additive schema changes and verified backfill.", "context": "A fictional support platform stores a mutable external account code as its primary relationship key. Renames and imports now break references in several tables.", "stack": [ "PostgreSQL", "Prisma", "TypeScript" ], "prerequisites": [ "Create a disposable database with synthetic customers and dependent records.", "Apply real migration files; never use production db push." ], "developerValue": "Practice migration ordering, compatibility and referential integrity.", "companyValue": "Review a reversible schema transition with measurable completeness checks.", "delivery": "Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup.", "phases": [ { "id": "expand", "title": "Expand the schema safely", "goal": "Add stable identities without breaking current reads." }, { "id": "bridge", "title": "Bridge old and new writers", "goal": "Backfill and preserve mixed-version compatibility." }, { "id": "contract", "title": "Contract after verification", "goal": "Remove legacy assumptions only with complete checks." } ], "tickets": [ { "id": "6c1026bd-9b5e-4b68-b665-fb894b921f6d", "key": "AMIGRATE-101", "title": "Inventory every reference to the mutable customer code", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "expand", "dependsOn": [], "scenario": "A customer rename updates its main row but leaves case and attachment references pointing to the old code.", "acceptanceCriteria": [ "List database foreign keys and application lookup boundaries.", "Classify direct, denormalized and external references.", "Record unresolved references before migration design." ], "implementationNotes": [ "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": "Review the inventory before migration; keep unknown dependencies as explicit blockers.", "skills": [ "Schema analysis", "Referential integrity" ], "fieldMix": [ { "field": "Database engineering", "percentage": 70 }, { "field": "System design", "percentage": 30 } ], "patterns": [] }, { "id": "2801fe20-f64b-4529-9da4-ca46c071f817", "key": "AMIGRATE-102", "title": "Add immutable customer IDs through an additive migration", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "expand", "dependsOn": [ "AMIGRATE-101" ], "scenario": "The migration needs stable customer identity while current clients continue using external codes.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Apply to a disposable copy first; rollback additive consumers before considering column removal.", "skills": [ "Migrations", "Database constraints" ], "fieldMix": [ { "field": "Database engineering", "percentage": 100 } ], "patterns": [] }, { "id": "481953d5-a5d0-424b-9755-2902357e2862", "key": "AMIGRATE-103", "title": "Add nullable customer-ID references to dependent tables", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "expand", "dependsOn": [ "AMIGRATE-102" ], "scenario": "Case rows need the new relationship without requiring a single locking rewrite of the entire dataset.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Deploy schema before bridge writers; remove unused new columns only before any consumer relies on them.", "skills": [ "Schema evolution", "Foreign keys" ], "fieldMix": [ { "field": "Database engineering", "percentage": 100 } ], "patterns": [] }, { "id": "fd024ec2-da00-46d8-8d64-6446cde5eec0", "key": "AMIGRATE-104", "title": "Backfill customer IDs with resumable keyset batches", "type": "STORY", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "bridge", "dependsOn": [ "AMIGRATE-103" ], "scenario": "A single UPDATE holds locks too long and cannot explain where to resume if the migration job stops.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Dry-run matching first; pause between batches and retain the checkpoint on errors.", "skills": [ "Backfills", "Keyset processing" ], "fieldMix": [ { "field": "Database engineering", "percentage": 70 }, { "field": "Performance engineering", "percentage": 30 } ], "patterns": [] }, { "id": "565e3e31-91a8-4630-b997-fc141c9bfc2f", "key": "AMIGRATE-105", "title": "Bridge legacy customer writes to the new identity transactionally", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "bridge", "dependsOn": [ "AMIGRATE-102", "AMIGRATE-103", "AMIGRATE-104" ], "scenario": "Old clients create cases using a code while new clients use IDs; both must produce equivalent relationships during rollout.", "acceptanceCriteria": [ "Resolve legacy code within organization inside the write boundary.", "Write matching legacy and immutable identity fields together.", "Reject contradictory code/ID pairs." ], "implementationNotes": [ "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": "Deploy bridge writers before enabling new-client reads; revert client routing while retaining dual fields.", "skills": [ "Compatibility", "Transactions" ], "fieldMix": [ { "field": "Database engineering", "percentage": 70 }, { "field": "Backend", "percentage": 30 } ], "patterns": [] }, { "id": "c2bb526b-362a-457b-ba6b-66ea101ecf1e", "key": "AMIGRATE-106", "title": "Protect customer-code renames during the backfill window", "type": "BUG", "priority": "HIGH", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "bridge", "dependsOn": [ "AMIGRATE-104", "AMIGRATE-105" ], "scenario": "A rename races a batch lookup and attaches a legacy case to the wrong customer when the old code is reused.", "acceptanceCriteria": [ "Resolve against a stable captured mapping or guarded revision.", "Prevent ambiguous code reuse during transition.", "Keep committed references bound to immutable customer identity." ], "implementationNotes": [ "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": "Temporarily constrain code reuse under the migration policy; pause backfill on mapping conflicts.", "skills": [ "Concurrency", "Migration safety" ], "fieldMix": [ { "field": "Database engineering", "percentage": 80 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] }, { "id": "6fdb0907-4cc0-4f45-96ef-dd7fc5ed366a", "key": "AMIGRATE-107", "title": "Verify relationship completeness before making customer IDs mandatory", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 180, "phaseId": "bridge", "dependsOn": [ "AMIGRATE-104", "AMIGRATE-105", "AMIGRATE-106" ], "scenario": "The team wants to mark new references non-null, but missing mappings are hidden by a dashboard that counts only completed batches.", "acceptanceCriteria": [ "Count null, orphan and contradictory references separately.", "Check rows created during and after backfill.", "Fail the readiness check unless every required relationship is valid." ], "implementationNotes": [ "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": "Run repeatedly before constraint changes; leave new columns nullable while gaps remain.", "skills": [ "Data validation", "Referential integrity" ], "fieldMix": [ { "field": "Database engineering", "percentage": 70 }, { "field": "Quality engineering", "percentage": 30 } ], "patterns": [] }, { "id": "7a321823-735d-451a-ac81-f81472fbb3d7", "key": "AMIGRATE-108", "title": "Validate and enforce the new customer relationship constraints", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "contract", "dependsOn": [ "AMIGRATE-107" ], "scenario": "Application checks pass, but a direct import can still create a case with an absent new customer identity.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Apply in a controlled synthetic window; abort on lock contention and preserve the bridge schema.", "skills": [ "Constraint validation", "Migration operations" ], "fieldMix": [ { "field": "Database engineering", "percentage": 100 } ], "patterns": [] }, { "id": "ff199277-03c3-49be-a14a-2264d099caeb", "key": "AMIGRATE-109", "title": "Switch customer reads to immutable IDs with a compatibility fallback plan", "type": "STORY", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "contract", "dependsOn": [ "AMIGRATE-105", "AMIGRATE-108" ], "scenario": "The new writer is deployed, but detail routes still resolve mutable codes and can display the wrong record after a rename.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Canary new routes; restore bridge reads if client compatibility fails.", "skills": [ "API migration", "Identity modeling" ], "fieldMix": [ { "field": "Database engineering", "percentage": 50 }, { "field": "API design", "percentage": 30 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] }, { "id": "26509c72-f358-48c1-acf1-78b21e06cf2e", "key": "AMIGRATE-110", "title": "Retire legacy customer references only after a rollback rehearsal", "type": "CHORE", "priority": "HIGH", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "contract", "dependsOn": [ "AMIGRATE-108", "AMIGRATE-109" ], "scenario": "Dropping old columns would end binary rollback to old readers, but the release checklist does not mention that boundary.", "acceptanceCriteria": [ "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." ], "implementationNotes": [ "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": "Apply contraction only after reviewed readiness; preserve a tested backup and forward-repair procedure.", "skills": [ "Migration planning", "Recovery" ], "fieldMix": [ { "field": "Database engineering", "percentage": 60 }, { "field": "Platform engineering", "percentage": 40 } ], "patterns": [] } ] } ] }