{ "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": "68fae2f7-7dba-4d95-9336-9fd78bf24cf2", "key": "ANOTIFY", "title": "Design notification delivery around preferences and receipts", "field": "System design", "summary": "Separate notification intent, delivery attempts and user-visible receipt semantics.", "context": "A fictional collaboration tool sends email and in-app notifications. Duplicate alerts and preference changes reveal that the design has no single definition of delivery.", "stack": [ "TypeScript", "PostgreSQL", "Provider interfaces" ], "prerequisites": [ "Create synthetic recipients, events and fake delivery providers.", "Do not send real email or messages." ], "developerValue": "Practice asynchronous contracts, preference timing and delivery uncertainty.", "companyValue": "Review a notification design that controls nuisance, disclosure and recovery.", "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": "intent", "title": "Define communication intent", "goal": "Identify recipients, semantics and privacy boundaries." }, { "id": "delivery", "title": "Specify delivery contracts", "goal": "Handle preference changes, retries and provider uncertainty." }, { "id": "operations", "title": "Validate operating behavior", "goal": "Model load and rehearse recovery without real messaging." } ], "tickets": [ { "id": "b5df5ea3-1af8-4e35-903f-73b79818167c", "key": "ANOTIFY-101", "title": "Separate notification intent from channel delivery and human receipt", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "intent", "dependsOn": [], "scenario": "Product labels a notification delivered when an email provider accepts it, though no human receipt is observed.", "acceptanceCriteria": [ "Define intent, attempted, provider-accepted and observed-read states.", "Keep channel-specific facts separate.", "Avoid claiming reading from provider acceptance." ], "implementationNotes": [ "Use synthetic provider receipts and explicit unknown states." ], "verification": [ "Map an accepted email and an opened in-app item separately.", "Timeout the provider and retain unknown delivery rather than sent." ], "deliverables": [ "Notification semantics table" ], "rollout": "Adopt precise status labels in the prototype; preserve uncertain older observations.", "skills": [ "Domain modeling", "Delivery semantics" ], "fieldMix": [ { "field": "System design", "percentage": 60 }, { "field": "Backend", "percentage": 40 } ], "patterns": [] }, { "id": "84b7be4c-5712-40f1-a5d3-68903c6b5d3d", "key": "ANOTIFY-102", "title": "Specify recipient resolution without copying event payloads broadly", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "intent", "dependsOn": [ "ANOTIFY-101" ], "scenario": "The event producer includes every collaborator's contact details so downstream handlers can decide recipients.", "acceptanceCriteria": [ "Resolve recipients through a scoped authority boundary.", "Keep generic event payloads to opaque identifiers.", "Authorize recipient access before creating a channel attempt." ], "implementationNotes": [ "Use synthetic addresses and a dedicated contact provider fake." ], "verification": [ "Resolve members of the correct synthetic workspace.", "Request recipients across workspaces and produce no channel attempts." ], "deliverables": [ "Recipient-resolution contract" ], "rollout": "Review the contract before broad event publication; quarantine events without valid scope.", "skills": [ "Privacy boundaries", "Authorization" ], "fieldMix": [ { "field": "Privacy engineering", "percentage": 50 }, { "field": "System design", "percentage": 30 }, { "field": "Security", "percentage": 20 } ], "patterns": [] }, { "id": "d35d1b68-fddd-40d5-a06e-9aa0fa4eb7b3", "key": "ANOTIFY-103", "title": "Choose when notification preferences are evaluated", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 120, "phaseId": "intent", "dependsOn": [ "ANOTIFY-101", "ANOTIFY-102" ], "scenario": "A user opts out after an event is queued but still receives the email, and the team has no documented policy.", "acceptanceCriteria": [ "Compare preference-at-intent and preference-at-send semantics.", "Choose and document behavior for opt-out and critical notices.", "Define how a changed preference version affects queued work." ], "implementationNotes": [ "Do not silently invent a legal or mandatory-notice requirement." ], "verification": [ "Trace an opt-out between event and send.", "Trace a missing preference record under the declared default policy." ], "deliverables": [ "Preference-timing architecture decision" ], "rollout": "Review with product before adapter work; keep unresolved categories unsent.", "skills": [ "Tradeoff analysis", "Preference design" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Privacy engineering", "percentage": 30 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] }, { "id": "df59929a-f99f-4e04-9b4b-ae9fa27327ce", "key": "ANOTIFY-104", "title": "Model notification intent and dispatch in one durable transaction", "type": "STORY", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "delivery", "dependsOn": [ "ANOTIFY-102", "ANOTIFY-103" ], "scenario": "A collaboration action commits but crashes before queue publication, so some recipients never receive an alert.", "acceptanceCriteria": [ "Persist domain reference and notification intent atomically.", "Use an outbox fact with deterministic intent identity.", "Make repeated event delivery resolve the same logical intent." ], "implementationNotes": [ "Keep intent creation inside the existing modular application boundary." ], "verification": [ "Crash after action commit and replay the outbox to one intent.", "Repeat the originating event and verify no duplicate recipient intent." ], "deliverables": [ "Intent/outbox model and interruption probe" ], "rollout": "Use a local provider fake initially; pause originating notifications if intent persistence fails.", "skills": [ "Transactional outbox", "Idempotency" ], "fieldMix": [ { "field": "System design", "percentage": 40 }, { "field": "Distributed systems", "percentage": 40 }, { "field": "Database engineering", "percentage": 20 } ], "patterns": [] }, { "id": "38dfb67d-7f42-4396-97b5-57be7c8a9f33", "key": "ANOTIFY-105", "title": "Design per-channel attempt identity and provider reconciliation", "type": "TASK", "priority": "MEDIUM", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "delivery", "dependsOn": [ "ANOTIFY-101", "ANOTIFY-104" ], "scenario": "The email provider times out after accepting a request; retrying blindly sends the same message twice.", "acceptanceCriteria": [ "Bind each logical channel delivery to a stable provider key.", "Represent unknown acceptance and define a status lookup path.", "Document provider limitations that prevent exactly-once claims." ], "implementationNotes": [ "The local fake must support accepted-but-response-lost behavior." ], "verification": [ "Reconcile lost response to one accepted synthetic delivery.", "Use a provider without lookup support and retain an explicit uncertain state." ], "deliverables": [ "Channel contract and uncertainty probe" ], "rollout": "Select adapters only after contract review; stop automatic retries where duplicate risk is unresolved.", "skills": [ "Distributed contracts", "Uncertainty" ], "fieldMix": [ { "field": "Distributed systems", "percentage": 60 }, { "field": "System design", "percentage": 40 } ], "patterns": [] }, { "id": "c4d4f6c2-aba2-4bce-a6d3-c40683740dc1", "key": "ANOTIFY-106", "title": "Bound notification fan-out without creating one huge transaction", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "delivery", "dependsOn": [ "ANOTIFY-102", "ANOTIFY-104" ], "scenario": "One workspace event targets 50,000 hypothetical members and the proposed transaction attempts to create every delivery row at once.", "acceptanceCriteria": [ "Specify bounded recipient pages and stable page checkpoints.", "Preserve one logical intent per recipient across retries.", "Define membership snapshot versus live-membership semantics." ], "implementationNotes": [ "Use a synthetic membership generator with documented cardinality." ], "verification": [ "Process a 1,000-recipient local sample in fixed-size pages.", "Interrupt a page and resume without duplicate recipient intents." ], "deliverables": [ "Fan-out plan and checkpoint prototype" ], "rollout": "Validate with local samples before wider scale assumptions; pause dispatch while keeping checkpoints.", "skills": [ "Fan-out", "Batching" ], "fieldMix": [ { "field": "System design", "percentage": 40 }, { "field": "Distributed systems", "percentage": 30 }, { "field": "Performance engineering", "percentage": 30 } ], "patterns": [] }, { "id": "21853cf6-e439-4e52-a7d6-a54f1ddfc726", "key": "ANOTIFY-107", "title": "Keep in-app notification reads separate from email provider state", "type": "STORY", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "delivery", "dependsOn": [ "ANOTIFY-101", "ANOTIFY-105", "ANOTIFY-106" ], "scenario": "Marking an in-app alert read currently suppresses an unrelated email retry by changing one shared status column.", "acceptanceCriteria": [ "Model channel delivery and in-app acknowledgement separately.", "Bind acknowledgement to the authenticated recipient.", "Preserve delivery-attempt history after acknowledgement." ], "implementationNotes": [ "Use an explicit read model for the in-app feed." ], "verification": [ "Mark one in-app item read and retain email attempt state.", "Acknowledge another recipient's item and reject it." ], "deliverables": [ "Read-model contract and channel-isolation probe" ], "rollout": "Prototype the read model behind a local route; revert read wiring without changing delivery history.", "skills": [ "State separation", "Authorization" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Backend", "percentage": 50 } ], "patterns": [] }, { "id": "dbbab7af-cd4a-4b6e-8acb-9331c29ff505", "key": "ANOTIFY-108", "title": "Calculate notification drain time under a channel rate limit", "type": "TASK", "priority": "MEDIUM", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "operations", "dependsOn": [ "ANOTIFY-105", "ANOTIFY-106" ], "scenario": "A launch generates a burst of alerts, but the architecture plan ignores provider quotas and retry traffic.", "acceptanceCriteria": [ "Model initial backlog, arrival rate and provider throughput.", "Reserve capacity for retries within a bounded budget.", "Show conditions where backlog cannot drain." ], "implementationNotes": [ "Use explicitly hypothetical rates and an executable calculation." ], "verification": [ "Calculate drain time for a named burst and fixed delivery rate.", "Raise arrivals above capacity and report unbounded growth instead of a finite answer." ], "deliverables": [ "Capacity calculator and quota assumptions" ], "rollout": "Use results to propose admission and batching limits; replace assumptions before real rollout.", "skills": [ "Queueing", "Capacity analysis" ], "fieldMix": [ { "field": "Performance engineering", "percentage": 50 }, { "field": "System design", "percentage": 30 }, { "field": "Integrations", "percentage": 20 } ], "patterns": [] }, { "id": "cb148329-cdd7-451a-ac00-87cddaedc084", "key": "ANOTIFY-109", "title": "Exercise preference revocation during a notification backlog", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "operations", "dependsOn": [ "ANOTIFY-103", "ANOTIFY-105", "ANOTIFY-108" ], "scenario": "A user disables a channel while thousands of queued intents wait for provider quota, exposing ambiguous preference timing.", "acceptanceCriteria": [ "Apply the chosen preference-timing policy consistently.", "Record suppressed versus attempted outcomes without contact details.", "Keep already accepted provider facts immutable." ], "implementationNotes": [ "Use a local backlog and fake provider; send no real messages." ], "verification": [ "Change preferences before a queued intent reaches its decision boundary.", "Change preferences after provider acceptance and preserve the accepted fact without claiming recall." ], "deliverables": [ "Backlog preference drill and outcome trace" ], "rollout": "Run before adapter approval; suspend the affected category if policy and implementation diverge.", "skills": [ "Policy consistency", "Fault scenarios" ], "fieldMix": [ { "field": "System design", "percentage": 40 }, { "field": "Privacy engineering", "percentage": 30 }, { "field": "Quality engineering", "percentage": 30 } ], "patterns": [] }, { "id": "32bc4eda-18ec-4586-96b8-2415c28e5872", "key": "ANOTIFY-110", "title": "Document notification architecture limits for stakeholder review", "type": "CHORE", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "operations", "dependsOn": [ "ANOTIFY-105", "ANOTIFY-108", "ANOTIFY-109" ], "scenario": "The launch plan describes exactly-once delivery and confirmed readership even though the provider contract supports neither.", "acceptanceCriteria": [ "List supported guarantees and unresolved provider dependencies.", "Link each guarantee to a contract or local probe.", "Include retry suspension and backlog recovery decisions." ], "implementationNotes": [ "State that local tests do not prove real provider delivery." ], "verification": [ "Trace an accepted guarantee to its executable probe.", "Identify an unsupported receipt claim and replace it with the observed state." ], "deliverables": [ "Notification design review packet" ], "rollout": "Review the packet before provider rollout; revise claims when adapter evidence changes.", "skills": [ "Technical communication", "Architecture review" ], "fieldMix": [ { "field": "System design", "percentage": 70 }, { "field": "Integrations", "percentage": 30 } ], "patterns": [] } ] } ] }