{
  "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": "afa5117f-48c7-4711-b8ba-558ce59c02b3",
      "key": "FLEET",
      "title": "A dispatch map that does not invent certainty",
      "field": "Real-time systems",
      "summary": "Reconcile synthetic vehicle locations, assignment changes, and stream interruptions in an operations dashboard.",
      "context": "The fictional Cedar delivery depot dispatches vans through a browser map and accessible list. Synthetic telemetry arrives through a gateway with device sequence numbers. This is operational fleet software practice; no real driver tracking, employee scoring, or routing safety guarantee is part of the project.",
      "stack": [
        "TypeScript",
        "React",
        "MapLibre",
        "Node.js",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Synthetic vehicle telemetry with device sessions and sequence numbers",
        "Dispatch assignment and authorized region API contracts"
      ],
      "developerValue": "Practice geospatial boundaries, stream ordering, snapshot recovery, and concurrent operational commands.",
      "companyValue": "Inspect whether a developer keeps dispatch decisions grounded in current authorized data and exposes uncertainty during outages.",
      "delivery": "Use a fixed synthetic depot and replayable location traces. Each ticket is independently bounded by its declared prerequisites.",
      "phases": [
        {
          "id": "map",
          "title": "Establish a truthful map",
          "goal": "Validate coordinates and show age and identity clearly."
        },
        {
          "id": "stream",
          "title": "Reconcile live telemetry",
          "goal": "Handle device ordering and reconnect boundaries."
        },
        {
          "id": "dispatch",
          "title": "Support operational decisions",
          "goal": "Keep assignments, filters, and access consistent."
        },
        {
          "id": "launch",
          "title": "Bound and rehearse the system",
          "goal": "Maintain responsiveness and verify failure recovery."
        }
      ],
      "tickets": [
        {
          "id": "18e4c07e-5fc7-42f9-a2b1-c956e9a2b111",
          "key": "FLEET-101",
          "title": "Keep invalid coordinates from appearing as real vans",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "map",
          "dependsOn": [],
          "scenario": "Missing coordinates are coerced to zero, placing a depot van in the ocean. Validate telemetry before rendering and explain vehicles with no usable position.",
          "acceptanceCriteria": [
            "Latitude and longitude must be finite numeric values within documented geographic bounds.",
            "Missing or rejected position data produces an unknown-location state in the list.",
            "A valid zero coordinate remains valid and is not treated as a missing value."
          ],
          "implementationNotes": [
            "Keep vehicle identity separate from location availability; rejecting one fix must not delete the vehicle."
          ],
          "verification": [
            "Render valid zero latitude and a normal depot position correctly.",
            "Send null, a numeric string, an out-of-range value, and non-finite coordinates; none becomes a plausible marker."
          ],
          "deliverables": [
            "Telemetry coordinate parser and invalid-position fixtures"
          ],
          "rollout": "Validate traces before map display; hide invalid markers while retaining unknown-location list rows.",
          "skills": [
            "Input validation",
            "Geospatial data",
            "Data quality"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 40
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ecae7be5-c8f9-42b9-934d-ada571cec4b3",
          "key": "FLEET-102",
          "title": "Show dispatchers how old each vehicle position is",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "map",
          "dependsOn": [
            "FLEET-101"
          ],
          "scenario": "A van’s last position remains bright green after its device disconnects. Dispatch assigns a nearby job using a point that is twenty minutes old.",
          "acceptanceCriteria": [
            "Map and list expose last accepted fix time and age.",
            "Positions move through configured fresh, stale, and unknown states without requiring a new event.",
            "Device timestamps outside the allowed clock-skew range cannot make a position appear indefinitely fresh."
          ],
          "implementationNotes": [
            "Use a controllable clock and text labels as well as visual styling."
          ],
          "verification": [
            "Advance the clock past both freshness thresholds and verify map/list agreement.",
            "Send a future-dated fix and disconnect the stream; no false current label remains."
          ],
          "deliverables": [
            "Position freshness policy and fake-clock UI checks"
          ],
          "rollout": "Release age labels before assignment features; disable freshness coloring if timestamp authority is uncertain.",
          "skills": [
            "Time handling",
            "Real-time UX",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5b590832-0d21-4ebc-b68a-928e15d39fcc",
          "key": "FLEET-103",
          "title": "Fit selected vehicles without zooming out across the entire planet",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "map",
          "dependsOn": [
            "FLEET-101"
          ],
          "scenario": "A synthetic depot near the date line has vans at longitudes 179.8 and -179.7. Fit selection zooms to the whole world because the bounding box takes the long route.",
          "acceptanceCriteria": [
            "Viewport fitting chooses the intended minimal longitude span for the selected valid points.",
            "One-point and empty selections use documented zoom/fallback behavior.",
            "Unknown-location vehicles remain listed but do not distort geographic bounds."
          ],
          "implementationNotes": [
            "Bound this task to viewport fitting; route calculation and global projection replacement are excluded."
          ],
          "verification": [
            "Fit points on both sides of the date line and verify a local view contains both.",
            "Fit an empty selection, one point, and a mix containing invalid fixes; no invalid bounds or extreme zoom occurs."
          ],
          "deliverables": [
            "Dateline-aware bounds helper and geographic edge-case fixtures"
          ],
          "rollout": "Enable for selection fitting only; retain a manual reset-to-depot control if bounds calculation fails.",
          "skills": [
            "Geospatial reasoning",
            "Boundary cases",
            "Map UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8b3ed8f5-2fac-41f3-b096-b996fb082af9",
          "key": "FLEET-104",
          "title": "Prevent delayed telemetry from moving a van backwards",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "stream",
          "dependsOn": [
            "FLEET-102"
          ],
          "scenario": "A device buffers updates through a tunnel, then sends them out of order. The marker jumps to an older point and the arrival-age label resets incorrectly.",
          "acceptanceCriteria": [
            "Per-device session and sequence identify whether a fix advances accepted position.",
            "Duplicates and earlier fixes do not replace current position or refresh its age.",
            "A new device session follows an explicit reset/authority policy rather than comparing unrelated sequence counters."
          ],
          "implementationNotes": [
            "Arrival time alone cannot establish device order; keep bounded diagnostics for rejected categories."
          ],
          "verification": [
            "Deliver sequence 40, 42, 41, and 42 again; accepted position remains at 42.",
            "Restart the device session with sequence 1 and replay an old-session fix; the documented session policy chooses one authority."
          ],
          "deliverables": [
            "Device-session telemetry reducer and reordered-trace tests"
          ],
          "rollout": "Replay fixed traces before live pilot; freeze a device at its last confirmed fix when session authority is ambiguous.",
          "skills": [
            "Event ordering",
            "Device identity",
            "Stream processing"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e1a919f8-4bed-4912-a29b-4e85220be952",
          "key": "FLEET-105",
          "title": "Reconnect the map without losing updates between snapshot and stream",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "stream",
          "dependsOn": [
            "FLEET-103",
            "FLEET-104"
          ],
          "scenario": "The dashboard downloads a vehicle snapshot and opens the live stream afterward. Updates during that gap never arrive, so a van appears stale until its next fix.",
          "acceptanceCriteria": [
            "The snapshot supplies an authorized region identity and exact stream watermark.",
            "Buffered or replayed events after that watermark apply once after snapshot installation.",
            "Expired watermarks, buffer overflow, and mismatched region data trigger explicit resync rather than a partial-current view."
          ],
          "implementationNotes": [
            "Document the snapshot/replay boundary contract; use a bounded buffer and synthetic trace harness."
          ],
          "verification": [
            "Inject movement during snapshot loading and confirm the final position includes it exactly once.",
            "Expire the watermark and switch region during recovery; no mixed-region positions or falsely current state appears."
          ],
          "deliverables": [
            "Snapshot/stream handoff protocol and gap-recovery harness"
          ],
          "rollout": "Pilot with forced reconnects; keep the map visibly stale and commands disabled until a coherent snapshot is installed.",
          "skills": [
            "Snapshot consistency",
            "Replay",
            "Race conditions"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3d7d884e-8414-45c7-8381-563deb6f04bd",
          "key": "FLEET-106",
          "title": "Resolve competing dispatch assignments explicitly",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "dispatch",
          "dependsOn": [
            "FLEET-105"
          ],
          "scenario": "Two dispatchers assign the same van to different pickup jobs. Both dashboards show success until a refresh reveals the losing assignment disappeared.",
          "acceptanceCriteria": [
            "Assignment commands include expected van/job revision and a stable operation key.",
            "Only the server-confirmed assignment becomes authoritative in map and list.",
            "A competing change shows the current assignment and preserves the unsubmitted alternative for an explicit decision."
          ],
          "implementationNotes": [
            "Use conditional updates at the repository boundary; stale location is shown as context, not assumed current availability."
          ],
          "verification": [
            "Assign a free van and verify map/list share the confirmed revision.",
            "Race two dispatchers and lose one acknowledgement; one assignment wins, retries do not duplicate it, and the conflict is visible."
          ],
          "deliverables": [
            "Revision-aware dispatch command and concurrent-assignment tests"
          ],
          "rollout": "Enable for one synthetic depot after replay checks; disable assignment writes if confirmed map/list state diverges.",
          "skills": [
            "Optimistic concurrency",
            "Idempotency",
            "Operational UX"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0f6dc8b2-bd51-44cb-bc9d-4a675f52554b",
          "key": "FLEET-107",
          "title": "Keep map, list, and counts on the same filtered vehicle set",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "dispatch",
          "dependsOn": [
            "FLEET-102",
            "FLEET-106"
          ],
          "scenario": "Filtering to Unassigned removes map markers but leaves assigned vans in the keyboard list. The count in the toolbar then disagrees with both.",
          "acceptanceCriteria": [
            "One derived selection drives map IDs, list rows, and count.",
            "A live assignment change updates all representations without silently retargeting the selected van.",
            "If a selected van leaves the filter, the interface explains why and offers a deliberate clear-filter action."
          ],
          "implementationNotes": [
            "Maintain an accessible list as an operational alternative to the map."
          ],
          "verification": [
            "Filter unassigned vehicles and compare IDs across map, list, and count.",
            "Assign the selected vehicle remotely while keyboard focus is on its row; selection is explained and focus is not lost."
          ],
          "deliverables": [
            "Shared filtered projection and map/list consistency tests"
          ],
          "rollout": "Enable shared projection for one filter first; fall back to the authoritative list if map selection behavior regresses.",
          "skills": [
            "Derived state",
            "Accessibility",
            "Real-time UI"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 20
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fb425881-85ab-4fab-b441-58d24bc909e8",
          "key": "FLEET-108",
          "title": "Remove out-of-region location data when dispatch scope changes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "dispatch",
          "dependsOn": [
            "FLEET-105",
            "FLEET-106"
          ],
          "scenario": "A dispatcher moves from North depot coverage to East, but an existing stream continues delivering North vehicle coordinates. Hidden markers remain in the browser store.",
          "acceptanceCriteria": [
            "Subscriptions and snapshot queries enforce current authorized region at the service boundary.",
            "Scope changes close old delivery, clear disallowed cached positions, and reconcile a new authorized snapshot.",
            "Diagnostics contain safe event categories and IDs, not raw coordinate trails or personal driver details."
          ],
          "implementationNotes": [
            "Use synthetic fleet data and do not add employee behavior scores or continuous personal-device tracking."
          ],
          "verification": [
            "Switch from North to East and verify only authorized East vehicles remain in storage and presentation.",
            "Queue an old-region event during scope revocation; reject it after the documented barrier and deny a forged region query."
          ],
          "deliverables": [
            "Region-scoped delivery lifecycle and cross-region denial tests"
          ],
          "rollout": "Require this before multi-depot pilots; close all location streams when current scope cannot be established.",
          "skills": [
            "Authorization",
            "Cache isolation",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ed03ef60-6a03-444e-9056-7209427c13ac",
          "key": "FLEET-109",
          "title": "Coalesce position rendering without dropping dispatch events",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "launch",
          "dependsOn": [
            "FLEET-104",
            "FLEET-107",
            "FLEET-108"
          ],
          "scenario": "A replay of 500 vans updating twice a second freezes the browser. Dropping every other message improved drawing but also lost assignment changes.",
          "acceptanceCriteria": [
            "Position drawing may coalesce to the newest accepted fix per vehicle within a bounded frame window.",
            "Assignment, authorization, and removal events follow their full ordered state path and are never discarded as visual updates.",
            "A reproducible load profile records input rate, render frequency, memory bound, and keyboard interaction latency."
          ],
          "implementationNotes": [
            "Separate authoritative state reduction from rendering cadence; use synthetic bounded traces."
          ],
          "verification": [
            "Replay the agreed 500-vehicle trace and measure the documented interaction budget.",
            "Interleave assignment, region removal, and position bursts; all nonvisual state transitions apply and removed vehicles do not reappear."
          ],
          "deliverables": [
            "Render coalescing scheduler and mixed-event load report"
          ],
          "rollout": "Canary with conservative draw limits; reduce displayed live density or use the list if interaction budgets fail, preserving command state.",
          "skills": [
            "Backpressure",
            "Rendering performance",
            "Event classification"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5ed7bcf4-aefb-4cdb-ad81-58d1995979a7",
          "key": "FLEET-110",
          "title": "Rehearse a depot outage before enabling live dispatch",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "launch",
          "dependsOn": [
            "FLEET-105",
            "FLEET-106",
            "FLEET-108",
            "FLEET-109"
          ],
          "scenario": "Dispatch needs to know what remains usable when telemetry stops but assignment storage still works. Write a fixed-data outage rehearsal and an operator decision note.",
          "acceptanceCriteria": [
            "The rehearsal separates telemetry outage, assignment-store outage, and authorization outage.",
            "Every scenario records visible freshness, permitted actions, and recovery state.",
            "The note defines safe fallback actions and states that synthetic replay is not proof of real fleet readiness."
          ],
          "implementationNotes": [
            "Do not send real dispatch commands or connect to personal/production location feeds."
          ],
          "verification": [
            "Stop telemetry, advance the clock, and recover by snapshot; stale labels and final positions match the trace.",
            "Fail assignment storage and then authorization during a pending command; show no false success and close delivery when scope is unknown."
          ],
          "deliverables": [
            "Depot outage rehearsal and dispatch operator runbook"
          ],
          "rollout": "Require a reviewed rehearsal for pilot use; pause live dispatch when authority or assignment confirmation is unavailable.",
          "skills": [
            "Failure testing",
            "Operational handoff",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    }
  ]
}
