{
  "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": "73b7103c-798a-41b3-9a03-a86b22faba88",
      "key": "BREADINESS",
      "title": "Seasonal traffic readiness review",
      "field": "Site reliability",
      "summary": "Prepare a small service for a predictable launch surge through capacity and dependency review.",
      "context": "A fictional course platform expects a registration deadline spike. Capacity assumptions, escalation ownership, and degradation decisions are scattered across old documents.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create synthetic registration traces and local dependency doubles with finite connection and request limits."
      ],
      "developerValue": "Practice readiness reviews, capacity reasoning, and cross-functional operational handoffs.",
      "companyValue": "Produce a concrete launch-readiness assessment with measurable risks and recovery actions.",
      "delivery": "Deliver a local rehearsal and review packet; external launch approval remains outside the exercise.",
      "phases": [
        {
          "id": "scope",
          "title": "Collect assumptions",
          "goal": "Define demand, dependencies, and launch invariants."
        },
        {
          "id": "rehearse",
          "title": "Test constraints",
          "goal": "Exercise saturation and failure paths."
        },
        {
          "id": "review",
          "title": "Prepare operations",
          "goal": "Make readiness gaps and controls reviewable."
        }
      ],
      "tickets": [
        {
          "id": "8fdb04ec-e7cc-4e70-88f0-dca9d5a10f88",
          "key": "BREADINESS-101",
          "title": "Turn the registration forecast into a workload envelope",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "scope",
          "dependsOn": [],
          "scenario": "The launch plan says 'ten times traffic' without a base rate or request mix.",
          "acceptanceCriteria": [
            "Declare arrival range, duration, and request mix.",
            "Separate new registrations from read traffic.",
            "Identify unknown forecast assumptions."
          ],
          "implementationNotes": [
            "Use fictional demand figures and label them assumptions."
          ],
          "verification": [
            "Convert the forecast into a bounded local trace.",
            "Reject an unspecified multiplier as a complete workload definition."
          ],
          "deliverables": [
            "Workload envelope."
          ],
          "rollout": "Review assumptions before capacity testing.",
          "skills": [
            "Capacity planning"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "112a024b-a819-424a-8af6-a543887676cd",
          "key": "BREADINESS-102",
          "title": "Inventory dependency quotas and exhaustion behavior",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "scope",
          "dependsOn": [
            "BREADINESS-101"
          ],
          "scenario": "The database pool and email adapter have different limits and failure semantics.",
          "acceptanceCriteria": [
            "Record local pool and mock-provider ceilings.",
            "Describe behavior at each limit.",
            "Assign an owner to unresolved limits."
          ],
          "implementationNotes": [
            "No live provider quotas are assumed from memory."
          ],
          "verification": [
            "Exhaust a configured local limit.",
            "Keep unknown external quotas marked unverified."
          ],
          "deliverables": [
            "Dependency constraint register."
          ],
          "rollout": "Resolve critical unknowns before claiming launch readiness.",
          "skills": [
            "Dependency management"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d53a4ba7-f777-4523-a3ac-079889fc69b3",
          "key": "BREADINESS-103",
          "title": "Add connection-pool wait time to registration diagnostics",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "rehearse",
          "dependsOn": [
            "BREADINESS-102"
          ],
          "scenario": "Slow registration is blamed on SQL even when requests are waiting for a connection.",
          "acceptanceCriteria": [
            "Measure wait and query duration separately.",
            "Track pool occupancy with bounded labels.",
            "Bound waiting time and cancellation cleanup."
          ],
          "implementationNotes": [
            "Do not expose SQL parameters or user identifiers."
          ],
          "verification": [
            "Observe deliberate pool contention.",
            "Cancel a waiting request and verify it leaves the queue."
          ],
          "deliverables": [
            "Pool diagnostics."
          ],
          "rollout": "Introduce read-only metrics before changing pool size.",
          "skills": [
            "Database observability"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0594a5df-c12d-4aa8-a738-6ab5d2973256",
          "key": "BREADINESS-104",
          "title": "Exercise registration idempotency during client reconnects",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "rehearse",
          "dependsOn": [
            "BREADINESS-101"
          ],
          "scenario": "A network interruption causes clients to resubmit successful registrations.",
          "acceptanceCriteria": [
            "Reuse stable submission identity.",
            "Preserve one enrollment per intended registration.",
            "Return the accepted result on exact replay."
          ],
          "implementationNotes": [
            "Conflicting payload reuse must fail explicitly."
          ],
          "verification": [
            "Replay after a lost response.",
            "Race two conflicting submissions under one identity."
          ],
          "deliverables": [
            "Reconnect regression suite."
          ],
          "rollout": "Gate the surge rehearsal on idempotency correctness.",
          "skills": [
            "Idempotency",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6f639830-d4af-4227-aeac-862ff4ea80dd",
          "key": "BREADINESS-105",
          "title": "Decouple confirmation delivery from accepted registration",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rehearse",
          "dependsOn": [
            "BREADINESS-104"
          ],
          "scenario": "A slow notification provider makes accepted registrations appear failed.",
          "acceptanceCriteria": [
            "Commit registration and notification intent atomically.",
            "Return accepted registration independently of delivery latency.",
            "Expose pending delivery without duplicate enrollment."
          ],
          "implementationNotes": [
            "Use a local notification double; send no messages."
          ],
          "verification": [
            "Accept registration during a notification outage.",
            "Recover delivery and verify one logical notification operation."
          ],
          "deliverables": [
            "Notification outbox flow."
          ],
          "rollout": "Retain pending intents through rollback; pause dispatch independently.",
          "skills": [
            "Outbox",
            "Resilience"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "500d8be4-a8a8-481c-a1c8-88472a6ad13c",
          "key": "BREADINESS-106",
          "title": "Test read-only degradation when enrollment writes are unavailable",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "rehearse",
          "dependsOn": [
            "BREADINESS-103",
            "BREADINESS-105"
          ],
          "scenario": "A database write outage should not make the entire course catalog disappear.",
          "acceptanceCriteria": [
            "Preserve declared safe read behavior.",
            "Fail enrollment explicitly when writes cannot commit.",
            "Show data age when serving a cached catalog."
          ],
          "implementationNotes": [
            "Never queue unacknowledged enrollments invisibly."
          ],
          "verification": [
            "Read the catalog during a write failure.",
            "Attempt enrollment and verify no false confirmation."
          ],
          "deliverables": [
            "Write-outage behavior."
          ],
          "rollout": "Enable only documented degradation; clear stale cache on incompatible catalog changes.",
          "skills": [
            "Graceful degradation"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "60137285-7875-4516-b9f3-bc6602e7e66d",
          "key": "BREADINESS-107",
          "title": "Review cache warmup without creating a database stampede",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "rehearse",
          "dependsOn": [
            "BREADINESS-103",
            "BREADINESS-106"
          ],
          "scenario": "Every process warms the same popular course pages simultaneously after deployment.",
          "acceptanceCriteria": [
            "Bound warmup concurrency and total work.",
            "Coalesce identical cache fills.",
            "Keep cache failure from multiplying database reads."
          ],
          "implementationNotes": [
            "Use a finite synthetic course list."
          ],
          "verification": [
            "Warm popular entries under the configured budget.",
            "Expire entries together and verify bounded database pressure."
          ],
          "deliverables": [
            "Cache warmup controller."
          ],
          "rollout": "Warm gradually before synthetic peak; disable warmup if database wait rises.",
          "skills": [
            "Caching",
            "Load control"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d99d5c5a-0f81-4dcb-a95f-f56099397d84",
          "key": "BREADINESS-108",
          "title": "Decide launch capacity with cost and failure headroom",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "review",
          "dependsOn": [
            "BREADINESS-102",
            "BREADINESS-107"
          ],
          "scenario": "The cheapest configuration passes average load but fails when one worker is unavailable.",
          "acceptanceCriteria": [
            "Compare configurations under identical peak and degraded-capacity traces.",
            "Measure accepted work, latency, errors, and resource cost assumptions.",
            "Document required headroom and untested scale."
          ],
          "implementationNotes": [
            "Local observations do not prove production capacity."
          ],
          "verification": [
            "Rehearse the selected configuration with one simulated worker loss.",
            "Reject a configuration that only passes by dropping critical work."
          ],
          "deliverables": [
            "Capacity decision record."
          ],
          "rollout": "Adopt only within the declared workload envelope and retain rollback settings.",
          "skills": [
            "Capacity analysis",
            "Tradeoff reasoning"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "dcf9020b-869a-49de-a998-cc4e450ad02c",
          "key": "BREADINESS-109",
          "title": "Run a launch tabletop with explicit stop conditions",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "review",
          "dependsOn": [
            "BREADINESS-108"
          ],
          "scenario": "Operators lack a shared decision point for pausing registration during a surge.",
          "acceptanceCriteria": [
            "Define measurable pause and resume conditions.",
            "Assign incident and product decision roles.",
            "Rehearse notification outage and database saturation scenarios."
          ],
          "implementationNotes": [
            "Record decisions as simulation outcomes."
          ],
          "verification": [
            "Walk through a recoverable surge.",
            "Keep writes paused when integrity is uncertain."
          ],
          "deliverables": [
            "Tabletop record."
          ],
          "rollout": "Review open actions before the hypothetical launch.",
          "skills": [
            "Incident readiness"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "0a2a3e55-3e05-46bb-a41e-499ae1c2fd46",
          "key": "BREADINESS-110",
          "title": "Publish a launch handoff with unresolved readiness gaps",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "review",
          "dependsOn": [
            "BREADINESS-109"
          ],
          "scenario": "A green test report obscures that external quotas and target-environment recovery remain unverified.",
          "acceptanceCriteria": [
            "List observed checks and unresolved assumptions separately.",
            "Include active configuration and recovery commands.",
            "Name owners for deferred verification."
          ],
          "implementationNotes": [
            "Do not mark unexecuted checks complete."
          ],
          "verification": [
            "Trace a readiness claim to its local result.",
            "Keep an unverified provider limit visible."
          ],
          "deliverables": [
            "Readiness handoff packet."
          ],
          "rollout": "Update after configuration changes; withdraw stale readiness conclusions.",
          "skills": [
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    }
  ]
}
