{ "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": "8af906b0-ab4a-4506-b8c8-678d05d45087", "key": "PIPE", "title": "Make parcel tracking survive messy carrier events", "field": "Data engineering", "summary": "Ingest delayed, duplicated, and corrected parcel events into an explainable tracking timeline.", "context": "A fictional delivery marketplace receives JSON batches from three carriers. One uses local timestamps, another retries whole batches, and a third corrects delivery scans. Customer support needs a stable timeline rather than the last payload received.", "stack": [ "TypeScript", "PostgreSQL", "BullMQ", "S3-compatible storage" ], "prerequisites": [ "JSON schema validation", "SQL queries", "Event-time concepts" ], "developerValue": "Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair.", "companyValue": "Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events.", "delivery": "Ten tickets in three phases; hand off synthetic carrier fixtures, a replay procedure, and a support-readable tracking projection.", "phases": [ { "id": "receive", "title": "Receive and quarantine", "goal": "Keep valid events and explain rejected input." }, { "id": "timeline", "title": "Build the tracking timeline", "goal": "Resolve time, order, and corrections explicitly." }, { "id": "repair", "title": "Replay and monitor", "goal": "Repair data safely and detect silent ingestion gaps." } ], "tickets": [ { "id": "d9130ed1-dbd5-45b3-881d-bc2160eb2a53", "key": "PIPE-101", "title": "Validate carrier events without discarding a whole batch", "type": "TASK", "priority": "HIGH", "difficulty": "FOUNDATIONAL", "estimateMinutes": 120, "phaseId": "receive", "dependsOn": [], "scenario": "A 200-event batch contains one scan with an empty parcel reference. The importer rejects all 200, leaving valid deliveries invisible until the next carrier export.", "acceptanceCriteria": [ "Classify each row as accepted or rejected with a source position.", "Require carrier event ID, parcel reference, event code, and timestamp.", "Accepted and rejected counts sum to the received count." ], "implementationNotes": [ "Publish the partial-acceptance contract; never silently drop malformed rows." ], "verification": [ "Process 199 valid rows and one malformed row with exact counts.", "Reject oversized batches and invalid JSON without accepted events." ], "deliverables": [ "Batch validation contract and mixed-validity fixtures" ], "rollout": "Enable partial acceptance for one synthetic carrier; retain rejection reports if the route is disabled.", "skills": [ "Schema validation", "Batch processing", "Error reporting" ], "fieldMix": [ { "field": "Data engineering", "percentage": 80 }, { "field": "API design", "percentage": 20 } ], "patterns": [] }, { "id": "f5096420-95f6-423c-8f3c-afd015ac3c35", "key": "PIPE-102", "title": "Attach source lineage to every accepted scan", "type": "CHORE", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "receive", "dependsOn": [ "PIPE-101" ], "scenario": "Support found a delivery scan that neither carrier recognizes. The normalized table contains no batch hash, row position, or parser version to trace its origin.", "acceptanceCriteria": [ "Store batch hash, row position, carrier identity, receipt time, and parser version.", "Link normalized records to a bounded source artifact reference.", "Restrict artifact retrieval to ingest support permission." ], "implementationNotes": [ "Use synthetic data; do not copy full payloads into logs." ], "verification": [ "Trace two accepted rows to their exact source positions.", "Deny a tracking viewer direct source-artifact access." ], "deliverables": [ "Lineage migration and trace example" ], "rollout": "Populate new imports first and mark untraceable legacy rows explicitly.", "skills": [ "Data lineage", "Schema evolution", "Least privilege" ], "fieldMix": [ { "field": "Data engineering", "percentage": 80 }, { "field": "Storage systems", "percentage": 20 } ], "patterns": [] }, { "id": "cbf6a2bf-969e-4098-8ed5-25c8b6abf07a", "key": "PIPE-103", "title": "Deduplicate carrier retries and surface changed duplicates", "type": "BUG", "priority": "HIGH", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "receive", "dependsOn": [ "PIPE-102" ], "scenario": "Carrier Cedar retries yesterday's batch. Most event IDs are identical, but one delivery timestamp changed from 14:03 to 14:30 and is overwritten silently.", "acceptanceCriteria": [ "Identical carrier-scoped event IDs and content replay without duplicate scans.", "Changed content under an existing ID enters a conflict record.", "Concurrent duplicate imports converge to one accepted event." ], "implementationNotes": [ "An event ID from another carrier is a separate identity." ], "verification": [ "Replay the batch twice and compare accepted counts.", "Submit changed content and concurrent duplicates; inspect originals and conflicts." ], "deliverables": [ "Deduplication constraint and conflict handling contract" ], "rollout": "Observe duplicate classifications before enforcement; preserve originals if conflict routing is rolled back.", "skills": [ "Idempotency", "Unique constraints", "Provenance" ], "fieldMix": [ { "field": "Data engineering", "percentage": 60 }, { "field": "Database engineering", "percentage": 40 } ], "patterns": [] }, { "id": "993a040d-4c36-4f11-9c7d-3b6e4c07b805", "key": "PIPE-104", "title": "Stop interpreting offset-free scans as server-local time", "type": "BUG", "priority": "HIGH", "difficulty": "ADVANCED", "estimateMinutes": 180, "phaseId": "timeline", "dependsOn": [ "PIPE-102" ], "scenario": "A carrier sends 2025-11-02 01:30 in its configured New York time zone. The importer guesses one occurrence during the clock change and displays delivery before pickup.", "acceptanceCriteria": [ "Normalize explicit-offset timestamps to UTC.", "Quarantine ambiguous or nonexistent local times instead of guessing.", "Preserve original timestamp text and normalization policy version." ], "implementationNotes": [ "Use explicit carrier time-zone configuration; process time zone cannot define event meaning." ], "verification": [ "Normalize equivalent UTC and offset timestamps to one instant.", "Quarantine repeated-hour and skipped-hour local timestamps." ], "deliverables": [ "Timestamp normalization policy and clock-change fixtures" ], "rollout": "Shadow-normalize historical fixtures and review differences before switching timeline timestamps.", "skills": [ "Time zones", "Data normalization", "Ambiguity handling" ], "fieldMix": [ { "field": "Data engineering", "percentage": 100 } ], "patterns": [] }, { "id": "604f6558-71c2-4d0c-b8a7-1c872f206c41", "key": "PIPE-105", "title": "Keep a late pickup scan from undoing delivered status", "type": "BUG", "priority": "HIGH", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "timeline", "dependsOn": [ "PIPE-103", "PIPE-104" ], "scenario": "A DELIVERED scan arrives at 16:00, followed by a delayed PICKED_UP scan from 08:00. The tracking card switches back to In transit because it uses receipt order.", "acceptanceCriteria": [ "Build the timeline from event time with a documented deterministic tie-breaker.", "Retain late scans without regressing current delivery state.", "Represent inconsistent event sequences with a visible anomaly reason." ], "implementationNotes": [ "Receipt time remains diagnostic information, not a substitute for event time." ], "verification": [ "Import pickup and delivery in both arrival orders and compare projections.", "Add a pickup dated after delivery and inspect the anomaly." ], "deliverables": [ "Tracking projection and out-of-order fixtures" ], "rollout": "Compare projections in a shadow table; switch reads after reviewing differences.", "skills": [ "Event-time processing", "Determinism", "Read models" ], "fieldMix": [ { "field": "Data engineering", "percentage": 80 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] }, { "id": "9a908f23-3f85-4d27-b27e-407e0d24a03a", "key": "PIPE-106", "title": "Apply an explicit carrier correction without erasing the scan", "type": "STORY", "priority": "HIGH", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "timeline", "dependsOn": [ "PIPE-105" ], "scenario": "A driver scanned the wrong parcel as delivered. The carrier now sends corrections referencing the original scan; support must see why Delivered became In transit.", "acceptanceCriteria": [ "Require a same-carrier, same-parcel target event.", "Keep the original scan and append the correction relationship.", "Recompute the projection and expose the withdrawn delivery scan." ], "implementationNotes": [ "Missing targets become pending references with bounded retry, never permission to delete arbitrary events." ], "verification": [ "Apply a valid delivery withdrawal and inspect history and state.", "Reject a cross-parcel target and resolve a target that arrives later." ], "deliverables": [ "Correction contract and deferred-reference recovery" ], "rollout": "Enable the configured correction-capable carrier; retain history if projection readers are rolled back.", "skills": [ "Append-only models", "Referential integrity", "Event correction" ], "fieldMix": [ { "field": "Data engineering", "percentage": 70 }, { "field": "Database engineering", "percentage": 30 } ], "patterns": [] }, { "id": "8e816118-ac89-49b8-a630-279a8d55ef66", "key": "PIPE-107", "title": "Replay a parser fix into a new projection generation", "type": "TASK", "priority": "HIGH", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "repair", "dependsOn": [ "PIPE-106" ], "scenario": "Parser v3 mislabeled ARRIVED_AT_DEPOT as DELIVERED. Operations needs to rebuild 100,000 synthetic scans while fresh batches continue arriving.", "acceptanceCriteria": [ "Replay immutable sources into an isolated projection generation.", "Capture a high-water mark and include arrivals through the documented cutover boundary.", "Switch readers atomically only after counts and anomaly checks pass." ], "implementationNotes": [ "Record parser and projection versions; rebuilding cannot mutate sources." ], "verification": [ "Replay twice and compare deterministic output hashes.", "Interrupt replay and add events during catch-up; prove no cutover gaps." ], "deliverables": [ "Replay command, generation cutover, and recovery runbook" ], "rollout": "Keep the previous generation readable and revert its pointer if comparison fails.", "skills": [ "Replay architecture", "Cutover consistency", "Data repair", "Operational safety" ], "fieldMix": [ { "field": "Data engineering", "percentage": 60 }, { "field": "Distributed systems", "percentage": 40 } ], "patterns": [] }, { "id": "eb203f46-d0da-45b4-b0c8-448b80c671ae", "key": "PIPE-108", "title": "Throttle ingestion without losing accepted batches", "type": "TASK", "priority": "HIGH", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "repair", "dependsOn": [ "PIPE-103" ], "scenario": "After an outage, one carrier sends a day's events in 30 seconds. Memory pressure restarts workers and the API cannot tell which batches were accepted.", "acceptanceCriteria": [ "Bound request size and active ingest concurrency.", "Acknowledge only after durable source and dispatch intent exist.", "Return retryable overload before accepting work above the backlog limit." ], "implementationNotes": [ "Distinguish rejected-before-acceptance from delayed-after-acceptance responses." ], "verification": [ "Burst synthetic batches and account for every acknowledged batch.", "Fail storage and saturate the queue; assert no false acceptance." ], "deliverables": [ "Backpressure limits and accepted-batch accounting test" ], "rollout": "Start with conservative limits; reduce intake while draining accepted work if lag grows.", "skills": [ "Backpressure", "Durable acceptance", "Capacity measurement" ], "fieldMix": [ { "field": "Data engineering", "percentage": 50 }, { "field": "Performance engineering", "percentage": 30 }, { "field": "Distributed systems", "percentage": 20 } ], "patterns": [] }, { "id": "23a673fc-5685-497a-b9ab-73e7c49f45df", "key": "PIPE-109", "title": "Detect a quiet carrier feed independently of queue health", "type": "CHORE", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 120, "phaseId": "repair", "dependsOn": [ "PIPE-102" ], "scenario": "Every worker is healthy, but Carrier Elm has not sent a batch since morning. No alert fires because all dashboards measure processing failures.", "acceptanceCriteria": [ "Track last accepted receipt separately from event-time freshness.", "Apply each carrier's configured operating schedule and lateness budget.", "Feed-gap alerts name the integration and diagnostic step without parcel data." ], "implementationNotes": [ "Empty valid batches count as receipts but do not imply fresh parcel scans." ], "verification": [ "Advance the clock during operating hours to trigger a feed-gap alert.", "Suppress quiet-window paging and distinguish stale event times." ], "deliverables": [ "Freshness metrics, alert rule, and escalation notes" ], "rollout": "Review a simulated week in report-only mode before enabling paging.", "skills": [ "Data observability", "Schedules", "Alert semantics" ], "fieldMix": [ { "field": "Data engineering", "percentage": 50 }, { "field": "Site reliability", "percentage": 50 } ], "patterns": [] }, { "id": "cb80ad39-c5a9-4971-94b4-4377c548e205", "key": "PIPE-110", "title": "Expire raw tracking payloads while retaining minimal lineage", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 180, "phaseId": "repair", "dependsOn": [ "PIPE-107" ], "scenario": "Carrier payloads contain recipient notes unnecessary after the exercise's 30-day debugging window. A cleanup script removes artifacts still used by an active replay.", "acceptanceCriteria": [ "Delete eligible raw artifacts after configured retention.", "Protect artifacts referenced by an active authorized replay lease.", "Retain minimal hashes, deletion receipts, and normalized non-sensitive facts." ], "implementationNotes": [ "Thirty days is a fictional exercise policy; expired leases cannot pin data forever." ], "verification": [ "Expire an eligible artifact and verify its deletion record.", "Protect an active replay artifact, then expire the lease and delete it." ], "deliverables": [ "Retention job and replay-lease cleanup cases" ], "rollout": "Review a dry-run deletion manifest before enabling deletion on synthetic artifacts.", "skills": [ "Retention", "Lease lifecycle", "Data minimization" ], "fieldMix": [ { "field": "Privacy engineering", "percentage": 50 }, { "field": "Data engineering", "percentage": 30 }, { "field": "Storage systems", "percentage": 20 } ], "patterns": [] } ] } ] }