{ "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": "2ad10175-c648-4bd1-aebe-c4ea83fca8e5", "key": "ABOUND", "title": "Design an isolated document-processing boundary", "field": "System design", "summary": "Turn a document-processing brief into reviewable boundaries, contracts and failure probes.", "context": "A fictional procurement portal extracts metadata from uploaded documents. Product wants a responsive upload flow; security wants parser failures isolated from customer-facing processes.", "stack": [ "TypeScript", "PostgreSQL", "HTTP", "Provider interfaces" ], "prerequisites": [ "Create synthetic upload metadata and a fake processing provider.", "Treat diagrams as proposals; implement only local contract probes." ], "developerValue": "Practice boundary decisions backed by executable consistency and failure checks.", "companyValue": "Review architecture tradeoffs with explicit assumptions before infrastructure commitment.", "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": "decide", "title": "Frame the boundary", "goal": "Define workload, authority and state ownership." }, { "id": "contract", "title": "Specify the interactions", "goal": "Make contracts and failure semantics executable." }, { "id": "challenge", "title": "Challenge the design", "goal": "Test alternatives, failure modes and migration steps." } ], "tickets": [ { "id": "5e8374ee-28f2-4a8b-b747-c6672c32edc0", "key": "ABOUND-101", "title": "Translate document-processing expectations into a bounded workload model", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 90, "phaseId": "decide", "dependsOn": [], "scenario": "A design request says uploads should be instant but does not separate transfer time from extraction completion.", "acceptanceCriteria": [ "Define upload acceptance and extraction completion separately.", "State hypothetical size, arrival and concurrency assumptions.", "List unresolved product constraints with owners." ], "implementationNotes": [ "Use a synthetic scenario of 2 MiB median and 20 MiB maximum documents; label it an assumption." ], "verification": [ "Calculate transfer time under two named bandwidth assumptions.", "Show how a maximum-size document changes the completion budget." ], "deliverables": [ "Workload worksheet and clarified latency definitions" ], "rollout": "Review assumptions before design approval; revise the worksheet when constraints change.", "skills": [ "Requirements analysis", "Capacity modeling" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Performance engineering", "percentage": 50 } ], "patterns": [] }, { "id": "66e9b299-64bf-46de-a4bd-24c01d739f6c", "key": "ABOUND-102", "title": "Draw the document trust boundary with authoritative state owners", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 150, "phaseId": "decide", "dependsOn": [ "ABOUND-101" ], "scenario": "The first sketch lets the API parse uploaded documents and write arbitrary worker status into the upload row.", "acceptanceCriteria": [ "Identify storage, API, coordinator and isolated parser boundaries.", "Assign one owner to each lifecycle transition.", "Mark untrusted bytes and privileged credentials on data flows." ], "implementationNotes": [ "Parsing belongs behind an explicit isolated provider; no candidate code runs in product processes." ], "verification": [ "Trace a valid upload through every boundary.", "Trace a malformed document and show that parser failure cannot mutate API memory." ], "deliverables": [ "Trust-boundary diagram and state-ownership table" ], "rollout": "Review the boundary before implementation; reject paths that collapse isolation.", "skills": [ "System boundaries", "Threat modeling" ], "fieldMix": [ { "field": "System design", "percentage": 60 }, { "field": "Security", "percentage": 40 } ], "patterns": [] }, { "id": "c44475a0-dc88-4c45-961d-fdb0e003a992", "key": "ABOUND-103", "title": "Write the decision record for direct-to-storage document upload", "type": "TASK", "priority": "MEDIUM", "difficulty": "FOUNDATIONAL", "estimateMinutes": 120, "phaseId": "decide", "dependsOn": [ "ABOUND-101", "ABOUND-102" ], "scenario": "The team is choosing whether large document bytes should pass through the API or go directly to controlled object storage.", "acceptanceCriteria": [ "Compare bandwidth, authorization and retry responsibilities.", "Specify capability scope, expiry and finalization checks.", "Name conditions that would justify revisiting the choice." ], "implementationNotes": [ "Use a provider-neutral capability contract and hypothetical costs." ], "verification": [ "Trace a successful capability upload and verified finalization.", "Trace expired capability and changed-object cases without accepting an unverified document." ], "deliverables": [ "Upload architecture decision record" ], "rollout": "Review the decision with a local capability fixture; defer provider rollout until its checks exist.", "skills": [ "Architecture decisions", "Storage contracts" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Storage systems", "percentage": 30 }, { "field": "Security", "percentage": 20 } ], "patterns": [] }, { "id": "35d94fa6-5404-4e2f-bfe8-cc8417fff284", "key": "ABOUND-104", "title": "Specify a document lifecycle that survives parser retries", "type": "STORY", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 210, "phaseId": "contract", "dependsOn": [ "ABOUND-102", "ABOUND-103" ], "scenario": "A retry currently moves a completed document back to processing because delivery events are mistaken for authoritative transitions.", "acceptanceCriteria": [ "Define legal transitions and terminal-state behavior.", "Bind processing attempts to one immutable upload generation.", "Reject stale provider completion for a replaced generation." ], "implementationNotes": [ "Express the transition table as executable tests against a small pure model." ], "verification": [ "Replay valid completion twice and retain one terminal result.", "Deliver an older generation result after replacement and reject it." ], "deliverables": [ "State model and transition probes" ], "rollout": "Use the model to gate implementation review; create a new model version for changed semantics.", "skills": [ "State machines", "Idempotency" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Backend", "percentage": 30 }, { "field": "Distributed systems", "percentage": 20 } ], "patterns": [] }, { "id": "daa92c91-bccb-4e7e-a228-3b52e310ccd1", "key": "ABOUND-105", "title": "Design the transactional dispatch contract for extraction work", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "contract", "dependsOn": [ "ABOUND-104" ], "scenario": "An accepted upload can be stranded if the API commits metadata and crashes before calling the processing provider.", "acceptanceCriteria": [ "Commit upload acceptance and an outbox fact together.", "Derive a deterministic dispatch identity from the accepted generation.", "Specify claim, retry and duplicate-delivery behavior." ], "implementationNotes": [ "Use PostgreSQL plus a local provider fake, without adding a broker topology." ], "verification": [ "Crash after transaction commit and recover dispatch from the outbox.", "Repeat provider delivery and prove one accepted completion." ], "deliverables": [ "Outbox contract and interruption probe" ], "rollout": "Prototype on synthetic uploads; halt new acceptance if durable dispatch cannot be recorded.", "skills": [ "Transactional outbox", "Recovery" ], "fieldMix": [ { "field": "System design", "percentage": 40 }, { "field": "Distributed systems", "percentage": 40 }, { "field": "Database engineering", "percentage": 20 } ], "patterns": [] }, { "id": "9168a5b4-3e85-4327-8bbc-fbe92aea60de", "key": "ABOUND-106", "title": "Define extraction-provider deadlines and uncertain completion semantics", "type": "TASK", "priority": "MEDIUM", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "contract", "dependsOn": [ "ABOUND-104", "ABOUND-105" ], "scenario": "A provider times out after accepting work; blindly retrying may launch duplicate expensive processing.", "acceptanceCriteria": [ "Separate rejected, accepted, completed and unknown outcomes.", "Use an idempotent provider request identity and status lookup.", "Define bounded retry and operator-visible unresolved states." ], "implementationNotes": [ "Model uncertain responses explicitly rather than interpreting timeout as failure." ], "verification": [ "Timeout after acceptance and reconcile by request identity.", "Return an unresolved status until the deadline and keep completion unclaimed." ], "deliverables": [ "Provider contract and uncertainty state probe" ], "rollout": "Use the fake provider to validate behavior; fail closed when a real adapter lacks required identity guarantees.", "skills": [ "Distributed failure", "Provider design" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Distributed systems", "percentage": 50 } ], "patterns": [] }, { "id": "c0b0d5d7-61c5-4dfc-a731-30bcf701f86a", "key": "ABOUND-107", "title": "Choose the read model for pending document status", "type": "STORY", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 180, "phaseId": "contract", "dependsOn": [ "ABOUND-104", "ABOUND-106" ], "scenario": "Product wants frequent status updates, but the proposal polls the external parser on every customer request.", "acceptanceCriteria": [ "Serve status from authorized durable local state.", "Specify freshness and pending-state wording.", "Compare bounded polling and push updates under the assumed workload." ], "implementationNotes": [ "Keep raw parser diagnostics outside customer projections." ], "verification": [ "Read one pending and one completed document through the local model.", "Request another tenant's document and verify no provider lookup occurs." ], "deliverables": [ "Read-model decision and scoped contract probe" ], "rollout": "Prototype the local status route; retain polling until push delivery has a measured need.", "skills": [ "Read models", "Authorization" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Backend", "percentage": 30 }, { "field": "Real-time systems", "percentage": 20 } ], "patterns": [] }, { "id": "31cd6682-93cc-4e79-9454-f9d1fc3f7002", "key": "ABOUND-108", "title": "Estimate document backlog growth during a provider outage", "type": "TASK", "priority": "MEDIUM", "difficulty": "EXPERT", "estimateMinutes": 300, "phaseId": "challenge", "dependsOn": [ "ABOUND-101", "ABOUND-105", "ABOUND-106" ], "scenario": "The design has no answer for how long a backlog takes to drain after the parser is unavailable for an hour.", "acceptanceCriteria": [ "Calculate arrivals, stored bytes and queued work during outage.", "Model recovery with explicit service-time and concurrency assumptions.", "Identify when admission must slow or stop." ], "implementationNotes": [ "Use a spreadsheet or executable script with hypothetical values, not invented measurements." ], "verification": [ "Calculate backlog for the declared baseline assumptions.", "Increase arrival rate above recovery capacity and show the queue does not drain." ], "deliverables": [ "Capacity model and outage sensitivity script" ], "rollout": "Use the model to set a reviewed admission proposal; revise with real measurements before production sizing.", "skills": [ "Queueing", "Capacity planning" ], "fieldMix": [ { "field": "Performance engineering", "percentage": 50 }, { "field": "System design", "percentage": 30 }, { "field": "Site reliability", "percentage": 20 } ], "patterns": [] }, { "id": "3030662a-99ba-472b-b33c-c840ad0be8a7", "key": "ABOUND-109", "title": "Compare synchronous and asynchronous extraction against the same failure cases", "type": "TASK", "priority": "MEDIUM", "difficulty": "ADVANCED", "estimateMinutes": 240, "phaseId": "challenge", "dependsOn": [ "ABOUND-103", "ABOUND-106", "ABOUND-108" ], "scenario": "Stakeholders disagree about queueing because one alternative is evaluated only on its happy path.", "acceptanceCriteria": [ "Compare both alternatives under identical workload assumptions.", "Include timeout, duplicate request and parser isolation cases.", "Record accepted tradeoffs and rejected assumptions." ], "implementationNotes": [ "A decision matrix must link to the already-created local probes." ], "verification": [ "Score each alternative against documented correctness requirements.", "Demonstrate the case where synchronous processing exceeds the request deadline." ], "deliverables": [ "Alternative comparison and reviewed decision record" ], "rollout": "Use the comparison for architecture review; revisit when workload or provider guarantees change.", "skills": [ "Tradeoff analysis", "System design" ], "fieldMix": [ { "field": "System design", "percentage": 70 }, { "field": "Distributed systems", "percentage": 30 } ], "patterns": [] }, { "id": "28939897-cc8b-41de-8747-3bb9cea54a2b", "key": "ABOUND-110", "title": "Plan a reversible migration from inline document parsing", "type": "TASK", "priority": "MEDIUM", "difficulty": "INTERMEDIATE", "estimateMinutes": 180, "phaseId": "challenge", "dependsOn": [ "ABOUND-105", "ABOUND-107", "ABOUND-109" ], "scenario": "An existing local prototype parses in its request handler; the team needs an incremental path to the agreed boundary.", "acceptanceCriteria": [ "Sequence durable metadata, dispatch and status-reader changes.", "Define comparison checkpoints and rollback boundaries.", "Keep uploaded bytes and completed results bound to original generations." ], "implementationNotes": [ "Only local prototype migration is in scope; do not provision production execution." ], "verification": [ "Walk a synthetic upload through each migration stage.", "Rollback before activation and show existing completed documents remain readable." ], "deliverables": [ "Migration plan and staged local walkthrough" ], "rollout": "Move one synthetic route at a time; pause migration when old and new status projections disagree.", "skills": [ "Migration design", "Operational planning" ], "fieldMix": [ { "field": "System design", "percentage": 50 }, { "field": "Platform engineering", "percentage": 30 }, { "field": "Backend", "percentage": 20 } ], "patterns": [] } ] } ] }