{
  "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": "e7e87253-d8c0-44f3-855e-a5f292bf9d97",
      "key": "STOCK",
      "title": "Stop overselling the last warehouse unit",
      "field": "Backend",
      "summary": "Build reservation and allocation behavior for a small retailer with two warehouses and unreliable checkout retries.",
      "context": "A fictional retailer sells bicycle parts from East and West warehouses. Cart reservations last ten minutes, payment callbacks arrive late, and warehouse counts occasionally need correction. The exercise has no real orders or payment integration.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL",
        "Redis"
      ],
      "prerequisites": [
        "Relational modeling",
        "Concurrent API requests",
        "State transitions"
      ],
      "developerValue": "Practice inventory invariants and timed state transitions while balancing customer experience with operational repair.",
      "companyValue": "Inspect an engineer's handling of overselling, delayed callbacks, warehouse boundaries, and reversible schema changes.",
      "delivery": "Three phases of ten reviewable issues, from a stock lookup to a concurrency and recovery handoff using synthetic orders.",
      "phases": [
        {
          "id": "contract",
          "title": "Stock contract",
          "goal": "Define quantities and safe reservation boundaries."
        },
        {
          "id": "checkout",
          "title": "Checkout under contention",
          "goal": "Handle retries, timeouts, and allocations consistently."
        },
        {
          "id": "warehouse",
          "title": "Warehouse operations",
          "goal": "Introduce corrections and operational visibility without corrupting reservations."
        }
      ],
      "tickets": [
        {
          "id": "a1fbd280-b278-43ed-b2e4-7f97d592b349",
          "key": "STOCK-101",
          "title": "Return available stock for a specific warehouse",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Product pages display total stock across both warehouses, although East cannot ship West inventory. A customer sees four brake kits available when their shipping warehouse has none.",
          "acceptanceCriteria": [
            "Return on-hand, reserved, and available quantities for the selected warehouse and SKU.",
            "Unknown SKUs return a documented not-found response.",
            "Reject warehouse IDs outside the caller's retailer scope."
          ],
          "implementationNotes": [
            "Available means on-hand minus active reservations; do not silently substitute another warehouse."
          ],
          "verification": [
            "Read the same SKU from East and West with different balances.",
            "Deny a foreign warehouse and reject an empty SKU."
          ],
          "deliverables": [
            "Warehouse stock endpoint and response examples"
          ],
          "rollout": "Switch the synthetic product page lookup by warehouse behind a flag; restore the earlier lookup if contract errors rise.",
          "skills": [
            "REST contracts",
            "SQL",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "de81d472-c1a1-4181-9a09-0ad5bb141c40",
          "key": "STOCK-102",
          "title": "Define legal reservation transitions",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "A support script changed a paid reservation from COMMITTED back to ACTIVE. Inventory is now counted twice because each endpoint writes status directly.",
          "acceptanceCriteria": [
            "Allow ACTIVE to become COMMITTED, RELEASED, or EXPIRED through named operations.",
            "Terminal reservations cannot return to ACTIVE.",
            "Each successful transition records actor, reason, and timestamp."
          ],
          "implementationNotes": [
            "Keep transition validation in the domain/service boundary, including maintenance callers."
          ],
          "verification": [
            "Exercise all three allowed exits from ACTIVE.",
            "Attempt every terminal-to-active transition and assert no quantity or audit mutation."
          ],
          "deliverables": [
            "Reservation transition table and domain operations"
          ],
          "rollout": "Route existing writes through the new operations first; rollback callers without reopening terminal records.",
          "skills": [
            "State machines",
            "Domain boundaries",
            "Audit trails"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 100
            }
          ],
          "patterns": [
            {
              "pattern": "state",
              "activity": "COMPARE",
              "focus": "Compare a transition table with State objects for the reservation lifecycle. Legal transitions and terminal-state protection matter more than the number of classes."
            }
          ]
        },
        {
          "id": "bf06bb26-ae65-4979-85fd-f6ecb0f7d948",
          "key": "STOCK-103",
          "title": "Reserve the last unit atomically",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "checkout",
          "dependsOn": [
            "STOCK-101",
            "STOCK-102"
          ],
          "scenario": "Two checkouts both read one remaining wheelset before either writes a reservation. Both succeed, leaving the warehouse with available stock of minus one.",
          "acceptanceCriteria": [
            "At most one of two concurrent requests for the last unit succeeds.",
            "Availability never drops below zero for committed reservation transactions.",
            "An insufficient-stock failure creates neither a reservation nor an audit success."
          ],
          "implementationNotes": [
            "The database must enforce correctness when requests arrive at different API processes."
          ],
          "verification": [
            "Run overlapping reservations against one unit and inspect final state.",
            "Inject a failure before commit and prove the available quantity is restored."
          ],
          "deliverables": [
            "Atomic reservation path and deterministic race reproduction"
          ],
          "rollout": "Canary with one synthetic SKU under contention; disable reservation writes if the invariant monitor fails.",
          "skills": [
            "Concurrency",
            "Transactions",
            "Invariant testing"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "bde72df9-70a5-4a95-8343-bdb83e46f4ce",
          "key": "STOCK-104",
          "title": "Replay checkout retries without extending a hold",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "checkout",
          "dependsOn": [
            "STOCK-103"
          ],
          "scenario": "A flaky mobile connection retries the reserve call every minute. Each retry adds another ten minutes to the hold and can change the requested quantity.",
          "acceptanceCriteria": [
            "The same order request replays the original reservation and expiry.",
            "Changing quantity or warehouse under the same request key returns conflict.",
            "An expired reservation remains expired when the request is replayed."
          ],
          "implementationNotes": [
            "Bind the request identity to retailer and order; a replay is not a renewal."
          ],
          "verification": [
            "Retry after nine minutes and assert the original expiry remains.",
            "Replay with changed quantity and replay after expiry; inspect both responses."
          ],
          "deliverables": [
            "Reservation idempotency contract and time-controlled examples"
          ],
          "rollout": "Enable replay behavior for new keys; retain legacy key interpretation until outstanding holds expire.",
          "skills": [
            "Idempotency",
            "Time semantics",
            "API compatibility"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "796c4468-855f-49c6-a754-c5975300d3b8",
          "key": "STOCK-105",
          "title": "Decide the winner when payment and expiry arrive together",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "checkout",
          "dependsOn": [
            "STOCK-104"
          ],
          "scenario": "Payment confirmation and the expiry sweeper reach reservation R-42 at the same instant. Today both handlers succeed and a paid order loses its stock.",
          "acceptanceCriteria": [
            "Document one deadline rule using server time and apply it in both handlers.",
            "Exactly one terminal transition wins under concurrency.",
            "A payment arriving after a lost hold enters an explicit exception path without reserving unavailable stock."
          ],
          "implementationNotes": [
            "Payment success alone does not authorize negative stock; retain callback identity for replay."
          ],
          "verification": [
            "Exercise callback just before, at, and just after the deadline.",
            "Run callback and sweeper concurrently, then replay both and inspect one terminal audit."
          ],
          "deliverables": [
            "Deadline decision record, race tests, and late-payment exception contract"
          ],
          "rollout": "Shadow-classify deadline decisions first; rollback new routing while preserving terminal decisions already recorded.",
          "skills": [
            "Concurrency control",
            "Temporal invariants",
            "Distributed callbacks",
            "Failure design"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7a124d59-944a-4337-9ba3-aad675fbbafc",
          "key": "STOCK-106",
          "title": "Reserve a multi-line order without partial holds",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "checkout",
          "dependsOn": [
            "STOCK-103"
          ],
          "scenario": "An order for a cassette and chain reserves the cassette, then fails on the chain. The abandoned partial hold blocks another buyer for ten minutes.",
          "acceptanceCriteria": [
            "Reserve all requested lines or none within one warehouse.",
            "Combine repeated SKU lines before checking stock.",
            "Concurrent orders listing SKUs in opposite orders finish or return bounded retryable failures."
          ],
          "implementationNotes": [
            "Set a maximum of 50 distinct SKUs per request and define deterministic acquisition order."
          ],
          "verification": [
            "Reserve two available lines and verify both holds.",
            "Fail the second line and run opposite-order concurrent carts; check no partial state."
          ],
          "deliverables": [
            "Atomic basket reservation operation and deadlock exercise"
          ],
          "rollout": "Opt in synthetic multi-line carts; fall back to rejecting whole baskets if contention exceeds the agreed budget.",
          "skills": [
            "Transactions",
            "Lock ordering",
            "Batch validation"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "35352a49-b8cc-46e6-bbcd-e0c9b675171b",
          "key": "STOCK-107",
          "title": "Apply a stock count correction with an explicit shortage",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "warehouse",
          "dependsOn": [
            "STOCK-102",
            "STOCK-103"
          ],
          "scenario": "A warehouse count finds two damaged lights while three lights are reserved. Operations needs to record the loss without silently cancelling customer holds.",
          "acceptanceCriteria": [
            "Append an authorized adjustment with reason and counted quantity.",
            "Represent a shortage when active reservations exceed the corrected on-hand quantity.",
            "Block new holds during a shortage while preserving existing reservation history."
          ],
          "implementationNotes": [
            "An inventory correction is not permission to cancel a paid allocation."
          ],
          "verification": [
            "Correct an unreserved SKU and inspect the new available balance.",
            "Create a shortage and assert existing holds survive while new requests fail."
          ],
          "deliverables": [
            "Stock adjustment command and shortage response contract"
          ],
          "rollout": "Limit adjustments to a test warehouse role; reverse mistakes through a compensating adjustment.",
          "skills": [
            "Inventory modeling",
            "Authorization",
            "Compensating records"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "af3e45ae-dc3e-43a5-92ba-d6cf76baeb86",
          "key": "STOCK-108",
          "title": "Split existing stock rows by warehouse without a write outage",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "warehouse",
          "dependsOn": [
            "STOCK-101",
            "STOCK-103"
          ],
          "scenario": "The old table has one quantity per SKU. The East/West launch needs a warehouse key, but a one-shot table rewrite blocks checkout on the large synthetic inventory fixture.",
          "acceptanceCriteria": [
            "Provide expand, backfill, validation, and contract steps with explicit compatibility windows.",
            "Backfill is resumable and preserves total on-hand quantities.",
            "Demonstrate old and new application versions coexist during the supported migration window."
          ],
          "implementationNotes": [
            "Define the mapping of legacy stock to East before backfill; never infer a warehouse from a SKU."
          ],
          "verification": [
            "Interrupt the backfill and resume without duplicate inventory.",
            "Run reservation traffic during migration and test rollback before the contract step."
          ],
          "deliverables": [
            "Versioned migration set and measured lock-duration report"
          ],
          "rollout": "Use the documented expand/backfill/switch sequence; prohibit old-version rollback after incompatible cleanup.",
          "skills": [
            "Schema evolution",
            "Online migrations",
            "Compatibility",
            "Database operations"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a3bf915c-bfc4-48d8-8a58-5deba1f6f9ea",
          "key": "STOCK-109",
          "title": "Invalidate availability cache after committed stock changes",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "warehouse",
          "dependsOn": [
            "STOCK-107"
          ],
          "scenario": "The product page shows an old available count for five minutes after a warehouse adjustment. A failed adjustment also evicts unrelated retailers' cached stock.",
          "acceptanceCriteria": [
            "Invalidate only the retailer, warehouse, and SKU affected by a committed change.",
            "A rolled-back transaction emits no successful invalidation event.",
            "Reservation correctness remains database-backed when the cache is stale or unavailable."
          ],
          "implementationNotes": [
            "The cache is a display optimization and cannot authorize a hold."
          ],
          "verification": [
            "Apply an adjustment and observe the next lookup refresh.",
            "Rollback an adjustment and disable Redis; check scope and successful authoritative reads."
          ],
          "deliverables": [
            "Scoped cache invalidation and stale-read behavior notes"
          ],
          "rollout": "Reduce cache lifetime before enabling invalidation; bypass the cache if refresh failures rise.",
          "skills": [
            "Caching",
            "Transaction boundaries",
            "Resilience"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "c9341653-e40d-48ab-841d-ef091ffb90ef",
          "key": "STOCK-110",
          "title": "Give support a safe reservation incident view",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "warehouse",
          "dependsOn": [
            "STOCK-105",
            "STOCK-107"
          ],
          "scenario": "Support needs to explain why an order lost its hold. The current workaround is database access that exposes customer addresses and permits accidental stock edits.",
          "acceptanceCriteria": [
            "Show reservation transitions, expiry, warehouse, and exception reason for one authorized order.",
            "Exclude addresses, payment payloads, and write controls.",
            "Distinguish a late payment exception from a normal expiry in readable text."
          ],
          "implementationNotes": [
            "The view is diagnostic only; corrective actions remain separate audited commands."
          ],
          "verification": [
            "Inspect committed, expired, and shortage examples.",
            "Deny another retailer and assert sensitive fields are absent."
          ],
          "deliverables": [
            "Support projection and a three-case incident walkthrough"
          ],
          "rollout": "Grant read access to the synthetic support role; revoke the route permission to rollback.",
          "skills": [
            "Read models",
            "Least privilege",
            "Operational communication"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    }
  ]
}
