{ "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": "db113b8f-7f11-4fc5-bbaf-e81230c589b8", "key": "AMETA", "title": "Turn unbounded document metadata into a queryable contract", "field": "Database engineering", "summary": "Separate stable document fields from versioned bounded metadata and migrate safely.", "context": "A fictional records portal stores every property in one JSON column. Queries disagree about missing values, and malformed records make ordinary filters fail.", "stack": [ "PostgreSQL", "Prisma", "TypeScript", "JSON Schema" ], "prerequisites": [ "Create synthetic document metadata with malformed and legacy versions.", "Use migrations and a local query API." ], "developerValue": "Practice relational/JSON boundaries, versioned validation and query semantics.", "companyValue": "Review a data model that stays inspectable while allowing controlled variation.", "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": "contract", "title": "Define metadata meaning", "goal": "Choose stable columns and bounded flexible fields." }, { "id": "migrate", "title": "Validate and migrate records", "goal": "Bridge legacy data while protecting writes." }, { "id": "query", "title": "Make filters trustworthy", "goal": "Verify query semantics and release the model." } ], "tickets": [ { "id": "1c44b1aa-0b4e-4168-a274-d8e53c479f2d", "key": "AMETA-101", "title": "Separate stable document identity fields from flexible attributes", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "contract", "dependsOn": [], "scenario": "Document owner, creation time and type are buried beside optional tags in JSON, so every query reinvents their shape.", "acceptanceCriteria": [ "List stable required columns and bounded flexible attributes.", "Document ownership and nullability for each field.", "Reject storing lifecycle authority in arbitrary metadata." ], "implementationNotes": [ "Use a small fictional record taxonomy." ], "verification": [ "Map two document types to the proposed model.", "Classify an unknown authoritative status field as a schema decision rather than generic JSON." ], "deliverables": [ "Relational/JSON field map" ], "rollout": "Review the field map before migrations; keep unresolved authority fields out of metadata writes.", "skills": [ "Data modeling", "Schema boundaries" ], "fieldMix": [ { "field": "Database engineering", "percentage": 70 }, { "field": "System design", "percentage": 30 } ], "patterns": [] }, { "id": "206abfb8-c247-439b-af80-8d8eda1e9aed", "key": "AMETA-102", "title": "Define versioned metadata schemas with explicit size and depth limits", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "contract", "dependsOn": [ "AMETA-101" ], "scenario": "A client submits deeply nested metadata that the API accepts but later query code cannot handle.", "acceptanceCriteria": [ "Require an explicit supported metadata version.", "Bound object depth, field count and serialized size.", "Reject unknown protected fields and invalid field types." ], "implementationNotes": [ "Use schema validation at the write boundary and safe error paths." ], "verification": [ "Validate supported synthetic document metadata.", "Exceed depth and size limits and verify no row is stored." ], "deliverables": [ "Metadata schemas and bound checks" ], "rollout": "Deploy validation for new writes; quarantine incompatible legacy records.", "skills": [ "JSON Schema", "Resource limits" ], "fieldMix": [ { "field": "Database engineering", "percentage": 40 }, { "field": "API design", "percentage": 30 }, { "field": "Security", "percentage": 30 } ], "patterns": [] }, { "id": "26b9599a-8e57-4ae9-abad-07eadcf6bff3", "key": "AMETA-103", "title": "Choose distinct semantics for absent, null and empty metadata values", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "contract", "dependsOn": [ "AMETA-101", "AMETA-102" ], "scenario": "A filter for documents without a retention tag returns different results depending on whether the field is absent, null or an empty string.", "acceptanceCriteria": [ "Define the three states for each supported filter.", "Reject empty strings where they lack business meaning.", "Publish a truth table consumed by query tests." ], "implementationNotes": [ "Avoid blanket coercion of all empty-like values." ], "verification": [ "Query one fixture for each declared state.", "Send an unsupported empty value and verify validation behavior matches the table." ], "deliverables": [ "Metadata null-semantics contract" ], "rollout": "Review the truth table with API consumers; retain old filter names until compatibility is documented.", "skills": [ "SQL semantics", "API contracts" ], "fieldMix": [ { "field": "Database engineering", "percentage": 60 }, { "field": "API design", "percentage": 40 } ], "patterns": [] }, { "id": "11622e17-1aa8-4d05-9623-6b75d3890ec5", "key": "AMETA-104", "title": "Extract stable document fields through an additive migration", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "migrate", "dependsOn": [ "AMETA-101", "AMETA-102", "AMETA-103" ], "scenario": "The model needs relational owner and created-at columns while old records and clients still use JSON.", "acceptanceCriteria": [ "Add nullable relational fields and required target constraints.", "Keep original metadata available during migration.", "Reject contradictory dual representations on new writes." ], "implementationNotes": [ "Use a migration file and explicit data conversion rules." ], "verification": [ "Insert a consistent bridge record.", "Provide different owner identities in columns and JSON and reject the write." ], "deliverables": [ "Schema expansion and bridge validation" ], "rollout": "Deploy additive schema before readers; rollback bridge code while retaining untouched metadata.", "skills": [ "Migrations", "Compatibility" ], "fieldMix": [ { "field": "Database engineering", "percentage": 80 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] }, { "id": "ec7be5b2-6ce3-4ad9-93e4-53c895319dc4", "key": "AMETA-105", "title": "Backfill document timestamps without guessing missing offsets", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "migrate", "dependsOn": [ "AMETA-104" ], "scenario": "Legacy created-at values mix UTC strings with offset-free dates; blindly casting them uses the database session timezone.", "acceptanceCriteria": [ "Convert only timestamps with an unambiguous documented interpretation.", "Quarantine missing-offset and malformed values.", "Use resumable batches with counts by conversion outcome." ], "implementationNotes": [ "Preserve original metadata for later review." ], "verification": [ "Backfill valid offset-bearing values under two session timezones with identical UTC results.", "Process ambiguous dates and retain null target fields plus explicit errors." ], "deliverables": [ "Timestamp backfill and timezone regression" ], "rollout": "Dry-run first; pause on unexpected conversion categories and keep the checkpoint.", "skills": [ "Data migration", "Time zones" ], "fieldMix": [ { "field": "Database engineering", "percentage": 60 }, { "field": "Data engineering", "percentage": 40 } ], "patterns": [] }, { "id": "ecd3cb4e-2e38-4f18-b299-b5551b9db68d", "key": "AMETA-106", "title": "Keep document metadata updates under optimistic revision control", "type": "BUG", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "migrate", "dependsOn": [ "AMETA-102", "AMETA-104" ], "scenario": "Two editors update different metadata fields through whole-object replacement and silently overwrite each other's changes.", "acceptanceCriteria": [ "Require expected document revision on metadata mutation.", "Validate the complete resulting versioned object.", "Return a conflict without discarding either editor's input." ], "implementationNotes": [ "Use explicit patch semantics; do not merge unknown nested arrays heuristically." ], "verification": [ "Apply a patch at the current revision.", "Race two patches and verify the stale one cannot overwrite the first." ], "deliverables": [ "Revision-guarded metadata update" ], "rollout": "Canary patches on synthetic documents; restore read-only editing if conflict handling is incomplete.", "skills": [ "Optimistic concurrency", "Patch semantics" ], "fieldMix": [ { "field": "Database engineering", "percentage": 60 }, { "field": "Backend", "percentage": 40 } ], "patterns": [] }, { "id": "0188e944-d518-4d11-83f9-20dc0e017197", "key": "AMETA-107", "title": "Build parameterized metadata filters with an allowlisted operator set", "type": "TASK", "priority": "HIGH", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "migrate", "dependsOn": [ "AMETA-102", "AMETA-103", "AMETA-106" ], "scenario": "A query endpoint interpolates client-provided JSON paths and operators into SQL.", "acceptanceCriteria": [ "Allow only documented fields and operators.", "Bind user values as parameters and tenant scope as a required predicate.", "Reject unsupported path syntax before query execution." ], "implementationNotes": [ "Do not expose arbitrary SQL or JSON-path execution to clients." ], "verification": [ "Filter known numeric and enum metadata under tenant scope.", "Submit malicious path/operator text and verify no query execution or cross-tenant results." ], "deliverables": [ "Safe filter compiler and injection regressions" ], "rollout": "Enable only reviewed filter combinations; disable newly added operators independently if checks fail.", "skills": [ "SQL safety", "Query compilation" ], "fieldMix": [ { "field": "Security", "percentage": 50 }, { "field": "Database engineering", "percentage": 50 } ], "patterns": [] }, { "id": "78c3e096-60ee-43b5-b36b-6e3660748063", "key": "AMETA-108", "title": "Verify metadata filter results against a simple reference evaluator", "type": "CHORE", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "query", "dependsOn": [ "AMETA-103", "AMETA-107" ], "scenario": "The database query for arrays and null values differs subtly from the API contract, making support reports inconsistent.", "acceptanceCriteria": [ "Author a bounded corpus covering all declared states.", "Compare SQL result identities with a simple reference evaluator.", "Report missing and extra identities separately." ], "implementationNotes": [ "Use identical synthetic inputs and keep the reference implementation straightforward." ], "verification": [ "Compare supported filters across the complete corpus.", "Mutate one SQL null condition and verify the differential check finds the mismatch." ], "deliverables": [ "Differential query harness" ], "rollout": "Require the harness for filter changes; keep the prior query compiler available for rollback.", "skills": [ "Differential testing", "SQL correctness" ], "fieldMix": [ { "field": "Quality engineering", "percentage": 50 }, { "field": "Database engineering", "percentage": 50 } ], "patterns": [] }, { "id": "0d5844e5-902b-4045-ae38-3303706c9263", "key": "AMETA-109", "title": "Enforce required relational document fields after a clean backfill", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "query", "dependsOn": [ "AMETA-104", "AMETA-105", "AMETA-108" ], "scenario": "New readers assume every document has a valid owner and UTC creation instant, but quarantined legacy rows still violate that assumption.", "acceptanceCriteria": [ "Check null, orphan and contradictory target fields before validation.", "Keep quarantined records outside normal reader activation.", "Add required constraints only after declared readiness passes." ], "implementationNotes": [ "Do not fabricate missing timestamps to make constraints pass." ], "verification": [ "Validate a fully resolved synthetic cohort.", "Leave one ambiguous timestamp and verify readiness blocks activation." ], "deliverables": [ "Readiness query and constraint migration" ], "rollout": "Activate resolved cohorts after verification; retain legacy quarantine and avoid destructive contraction.", "skills": [ "Constraint validation", "Migration safety" ], "fieldMix": [ { "field": "Database engineering", "percentage": 100 } ], "patterns": [] }, { "id": "00d51cbe-8d26-4d62-96af-ae8f8493da0d", "key": "AMETA-110", "title": "Rehearse metadata-schema rollback across old and new API consumers", "type": "TASK", "priority": "MEDIUM", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "query", "dependsOn": [ "AMETA-106", "AMETA-108", "AMETA-109" ], "scenario": "The team wants to remove legacy JSON fields immediately after switching reads, which could break old clients during a rollback.", "acceptanceCriteria": [ "Test old and new clients against the expanded schema.", "Document the compatibility window and contraction prerequisites.", "Keep versioned metadata and relational values coherent during rollback." ], "implementationNotes": [ "Use synthetic records from every supported version." ], "verification": [ "Switch readers and restore the prior compatible client with unchanged results.", "Introduce an unsupported version and verify a clear failure rather than lossy conversion." ], "deliverables": [ "Compatibility matrix and rollback drill" ], "rollout": "Retain bridge columns through the reviewed window; contract only after old writers are retired.", "skills": [ "Schema evolution", "Recovery" ], "fieldMix": [ { "field": "Database engineering", "percentage": 60 }, { "field": "API design", "percentage": 20 }, { "field": "Platform engineering", "percentage": 20 } ], "patterns": [] } ] } ] }