{
  "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": "a9c6bc62-e083-4c93-b2c3-bccfd759c82f",
      "key": "BILL",
      "title": "Close the billing reconciliation gap",
      "field": "Backend",
      "summary": "Reconcile payment settlements against invoice records without hiding money movement or retry failures.",
      "context": "A fictional subscription service invoices in USD and EUR. Finance currently compares a payment-provider CSV with database exports; late refunds and retried imports make the monthly close unreliable. Work on synthetic ledger entries only.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL",
        "BullMQ"
      ],
      "prerequisites": [
        "REST APIs",
        "SQL transactions",
        "Integer money representation"
      ],
      "developerValue": "Practice monetary invariants, concurrent writes, reconciliation, and operational recovery across one service boundary.",
      "companyValue": "Review how an engineer makes discrepancies explainable and recoverable before a financial workflow is trusted.",
      "delivery": "Ten bounded tickets over three phases; choose an individual issue or deliver the complete synthetic reconciliation service with a finance handoff.",
      "phases": [
        {
          "id": "intake",
          "title": "Reliable intake",
          "goal": "Make settlement imports inspectable and repeatable."
        },
        {
          "id": "reconcile",
          "title": "Explain the balance",
          "goal": "Match settlements and preserve unresolved differences."
        },
        {
          "id": "operate",
          "title": "Close and recover",
          "goal": "Make runs reproducible and safe to operate."
        }
      ],
      "tickets": [
        {
          "id": "bc37f44d-1c85-40c8-bbeb-b5fa97093b82",
          "key": "BILL-101",
          "title": "Reject ambiguous settlement amounts before import",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "intake",
          "dependsOn": [],
          "scenario": "Finance received a row containing 12,34 EUR beside rows using 12.34. The importer currently guesses the separator and silently books the wrong amount.",
          "acceptanceCriteria": [
            "Accept documented decimal-dot amounts and convert them to integer minor units.",
            "Reject mixed separators, excess precision, and unsupported currency codes with row numbers.",
            "A rejected file creates no settlement rows."
          ],
          "implementationNotes": [
            "The exercise supports USD and EUR, both with two minor digits; do not use floating-point arithmetic."
          ],
          "verification": [
            "Import 0.01, 12.34, and a negative refund amount exactly.",
            "Reject 12,34 and 1.005 without partial writes."
          ],
          "deliverables": [
            "Settlement input contract and parser regression fixtures"
          ],
          "rollout": "Run validation against saved synthetic files before enabling persistence; revert the parser behind the importer flag.",
          "skills": [
            "Input validation",
            "Money arithmetic",
            "Error contracts"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "19e07eb7-371b-4916-806a-3f17dc950ab1",
          "key": "BILL-102",
          "title": "Make repeated settlement uploads converge on one batch",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "intake",
          "dependsOn": [
            "BILL-101"
          ],
          "scenario": "An upload times out after committing. Finance retries the same file and sees every payout twice. Two browser tabs can also submit it together.",
          "acceptanceCriteria": [
            "Identical bytes within one merchant resolve to the same batch identity.",
            "Concurrent submissions create one committed batch and one set of rows.",
            "A different file with a reused client request key returns a conflict."
          ],
          "implementationNotes": [
            "Scope deduplication to the merchant and retain the original content hash."
          ],
          "verification": [
            "Submit the same file concurrently and compare persisted counts.",
            "Reuse a request key with a changed amount and assert conflict."
          ],
          "deliverables": [
            "Idempotent import command and concurrency reproduction"
          ],
          "rollout": "Enable for one synthetic merchant; rollback routing while preserving committed batch identities.",
          "skills": [
            "Idempotency",
            "Transactions",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "72799d15-f9b5-4998-bc2e-77e4c17e1930",
          "key": "BILL-103",
          "title": "Add a finance-readable import rejection report",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "intake",
          "dependsOn": [
            "BILL-101"
          ],
          "scenario": "Support currently pastes a stack trace into the finance channel when a file fails. Finance needs row-level corrections without exposure to provider tokens or infrastructure details.",
          "acceptanceCriteria": [
            "Report row number, field, stable reason code, and a plain-English correction hint.",
            "Cap the report at 100 errors and state the total omitted count.",
            "Require merchant authorization before downloading a report."
          ],
          "implementationNotes": [
            "Do not echo complete source rows or payment instrument data."
          ],
          "verification": [
            "Show distinct corrections for missing reference and invalid currency.",
            "Deny another merchant and confirm a token-like cell is absent."
          ],
          "deliverables": [
            "Bounded rejection report endpoint and example response"
          ],
          "rollout": "Expose reports for new imports first; disable downloads without deleting import audit records.",
          "skills": [
            "API design",
            "Authorization",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c30621b0-bf4a-47d5-a9ab-b4129e1cacb8",
          "key": "BILL-104",
          "title": "Match settlement lines without combining currencies",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "reconcile",
          "dependsOn": [
            "BILL-102"
          ],
          "scenario": "Provider reference pay_204 exists on a EUR invoice, but a malformed USD settlement row shares the reference. The current join marks the invoice paid.",
          "acceptanceCriteria": [
            "Match only within merchant, reference, and currency boundaries.",
            "Represent matched, unmatched, and conflicting lines separately.",
            "Calculate batch totals independently for each currency."
          ],
          "implementationNotes": [
            "A reference match with a currency mismatch is a conflict, never an exchange-rate conversion."
          ],
          "verification": [
            "Match a complete EUR batch to its invoices.",
            "Keep same-reference USD and cross-merchant rows unresolved."
          ],
          "deliverables": [
            "Reconciliation query and currency-conflict fixture"
          ],
          "rollout": "Compare dry-run classifications with the synthetic finance baseline before switching reports.",
          "skills": [
            "SQL",
            "Domain modeling",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7a35182a-6dc3-46b7-a660-d2e63194b9c5",
          "key": "BILL-105",
          "title": "Carry partial refunds across settlement days",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "reconcile",
          "dependsOn": [
            "BILL-104"
          ],
          "scenario": "A 100.00 charge receives refunds of 20.00 on Monday and 15.00 on Thursday. The report subtracts only the latest refund, overstating net revenue by 20.00.",
          "acceptanceCriteria": [
            "Net the charge against all distinct posted refunds in the selected cutoff.",
            "Keep pending refunds visible but outside settled totals.",
            "Flag cumulative refunds above the captured amount without silently clipping them."
          ],
          "implementationNotes": [
            "Preserve each provider refund identity and posting timestamp; never overwrite the original charge."
          ],
          "verification": [
            "Assert net 65.00 after both refunds and 80.00 at Monday cutoff.",
            "Replay a refund and inject an excess refund; check deduplication and conflict."
          ],
          "deliverables": [
            "Append-only refund matching change and cutoff examples"
          ],
          "rollout": "Recompute a shadow report for one month; retain the previous report revision for comparison.",
          "skills": [
            "Temporal data",
            "Ledger invariants",
            "Regression analysis"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "17f73b86-1e7c-43bb-a1af-c8b64c7e05ae",
          "key": "BILL-106",
          "title": "Record discrepancy decisions without editing source entries",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "reconcile",
          "dependsOn": [
            "BILL-104"
          ],
          "scenario": "Finance has confirmed that a 0.03 difference is a provider fee adjustment. They need to explain it without changing the settlement CSV or marking every mismatch resolved automatically.",
          "acceptanceCriteria": [
            "An authorized reviewer can append a reason and decision to one discrepancy.",
            "Concurrent decisions against the same revision produce one success and one conflict.",
            "Reports show the original difference and complete decision history."
          ],
          "implementationNotes": [
            "A decision changes review state, not the immutable amounts or provider provenance."
          ],
          "verification": [
            "Resolve and reopen a discrepancy while preserving both decisions.",
            "Reject stale revisions and an actor lacking finance-review permission."
          ],
          "deliverables": [
            "Discrepancy decision API and history contract"
          ],
          "rollout": "Gate the command to a test finance role; disable writes while keeping history readable on rollback.",
          "skills": [
            "Optimistic concurrency",
            "Auditability",
            "RBAC"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 20
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "623302ca-54bd-4cb4-91fc-8c14e8caa875",
          "key": "BILL-107",
          "title": "Freeze a close report against a reproducible cutoff",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BILL-105",
            "BILL-106"
          ],
          "scenario": "The April report changed after a late settlement arrived in May. Finance needs to explain what was known at close while still showing corrections in a new revision.",
          "acceptanceCriteria": [
            "Freeze source identities, cutoff, calculation version, and report hash for a close revision.",
            "Later imports cannot mutate the frozen report.",
            "A correction creates a new linked revision with explicit differences."
          ],
          "implementationNotes": [
            "Distinguish provider effective time from system receipt time; document which governs inclusion."
          ],
          "verification": [
            "Regenerate a frozen revision and compare canonical hashes.",
            "Import a backdated settlement after close and prove the old revision is unchanged."
          ],
          "deliverables": [
            "Versioned close report design, implementation, and correction walkthrough"
          ],
          "rollout": "Introduce revisioned closes in parallel with the current export; retain old readers until reconciliation agrees.",
          "skills": [
            "Snapshot consistency",
            "Temporal modeling",
            "Canonical hashing",
            "Migration design"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c809f0fc-1f55-4e16-a25d-8452a8c1a8ac",
          "key": "BILL-108",
          "title": "Recover an import after the queue acknowledgement is lost",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operate",
          "dependsOn": [
            "BILL-102",
            "BILL-104"
          ],
          "scenario": "The database commits an accepted batch and the API process exits before enqueueing reconciliation. The UI remains on Processing until someone runs SQL manually.",
          "acceptanceCriteria": [
            "Accepted batch and dispatch intent commit atomically.",
            "Restarted dispatch delivers pending work with a deterministic job identity.",
            "Repeated delivery produces the same reconciliation result without duplicate entries."
          ],
          "implementationNotes": [
            "Keep provider payloads out of queue metadata; use a durable batch identifier."
          ],
          "verification": [
            "Interrupt after database commit and recover through the dispatcher.",
            "Deliver the same job twice and compare the ledger and audit counts."
          ],
          "deliverables": [
            "Transactional dispatch path and crash-recovery reproduction"
          ],
          "rollout": "Start dispatch in observe mode, then enable pending batches; pause dispatch to rollback without losing intent.",
          "skills": [
            "Outbox",
            "Queue semantics",
            "Failure recovery"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a088a39d-2bde-4f74-8b26-94f54bf591a0",
          "key": "BILL-109",
          "title": "Alert when a merchant close is blocked by stale imports",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "operate",
          "dependsOn": [
            "BILL-108"
          ],
          "scenario": "Operations sees a healthy API while three accepted imports have made no progress for 45 minutes. Finance discovers the blockage at the end of the day.",
          "acceptanceCriteria": [
            "Expose accepted-to-completed age and counts by bounded processing state.",
            "Alert after the oldest accepted batch exceeds 15 minutes for two observations.",
            "The runbook identifies the batch safely and distinguishes retryable from invalid input failures."
          ],
          "implementationNotes": [
            "Avoid merchant IDs, file names, and references as metric labels."
          ],
          "verification": [
            "Advance a controlled clock to trigger a stale-batch alert.",
            "Confirm a rejected file does not trigger queue-lag paging."
          ],
          "deliverables": [
            "Metrics, alert rule, and import recovery runbook"
          ],
          "rollout": "Observe alerts for one synthetic close cycle before enabling paging; disable the rule if it pages on rejected files.",
          "skills": [
            "Observability",
            "Alert design",
            "Incident operations"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5b487ee4-16a4-4370-b996-73e39c62ee7c",
          "key": "BILL-110",
          "title": "Paginate the discrepancy export during a large close",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operate",
          "dependsOn": [
            "BILL-107"
          ],
          "scenario": "A synthetic close with 250,000 discrepancies exhausts API memory because the export loads every row. Finance also receives spreadsheet formulas when a reference begins with an equals sign.",
          "acceptanceCriteria": [
            "Stream a stable report revision in bounded pages without omissions or duplicate rows.",
            "Neutralize spreadsheet formula prefixes in text cells.",
            "Abort export promptly on client disconnect and preserve authorization on resume."
          ],
          "implementationNotes": [
            "Use a repeatable 250,000-row synthetic benchmark and report peak memory rather than assuming scalability."
          ],
          "verification": [
            "Compare streamed row identities with the frozen report count.",
            "Export malicious-looking references and cancel halfway through; check escaping and cleanup."
          ],
          "deliverables": [
            "Bounded CSV export and benchmark report"
          ],
          "rollout": "Offer the streamed export alongside the old limit; rollback the route while retaining report revisions.",
          "skills": [
            "Streaming",
            "Pagination",
            "CSV safety",
            "Performance measurement"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "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": []
        }
      ]
    },
    {
      "id": "8af906b0-ab4a-4506-b8c8-678d05d45087",
      "key": "PIPE",
      "title": "Make parcel tracking survive messy carrier events",
      "field": "Data engineering",
      "summary": "Ingest delayed, duplicated, and corrected parcel events into an explainable tracking timeline.",
      "context": "A fictional delivery marketplace receives JSON batches from three carriers. One uses local timestamps, another retries whole batches, and a third corrects delivery scans. Customer support needs a stable timeline rather than the last payload received.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "BullMQ",
        "S3-compatible storage"
      ],
      "prerequisites": [
        "JSON schema validation",
        "SQL queries",
        "Event-time concepts"
      ],
      "developerValue": "Practice ingestion contracts, deduplication, event-time reconciliation, and replayable data repair.",
      "companyValue": "Examine how an engineer preserves source lineage and handles bad partner data without losing valid business events.",
      "delivery": "Ten tickets in three phases; hand off synthetic carrier fixtures, a replay procedure, and a support-readable tracking projection.",
      "phases": [
        {
          "id": "receive",
          "title": "Receive and quarantine",
          "goal": "Keep valid events and explain rejected input."
        },
        {
          "id": "timeline",
          "title": "Build the tracking timeline",
          "goal": "Resolve time, order, and corrections explicitly."
        },
        {
          "id": "repair",
          "title": "Replay and monitor",
          "goal": "Repair data safely and detect silent ingestion gaps."
        }
      ],
      "tickets": [
        {
          "id": "d9130ed1-dbd5-45b3-881d-bc2160eb2a53",
          "key": "PIPE-101",
          "title": "Validate carrier events without discarding a whole batch",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "receive",
          "dependsOn": [],
          "scenario": "A 200-event batch contains one scan with an empty parcel reference. The importer rejects all 200, leaving valid deliveries invisible until the next carrier export.",
          "acceptanceCriteria": [
            "Classify each row as accepted or rejected with a source position.",
            "Require carrier event ID, parcel reference, event code, and timestamp.",
            "Accepted and rejected counts sum to the received count."
          ],
          "implementationNotes": [
            "Publish the partial-acceptance contract; never silently drop malformed rows."
          ],
          "verification": [
            "Process 199 valid rows and one malformed row with exact counts.",
            "Reject oversized batches and invalid JSON without accepted events."
          ],
          "deliverables": [
            "Batch validation contract and mixed-validity fixtures"
          ],
          "rollout": "Enable partial acceptance for one synthetic carrier; retain rejection reports if the route is disabled.",
          "skills": [
            "Schema validation",
            "Batch processing",
            "Error reporting"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f5096420-95f6-423c-8f3c-afd015ac3c35",
          "key": "PIPE-102",
          "title": "Attach source lineage to every accepted scan",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "receive",
          "dependsOn": [
            "PIPE-101"
          ],
          "scenario": "Support found a delivery scan that neither carrier recognizes. The normalized table contains no batch hash, row position, or parser version to trace its origin.",
          "acceptanceCriteria": [
            "Store batch hash, row position, carrier identity, receipt time, and parser version.",
            "Link normalized records to a bounded source artifact reference.",
            "Restrict artifact retrieval to ingest support permission."
          ],
          "implementationNotes": [
            "Use synthetic data; do not copy full payloads into logs."
          ],
          "verification": [
            "Trace two accepted rows to their exact source positions.",
            "Deny a tracking viewer direct source-artifact access."
          ],
          "deliverables": [
            "Lineage migration and trace example"
          ],
          "rollout": "Populate new imports first and mark untraceable legacy rows explicitly.",
          "skills": [
            "Data lineage",
            "Schema evolution",
            "Least privilege"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "cbf6a2bf-969e-4098-8ed5-25c8b6abf07a",
          "key": "PIPE-103",
          "title": "Deduplicate carrier retries and surface changed duplicates",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "receive",
          "dependsOn": [
            "PIPE-102"
          ],
          "scenario": "Carrier Cedar retries yesterday's batch. Most event IDs are identical, but one delivery timestamp changed from 14:03 to 14:30 and is overwritten silently.",
          "acceptanceCriteria": [
            "Identical carrier-scoped event IDs and content replay without duplicate scans.",
            "Changed content under an existing ID enters a conflict record.",
            "Concurrent duplicate imports converge to one accepted event."
          ],
          "implementationNotes": [
            "An event ID from another carrier is a separate identity."
          ],
          "verification": [
            "Replay the batch twice and compare accepted counts.",
            "Submit changed content and concurrent duplicates; inspect originals and conflicts."
          ],
          "deliverables": [
            "Deduplication constraint and conflict handling contract"
          ],
          "rollout": "Observe duplicate classifications before enforcement; preserve originals if conflict routing is rolled back.",
          "skills": [
            "Idempotency",
            "Unique constraints",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "993a040d-4c36-4f11-9c7d-3b6e4c07b805",
          "key": "PIPE-104",
          "title": "Stop interpreting offset-free scans as server-local time",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "timeline",
          "dependsOn": [
            "PIPE-102"
          ],
          "scenario": "A carrier sends 2025-11-02 01:30 in its configured New York time zone. The importer guesses one occurrence during the clock change and displays delivery before pickup.",
          "acceptanceCriteria": [
            "Normalize explicit-offset timestamps to UTC.",
            "Quarantine ambiguous or nonexistent local times instead of guessing.",
            "Preserve original timestamp text and normalization policy version."
          ],
          "implementationNotes": [
            "Use explicit carrier time-zone configuration; process time zone cannot define event meaning."
          ],
          "verification": [
            "Normalize equivalent UTC and offset timestamps to one instant.",
            "Quarantine repeated-hour and skipped-hour local timestamps."
          ],
          "deliverables": [
            "Timestamp normalization policy and clock-change fixtures"
          ],
          "rollout": "Shadow-normalize historical fixtures and review differences before switching timeline timestamps.",
          "skills": [
            "Time zones",
            "Data normalization",
            "Ambiguity handling"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "604f6558-71c2-4d0c-b8a7-1c872f206c41",
          "key": "PIPE-105",
          "title": "Keep a late pickup scan from undoing delivered status",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "timeline",
          "dependsOn": [
            "PIPE-103",
            "PIPE-104"
          ],
          "scenario": "A DELIVERED scan arrives at 16:00, followed by a delayed PICKED_UP scan from 08:00. The tracking card switches back to In transit because it uses receipt order.",
          "acceptanceCriteria": [
            "Build the timeline from event time with a documented deterministic tie-breaker.",
            "Retain late scans without regressing current delivery state.",
            "Represent inconsistent event sequences with a visible anomaly reason."
          ],
          "implementationNotes": [
            "Receipt time remains diagnostic information, not a substitute for event time."
          ],
          "verification": [
            "Import pickup and delivery in both arrival orders and compare projections.",
            "Add a pickup dated after delivery and inspect the anomaly."
          ],
          "deliverables": [
            "Tracking projection and out-of-order fixtures"
          ],
          "rollout": "Compare projections in a shadow table; switch reads after reviewing differences.",
          "skills": [
            "Event-time processing",
            "Determinism",
            "Read models"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9a908f23-3f85-4d27-b27e-407e0d24a03a",
          "key": "PIPE-106",
          "title": "Apply an explicit carrier correction without erasing the scan",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "timeline",
          "dependsOn": [
            "PIPE-105"
          ],
          "scenario": "A driver scanned the wrong parcel as delivered. The carrier now sends corrections referencing the original scan; support must see why Delivered became In transit.",
          "acceptanceCriteria": [
            "Require a same-carrier, same-parcel target event.",
            "Keep the original scan and append the correction relationship.",
            "Recompute the projection and expose the withdrawn delivery scan."
          ],
          "implementationNotes": [
            "Missing targets become pending references with bounded retry, never permission to delete arbitrary events."
          ],
          "verification": [
            "Apply a valid delivery withdrawal and inspect history and state.",
            "Reject a cross-parcel target and resolve a target that arrives later."
          ],
          "deliverables": [
            "Correction contract and deferred-reference recovery"
          ],
          "rollout": "Enable the configured correction-capable carrier; retain history if projection readers are rolled back.",
          "skills": [
            "Append-only models",
            "Referential integrity",
            "Event correction"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8e816118-ac89-49b8-a630-279a8d55ef66",
          "key": "PIPE-107",
          "title": "Replay a parser fix into a new projection generation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "repair",
          "dependsOn": [
            "PIPE-106"
          ],
          "scenario": "Parser v3 mislabeled ARRIVED_AT_DEPOT as DELIVERED. Operations needs to rebuild 100,000 synthetic scans while fresh batches continue arriving.",
          "acceptanceCriteria": [
            "Replay immutable sources into an isolated projection generation.",
            "Capture a high-water mark and include arrivals through the documented cutover boundary.",
            "Switch readers atomically only after counts and anomaly checks pass."
          ],
          "implementationNotes": [
            "Record parser and projection versions; rebuilding cannot mutate sources."
          ],
          "verification": [
            "Replay twice and compare deterministic output hashes.",
            "Interrupt replay and add events during catch-up; prove no cutover gaps."
          ],
          "deliverables": [
            "Replay command, generation cutover, and recovery runbook"
          ],
          "rollout": "Keep the previous generation readable and revert its pointer if comparison fails.",
          "skills": [
            "Replay architecture",
            "Cutover consistency",
            "Data repair",
            "Operational safety"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "eb203f46-d0da-45b4-b0c8-448b80c671ae",
          "key": "PIPE-108",
          "title": "Throttle ingestion without losing accepted batches",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "repair",
          "dependsOn": [
            "PIPE-103"
          ],
          "scenario": "After an outage, one carrier sends a day's events in 30 seconds. Memory pressure restarts workers and the API cannot tell which batches were accepted.",
          "acceptanceCriteria": [
            "Bound request size and active ingest concurrency.",
            "Acknowledge only after durable source and dispatch intent exist.",
            "Return retryable overload before accepting work above the backlog limit."
          ],
          "implementationNotes": [
            "Distinguish rejected-before-acceptance from delayed-after-acceptance responses."
          ],
          "verification": [
            "Burst synthetic batches and account for every acknowledged batch.",
            "Fail storage and saturate the queue; assert no false acceptance."
          ],
          "deliverables": [
            "Backpressure limits and accepted-batch accounting test"
          ],
          "rollout": "Start with conservative limits; reduce intake while draining accepted work if lag grows.",
          "skills": [
            "Backpressure",
            "Durable acceptance",
            "Capacity measurement"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "23a673fc-5685-497a-b9ab-73e7c49f45df",
          "key": "PIPE-109",
          "title": "Detect a quiet carrier feed independently of queue health",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "repair",
          "dependsOn": [
            "PIPE-102"
          ],
          "scenario": "Every worker is healthy, but Carrier Elm has not sent a batch since morning. No alert fires because all dashboards measure processing failures.",
          "acceptanceCriteria": [
            "Track last accepted receipt separately from event-time freshness.",
            "Apply each carrier's configured operating schedule and lateness budget.",
            "Feed-gap alerts name the integration and diagnostic step without parcel data."
          ],
          "implementationNotes": [
            "Empty valid batches count as receipts but do not imply fresh parcel scans."
          ],
          "verification": [
            "Advance the clock during operating hours to trigger a feed-gap alert.",
            "Suppress quiet-window paging and distinguish stale event times."
          ],
          "deliverables": [
            "Freshness metrics, alert rule, and escalation notes"
          ],
          "rollout": "Review a simulated week in report-only mode before enabling paging.",
          "skills": [
            "Data observability",
            "Schedules",
            "Alert semantics"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "cb80ad39-c5a9-4971-94b4-4377c548e205",
          "key": "PIPE-110",
          "title": "Expire raw tracking payloads while retaining minimal lineage",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "repair",
          "dependsOn": [
            "PIPE-107"
          ],
          "scenario": "Carrier payloads contain recipient notes unnecessary after the exercise's 30-day debugging window. A cleanup script removes artifacts still used by an active replay.",
          "acceptanceCriteria": [
            "Delete eligible raw artifacts after configured retention.",
            "Protect artifacts referenced by an active authorized replay lease.",
            "Retain minimal hashes, deletion receipts, and normalized non-sensitive facts."
          ],
          "implementationNotes": [
            "Thirty days is a fictional exercise policy; expired leases cannot pin data forever."
          ],
          "verification": [
            "Expire an eligible artifact and verify its deletion record.",
            "Protect an active replay artifact, then expire the lease and delete it."
          ],
          "deliverables": [
            "Retention job and replay-lease cleanup cases"
          ],
          "rollout": "Review a dry-run deletion manifest before enabling deletion on synthetic artifacts.",
          "skills": [
            "Retention",
            "Lease lifecycle",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "b164206a-8a79-461f-8c71-15e635e0b531",
      "key": "LAKE",
      "title": "Rebuild a trustworthy merchant analytics mart",
      "field": "Data engineering",
      "summary": "Replace a fragile daily sales query with versioned, reconcilable warehouse metrics.",
      "context": "A fictional marketplace reports daily sales to merchants. Refund joins inflate revenue, merchants close books in different time zones, and backfills compete with nightly loads. All source orders and merchants are synthetic.",
      "stack": [
        "SQL",
        "PostgreSQL",
        "TypeScript",
        "Object storage"
      ],
      "prerequisites": [
        "SQL joins and aggregates",
        "Batch pipelines",
        "Metric definitions"
      ],
      "developerValue": "Practice metric contracts, historical dimensions, incremental processing, and reproducible warehouse releases.",
      "companyValue": "Inspect whether an engineer can reconcile business totals and explain metric changes in a reviewable data product.",
      "delivery": "Ten issues across definition, modeling, and release; deliver SQL, synthetic reconciliation fixtures, and an analyst handoff.",
      "phases": [
        {
          "id": "define",
          "title": "Agree on the numbers",
          "goal": "Make metric grain and source assumptions explicit."
        },
        {
          "id": "model",
          "title": "Build reliable models",
          "goal": "Handle refunds, dimensions, dates, and incremental updates."
        },
        {
          "id": "release",
          "title": "Release the mart safely",
          "goal": "Reconcile, backfill, and govern a versioned dataset."
        }
      ],
      "tickets": [
        {
          "id": "860da3db-7a5a-49f1-91ad-71abdb6f46c5",
          "key": "LAKE-101",
          "title": "Write the daily net-sales contract with worked rows",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "define",
          "dependsOn": [],
          "scenario": "Finance subtracts posted refunds from captured charges; product subtracts pending refunds too. Both dashboards use Net sales and disagree for merchant M-17.",
          "acceptanceCriteria": [
            "Define grain, inclusion states, currencies, and reporting date.",
            "Provide six worked rows covering captures, refunds, pending entries, and voids.",
            "Explicitly exclude tax and shipping from this exercise's net-sales metric."
          ],
          "implementationNotes": [
            "Do not resolve ambiguity by silently adopting whichever query exists."
          ],
          "verification": [
            "Recalculate worked totals independently from the contract.",
            "Demonstrate why pending refunds and voids do not change posted totals."
          ],
          "deliverables": [
            "Versioned metric contract with executable example assertions"
          ],
          "rollout": "Review worked examples with the synthetic analyst role before downstream adoption.",
          "skills": [
            "Metric definitions",
            "Data contracts",
            "Analytical reasoning"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8cc8501a-e1ed-438e-a4ac-b713d302c608",
          "key": "LAKE-102",
          "title": "Profile source keys before trusting the order feed",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "define",
          "dependsOn": [],
          "scenario": "The warehouse assumes order_id is globally unique, but two merchants both supplied order 7001. Daily deduplication keeps only one.",
          "acceptanceCriteria": [
            "Report duplicates at global and merchant-scoped order grain.",
            "Count missing merchant IDs, order IDs, currencies, and update timestamps.",
            "Produce bounded sample references without customer details."
          ],
          "implementationNotes": [
            "Profiling reports anomalies and never deletes source rows."
          ],
          "verification": [
            "Detect intentionally duplicated merchant/order pairs.",
            "Keep same-ID orders from different merchants distinct and report missing keys."
          ],
          "deliverables": [
            "Read-only profiling SQL and annotated output"
          ],
          "rollout": "Profile before changing ingestion; retain only minimized aggregate reports.",
          "skills": [
            "Data profiling",
            "Composite keys",
            "SQL"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f9941471-d54b-43c5-b00b-e447d95c0ddc",
          "key": "LAKE-103",
          "title": "Remove the order-line and refund join fan-out",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "LAKE-101",
            "LAKE-102"
          ],
          "scenario": "An order with three lines and two refunds becomes six joined rows. The daily mart counts each captured amount several times although the ledger is correct.",
          "acceptanceCriteria": [
            "Aggregate sources at declared grains before joining.",
            "Count each capture and posted refund exactly once.",
            "Keep orders without refunds and flag orphan refunds."
          ],
          "implementationNotes": [
            "DISTINCT on monetary values is not a fix; equal legitimate amounts remain distinct."
          ],
          "verification": [
            "Reconcile a three-line, two-refund order to its source total.",
            "Include equal-value captures and an orphan refund to expose accidental deduplication."
          ],
          "deliverables": [
            "Corrected SQL and join-fan-out fixture"
          ],
          "rollout": "Compare a synthetic month and publish a new metric version with its correction delta.",
          "skills": [
            "Join cardinality",
            "Aggregation",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "769f9fe4-d4f5-4db0-80ac-cb6991f18f4f",
          "key": "LAKE-104",
          "title": "Assign sales to the merchant's reporting day",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "LAKE-101"
          ],
          "scenario": "A 23:30 Los Angeles sale appears on tomorrow's report because the mart groups UTC dates. Merchants cannot reconcile their register totals.",
          "acceptanceCriteria": [
            "Derive reporting dates from the merchant's configured time zone.",
            "Retain the original UTC instant.",
            "Handle 23-hour and 25-hour days without lost or duplicate source rows."
          ],
          "implementationNotes": [
            "An unknown time zone blocks the affected partition instead of defaulting silently."
          ],
          "verification": [
            "Assign sales on both sides of local midnight correctly.",
            "Exercise clock-change boundaries and an invalid time zone."
          ],
          "deliverables": [
            "Reporting-date model and boundary fixtures"
          ],
          "rollout": "Compare date-shifted totals before switching the synthetic merchant dashboard.",
          "skills": [
            "Time-zone modeling",
            "Date dimensions",
            "Data quality"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c1ae672f-dad4-488c-acd0-9c3a9b6ddda7",
          "key": "LAKE-105",
          "title": "Preserve historical merchant plans in revenue breakdowns",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "model",
          "dependsOn": [
            "LAKE-102",
            "LAKE-104"
          ],
          "scenario": "M-17 upgrades from Starter to Growth in June. Joining today's merchant record moves all earlier revenue into Growth and rewrites quarterly comparisons.",
          "acceptanceCriteria": [
            "Join sales to the plan effective at the sale instant.",
            "Reject overlapping effective intervals per merchant.",
            "Represent missing history explicitly instead of using today's plan."
          ],
          "implementationNotes": [
            "Use inclusive-start, exclusive-end intervals and document their boundary."
          ],
          "verification": [
            "Assign sales before and at the upgrade instant correctly.",
            "Detect interval overlaps and gaps without double-counting."
          ],
          "deliverables": [
            "Historical dimension model and interval checks"
          ],
          "rollout": "Backfill synthetic history and retain the prior dimension version until totals reconcile.",
          "skills": [
            "Slowly changing dimensions",
            "Temporal joins",
            "Integrity constraints"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "48420dcb-3f18-49bf-9d14-cda6e9dca4e7",
          "key": "LAKE-106",
          "title": "Pick up late refunds in an incremental load",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "model",
          "dependsOn": [
            "LAKE-103",
            "LAKE-104"
          ],
          "scenario": "The nightly job filters on order creation date. A refund posted today against a six-week-old order never reaches the mart.",
          "acceptanceCriteria": [
            "Select changed keys using source change positions or update times.",
            "Recompute affected reporting partitions beyond today's orders.",
            "Advance checkpoints only after selected changes commit."
          ],
          "implementationNotes": [
            "Document watermark precision and ties; overlapping reads must be idempotent."
          ],
          "verification": [
            "Apply a late refund and reconcile its affected date.",
            "Fail mid-load and replay equal-timestamp updates without loss or duplication."
          ],
          "deliverables": [
            "Incremental model and checkpoint recovery tests"
          ],
          "rollout": "Compare incremental and full builds on identical synthetic changes before switching schedules.",
          "skills": [
            "Incremental processing",
            "Watermarks",
            "Idempotent loads"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f1c26437-3860-4bd5-a65f-997651d8af2b",
          "key": "LAKE-107",
          "title": "Prevent a backfill from replacing a newer nightly partition",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "release",
          "dependsOn": [
            "LAKE-105",
            "LAKE-106"
          ],
          "scenario": "A noon backfill finishes after the nightly job. Its older snapshot overwrites May's newer partition and removes refunds received at 18:00.",
          "acceptanceCriteria": [
            "Associate each generation with a source snapshot boundary.",
            "Reject cutover when another generation superseded the intended partition revision.",
            "Resume backfills without publishing incomplete partition sets."
          ],
          "implementationNotes": [
            "Document locking or compare-and-swap policy; finish time is not freshness."
          ],
          "verification": [
            "Overlap backfill and nightly load; prove the fresher state wins.",
            "Interrupt before publication and verify readers see a complete prior generation."
          ],
          "deliverables": [
            "Partition publication protocol and overlap reproduction"
          ],
          "rollout": "Publish shadow generations first; retain the previous complete manifest for rollback.",
          "skills": [
            "Snapshot isolation",
            "Batch concurrency",
            "Atomic publication",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e50f9057-920e-4a92-808a-dc112da2cefd",
          "key": "LAKE-108",
          "title": "Block publication when revenue fails source reconciliation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "release",
          "dependsOn": [
            "LAKE-103",
            "LAKE-106"
          ],
          "scenario": "A transformation passes SQL syntax checks while dropping one currency partition. The dashboard refresh succeeds and hides the revenue gap.",
          "acceptanceCriteria": [
            "Compare counts and exact minor-unit totals by merchant, date, and currency.",
            "Block unexplained differences while preserving the previous generation.",
            "Report bounded discrepancy references and transformation version."
          ],
          "implementationNotes": [
            "Percentage tolerance cannot excuse exact integer ledger mismatches."
          ],
          "verification": [
            "Publish a fully reconciled fixture.",
            "Drop one EUR partition and assert publication blocks with an actionable report."
          ],
          "deliverables": [
            "Reconciliation gate and discrepancy report"
          ],
          "rollout": "Observe known fixtures first, then enforce the gate before manifest publication.",
          "skills": [
            "Data quality gates",
            "Financial reconciliation",
            "Release controls"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2c5a8ca5-e926-47d7-b0b5-5f7b3650ac9f",
          "key": "LAKE-109",
          "title": "Separate merchant exports from the analyst-wide mart",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "release",
          "dependsOn": [
            "LAKE-108"
          ],
          "scenario": "Removing merchant_id from an export request returns every merchant's sales because the support route passes filters directly to an analyst-wide query.",
          "acceptanceCriteria": [
            "Derive merchant scope from authorized context at the export boundary.",
            "Expose only approved aggregate columns.",
            "Reject unbounded date ranges and cross-merchant access."
          ],
          "implementationNotes": [
            "An analyst credential cannot substitute for merchant authorization."
          ],
          "verification": [
            "Export permitted dates for one merchant with correct totals.",
            "Omit or replace merchant scope and request raw customer columns; assert denial."
          ],
          "deliverables": [
            "Scoped export boundary and authorization regression cases"
          ],
          "rollout": "Route one synthetic merchant through reduced credentials first; revoke export permission on scope failures.",
          "skills": [
            "Data access control",
            "Tenant boundaries",
            "Column minimization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8e1240e6-a04e-4a42-bdb4-9cb1dd597f0d",
          "key": "LAKE-110",
          "title": "Explain a metric release to the analyst on call",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "release",
          "dependsOn": [
            "LAKE-107",
            "LAKE-108"
          ],
          "scenario": "After a mart correction, May net sales changes and analysts need to know which rows moved. Build a synthetic before/after comparison and quantify the delta instead of assuming a target percentage.",
          "acceptanceCriteria": [
            "Document metric versions, source cutoff, and affected partitions.",
            "Break the delta into fan-out, late-refund, and reporting-day effects.",
            "Provide reproducible comparison queries and previous-manifest restoration steps."
          ],
          "implementationNotes": [
            "Label measured deltas as results from the synthetic fixture, not expected company impact."
          ],
          "verification": [
            "Reproduce the note's totals from the synthetic fixture created for this project.",
            "Exercise rollback and confirm the prior version is visible."
          ],
          "deliverables": [
            "Analyst release note and verified handoff checklist"
          ],
          "rollout": "Ship the note with the generation switch and record any rollback in the incident log.",
          "skills": [
            "Technical communication",
            "Data explainability",
            "Operational handoff"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "caa606e0-b31e-4e75-a62f-6c4f294f1a93",
      "key": "ROLL",
      "title": "Make a small service release recoverable",
      "field": "Platform engineering",
      "summary": "Build a release workflow that can distinguish a healthy process from a safe application version.",
      "context": "A fictional scheduling service has an API, a worker, and PostgreSQL. Releases use immutable images on two application instances. The team needs compatibility checks, staged traffic, and a rehearsed rollback without introducing a new orchestration platform.",
      "stack": [
        "TypeScript",
        "OCI image metadata",
        "PostgreSQL",
        "CI workflows"
      ],
      "prerequisites": [
        "HTTP health checks",
        "CI pipelines",
        "Database migrations"
      ],
      "developerValue": "Practice release contracts, compatibility windows, measurable canaries, and incident decisions on a modest application topology.",
      "companyValue": "Review whether an engineer can make deployments diagnosable and reversible while identifying when rollback is unsafe.",
      "delivery": "Ten phased issues using a synthetic service and simulated release provider; submit manifests, failure drills, and an operator handoff.",
      "phases": [
        {
          "id": "identity",
          "title": "Know what is running",
          "goal": "Establish artifact identity and useful health signals."
        },
        {
          "id": "safety",
          "title": "Control release risk",
          "goal": "Enforce compatibility, serialization, and staged rollout decisions."
        },
        {
          "id": "recovery",
          "title": "Recover with evidence",
          "goal": "Drain work, diagnose failures, and rehearse rollback."
        }
      ],
      "tickets": [
        {
          "id": "b7a9d0a1-ab9e-46eb-b1e5-26fe700a6709",
          "key": "ROLL-101",
          "title": "Display the exact release identity in diagnostics",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "identity",
          "dependsOn": [],
          "scenario": "Two API instances report version latest even though only one received yesterday's build. On call cannot connect a failing request to its deployed artifact.",
          "acceptanceCriteria": [
            "Expose build revision, immutable artifact digest, and deployment ID through an authorized diagnostic endpoint.",
            "Fail validation when a release manifest lacks immutable identity.",
            "Keep build secrets and environment values outside the response."
          ],
          "implementationNotes": [
            "The build injects identity; request parameters cannot override it."
          ],
          "verification": [
            "Read distinct diagnostics from two synthetic release versions.",
            "Reject a manifest containing only a mutable tag and inspect response redaction."
          ],
          "deliverables": [
            "Release manifest schema and diagnostic projection"
          ],
          "rollout": "Add diagnostics before changing deployment routing; remove endpoint exposure without changing artifact identities.",
          "skills": [
            "Artifact provenance",
            "Configuration",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f402689e-6dd3-47b2-aefc-de7d55a0d892",
          "key": "ROLL-102",
          "title": "Separate liveness from database readiness",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "identity",
          "dependsOn": [],
          "scenario": "A brief database outage makes the process liveness endpoint fail. The restart policy kills every API instance and turns a recoverable connection issue into a restart loop.",
          "acceptanceCriteria": [
            "Liveness reports whether the process can serve its own health handler.",
            "Readiness fails when required database operations cannot complete within a bounded timeout.",
            "Dependency errors return a stable diagnostic code without connection strings."
          ],
          "implementationNotes": [
            "A readiness probe must not create user records or run migrations."
          ],
          "verification": [
            "Assert both probes succeed with healthy synthetic dependencies.",
            "Disable the database and verify readiness fails while liveness remains successful."
          ],
          "deliverables": [
            "Separate health routes and dependency-outage reproduction"
          ],
          "rollout": "Switch traffic readiness first, then restart-policy probes; restore prior routing if probe semantics are misconfigured.",
          "skills": [
            "Health checks",
            "Dependency failures",
            "Operational contracts"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d87c1362-bc0a-447e-bcfb-cd0f853709e1",
          "key": "ROLL-103",
          "title": "Refuse deploys with incomplete runtime configuration",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "identity",
          "dependsOn": [
            "ROLL-101"
          ],
          "scenario": "The new worker image needs STORAGE_REGION, but its environment is missing the setting. The rollout reports success while every document job fails on first use.",
          "acceptanceCriteria": [
            "Validate required settings and allowed combinations before readiness succeeds.",
            "Produce setting names and reason codes without printing values.",
            "Validate API and worker manifests against their own declared configuration versions."
          ],
          "implementationNotes": [
            "Use dummy values in fixtures; configuration validation cannot contact production services."
          ],
          "verification": [
            "Validate complete API and worker manifests.",
            "Reject missing storage region and incompatible settings while checking log redaction."
          ],
          "deliverables": [
            "Configuration preflight and role-specific fixtures"
          ],
          "rollout": "Run preflight as an advisory CI step, then block invalid synthetic release manifests.",
          "skills": [
            "Typed configuration",
            "Fail-closed startup",
            "Secret redaction"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0d38a80a-e6f2-4e7c-94a5-08c4e7d06a3d",
          "key": "ROLL-104",
          "title": "Keep old API instances working during a column rename",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "safety",
          "dependsOn": [
            "ROLL-103"
          ],
          "scenario": "A migration renames booking.start to booking.starts_at before old API instances finish draining. Half the requests fail until every instance updates.",
          "acceptanceCriteria": [
            "Define expand, compatible application rollout, backfill, and contract stages.",
            "Prove old and new application versions work during the supported overlap.",
            "Block destructive cleanup while the old reader version remains active."
          ],
          "implementationNotes": [
            "Include rollback compatibility explicitly; a reverse rename alone is not a release strategy."
          ],
          "verification": [
            "Run mixed-version synthetic requests through the expanded schema.",
            "Attempt cleanup with an old instance present and assert the gate blocks."
          ],
          "deliverables": [
            "Versioned migration plan and mixed-version compatibility checks"
          ],
          "rollout": "Apply only expansion first; rollback application traffic before the contract stage if errors appear.",
          "skills": [
            "Expand-contract migrations",
            "Compatibility",
            "Release sequencing"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d59ab3d9-f718-44d3-8b6b-fc7de94307d2",
          "key": "ROLL-105",
          "title": "Prevent two release jobs from overwriting the same environment",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "safety",
          "dependsOn": [
            "ROLL-101",
            "ROLL-103"
          ],
          "scenario": "Two commits deploy simultaneously. The older job finishes last and marks its artifact current after the newer release already passed validation.",
          "acceptanceCriteria": [
            "Serialize mutations per environment with a bounded renewable lease.",
            "Reject state updates from expired or superseded lease holders.",
            "Record the winning release identity and every rejected stale update."
          ],
          "implementationNotes": [
            "A process-local mutex cannot coordinate independent CI jobs."
          ],
          "verification": [
            "Race two simulated releases and inspect one current manifest.",
            "Expire a lease, acquire a successor, and prove the old holder cannot publish."
          ],
          "deliverables": [
            "Release lease protocol and stale-writer regression"
          ],
          "rollout": "Enable serialization on the test environment; disable dispatch while investigating lease failures.",
          "skills": [
            "Distributed leases",
            "Fencing",
            "CI concurrency"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "f07c604e-e325-417b-a5ba-e9a518c59c1e",
          "key": "ROLL-106",
          "title": "Base canary decisions on enough comparable requests",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "safety",
          "dependsOn": [
            "ROLL-102",
            "ROLL-104",
            "ROLL-105"
          ],
          "scenario": "A release automatically promotes after five error-free canary requests while the stable version serves thousands. Low traffic makes an untested version look healthy.",
          "acceptanceCriteria": [
            "Require a configured minimum request count and observation window before promotion.",
            "Compare matching route classes with error-rate and latency budgets declared in the fixture.",
            "Return HOLD for insufficient traffic and ABORT for breached safety thresholds."
          ],
          "implementationNotes": [
            "Use bounded route labels; a percentage alone cannot justify a decision without sample counts."
          ],
          "verification": [
            "Promote a synthetic canary with adequate comparable traffic.",
            "Exercise sparse traffic, a route-mix shift, and rising errors; inspect HOLD or ABORT reasons."
          ],
          "deliverables": [
            "Canary decision function, fixture traces, and decision report"
          ],
          "rollout": "Run decisions in observe mode against simulated traffic before allowing the simulated provider to advance stages.",
          "skills": [
            "Release analysis",
            "Measurement design",
            "Decision systems",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "46906410-3c14-47cd-b9c4-7e480b6c75d4",
          "key": "ROLL-107",
          "title": "Drain long requests before retiring an API instance",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "recovery",
          "dependsOn": [
            "ROLL-102"
          ],
          "scenario": "During release, an instance exits halfway through a report download. The load balancer keeps sending new requests during its shutdown grace period.",
          "acceptanceCriteria": [
            "Mark the instance unready before starting its bounded drain period.",
            "Allow existing requests to complete until the documented deadline.",
            "Close remaining connections and report forced terminations at deadline without hanging shutdown."
          ],
          "implementationNotes": [
            "Do not count idle keep-alive connections as unfinished business requests indefinitely."
          ],
          "verification": [
            "Start a long synthetic request, initiate shutdown, and observe completion.",
            "Keep a request stuck beyond the deadline and confirm bounded exit and termination count."
          ],
          "deliverables": [
            "Graceful shutdown behavior and request-drain reproduction"
          ],
          "rollout": "Exercise draining on one test instance; restore the previous grace settings if traffic does not stop arriving.",
          "skills": [
            "Graceful shutdown",
            "HTTP lifecycle",
            "Timeouts"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2b37920d-080d-40a8-aeb5-b1d5e0bab23c",
          "key": "ROLL-108",
          "title": "Do not roll back a worker into an unreadable job format",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recovery",
          "dependsOn": [
            "ROLL-104",
            "ROLL-105"
          ],
          "scenario": "Worker v8 enqueues a new payload shape. Rolling back to v7 starts a retry storm because v7 cannot parse jobs already accepted by v8.",
          "acceptanceCriteria": [
            "Version job envelopes and declare the worker versions able to consume each version.",
            "Gate rollback when queued work would become unreadable.",
            "Provide a safe drain or compatibility path that preserves accepted job identities."
          ],
          "implementationNotes": [
            "Do not rewrite historical payloads in place or discard incompatible jobs to make rollback green."
          ],
          "verification": [
            "Process old and new fixture envelopes with the declared compatible worker.",
            "Attempt an incompatible rollback with queued v8 work and assert a useful blocking reason."
          ],
          "deliverables": [
            "Job compatibility matrix and rollback preflight"
          ],
          "rollout": "Deploy backward readers before new writers; remove old readers only after the compatibility window closes.",
          "skills": [
            "Message evolution",
            "Rollback safety",
            "Queue operations",
            "Compatibility contracts"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "43d0beae-b8d1-475e-b862-b98121b28667",
          "key": "ROLL-109",
          "title": "Attach a release marker to bounded operational telemetry",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recovery",
          "dependsOn": [
            "ROLL-101",
            "ROLL-106"
          ],
          "scenario": "An error spike starts near a deploy, but the dashboard has no release event or stable artifact link. Engineers compare screenshots and guess which change was live.",
          "acceptanceCriteria": [
            "Emit a release event with environment, deployment ID, artifact digest, and stage outcome.",
            "Link stage failures to sanitized diagnostic references.",
            "Keep request bodies, secret values, and arbitrary commit messages out of metric labels."
          ],
          "implementationNotes": [
            "Store high-cardinality release details in events; use bounded dimensions for metrics."
          ],
          "verification": [
            "Trace a simulated canary abort from its marker to its release manifest.",
            "Inject secret-like fixture metadata and verify the telemetry projection excludes it."
          ],
          "deliverables": [
            "Release event schema and incident dashboard query"
          ],
          "rollout": "Add markers without changing alert thresholds; disable the new event sink if it delays release decisions.",
          "skills": [
            "Observability",
            "Cardinality",
            "Release diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "462e7886-df26-4e60-891f-ef6f4472ac55",
          "key": "ROLL-110",
          "title": "Rehearse an aborted release and write the operator handoff",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "recovery",
          "dependsOn": [
            "ROLL-106",
            "ROLL-107",
            "ROLL-108",
            "ROLL-109"
          ],
          "scenario": "The release checklist says rollback tested, but nobody has timed recovery or tried it with an expanded database schema and pending worker jobs.",
          "acceptanceCriteria": [
            "Run one simulated failed canary with pending jobs and expanded schema.",
            "Record detection, abort, drain, and recovery timestamps with observed limitations.",
            "Provide exact preconditions and stop conditions for the documented rollback path."
          ],
          "implementationNotes": [
            "A simulated drill establishes fixture behavior only; label its measured timings accordingly."
          ],
          "verification": [
            "Recover the previous compatible release and reconcile accepted jobs.",
            "Include an incompatible rollback example and prove the checklist tells the operator to stop."
          ],
          "deliverables": [
            "Recorded release drill and operator runbook"
          ],
          "rollout": "Version the runbook with the tested manifests; repeat the bounded drill when compatibility assumptions change.",
          "skills": [
            "Incident drills",
            "Runbooks",
            "Recovery measurement"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "4cbe8d74-12ed-43d2-9bca-6503851d91a7",
      "key": "QUEUE",
      "title": "Bring document processing back under control",
      "field": "Platform engineering",
      "summary": "Operate an asynchronous document pipeline through retries, poison jobs, worker loss, and tenant bursts.",
      "context": "A fictional internal document portal creates previews through a trusted mock renderer. Large batches crowd out small teams, failed documents retry forever, and operators lack a safe replay command. This exercise never executes uploaded code or real document macros.",
      "stack": [
        "TypeScript",
        "BullMQ",
        "Redis",
        "PostgreSQL",
        "Object storage"
      ],
      "prerequisites": [
        "Queue semantics",
        "Database transactions",
        "Operational metrics"
      ],
      "developerValue": "Practice asynchronous lifecycle control, fair scheduling, bounded retries, and artifact recovery with a deterministic provider.",
      "companyValue": "See how an engineer accounts for accepted work and reduces operational toil without granting operators broad data access.",
      "delivery": "Ten tickets in intake, resilience, and operations phases; use only synthetic document metadata and a trusted deterministic renderer.",
      "phases": [
        {
          "id": "intake",
          "title": "Account for accepted work",
          "goal": "Create traceable jobs with bounded inputs."
        },
        {
          "id": "resilience",
          "title": "Handle failures deliberately",
          "goal": "Control retries, concurrency, cancellation, and worker loss."
        },
        {
          "id": "operations",
          "title": "Make recovery routine",
          "goal": "Expose useful lag signals and safe repair operations."
        }
      ],
      "tickets": [
        {
          "id": "430c0420-821f-4e1a-86a5-38b5c0a1a9e0",
          "key": "QUEUE-101",
          "title": "Expose a document job's current phase and terminal reason",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "intake",
          "dependsOn": [],
          "scenario": "The portal shows Processing for both queued and permanently rejected documents. Support cannot tell whether a file is waiting, rendering, or never going to finish.",
          "acceptanceCriteria": [
            "Expose QUEUED, RUNNING, SUCCEEDED, FAILED, and CANCELLED through an allowlisted projection.",
            "Include a stable terminal reason code and last transition time.",
            "Deny jobs owned by another tenant."
          ],
          "implementationNotes": [
            "Only service transition methods may update lifecycle state; logs are not the source of truth."
          ],
          "verification": [
            "Read queued and failed fixture jobs with distinct explanations.",
            "Reject foreign-tenant lookup and ensure renderer payloads are absent."
          ],
          "deliverables": [
            "Job status contract and authorized read endpoint"
          ],
          "rollout": "Switch status reads for synthetic jobs first; retain historical transition records if the view is reverted.",
          "skills": [
            "State projection",
            "Tenant isolation",
            "API design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "371a4f08-25c9-43c8-bac3-e6e1dddbde08",
          "key": "QUEUE-102",
          "title": "Reject oversized document batches before accepting work",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "intake",
          "dependsOn": [],
          "scenario": "A client submits 50,000 document references in one call. Validation exhausts API memory before the queue sees a single job.",
          "acceptanceCriteria": [
            "Enforce a documented request byte limit and a maximum of 100 document references.",
            "Reject duplicate references within the batch with a clear validation reason.",
            "Create no jobs when batch validation fails."
          ],
          "implementationNotes": [
            "Validate metadata only; the API must not download or render document contents."
          ],
          "verification": [
            "Accept a valid 100-reference synthetic batch.",
            "Reject 101 references, excessive bytes, and duplicate references without partial jobs."
          ],
          "deliverables": [
            "Bounded batch contract and boundary cases"
          ],
          "rollout": "Publish limits before enforcing them on the test client; rollback client batching rather than raising limits without measurement.",
          "skills": [
            "Input limits",
            "Resource bounds",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fa3b1d74-b9f5-4d75-8357-4d4523e8539f",
          "key": "QUEUE-103",
          "title": "Commit job acceptance and dispatch intent together",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "intake",
          "dependsOn": [
            "QUEUE-101",
            "QUEUE-102"
          ],
          "scenario": "The portal returns 202 after storing a job, then loses Redis connectivity before enqueueing it. The job stays QUEUED forever with no delivery attempt.",
          "acceptanceCriteria": [
            "Commit accepted job records and durable dispatch intents atomically.",
            "Dispatch retries use deterministic job identities.",
            "A failed database transaction cannot return accepted status."
          ],
          "implementationNotes": [
            "Queue messages contain identifiers and bounded metadata, not document bytes."
          ],
          "verification": [
            "Lose Redis after acceptance and recover every job when dispatch resumes.",
            "Fail the database commit and assert neither job nor dispatch intent exists."
          ],
          "deliverables": [
            "Outbox-backed acceptance and recovery reproduction"
          ],
          "rollout": "Drain synthetic pending intents through the new dispatcher; pause dispatch without deleting accepted work to rollback.",
          "skills": [
            "Transactional outbox",
            "Durable acceptance",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "transactional-outbox",
              "activity": "APPLY",
              "focus": "Commit acceptance and dispatch intent in one transaction, then demonstrate recovery after the queue is unavailable or the process stops before dispatch."
            }
          ]
        },
        {
          "id": "e3cb7c2c-1160-4aed-9af8-3df3c25fb6d1",
          "key": "QUEUE-104",
          "title": "Stop retrying unsupported document formats",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "resilience",
          "dependsOn": [
            "QUEUE-103"
          ],
          "scenario": "The trusted mock renderer returns UNSUPPORTED_FORMAT for a fixture file. The worker retries it every minute, consuming the same capacity as a temporary storage timeout.",
          "acceptanceCriteria": [
            "Classify unsupported format as terminal and storage timeout as retryable.",
            "Apply a bounded attempt count and backoff policy to retryable failures.",
            "Record each attempt and the final exhaustion reason without replacing earlier failures."
          ],
          "implementationNotes": [
            "Unknown provider errors need an explicit conservative policy; do not retry forever."
          ],
          "verification": [
            "Retry a transient failure that succeeds on its third attempt.",
            "Verify unsupported format runs once and persistent timeout reaches a bounded terminal state."
          ],
          "deliverables": [
            "Failure classification table and retry policy"
          ],
          "rollout": "Apply new classification to future attempts; stop scheduling exhausted jobs without erasing their attempt history.",
          "skills": [
            "Retry policy",
            "Error taxonomy",
            "Failure budgets"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ef2da24e-e945-4621-beb0-1d580d78bb6f",
          "key": "QUEUE-105",
          "title": "Keep one team's bulk import from occupying every worker",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "resilience",
          "dependsOn": [
            "QUEUE-103",
            "QUEUE-104"
          ],
          "scenario": "A synthetic tenant uploads 10,000 documents. A second tenant's single preview waits behind the entire batch although the renderer has spare concurrency slots between completions.",
          "acceptanceCriteria": [
            "Enforce configured global and per-tenant active-job limits.",
            "Allow eligible tenants to make progress while a bulk tenant has backlog.",
            "Release capacity after success, terminal failure, cancellation, or expired execution lease."
          ],
          "implementationNotes": [
            "Do not create an unbounded queue or metric family per tenant; explain the fairness policy."
          ],
          "verification": [
            "Run one bulk tenant and two small tenants and measure their wait times.",
            "Crash a worker while holding capacity and prove another eligible tenant eventually progresses."
          ],
          "deliverables": [
            "Fair dispatch policy and controlled-load report"
          ],
          "rollout": "Start with conservative synthetic limits; disable new intake and drain leases if accounting diverges.",
          "skills": [
            "Fair scheduling",
            "Concurrency limits",
            "Capacity accounting"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "04530a6b-1191-4a5e-b627-b75324118e3f",
          "key": "QUEUE-106",
          "title": "Fence a late worker after its rendering lease expires",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "resilience",
          "dependsOn": [
            "QUEUE-104",
            "QUEUE-105"
          ],
          "scenario": "Worker A pauses long enough to lose its lease. Worker B completes the same preview, then A resumes and overwrites B's artifact pointer with stale output.",
          "acceptanceCriteria": [
            "Associate each execution attempt with a monotonic fencing identity.",
            "Accept completion only from the current authorized lease holder.",
            "Keep rejected late completions observable and prevent them from changing terminal job state."
          ],
          "implementationNotes": [
            "Lease expiration alone does not stop a process; the persistence boundary must reject stale writes."
          ],
          "verification": [
            "Expire A, complete through B, then submit A's completion and inspect unchanged output.",
            "Replay B's completion and assert one terminal transition and artifact reference."
          ],
          "deliverables": [
            "Fenced completion operation and paused-worker reproduction"
          ],
          "rollout": "Introduce fencing before extending concurrency; rollback dispatch while retaining fencing checks on completions.",
          "skills": [
            "Fencing tokens",
            "Worker leases",
            "Concurrency",
            "Artifact consistency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6502461a-e612-4d91-9fa6-cf8134370266",
          "key": "QUEUE-107",
          "title": "Cancel queued work without racing a completed preview",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "resilience",
          "dependsOn": [
            "QUEUE-106"
          ],
          "scenario": "A user cancels a batch just as one preview finishes. The portal reports Cancelled while retaining an accessible success artifact, and a retry renders it again.",
          "acceptanceCriteria": [
            "Make cancellation an authorized state transition with documented running-job semantics.",
            "Resolve cancellation and completion races to one terminal result.",
            "Prevent cancelled jobs from being newly dispatched or retried."
          ],
          "implementationNotes": [
            "For the mock renderer, cancellation can be cooperative; disclose work that cannot stop immediately."
          ],
          "verification": [
            "Cancel queued work and prove the renderer is never called.",
            "Race running completion and cancellation, then replay both commands and inspect stable state."
          ],
          "deliverables": [
            "Cancellation contract and race regression"
          ],
          "rollout": "Enable queued cancellation first, then running cancellation after the race cases pass; retain terminal records on rollback.",
          "skills": [
            "Cancellation",
            "State transitions",
            "Race handling"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "50c5f8de-f4b3-4723-b536-69305c0b8e70",
          "key": "QUEUE-108",
          "title": "Measure oldest runnable work instead of queue size alone",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "operations",
          "dependsOn": [
            "QUEUE-104",
            "QUEUE-105"
          ],
          "scenario": "The queue contains only ten jobs, but the oldest eligible preview has waited 40 minutes. A queue-depth alert never fires, while scheduled retries inflate another dashboard.",
          "acceptanceCriteria": [
            "Measure oldest eligible-job age separately from delayed retries and running age.",
            "Expose attempt exhaustion and stale-lease counts with bounded labels.",
            "Alert when eligible wait exceeds the fixture's ten-minute budget for two observations."
          ],
          "implementationNotes": [
            "Exclude document IDs and tenant IDs from metric label sets."
          ],
          "verification": [
            "Advance a controlled clock and trigger runnable-age paging.",
            "Keep a future retry delayed and verify it does not inflate eligible wait."
          ],
          "deliverables": [
            "Queue age metrics and diagnosis-oriented alert"
          ],
          "rollout": "Compare alerts with the synthetic workload trace in report-only mode before paging.",
          "skills": [
            "Queue observability",
            "Metric semantics",
            "Alert design"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c9a69594-abdc-4f09-8121-2b43536a302a",
          "key": "QUEUE-109",
          "title": "Replay a failed preview through an audited repair command",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operations",
          "dependsOn": [
            "QUEUE-104",
            "QUEUE-106"
          ],
          "scenario": "Operators repair failed jobs by deleting Redis keys. That loses failure history and can replay work for the wrong tenant when a copied ID is mistaken.",
          "acceptanceCriteria": [
            "Allow an authorized operator to create a linked repair attempt for a terminal failure.",
            "Require tenant scope, expected job revision, and a reason.",
            "Preserve original failure history and make duplicate repair requests idempotent."
          ],
          "implementationNotes": [
            "Do not reopen the failed record in place or expose a general queue-management console."
          ],
          "verification": [
            "Repair one terminal fixture failure and follow the linked attempts.",
            "Reject a foreign tenant, stale revision, and repair of a successful job."
          ],
          "deliverables": [
            "Scoped repair command and audit projection"
          ],
          "rollout": "Grant repair permission to a synthetic operator role; revoke command access while retaining read-only audit history.",
          "skills": [
            "Operational APIs",
            "Audit trails",
            "Least privilege"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ca2316a5-d93a-4bd0-849b-ad157c8a0d63",
          "key": "QUEUE-110",
          "title": "Collect orphaned preview artifacts without deleting live output",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "operations",
          "dependsOn": [
            "QUEUE-106",
            "QUEUE-107",
            "QUEUE-109"
          ],
          "scenario": "A worker writes an artifact then loses its lease before committing the pointer. Storage grows with orphaned previews, but a naive age-based cleanup can delete an output still being committed.",
          "acceptanceCriteria": [
            "Separate temporary attempt artifacts from committed output references.",
            "Delete only unreferenced artifacts beyond a documented grace period with no active lease.",
            "Make cleanup resumable and record bounded deletion outcomes."
          ],
          "implementationNotes": [
            "Use synthetic objects; an artifact listing alone cannot prove an object is unreferenced."
          ],
          "verification": [
            "Collect an abandoned attempt artifact after its grace period.",
            "Race cleanup with a valid completion and prove committed output survives."
          ],
          "deliverables": [
            "Orphan collector, race fixture, and dry-run manifest"
          ],
          "rollout": "Review deletion manifests in dry-run mode, then enable cleanup for the synthetic storage prefix only.",
          "skills": [
            "Object lifecycle",
            "Garbage collection",
            "Race prevention",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "4f4b6b1e-4e59-4a19-8701-b8f2ce3f673c",
      "key": "ACCESS",
      "title": "Tighten a partner portal's access boundaries",
      "field": "Security",
      "summary": "Make partner access explicit across list APIs, batch commands, invitations, cached sessions, and exports.",
      "context": "A fictional manufacturing company shares purchase-order documents with partner organizations. Buyers, partner administrators, and read-only agents use the same API. Recent support reports suggest list filters and background downloads disagree about who may see an order.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL",
        "Redis"
      ],
      "prerequisites": [
        "HTTP APIs",
        "Session authentication",
        "Tenant-scoped data access"
      ],
      "developerValue": "Practice authorization as a service-level invariant, including revocation timing, concurrent membership changes, and asynchronous data delivery.",
      "companyValue": "Inspect a concrete record of cross-organization denial, least-privilege decisions, and access-recovery behavior using fictional partner records.",
      "delivery": "Ten defensive engineering issues over mapping, enforcement, and assurance phases; use synthetic accounts and documents in an owned test environment.",
      "phases": [
        {
          "id": "map",
          "title": "Map permissions",
          "goal": "Identify resources and define authorized actions."
        },
        {
          "id": "enforce",
          "title": "Enforce at every boundary",
          "goal": "Apply tenant and permission rules across synchronous and asynchronous access."
        },
        {
          "id": "assure",
          "title": "Prove revocation and explain denials",
          "goal": "Handle changes in authority and provide useful audit records."
        }
      ],
      "tickets": [
        {
          "id": "ff8477d9-e707-4c86-8738-9dfb12ebf572",
          "key": "ACCESS-101",
          "title": "Write the partner permission matrix from existing routes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "map",
          "dependsOn": [],
          "scenario": "The portal has three roles, but engineers infer permissions from page names. A read-only agent can discover an Edit route that was added for partner administrators.",
          "acceptanceCriteria": [
            "Inventory order, document, invitation, and export actions at route and service boundaries.",
            "Define allowed actions for buyer, partner administrator, and read-only agent.",
            "Mark unspecified combinations as denied and identify ownership or tenant conditions."
          ],
          "implementationNotes": [
            "A hidden button is not an authorization rule; include non-UI callers."
          ],
          "verification": [
            "Map each fixture route to exactly one documented action.",
            "Show explicit denials for agent edits and cross-partner document reads."
          ],
          "deliverables": [
            "Permission matrix and route-to-action inventory"
          ],
          "rollout": "Review the matrix before enforcing new checks; record intentional compatibility changes for test clients.",
          "skills": [
            "Threat modeling",
            "Authorization design",
            "API inventory"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f5e4be88-ea30-4a39-91a3-23070a721d59",
          "key": "ACCESS-102",
          "title": "Remove partner scope from client-controlled list filters",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "enforce",
          "dependsOn": [
            "ACCESS-101"
          ],
          "scenario": "Changing partnerId in the purchase-order query reveals another partner's orders. The controller authenticates the session but trusts the query filter to choose the tenant.",
          "acceptanceCriteria": [
            "Derive authorized partner scope from the server-side actor context.",
            "Apply that scope within the order repository query.",
            "Return scoped counts and pagination cursors that cannot widen access."
          ],
          "implementationNotes": [
            "Test the repository directly as well as the route; controller-only filtering is insufficient."
          ],
          "verification": [
            "List two pages of the authorized partner's orders with correct counts.",
            "Replace partnerId and replay a foreign cursor; assert no foreign records or totals."
          ],
          "deliverables": [
            "Tenant-scoped list boundary and denial regressions"
          ],
          "rollout": "Switch the synthetic partner list first; disable the route if scoped count comparisons fail.",
          "skills": [
            "Tenant isolation",
            "Repository boundaries",
            "Pagination security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a2e46e44-4b53-4b0b-88c8-1de3b29465e7",
          "key": "ACCESS-103",
          "title": "Make bulk order updates all-or-nothing across authorization checks",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "enforce",
          "dependsOn": [
            "ACCESS-101",
            "ACCESS-102"
          ],
          "scenario": "A batch update contains nine permitted order IDs and one foreign ID. The service updates the first nine before discovering the forbidden order and returning 403.",
          "acceptanceCriteria": [
            "Authorize the complete bounded target set before committing changes.",
            "A missing, duplicate, or foreign order prevents the entire batch update.",
            "Record no success audit when the transaction is rejected."
          ],
          "implementationNotes": [
            "Do not reveal which foreign order exists through different error shapes."
          ],
          "verification": [
            "Update a fully authorized synthetic batch atomically.",
            "Mix permitted and forbidden IDs and inject a final-write failure; verify unchanged records."
          ],
          "deliverables": [
            "Atomic bulk command and mixed-scope reproduction"
          ],
          "rollout": "Enable a bounded batch size on the synthetic client; revert batch routing without relaxing individual authorization.",
          "skills": [
            "Batch authorization",
            "Transactions",
            "Information disclosure"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5d6b5439-cd65-427c-acb3-343f39b60d6a",
          "key": "ACCESS-104",
          "title": "Stop a document lookup from revealing foreign filenames",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "enforce",
          "dependsOn": [
            "ACCESS-102"
          ],
          "scenario": "A foreign document request returns Forbidden: invoice-acme-september.pdf. Download is blocked, but the error itself leaks the other partner's filename.",
          "acceptanceCriteria": [
            "Use the same public not-found response for missing and out-of-scope documents.",
            "Do not include filename, owner, storage key, or existence hints in denied responses.",
            "Keep an internal denial reason behind authorized audit access."
          ],
          "implementationNotes": [
            "Apply the projection to metadata and download-link routes, not just the file response."
          ],
          "verification": [
            "Retrieve an authorized filename normally.",
            "Compare missing and foreign-document response bodies and inspect sanitized logs."
          ],
          "deliverables": [
            "Document denial projection and metadata-leak regression"
          ],
          "rollout": "Replace external error text immediately in the fixture routes; keep internal reason codes for diagnosis.",
          "skills": [
            "Error hygiene",
            "Information disclosure",
            "Read authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "658fe6b7-55ac-4d8b-a2e9-0cbaf7707c1b",
          "key": "ACCESS-105",
          "title": "Consume partner invitations once under concurrent acceptance",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "enforce",
          "dependsOn": [
            "ACCESS-101"
          ],
          "scenario": "Two acceptance requests use the same invitation token at nearly the same time. The portal creates duplicate memberships and occasionally accepts a token after its role was revoked.",
          "acceptanceCriteria": [
            "Bind an invitation to partner, intended recipient, role, expiry, and current invitation state.",
            "Consume it and create membership in one transaction.",
            "Concurrent acceptance yields one membership with a documented replay or conflict response."
          ],
          "implementationNotes": [
            "Persist token hashes only; synthetic invitation secrets must not enter logs."
          ],
          "verification": [
            "Accept a valid invitation once and inspect its membership.",
            "Race acceptance and try expired, revoked, and wrong-recipient tokens; assert denial or one winner."
          ],
          "deliverables": [
            "Invitation consumption command and concurrency cases"
          ],
          "rollout": "Issue the new token format for future synthetic invitations; retain a documented expiry window for legacy links.",
          "skills": [
            "Single-use tokens",
            "Atomic authorization",
            "Identity binding"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9c66c4a3-e81d-491c-8da7-bad5c9858ee2",
          "key": "ACCESS-106",
          "title": "Narrow integration keys to the permissions they were issued",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "enforce",
          "dependsOn": [
            "ACCESS-101",
            "ACCESS-102"
          ],
          "scenario": "A partner creates a read-only reporting key while an administrator is logged in. Requests using that key inherit the administrator's full session permissions.",
          "acceptanceCriteria": [
            "Evaluate key scopes separately from browser-session roles.",
            "Restrict effective permissions to both key scope and current partner authority.",
            "Support key revocation without disabling unrelated partner sessions."
          ],
          "implementationNotes": [
            "A key cannot grant a permission its issuer was not authorized to delegate."
          ],
          "verification": [
            "Read permitted reports through a scoped synthetic key.",
            "Attempt order edits, cross-partner reads, and use after revocation; assert denial."
          ],
          "deliverables": [
            "Integration-key authorization policy and scope tests"
          ],
          "rollout": "Create scoped test keys alongside existing clients; remove broad key support after explicit client migration.",
          "skills": [
            "API key scopes",
            "Least privilege",
            "Credential revocation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2cd47283-b943-4cb6-9d2a-d041a0f6856b",
          "key": "ACCESS-107",
          "title": "Recheck export authority when a background job completes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "assure",
          "dependsOn": [
            "ACCESS-103",
            "ACCESS-104"
          ],
          "scenario": "An administrator starts a large partner export and loses membership while it runs. The worker later emails a long-lived storage URL using authorization captured only at request time.",
          "acceptanceCriteria": [
            "Record immutable request scope without treating it as permanent authorization.",
            "Reauthorize delivery and each download against current membership and export scope.",
            "Revoked users cannot receive or use new access grants; completed artifacts remain tenant-restricted."
          ],
          "implementationNotes": [
            "Use an authenticated download boundary or similarly revocable design; do not send real email in this exercise."
          ],
          "verification": [
            "Complete and download a permitted synthetic export.",
            "Revoke access between request, completion, and download; verify denial at each relevant boundary."
          ],
          "deliverables": [
            "Export authorization lifecycle and revocation timing tests"
          ],
          "rollout": "Route synthetic exports through the new download boundary; expire legacy links before removing their compatibility path.",
          "skills": [
            "Asynchronous authorization",
            "Revocation",
            "Artifact access",
            "Time-of-check races"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "055312f5-1ff9-417c-83a3-c680b320ec4f",
          "key": "ACCESS-108",
          "title": "Invalidate cached permissions after a role downgrade",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "assure",
          "dependsOn": [
            "ACCESS-102",
            "ACCESS-106"
          ],
          "scenario": "A partner administrator is downgraded to read-only but retains edit access on one API instance for an hour because permission caches are local and keyed only by user ID.",
          "acceptanceCriteria": [
            "Scope cached decisions by actor, partner, and authority revision.",
            "Enforce a documented maximum revocation delay with an authoritative fallback.",
            "Fail closed for privileged writes when current authority cannot be established."
          ],
          "implementationNotes": [
            "User ID alone is insufficient when the same user belongs to multiple partners."
          ],
          "verification": [
            "Downgrade a role across two synthetic API instances and measure the revocation delay.",
            "Simulate cache invalidation loss and authority-store failure; assert privileged writes cannot persist indefinitely."
          ],
          "deliverables": [
            "Permission cache policy and revocation-latency reproduction"
          ],
          "rollout": "Shorten cache lifetime before enabling revisioned entries; bypass the cache if revision propagation fails.",
          "skills": [
            "Authorization caching",
            "Consistency",
            "Fail-closed behavior"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "35edffbc-ea3b-4211-a788-538dc64e8a91",
          "key": "ACCESS-109",
          "title": "Record useful access-denial audits without copying documents",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "assure",
          "dependsOn": [
            "ACCESS-104",
            "ACCESS-106"
          ],
          "scenario": "Security receives Denied entries with no action name, while application debug logs include complete document metadata. Neither source is suitable for reviewing a partner complaint.",
          "acceptanceCriteria": [
            "Record actor reference, scoped action, tenant reference, reason code, and correlation ID.",
            "Exclude document text, credential values, request bodies, and raw download URLs.",
            "Protect audit queries with a dedicated read permission and bounded date range."
          ],
          "implementationNotes": [
            "Security audit records are append-only; generic analytics must not receive sensitive audit detail."
          ],
          "verification": [
            "Follow an authorized denial investigation through its correlation ID.",
            "Attempt audit access as a partner agent and scan secret-like fixture values for absence."
          ],
          "deliverables": [
            "Minimized audit schema and investigation example"
          ],
          "rollout": "Mirror fixture denials into the new sink and inspect redaction before enabling operator queries.",
          "skills": [
            "Security logging",
            "Data minimization",
            "Audit access"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7b78b18d-f3a7-4f74-a630-2749ab82b6a2",
          "key": "ACCESS-110",
          "title": "Serialize membership removal with privileged order approval",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "assure",
          "dependsOn": [
            "ACCESS-103",
            "ACCESS-108",
            "ACCESS-109"
          ],
          "scenario": "A buyer is removed from a partner while their order-approval request is between authorization and commit. The current implementation commits the approval after removal without a defined policy.",
          "acceptanceCriteria": [
            "Declare the transactional ordering rule for removal and approval.",
            "Reconcile authority revision within the privileged write transaction so one ordering is enforced.",
            "Keep successful approvals and rejected stale authority attempts separately auditable."
          ],
          "implementationNotes": [
            "A second controller check does not close the race; prove the service/database boundary controls it."
          ],
          "verification": [
            "Commit approval before removal under the declared ordering and inspect attribution.",
            "Commit removal first while approval is paused and assert no unauthorized order mutation."
          ],
          "deliverables": [
            "Authority/write serialization design and deterministic interleaving tests"
          ],
          "rollout": "Apply the rule to order approvals before broader privileged writes; retain audit records through application rollback.",
          "skills": [
            "Transactional authorization",
            "Concurrency",
            "Revocation semantics",
            "Audit integrity"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "771755b5-497b-4cb3-9c10-88c5cf9ab984",
      "key": "VAULT",
      "title": "Rotate an integration credential without losing work",
      "field": "Security",
      "summary": "Introduce explicit credential versions, safe rotation, redacted diagnostics, and recovery for a webhook integration.",
      "context": "A fictional supplier integration signs incoming webhooks and uses an outbound API credential. Operators currently replace environment values by hand. Build with a deterministic secret-store adapter and fabricated keys only; no live provider account or production credential is part of the exercise.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL",
        "Secret-provider interface"
      ],
      "prerequisites": [
        "Cryptographic hash APIs",
        "HTTP webhook handling",
        "Access control"
      ],
      "developerValue": "Practice credential lifecycle design, overlap windows, authenticated webhooks, and failure recovery without handling real secrets.",
      "companyValue": "Review whether an engineer can make rotation auditable and fail closed while preserving availability and replay safety.",
      "delivery": "Ten issues across inventory, rotation, and recovery phases; deliver a deterministic provider, synthetic contract checks, and a credential incident drill.",
      "phases": [
        {
          "id": "inventory",
          "title": "Make credential use explicit",
          "goal": "Establish provider boundaries and prevent secret exposure."
        },
        {
          "id": "rotation",
          "title": "Rotate with controlled overlap",
          "goal": "Handle version changes, webhook verification, and in-flight work."
        },
        {
          "id": "recovery",
          "title": "Recover and audit",
          "goal": "Revoke compromised versions, bound caching, and rehearse provider failure."
        }
      ],
      "tickets": [
        {
          "id": "744f5aab-f118-4ea9-87bf-222c8c910f30",
          "key": "VAULT-101",
          "title": "Inventory credential consumers without exporting their values",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "inventory",
          "dependsOn": [],
          "scenario": "Operations knows the supplier key is used by the API but discovers a nightly worker still reads an old environment variable. Rotation planning has no reliable consumer list.",
          "acceptanceCriteria": [
            "List logical credential names, consuming processes, purposes, and required permissions.",
            "Distinguish inbound signing verification from outbound API authentication.",
            "Exclude credential values and private material from the inventory artifact."
          ],
          "implementationNotes": [
            "Prepare a synthetic API/worker consumer configuration; inspect its names only and do not enumerate the user's environment or local secrets."
          ],
          "verification": [
            "Account for API and worker consumers in the synthetic configuration prepared for this project.",
            "Insert a dummy secret value and confirm the inventory output never contains it."
          ],
          "deliverables": [
            "Credential consumer map and rotation dependency list"
          ],
          "rollout": "Review the map before changing lookup paths; version it with each new consumer.",
          "skills": [
            "Credential inventory",
            "Data minimization",
            "Operational dependencies"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b8c6c5d7-050c-4677-99a8-71d82d61f008",
          "key": "VAULT-102",
          "title": "Move secret lookup behind a version-aware provider",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "inventory",
          "dependsOn": [
            "VAULT-101"
          ],
          "scenario": "API and worker read process environment independently and cannot report which credential version they are using. The test suite also embeds key values in request snapshots.",
          "acceptanceCriteria": [
            "Define lookup by logical credential name and permitted version reference.",
            "Return a non-secret version identity separately from sensitive material.",
            "Use a deterministic fixture adapter and fail closed when no provider is configured."
          ],
          "implementationNotes": [
            "Keep secret material out of serialized DTOs and snapshot assertions."
          ],
          "verification": [
            "Resolve a known synthetic version for an authorized consumer.",
            "Reject an unknown version, unauthorized consumer, and absent provider without fallback secrets."
          ],
          "deliverables": [
            "Secret provider contract and deterministic adapter"
          ],
          "rollout": "Migrate one synthetic consumer at a time; keep configuration rollback limited to the fixture provider.",
          "skills": [
            "Provider interfaces",
            "Secret handling",
            "Fail-closed configuration"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "ports-and-adapters",
              "activity": "APPLY",
              "focus": "Separate version-aware secret lookup from provider details so the deterministic adapter and an unavailable provider obey the same fail-closed contract."
            }
          ]
        },
        {
          "id": "ee9a1cc0-b7c4-48e6-a0a7-0b173c6e64a8",
          "key": "VAULT-103",
          "title": "Redact credentials from failed supplier requests",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "inventory",
          "dependsOn": [
            "VAULT-102"
          ],
          "scenario": "The HTTP client's error serializer includes Authorization headers and query parameters. A supplier timeout writes the outbound credential into a generic error log.",
          "acceptanceCriteria": [
            "Log an allowlisted error projection with operation, status class, timeout, and correlation ID.",
            "Exclude headers, raw URLs, request bodies, and provider response bodies.",
            "Expose credential version identity only when it is a non-secret reference."
          ],
          "implementationNotes": [
            "Do not rely on replacing one known key value; future values and nested errors must remain safe."
          ],
          "verification": [
            "Diagnose a synthetic timeout through permitted metadata.",
            "Inject secret-like values into nested headers, URLs, and response bodies and assert absence."
          ],
          "deliverables": [
            "Safe supplier error serializer and redaction fixtures"
          ],
          "rollout": "Replace error serialization before rotation drills; disable verbose client logging in the fixture configuration.",
          "skills": [
            "Log redaction",
            "Error serialization",
            "Secret hygiene"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b3a885a1-0a0d-4d6f-a52b-81490c8348c3",
          "key": "VAULT-104",
          "title": "Model credential activation and retirement as explicit transitions",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "rotation",
          "dependsOn": [
            "VAULT-102",
            "VAULT-103"
          ],
          "scenario": "An operator changes a credential row from RETIRED to ACTIVE to recover an outage. The service resumes using a version that was deliberately revoked after a drill.",
          "acceptanceCriteria": [
            "Define staged, active, retiring, retired, and revoked states with named commands.",
            "Prevent revoked and retired versions from becoming active again.",
            "Audit actor, reason, version references, and transition time without secret material."
          ],
          "implementationNotes": [
            "A replacement requires a new credential version; state changes cannot rewrite historical identity."
          ],
          "verification": [
            "Walk a staged fixture version through activation and retirement.",
            "Attempt forbidden reactivation and stale revision updates; assert unchanged history."
          ],
          "deliverables": [
            "Credential lifecycle operations and transition matrix"
          ],
          "rollout": "Route fixture operator changes through the commands before removing direct state writes.",
          "skills": [
            "Lifecycle modeling",
            "Audit trails",
            "Immutable identity"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ce377dc7-9fe1-4ad1-836b-7c0b6c92c7c8",
          "key": "VAULT-105",
          "title": "Verify signed webhooks against raw bytes before parsing",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rotation",
          "dependsOn": [
            "VAULT-102"
          ],
          "scenario": "The receiver parses JSON and reserializes it before checking the supplier signature. Harmless whitespace changes break valid signatures, while trusted routing fields are read before authenticity is established.",
          "acceptanceCriteria": [
            "Verify the exact bounded raw body using the fixture protocol's HMAC signature format.",
            "Use constant-time comparison for equal-length signature bytes and reject malformed encodings.",
            "Parse trusted fields only after successful verification and enforce the protocol's timestamp tolerance."
          ],
          "implementationNotes": [
            "The fixture protocol signs timestamp plus raw body with HMAC-SHA-256; define the byte separator explicitly."
          ],
          "verification": [
            "Accept a correctly signed body including deliberate whitespace.",
            "Reject one-byte changes, invalid signature length, and timestamps outside the declared tolerance."
          ],
          "deliverables": [
            "Raw-body webhook verification and protocol fixtures"
          ],
          "rollout": "Run signature checks on a fixture receiver first; fail closed when verification material is unavailable.",
          "skills": [
            "Webhook authentication",
            "Byte-level contracts",
            "Constant-time comparison"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8133aab5-486d-4dbe-ac07-0a3674c46e31",
          "key": "VAULT-106",
          "title": "Accept old and new webhook signatures only during a bounded overlap",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rotation",
          "dependsOn": [
            "VAULT-104",
            "VAULT-105"
          ],
          "scenario": "The supplier rotates signing keys gradually across senders. Switching instantly drops valid traffic; retaining every old key forever defeats retirement.",
          "acceptanceCriteria": [
            "Accept only the configured active and retiring versions during their explicit validity windows.",
            "Reject retired or revoked versions regardless of timestamp tolerance.",
            "Record the non-secret verifying version identity for accepted webhook receipts."
          ],
          "implementationNotes": [
            "Bound the candidate key set; an untrusted key ID cannot trigger arbitrary provider lookups."
          ],
          "verification": [
            "Accept both fixture versions inside overlap and only the new version after retirement.",
            "Try a revoked version and an unknown attacker-controlled key ID; assert rejection without broad lookup."
          ],
          "deliverables": [
            "Signing overlap policy and boundary-time tests"
          ],
          "rollout": "Stage the new version, begin bounded overlap, then retire the old version after fixture sender convergence.",
          "skills": [
            "Key rotation",
            "Validity windows",
            "Input trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Integrations",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7a188375-2b36-48b3-8d55-82e3f2b843ad",
          "key": "VAULT-107",
          "title": "Keep duplicate signed callbacks from creating duplicate supplier events",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "rotation",
          "dependsOn": [
            "VAULT-105",
            "VAULT-106"
          ],
          "scenario": "The supplier retries a valid signed callback through both old and new signing keys during overlap. Signature checks pass twice and both requests create a purchase-order update.",
          "acceptanceCriteria": [
            "Deduplicate by authenticated supplier event identity and tenant, independent of signing version.",
            "Bind the identity to a canonical payload fingerprint and conflict on changed content.",
            "Commit the receipt and business dispatch intent atomically."
          ],
          "implementationNotes": [
            "A valid signature proves message authenticity under the fixture protocol, not permission for duplicate side effects."
          ],
          "verification": [
            "Deliver the same event under both allowed keys and assert one business dispatch.",
            "Race duplicate callbacks and reuse the event ID with changed content; inspect stable state and conflict."
          ],
          "deliverables": [
            "Authenticated receipt deduplication and overlap replay cases"
          ],
          "rollout": "Enable receipt uniqueness before starting overlap; retain receipts through any receiver rollback.",
          "skills": [
            "Replay prevention",
            "Idempotency",
            "Transactional dispatch"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3506bbef-9a14-4bf1-b6ba-bb799c10c1b7",
          "key": "VAULT-108",
          "title": "Rotate outbound credentials without retrying an ambiguous write twice",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recovery",
          "dependsOn": [
            "VAULT-104",
            "VAULT-107"
          ],
          "scenario": "An outbound supplier update times out during credential rotation. The worker retries with the new key and a fresh request ID, creating the same supplier instruction twice.",
          "acceptanceCriteria": [
            "Keep one operation identity across credential version changes and retries.",
            "Distinguish authentication rejection from an unknown remote commit outcome.",
            "Use the fixture supplier's idempotency/status contract before resending an ambiguous write."
          ],
          "implementationNotes": [
            "Do not assume changing credentials resets business idempotency or proves a timed-out request failed."
          ],
          "verification": [
            "Rotate after a confirmed authentication failure and complete one logical operation.",
            "Simulate remote commit followed by timeout; reconcile through status lookup and assert no duplicate instruction."
          ],
          "deliverables": [
            "Outbound rotation retry protocol and ambiguous-outcome reproduction"
          ],
          "rollout": "Verify against the deterministic supplier adapter before switching fixture consumers; pause ambiguous writes if status lookup fails.",
          "skills": [
            "Credential rotation",
            "Ambiguous outcomes",
            "Idempotent integrations",
            "Recovery protocols"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "862c6d32-4512-4f19-a1ec-c9d725c4edc5",
          "key": "VAULT-109",
          "title": "Make emergency revocation reach cached consumers",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recovery",
          "dependsOn": [
            "VAULT-104",
            "VAULT-106",
            "VAULT-108"
          ],
          "scenario": "An operator revokes a synthetic compromised key, but a worker's indefinite cache continues signing requests with it. Another worker refreshes and succeeds, hiding the inconsistent state.",
          "acceptanceCriteria": [
            "Bound cache lifetime and propagate credential authority revisions to all consumers.",
            "Prevent use after the declared revocation deadline, including during provider outage.",
            "Audit revocation convergence using version references and consumer acknowledgements only."
          ],
          "implementationNotes": [
            "Cached availability cannot override explicit revocation; define the exercise's maximum revocation delay."
          ],
          "verification": [
            "Revoke a cached fixture key across two consumers and measure convergence.",
            "Drop one invalidation notification and disable lookup; verify use stops at the deadline."
          ],
          "deliverables": [
            "Revocation propagation design and failure-interleaving tests"
          ],
          "rollout": "Enforce bounded caching before testing emergency revoke; pause outbound work when authority cannot be refreshed safely.",
          "skills": [
            "Revocation consistency",
            "Cache lifetimes",
            "Failure modes",
            "Security operations"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a0c642b9-3d87-4fd8-9672-e01a67c5e55c",
          "key": "VAULT-110",
          "title": "Rehearse a secret-provider outage and document recovery limits",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recovery",
          "dependsOn": [
            "VAULT-103",
            "VAULT-108",
            "VAULT-109"
          ],
          "scenario": "The provider is unavailable during a planned rotation. On call needs to know which reads can continue, which writes must wait, and how to recover without pasting keys into environment files.",
          "acceptanceCriteria": [
            "Exercise provider outage before activation, during overlap, and after old-version revocation.",
            "Document allowed cached behavior and fail-closed conditions for each stage.",
            "Restore processing through the provider while preserving operation IDs and audit history."
          ],
          "implementationNotes": [
            "Use fabricated credentials and deterministic failures; no manual secret-value fallback is allowed."
          ],
          "verification": [
            "Recover a staged fixture rotation after provider availability returns.",
            "Keep the revoked version unusable throughout outage and recovery, and inspect logs for secret absence."
          ],
          "deliverables": [
            "Credential incident drill report and stage-specific recovery runbook"
          ],
          "rollout": "Version the runbook with provider and policy versions; repeat the drill when cache or overlap behavior changes.",
          "skills": [
            "Security incident drills",
            "Provider resilience",
            "Recovery documentation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "f6dc6904-7fbe-4c66-bb1a-d6e1540bebba",
      "key": "DESK",
      "title": "A support console that survives a busy shift",
      "field": "Frontend",
      "summary": "Repair queue navigation, reply composition, and agent handoffs in a customer support workspace.",
      "context": "The fictional Alder support team handles billing and delivery conversations in a browser console. Agents keep several tickets open, share filtered queues, and work through unreliable office Wi-Fi. The API contract returns ticket revisions and cursor-based pages; work stays within the console and its test adapter.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Testing Library",
        "Playwright"
      ],
      "prerequisites": [
        "A ticket-list and reply API contract to implement or stub",
        "Synthetic conversations across two organizations with revision conflicts"
      ],
      "developerValue": "Practice state ownership, asynchronous races, accessible interaction, and recovery in bounded changes.",
      "companyValue": "Inspect how an engineer protects agent work and handles failures that interrupt support operations.",
      "delivery": "Choose one ticket or deliver the phases as separate pull requests. Use synthetic customer content; live email delivery is outside scope.",
      "phases": [
        {
          "id": "orientation",
          "title": "Make the queue dependable",
          "goal": "Keep navigation and list state understandable."
        },
        {
          "id": "workspace",
          "title": "Protect the conversation",
          "goal": "Keep drafts, revisions, and focus tied to the right ticket."
        },
        {
          "id": "resilience",
          "title": "Handle interruptions",
          "goal": "Recover from partial failures and concurrent work."
        },
        {
          "id": "handoff",
          "title": "Prepare the next shift",
          "goal": "Make the release diagnosable and supportable."
        }
      ],
      "tickets": [
        {
          "id": "b140e640-2ac6-440b-93f4-917506f105fb",
          "key": "DESK-101",
          "title": "Keep shared queue links useful after refresh",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "orientation",
          "dependsOn": [],
          "scenario": "A shift lead shares the unassigned billing queue, but recipients land on All tickets. Put filters in the URL so opening the link, refreshing, and using Back retain the intended view.",
          "acceptanceCriteria": [
            "Status, team, and reference filters round-trip through the URL.",
            "Unknown filter values use documented defaults without crashing.",
            "Back restores the preceding filters and clears any cursor invalidated by them."
          ],
          "implementationNotes": [
            "Reference search targets synthetic ticket IDs; customer message text must not enter query parameters."
          ],
          "verification": [
            "Open team=billing and status=unassigned in a fresh tab and inspect the request.",
            "Use an unknown status, then navigate Back after two filter changes; verify fallback and history order."
          ],
          "deliverables": [
            "Queue URL parser and browser navigation regression case"
          ],
          "rollout": "Enable URL filters for the internal queue; a flag restores the default queue without invalidating ticket links.",
          "skills": [
            "URL state",
            "React",
            "Navigation"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "3973e7cf-fee7-4139-8a0f-afcbe009a5f1",
          "key": "DESK-102",
          "title": "Separate an empty queue from a failed request",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "orientation",
          "dependsOn": [],
          "scenario": "During an API outage the console said No tickets, and an agent assumed the queue was clear. Give loading, empty, stale, and failed responses distinct presentations.",
          "acceptanceCriteria": [
            "An empty successful response shows active filters and a clear-filters action.",
            "A failed refresh retains previously loaded rows and labels them stale.",
            "Retry fetches the active query once and exposes an accessible error if it fails again."
          ],
          "implementationNotes": [
            "Keep the last successful response while refreshing."
          ],
          "verification": [
            "Return an empty successful page and verify no outage message appears.",
            "Load three rows, reject refresh, then recover on retry; rows persist until replacement."
          ],
          "deliverables": [
            "Explicit queue request states and failure screenshots"
          ],
          "rollout": "Release state rendering independently; revert the presentation component if the queue becomes unusable.",
          "skills": [
            "Error handling",
            "UI state",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Accessibility",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5d2dd4c9-dd25-4437-b25f-53e916a95cf9",
          "key": "DESK-103",
          "title": "Stop a late search response replacing the current queue",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "orientation",
          "dependsOn": [
            "DESK-101",
            "DESK-102"
          ],
          "scenario": "On a slow connection, searching DL-42 and immediately clearing the field sometimes repopulates the screen with DL-42 results. Make response ownership follow the active query.",
          "acceptanceCriteria": [
            "Only a response for the active query updates rows, counts, or errors.",
            "Changing filters abandons the previous page cursor.",
            "Unmounting the queue prevents late responses from changing visible state."
          ],
          "implementationNotes": [
            "Guard against adapters that resolve after cancellation."
          ],
          "verification": [
            "Resolve two requests in reverse order and confirm the last selection wins.",
            "Reject a superseded request after the current one succeeds; no stale error appears."
          ],
          "deliverables": [
            "Query ownership fix and deterministic out-of-order response test"
          ],
          "rollout": "Canary with the support pilot; revert the coordinator if current-query results stop loading.",
          "skills": [
            "Async state",
            "Race conditions",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b38547ea-48c5-4130-ae20-45924e80c709",
          "key": "DESK-104",
          "title": "Restore the right reply draft when switching tickets",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "workspace",
          "dependsOn": [
            "DESK-103"
          ],
          "scenario": "Agents alternate between conversations while checking orders. The editor resets on every switch, and one experimental fix restored a draft into the wrong customer thread.",
          "acceptanceCriteria": [
            "Draft keys include organization, signed-in agent, and ticket.",
            "Returning to a ticket restores its text without copying it to another conversation.",
            "Sign-out clears local drafts; storage refusal leaves editing usable with a persistence notice."
          ],
          "implementationNotes": [
            "Use synthetic text and never record draft content in analytics."
          ],
          "verification": [
            "Write different drafts on two tickets, switch repeatedly, and reload in the same account.",
            "Switch organizations and simulate quota failure; no prior-account draft appears and typing still works."
          ],
          "deliverables": [
            "Scoped draft store and account-switch regression coverage"
          ],
          "rollout": "Start with session-scoped storage; disable persistence and retain the in-memory editor if corruption is reported.",
          "skills": [
            "State persistence",
            "Privacy",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4aecd497-906e-41bf-8f01-cee00ca9815a",
          "key": "DESK-105",
          "title": "Make ticket switching predictable from the keyboard",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "workspace",
          "dependsOn": [
            "DESK-102"
          ],
          "scenario": "An agent navigating by keyboard loses their place after closing ticket details. Define focus behavior for opening, closing, and removing the selected row.",
          "acceptanceCriteria": [
            "Opening details moves focus to the detail heading or first intentional control.",
            "Closing returns focus to the originating row or a documented adjacent fallback.",
            "Shortcuts do not fire in text inputs or during input method composition."
          ],
          "implementationNotes": [
            "Shortcuts supplement semantic controls and the ordinary tab sequence."
          ],
          "verification": [
            "Open and close details using only the keyboard and inspect focus.",
            "Remove the originating row while details are open, then close; focus remains visible and useful."
          ],
          "deliverables": [
            "Focus restoration and keyboard walkthrough notes"
          ],
          "rollout": "Ship focus restoration before shortcuts; disable shortcuts separately if they conflict with editing.",
          "skills": [
            "Keyboard access",
            "Focus management",
            "React"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "392d0ee6-6827-4558-849a-60ab9536e0c2",
          "key": "DESK-106",
          "title": "Show assignment conflicts without pretending a save worked",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "workspace",
          "dependsOn": [
            "DESK-103"
          ],
          "scenario": "Two leads assign the same ticket within a second. One console displays its optimistic assignment forever even though the API rejected the stale revision.",
          "acceptanceCriteria": [
            "Writes include the last observed ticket revision.",
            "A conflict restores authoritative assignment and explains the competing update.",
            "An older rollback cannot overwrite a newer confirmed assignment."
          ],
          "implementationNotes": [
            "The API remains authoritative; never automatically retry a stale assignment."
          ],
          "verification": [
            "Accept an assignment and verify the returned revision replaces the local one.",
            "Interleave two changes with a conflict arriving last; the newest authoritative owner remains visible."
          ],
          "deliverables": [
            "Revision-aware assignment flow and interleaving tests"
          ],
          "rollout": "Enable for one team and inspect conflicts; fall back to confirmed saves if optimistic rollback proves unreliable.",
          "skills": [
            "Concurrency",
            "Optimistic UI",
            "API contracts"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "86f7d66d-8ea5-467b-863b-4cc2cf86c8a4",
          "key": "DESK-107",
          "title": "Report partial bulk-close results per ticket",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "resilience",
          "dependsOn": [
            "DESK-106"
          ],
          "scenario": "Closing 25 conversations returns 22 successes, two permission denials, and one revision conflict. Today a green toast appears and every selected row disappears.",
          "acceptanceCriteria": [
            "Successful IDs leave the queue only if its filter excludes closed work.",
            "Denied and conflicting tickets remain selected with individual reasons.",
            "Retry targets retryable failures without replaying confirmed closes."
          ],
          "implementationNotes": [
            "Interpret the result per ID; a successful HTTP status does not mean every item succeeded."
          ],
          "verification": [
            "Run mixed outcomes and compare row visibility and selection with each result.",
            "Inspect retry IDs; denied and already closed items are excluded."
          ],
          "deliverables": [
            "Bulk result summary and mixed-outcome integration test"
          ],
          "rollout": "Limit the first release to 25 tickets; disable bulk close while retaining individual close on regression.",
          "skills": [
            "Batch operations",
            "Authorization UX",
            "Error recovery"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7e16f42d-c88f-41a9-8a4c-45532b1de624",
          "key": "DESK-108",
          "title": "Reconcile an uncertain reply send after a connection drop",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "resilience",
          "dependsOn": [
            "DESK-104",
            "DESK-106"
          ],
          "scenario": "The server accepts a reply, but Wi-Fi drops before acknowledgement. Clicking Send again duplicates the email. Model an uncertain result and recover through operation lookup.",
          "acceptanceCriteria": [
            "One operation key survives timeout and explicit retry.",
            "Uncertain sending preserves the draft and checks status before clearing it.",
            "Changed text receives a new operation only after reconciliation; account changes stop status polling."
          ],
          "implementationNotes": [
            "Use a stubbed idempotent send/status contract; actual email delivery is excluded."
          ],
          "verification": [
            "Accept sending but drop the response, then report accepted from lookup; display one reply.",
            "Return unknown and then unavailable from lookup; preserve the draft and prevent an unkeyed duplicate."
          ],
          "deliverables": [
            "Reply send state machine and lost-acknowledgement test"
          ],
          "rollout": "Pilot with synthetic mailboxes; disable the new sending flow if operation reconciliation cannot be trusted.",
          "skills": [
            "Idempotency",
            "State machines",
            "Network recovery"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a2db3a36-c354-4ea1-97ad-653e344c8a43",
          "key": "DESK-109",
          "title": "Keep a long conversation responsive without hiding context",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "resilience",
          "dependsOn": [
            "DESK-105"
          ],
          "scenario": "An 800-message synthetic conversation makes expanding attachments slow. Reduce initial rendering while preserving chronological reading and position when older messages load.",
          "acceptanceCriteria": [
            "Initial rendering uses a bounded window and explicit load-older control.",
            "Prepending older messages preserves the visible anchor and keyboard focus.",
            "A before/after profile on the same fixture records the performance budget and measurement environment."
          ],
          "implementationNotes": [
            "Prefer explicit pagination if virtualization would break assistive-technology reading order."
          ],
          "verification": [
            "Profile the 800-message fixture and load two older pages without a scroll jump.",
            "Fail and retry an older-page request; no messages duplicate and the current position remains."
          ],
          "deliverables": [
            "Bounded message rendering and reproducible profile note"
          ],
          "rollout": "Enable above an agreed conversation size; restore full rendering if reading order regresses.",
          "skills": [
            "Performance profiling",
            "Pagination",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "377936ee-afd8-4102-942c-88e2f77c4bc5",
          "key": "DESK-110",
          "title": "Give support a useful report when the console fails",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "handoff",
          "dependsOn": [
            "DESK-107",
            "DESK-108",
            "DESK-109"
          ],
          "scenario": "On-call receives screenshots saying It stopped working with no clue whether loading, assignment, or sending failed. Add redacted diagnostics and a release handoff.",
          "acceptanceCriteria": [
            "Diagnostics include build version, operation category, timestamp, and safe correlation ID.",
            "Customer text, drafts, tokens, and raw responses are excluded.",
            "Copying diagnostics after failure preserves current draft and navigation."
          ],
          "implementationNotes": [
            "Use a field allowlist and document the owner of each operation category."
          ],
          "verification": [
            "Trigger sending failure and match its correlation ID to the synthetic trace.",
            "Put secret-like strings in messages and errors; copied diagnostics contain none."
          ],
          "deliverables": [
            "Redacted diagnostics panel and one-page console runbook"
          ],
          "rollout": "Enable diagnostic copying for the pilot; hide it immediately if excluded content appears.",
          "skills": [
            "Observability",
            "Privacy",
            "Operational handoff"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "9d1ded75-447e-4375-9830-750cc6b77246",
      "key": "FORM",
      "title": "Purchase requests without spreadsheet follow-ups",
      "field": "Frontend",
      "summary": "Make purchase requests accurate, recoverable, and reviewable across revisions.",
      "context": "The fictional Beacon operations team buys equipment through a browser form. Finance checks totals, departments, and quotes. Scope is one currency per request and an approval API contract; payments and accounting integration are excluded.",
      "stack": [
        "Vue",
        "TypeScript",
        "CSS Modules",
        "Vitest",
        "Playwright"
      ],
      "prerequisites": [
        "Synthetic department and cost-center directory",
        "Draft, submission, and approval API fixtures"
      ],
      "developerValue": "Practice form modeling, exact totals, revision handling, and collaboration under failure.",
      "companyValue": "Inspect whether a developer protects business workflows from duplicate, lost, or misleading submissions.",
      "delivery": "Each issue is a bounded pull request against one shared form. The complete project is optional; document mocked APIs.",
      "phases": [
        {
          "id": "request",
          "title": "Capture the request",
          "goal": "Make entry accurate and accessible."
        },
        {
          "id": "draft",
          "title": "Keep work recoverable",
          "goal": "Preserve drafts and supporting documents."
        },
        {
          "id": "review",
          "title": "Make approval trustworthy",
          "goal": "Expose changes and protect submission boundaries."
        },
        {
          "id": "release",
          "title": "Validate the handoff",
          "goal": "Keep the workflow usable under team conditions."
        }
      ],
      "tickets": [
        {
          "id": "2e7a58ce-8173-4942-9746-3bc2d4d9136b",
          "key": "FORM-101",
          "title": "Point requesters to the field that needs fixing",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "request",
          "dependsOn": [],
          "scenario": "An incomplete request produces only Invalid request. Add field feedback and an error summary for vendor, business reason, and delivery date.",
          "acceptanceCriteria": [
            "Invalid submission focuses a summary with links to fields.",
            "Each error is associated with its field and stays visible until resolved.",
            "Entered values survive client and server validation failures."
          ],
          "implementationNotes": [
            "Map known server field errors and use a safe general fallback for unknown errors."
          ],
          "verification": [
            "Submit an empty form by keyboard and follow each summary link.",
            "Return an unknown server validation code; preserve values and display an actionable general error."
          ],
          "deliverables": [
            "Accessible validation summary and server-error mapping cases"
          ],
          "rollout": "Ship behind the form flag; restore the earlier route if requesters cannot correct errors.",
          "skills": [
            "Form validation",
            "Accessibility",
            "API errors"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Accessibility",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "3f727678-cefb-4555-9bac-12dbda8ddcae",
          "key": "FORM-102",
          "title": "Make the total match the submitted line items",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "request",
          "dependsOn": [],
          "scenario": "Three items at 19.99 sometimes display extra decimal digits. Finance also found a preview total that differed from the payload after a quantity edit.",
          "acceptanceCriteria": [
            "One calculation path derives display and payload totals from integer minor units.",
            "Fractional quantities, negative prices, overflow, and mixed currencies are rejected.",
            "Editing or removing a line immediately updates the same total."
          ],
          "implementationNotes": [
            "Document the fixed two-decimal practice currency and rounding rule; conversion is excluded."
          ],
          "verification": [
            "Enter three units at 19.99 and compare preview and payload at 59.97.",
            "Try overflow and negative amounts; submission is blocked with field errors."
          ],
          "deliverables": [
            "Pure total calculator and boundary fixtures"
          ],
          "rollout": "Compare old and new totals on synthetic requests; block submission rather than use inaccurate arithmetic on mismatch.",
          "skills": [
            "Money arithmetic",
            "Data modeling",
            "Boundary testing"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "13ef76d4-3d33-427e-bf8c-82a5b33f32b1",
          "key": "FORM-103",
          "title": "Clear an orphaned cost center when department changes",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "request",
          "dependsOn": [
            "FORM-101"
          ],
          "scenario": "Selecting Marketing / Events and then changing to Engineering leaves Events hidden in the payload. The reviewer has to send the request back.",
          "acceptanceCriteria": [
            "Department changes clear any incompatible cost center.",
            "Loading and unavailable directory states differ from an empty directory.",
            "A previous department response cannot replace active options."
          ],
          "implementationNotes": [
            "Store stable directory IDs and explain why a selection was cleared."
          ],
          "verification": [
            "Switch Marketing / Events to Engineering; the field and payload both lose Events.",
            "Reverse response order and reject the active request; stale options remain unavailable."
          ],
          "deliverables": [
            "Dependent-select fix and delayed-directory tests"
          ],
          "rollout": "Release after synthetic department-switch checks; prevent submission if required directory data is unavailable.",
          "skills": [
            "Dependent forms",
            "Async state",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "f0df6a5d-1dfb-453a-ad6d-1ce8f10ea892",
          "key": "FORM-104",
          "title": "Save drafts without overwriting a second browser tab",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "draft",
          "dependsOn": [
            "FORM-102",
            "FORM-103"
          ],
          "scenario": "A requester edits quantities in one tab and the explanation in another. Background autosave overwrites whichever tab saved first.",
          "acceptanceCriteria": [
            "Autosave includes the loaded revision and serializes local writes.",
            "Conflicts pause autosave and offer reload or a reviewable copy of local edits.",
            "Navigating away with unsaved changes triggers a meaningful warning where supported."
          ],
          "implementationNotes": [
            "Never merge money fields automatically; preserve local edits for explicit conflict resolution."
          ],
          "verification": [
            "Save normally and verify the saved indicator follows the acknowledged revision.",
            "Race two tabs, then fail recovery fetch; local edits remain and autosave stays paused."
          ],
          "deliverables": [
            "Revision-aware draft coordinator and two-tab conflict reproduction"
          ],
          "rollout": "Pilot manual saves before autosave; disable autosave without changing stored drafts if conflicts rise.",
          "skills": [
            "Optimistic concurrency",
            "Draft recovery",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b63e748c-3b01-4b08-b737-711a15587a77",
          "key": "FORM-105",
          "title": "Show attachment quarantine and upload recovery clearly",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "draft",
          "dependsOn": [
            "FORM-101"
          ],
          "scenario": "Quotes look attached immediately even though the upload service can reject or quarantine them. Requesters submit before learning the reviewer cannot open the PDF.",
          "acceptanceCriteria": [
            "Uploading, scanning, accepted, rejected, and failed have distinct labels.",
            "Submission stays unavailable while a required quote is pending or rejected.",
            "Retry uses the upload operation contract; removal cancels pending UI work."
          ],
          "implementationNotes": [
            "Treat names and service messages as untrusted text; scanning uses API fixtures here."
          ],
          "verification": [
            "Advance an upload from scanning to accepted and verify submission becomes available.",
            "Reject a file and resolve a removed upload late; neither appears accepted."
          ],
          "deliverables": [
            "Attachment state component and upload fixture scenarios"
          ],
          "rollout": "Pilot quote-required requests; disable new attachment submissions if accepted state cannot be reconciled.",
          "skills": [
            "Upload UX",
            "State modeling",
            "Untrusted input"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6de07eb8-9aaa-404d-ac1b-47c83a584eaf",
          "key": "FORM-106",
          "title": "Show finance what changed since their last review",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "review",
          "dependsOn": [
            "FORM-104",
            "FORM-105"
          ],
          "scenario": "After clarification, a requester changes both the explanation and amount. The review page says Updated without identifying which lines changed.",
          "acceptanceCriteria": [
            "The view compares two explicit immutable revisions.",
            "Stable line IDs identify additions, removals, and old/new values.",
            "Collapsing unchanged fields keeps total difference and revision identifiers visible."
          ],
          "implementationNotes": [
            "Use the shared money calculator; array position is not a line identity."
          ],
          "verification": [
            "Reorder unchanged lines and confirm no false replacements appear.",
            "Remove one line and increase another; verify both changes, total difference, and a missing-baseline error."
          ],
          "deliverables": [
            "Revision comparison view and change-set fixtures"
          ],
          "rollout": "Add a comparison tab; hide it on regression while preserving both original revision pages.",
          "skills": [
            "Diff presentation",
            "Immutable data",
            "Review workflows"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "d4bd4b1b-b325-4127-ba46-1a6654c5a282",
          "key": "FORM-107",
          "title": "Close the duplicate-submit gap after a slow response",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 195,
          "phaseId": "review",
          "dependsOn": [
            "FORM-104",
            "FORM-105"
          ],
          "scenario": "A 15-second response prompts a refresh and second submission. Finance receives two approval requests. Coordinate submission identity with saved revisions and uncertain responses.",
          "acceptanceCriteria": [
            "Submission waits for acknowledgement of the exact displayed draft revision.",
            "One revision reuses a durable operation key across refresh and retry.",
            "Uncertain results use status lookup; edits cannot silently reuse the old key for a different revision."
          ],
          "implementationNotes": [
            "Use the idempotency/status contract; disabling the button alone is insufficient."
          ],
          "verification": [
            "Drop the accepted response, refresh, and retry; one logical submission exists under the same operation key.",
            "Edit during failed autosave and submit; no unsaved or mismatched revision is sent."
          ],
          "deliverables": [
            "Submission coordinator and refresh-after-timeout test"
          ],
          "rollout": "Pilot with one queue and inspect operation conflicts; disable new submissions on reconciliation failure while preserving drafts.",
          "skills": [
            "Idempotency",
            "Concurrency",
            "Workflow integrity"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "caf839bf-5797-46e5-ac1c-26f251afb64d",
          "key": "FORM-108",
          "title": "Retire approval controls when authority changes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "review",
          "dependsOn": [
            "FORM-106"
          ],
          "scenario": "An approver leaves the page open past delegation expiry. Approve fails, but controls remain active and the page incorrectly labels the request handled.",
          "acceptanceCriteria": [
            "Denial preserves request state and removes stale controls after authority refresh.",
            "Organization switching clears previous request and permissions before rendering new context.",
            "Access-loss messages omit private authorization diagnostics."
          ],
          "implementationNotes": [
            "UI checks improve interaction; the API must authorize every action independently."
          ],
          "verification": [
            "Approve with current authority and display only the confirmed result.",
            "Expire delegation and switch organizations mid-request; no success state or old request content appears."
          ],
          "deliverables": [
            "Authority-refresh handling and denied-approval browser case"
          ],
          "rollout": "Release denial handling independently; disable approvals separately while preserving permitted reading.",
          "skills": [
            "Authorization UX",
            "Tenant isolation",
            "Error handling"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "10a7b798-b71b-42f2-845f-51da7e375880",
          "key": "FORM-109",
          "title": "Make a 40-line request usable on a narrow screen",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "release",
          "dependsOn": [
            "FORM-102",
            "FORM-106"
          ],
          "scenario": "At 200% zoom, a sticky total covers the final row and horizontal scrolling separates quantity inputs from labels. Fix the equipment-request layout.",
          "acceptanceCriteria": [
            "Labels, values, errors, and remove actions remain associated at the agreed narrow viewport and zoom.",
            "The total and footer never cover focusable content.",
            "Long vendor names and 40 lines remain readable without losing review information."
          ],
          "implementationNotes": [
            "Use semantic CSS; do not replace rows with unlabelled visual cards."
          ],
          "verification": [
            "Review the 40-line fixture by keyboard at 200% zoom and capture its final row.",
            "Use a long vendor and invalid quantity; the error remains visible without horizontal page overflow."
          ],
          "deliverables": [
            "Responsive line-item layout and zoom walkthrough"
          ],
          "rollout": "Preview on agreed finance viewports; revert the layout if associations or actions become inaccessible.",
          "skills": [
            "Responsive design",
            "CSS",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f9983b25-288f-4976-8007-4cc1ec25eabb",
          "key": "FORM-110",
          "title": "Check the request-return-resubmit journey before release",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "release",
          "dependsOn": [
            "FORM-107",
            "FORM-108",
            "FORM-109"
          ],
          "scenario": "Form tests passed, but the last release lost a quote when finance returned a request. Add a deterministic journey through return, edit, and resubmission.",
          "acceptanceCriteria": [
            "The journey covers submission, finance return, changed amount, and review of the new revision.",
            "Attachment and request identities stay stable across revision creation.",
            "Resubmission failure leaves the earlier revision readable and the new draft recoverable."
          ],
          "implementationNotes": [
            "Synthetic users and API fixtures establish workflow behavior, not live-service readiness."
          ],
          "verification": [
            "Run twice from clean fixtures and compare final revision relationships.",
            "Fail after draft save before submission acknowledgement; attachments survive and requests do not duplicate."
          ],
          "deliverables": [
            "Workflow browser check and release/rollback checklist"
          ],
          "rollout": "Gate form releases on this journey; stop rollout on identity loss and restore the prior form build.",
          "skills": [
            "End-to-end testing",
            "Release engineering",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "292bf637-b8f9-4ad3-adb8-dd5b496cbd03",
      "key": "FIELD",
      "title": "An offline workday for field technicians",
      "field": "Mobile",
      "summary": "Keep assigned maintenance work usable without reception and reconcile changes safely when connectivity returns.",
      "context": "The fictional Vale facilities team services equipment in basements with poor reception. Technicians receive assigned work orders, record checks, and attach synthetic equipment photos. The practice app uses an on-device database and a stub sync service; background location tracking is excluded.",
      "stack": [
        "React Native",
        "TypeScript",
        "SQLite",
        "Jest",
        "Android emulator"
      ],
      "prerequisites": [
        "Synthetic work orders and a revisioned sync contract",
        "An emulator with controllable connectivity and app lifecycle"
      ],
      "developerValue": "Practice durable local state, mobile lifecycle recovery, and conflict resolution in realistic offline workflows.",
      "companyValue": "Review whether an engineer can protect field work through crashes, interrupted uploads, and reassignment.",
      "delivery": "Deliver selected tickets against synthetic work orders. Full project phases are optional and do not require a live dispatch service.",
      "phases": [
        {
          "id": "local",
          "title": "Start the offline day",
          "goal": "Make downloaded work clear and durable."
        },
        {
          "id": "capture",
          "title": "Record the visit",
          "goal": "Capture work and attachments through interruptions."
        },
        {
          "id": "sync",
          "title": "Reconnect safely",
          "goal": "Resolve retries, reassignment, and conflicting edits."
        },
        {
          "id": "operations",
          "title": "Support the rollout",
          "goal": "Protect devices and give support safe diagnostics."
        }
      ],
      "tickets": [
        {
          "id": "93cd97b9-6099-42a7-828b-07b0c4013aae",
          "key": "FIELD-101",
          "title": "Tell technicians which work orders are available offline",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "local",
          "dependsOn": [],
          "scenario": "The assignment list looks ready in the depot, but opening a work order downstairs produces an endless spinner. Distinguish listed work from fully downloaded details.",
          "acceptanceCriteria": [
            "Each order states whether required details are cached, downloading, or unavailable offline.",
            "Opening an uncached order offline shows a recoverable explanation.",
            "The app shows the last successful download time without presenting cached data as current."
          ],
          "implementationNotes": [
            "Use a connectivity adapter for fixtures; an online signal does not guarantee the API is reachable."
          ],
          "verification": [
            "Download an order, disable connectivity, and open its cached details.",
            "Open a listed but uncached order offline and simulate a reachable network with a failed API; neither path spins indefinitely."
          ],
          "deliverables": [
            "Offline-availability presentation and connectivity fixture cases"
          ],
          "rollout": "Pilot with a small depot dataset; retain read-only cached access if download status regresses.",
          "skills": [
            "Offline UX",
            "Mobile state",
            "Error handling"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1120c719-5295-4a9c-accf-1100e20fc2dc",
          "key": "FIELD-102",
          "title": "Commit a completed checklist item before showing it saved",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "local",
          "dependsOn": [],
          "scenario": "A technician checks Replace intake filter and force-closes the app. On reopening, the check is gone even though the screen showed Saved.",
          "acceptanceCriteria": [
            "Saved appears only after the local transaction commits.",
            "A committed answer survives process termination and reopening.",
            "Database write failure preserves the editable value and clearly marks it unsaved."
          ],
          "implementationNotes": [
            "Keep persistence behind a repository boundary; component state alone is not durable."
          ],
          "verification": [
            "Commit an answer, terminate the app, and verify the answer after restart.",
            "Inject a database-full error before commit; the UI must not claim success or discard the typed value."
          ],
          "deliverables": [
            "Transactional checklist persistence and restart regression test"
          ],
          "rollout": "Enable on pilot devices with synthetic work; stop editing if local persistence is unavailable rather than falsely confirming saves.",
          "skills": [
            "SQLite",
            "Transactions",
            "Lifecycle testing"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f914c1c0-09f7-40b4-a1ef-ad61e820cef9",
          "key": "FIELD-103",
          "title": "Make inspection inputs usable with large text",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "local",
          "dependsOn": [
            "FIELD-101"
          ],
          "scenario": "A technician increases system text size. Pass/Fail controls overlap equipment names, and the last input disappears beneath the keyboard.",
          "acceptanceCriteria": [
            "The agreed largest supported text setting keeps labels and choices readable.",
            "Focused fields can scroll above the keyboard without hiding their error messages.",
            "Each checklist choice has an accessible name that includes its inspection item."
          ],
          "implementationNotes": [
            "Do not disable system text scaling to make the layout fit."
          ],
          "verification": [
            "Complete a six-item inspection at large text size with the on-screen keyboard.",
            "Use a long equipment name and an invalid reading; controls and errors remain reachable through assistive navigation."
          ],
          "deliverables": [
            "Adaptive inspection layout and emulator accessibility walkthrough"
          ],
          "rollout": "Review on the smallest supported test device; revert affected layout components if input becomes unreachable.",
          "skills": [
            "Mobile accessibility",
            "Responsive layout",
            "Forms"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7eadff40-7e44-4ee0-9ecb-d99312806e71",
          "key": "FIELD-104",
          "title": "Keep photo evidence attached after the app is suspended",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "capture",
          "dependsOn": [
            "FIELD-102"
          ],
          "scenario": "A technician takes an equipment photo, answers a phone call, and returns to a blank attachment tile. The draft stored a temporary camera URI that no longer exists.",
          "acceptanceCriteria": [
            "Attachment metadata becomes saved only after the file is copied into app-owned storage.",
            "Restart restores pending attachments with a clear missing-file recovery action when necessary.",
            "Cancelled capture and failed copies leave neither dangling records nor orphaned temporary files."
          ],
          "implementationNotes": [
            "Use synthetic equipment images; permission to capture does not authorize unrelated gallery access."
          ],
          "verification": [
            "Capture, suspend, terminate, and reopen; the saved attachment remains available.",
            "Delete the source URI before copying and cancel another capture; no accepted attachment or orphaned pending row remains."
          ],
          "deliverables": [
            "Durable attachment staging and lifecycle failure cases"
          ],
          "rollout": "Pilot capture separately from uploads; disable new capture if staged-file recovery fails while preserving existing files.",
          "skills": [
            "Mobile filesystems",
            "Lifecycle recovery",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5ea9cec4-2f80-4e05-afab-6cac466834cd",
          "key": "FIELD-105",
          "title": "Explain why a work order is not ready to finish",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "capture",
          "dependsOn": [
            "FIELD-102",
            "FIELD-103",
            "FIELD-104"
          ],
          "scenario": "Finish visit is disabled with no explanation when a required reading or photo is missing. Technicians tap through every section to find the blocker.",
          "acceptanceCriteria": [
            "A completion summary lists missing required answers and attachments with navigation actions.",
            "Optional notes never block completion.",
            "Finishing offline creates a pending completion operation and labels it as awaiting sync rather than server-confirmed."
          ],
          "implementationNotes": [
            "Derive readiness from the current local revision and the downloaded checklist version."
          ],
          "verification": [
            "Fill the required inputs and finish offline; a pending operation is visible after restart.",
            "Remove a required photo and leave optional notes empty; only the photo blocks completion."
          ],
          "deliverables": [
            "Completion-readiness summary and offline finish cases"
          ],
          "rollout": "Enable the summary before completion changes; pause finishing if checklist versions cannot be resolved.",
          "skills": [
            "Workflow modeling",
            "Validation",
            "Offline UX"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "daa7f5fb-4523-423b-b6a5-d9768be143e5",
          "key": "FIELD-106",
          "title": "Drain the sync queue without duplicating completed visits",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "FIELD-105"
          ],
          "scenario": "Reception returns briefly and drops again during sync. The same completed visit is sent twice, while a later note disappears after a failed batch.",
          "acceptanceCriteria": [
            "Each queued operation has a stable identity and advances only after acknowledgement.",
            "Per-order dependencies preserve answer and completion ordering while unrelated orders can progress.",
            "Retry uses bounded backoff and keeps unacknowledged operations durable across restart."
          ],
          "implementationNotes": [
            "The fixture service deduplicates operation IDs; do not assume a timeout means the server rejected a write."
          ],
          "verification": [
            "Acknowledge a batch and verify only confirmed queue entries leave local storage.",
            "Drop a response after server acceptance and restart; retries keep the same IDs and produce one logical completion."
          ],
          "deliverables": [
            "Durable sync queue processor and interrupted-batch tests"
          ],
          "rollout": "Limit initial batch size and observe backlog age; pause queue draining on repeated protocol errors without deleting pending work.",
          "skills": [
            "Idempotency",
            "Queues",
            "Retry design"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "631b1950-c7c4-4aa2-8d56-f9d0cee3176f",
          "key": "FIELD-107",
          "title": "Keep reassigned work from being silently completed offline",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "sync",
          "dependsOn": [
            "FIELD-106"
          ],
          "scenario": "Dispatch reassigns a job while the original technician is underground. That device later uploads completion against the old assignment. Preserve the technician’s work while honoring current server authority.",
          "acceptanceCriteria": [
            "Sync includes the assignment revision that authorized the offline visit.",
            "Reassignment rejection moves local work into an explicit review-required state without marking the job complete.",
            "The technician can inspect their unsynced notes and a redacted export while server-only actions remain blocked."
          ],
          "implementationNotes": [
            "Do not automatically apply old work to the new assignee; supervisor resolution is a documented stub contract."
          ],
          "verification": [
            "Sync a completion with the current assignment revision and confirm acceptance.",
            "Reassign before reconnecting and reject the old revision; retain local work and prevent repeated automatic completion retries."
          ],
          "deliverables": [
            "Reassignment conflict flow and preserved-work recovery fixture"
          ],
          "rollout": "Pilot with forced reassignment scenarios; disable offline finishing if authority conflicts cannot retain work safely.",
          "skills": [
            "Authorization",
            "Conflict resolution",
            "Distributed state"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "562e988f-9375-4d42-98ea-755bf996f35a",
          "key": "FIELD-108",
          "title": "Resume a large photo upload without restarting the whole queue",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "sync",
          "dependsOn": [
            "FIELD-104",
            "FIELD-106"
          ],
          "scenario": "One 12 MB equipment photo repeatedly fails halfway through and blocks all completed visits. Integrate the resumable-upload contract and isolate attachment progress from unrelated operations.",
          "acceptanceCriteria": [
            "Committed upload offsets are persisted and reconciled with the service after reconnect.",
            "An expired upload session starts a new session without losing the source file.",
            "Failure of one attachment does not block sync for another independent work order."
          ],
          "implementationNotes": [
            "Use small synthetic chunks in tests; server file integrity and scanning remain separate responsibilities."
          ],
          "verification": [
            "Interrupt after two acknowledged chunks and resume from the server-confirmed offset.",
            "Expire the session and simulate a missing local file; show repair guidance and allow another work order to sync."
          ],
          "deliverables": [
            "Resumable upload adapter and offset/session recovery cases"
          ],
          "rollout": "Enable for larger attachments first; pause uploads and keep staged files if offset reconciliation fails.",
          "skills": [
            "Resumable uploads",
            "Fault isolation",
            "Persistence"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b14875a2-9ac4-4ccf-8e9c-6dc16a6870ce",
          "key": "FIELD-109",
          "title": "Clear a shared device without dropping pending work invisibly",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "operations",
          "dependsOn": [
            "FIELD-107",
            "FIELD-108"
          ],
          "scenario": "Two technicians share a tablet between shifts. Sign-out currently leaves cached addresses for the next user, but blindly deleting storage would also erase unsynced repairs.",
          "acceptanceCriteria": [
            "Sign-out reports pending work before an explicit discard or sync choice.",
            "Confirmed sign-out removes account-scoped database rows, staged files, and credentials from the usable app context.",
            "Signing in as a different technician cannot render or sync the prior account’s data."
          ],
          "implementationNotes": [
            "Document the limits of app-level deletion; do not claim forensic erasure or export data automatically."
          ],
          "verification": [
            "Sync all work, sign out, and sign in as another user; no previous records appear.",
            "Fail sync with pending attachments and choose cancel; preserve the current session and work without exposing it to another account."
          ],
          "deliverables": [
            "Shared-device sign-out flow and account-boundary tests"
          ],
          "rollout": "Require this check before shared-device pilots; disable account switching if cleanup cannot be confirmed.",
          "skills": [
            "Privacy",
            "Account isolation",
            "Data lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "81110be7-0f2c-44ec-a850-a6b128d41707",
          "key": "FIELD-110",
          "title": "Expose sync health that depot support can act on",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "operations",
          "dependsOn": [
            "FIELD-106",
            "FIELD-109"
          ],
          "scenario": "Depot support cannot distinguish a device waiting for Wi-Fi from one stuck on an expired upload. Add an account-local sync health page and a safe support bundle.",
          "acceptanceCriteria": [
            "The page separates queued, retrying, blocked, and acknowledged counts with last successful sync time.",
            "The bundle includes app/schema versions and operation categories but excludes notes, photos, addresses, and tokens.",
            "A retry action obeys the same queue rules and cannot bypass blocked authority conflicts."
          ],
          "implementationNotes": [
            "Keep diagnostic storage bounded and document one recovery action per blocker category."
          ],
          "verification": [
            "Create a retryable upload and a reassignment blocker; verify distinct states and actions.",
            "Seed private fixture content and inspect the exported bundle; none of it is present and blocked work is not force-sent."
          ],
          "deliverables": [
            "Sync health screen and depot troubleshooting note"
          ],
          "rollout": "Enable for pilot support staff; remove bundle export if redaction fails while retaining local status labels.",
          "skills": [
            "Observability",
            "Support tooling",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "7686971b-e040-4dad-9c1f-ef8c3a641873",
      "key": "TRIP",
      "title": "A commuter planner that explains uncertainty",
      "field": "Mobile",
      "summary": "Make saved journeys, departures, and service alerts useful when feeds or device permissions change.",
      "context": "The fictional Northline commuter app plans bus and rail trips from synthetic timetable and alert feeds. Riders save journeys and choose optional reminders. The scope excludes ticket purchases, safety guarantees, and continuous location collection.",
      "stack": [
        "Kotlin",
        "Jetpack Compose",
        "Room",
        "JUnit",
        "Android emulator"
      ],
      "prerequisites": [
        "Synthetic timetable with explicit time zones and service dates",
        "Departure, alert, and permission adapters with failure fixtures"
      ],
      "developerValue": "Practice temporal modeling, feed reconciliation, battery-conscious refresh, and mobile permission design.",
      "companyValue": "Review how an engineer communicates uncertainty and keeps a consumer app useful under unreliable data.",
      "delivery": "Work from fixed fixtures and an emulator. Deliver individual issues or three-to-four focused phase increments.",
      "phases": [
        {
          "id": "journey",
          "title": "Make journeys readable",
          "goal": "Present stable saved trips and correct service times."
        },
        {
          "id": "feeds",
          "title": "Handle changing feeds",
          "goal": "Keep live data, cancellations, and stale results coherent."
        },
        {
          "id": "device",
          "title": "Respect device conditions",
          "goal": "Handle lifecycle, reminders, and permissions deliberately."
        },
        {
          "id": "launch",
          "title": "Prepare a measured release",
          "goal": "Explain limitations and verify the complete journey."
        }
      ],
      "tickets": [
        {
          "id": "ed34c934-1140-4842-9274-d388c6bd3929",
          "key": "TRIP-101",
          "title": "Give saved journeys names that survive station renames",
          "type": "STORY",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "journey",
          "dependsOn": [],
          "scenario": "Central Station becomes Central Exchange in a feed update and a saved commute disappears. Save journeys by station identity and let riders keep a personal label.",
          "acceptanceCriteria": [
            "Saved journeys use stable station IDs and optional rider labels.",
            "Renaming a station updates its display without duplicating the journey.",
            "A removed station shows an unavailable state with an edit action instead of silently deleting the journey."
          ],
          "implementationNotes": [
            "Limit labels and render them as text; no account sync is required."
          ],
          "verification": [
            "Save Home to Office and apply a station-name update; identity and label remain.",
            "Remove a referenced station and reload; the saved journey remains editable with an unavailable endpoint."
          ],
          "deliverables": [
            "Saved-journey model and station-update fixture tests"
          ],
          "rollout": "Migrate a copied local fixture database first; retain original IDs if label migration fails.",
          "skills": [
            "Data modeling",
            "Local persistence",
            "Migration"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "44507917-89cc-4ad4-b2fe-5d0f9fa14037",
          "key": "TRIP-102",
          "title": "Keep the last train on the correct service day",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "journey",
          "dependsOn": [],
          "scenario": "A Saturday service departing after midnight appears under Sunday and disappears from the late-night search. The feed expresses service-day times beyond 24:00.",
          "acceptanceCriteria": [
            "Service date and elapsed service-day time map to an instant using the feed time zone.",
            "Display uses rider-friendly local date/time while retaining the original service identity.",
            "Unsupported or ambiguous feed times produce an explicit data error rather than a guessed departure."
          ],
          "implementationNotes": [
            "Write the conversion policy for daylight-saving transitions; do not parse service times as ordinary clock-only strings."
          ],
          "verification": [
            "Resolve a Saturday 25:10 service to the expected next-calendar-day instant and keep Saturday service identity.",
            "Exercise the agreed clock-change fixtures and malformed time input; no negative journey duration or silent guess appears."
          ],
          "deliverables": [
            "Service-time conversion module and boundary fixture table"
          ],
          "rollout": "Compare converted times against curated synthetic examples; hide affected feed entries if conversion fails.",
          "skills": [
            "Time zones",
            "Domain modeling",
            "Boundary testing"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 80
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ffa4e66f-611a-49c8-9628-a36ec72f2d3a",
          "key": "TRIP-103",
          "title": "Explain transfers without relying on line colors",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "journey",
          "dependsOn": [
            "TRIP-102"
          ],
          "scenario": "The journey card distinguishes Line 4 from Line 8 only by color. Riders using grayscale or a screen reader cannot tell where to change.",
          "acceptanceCriteria": [
            "Each leg shows mode, line label, destination, and boarding/alighting stops in reading order.",
            "Transfers state walking and waiting time in text.",
            "Large text and grayscale preserve every required leg distinction."
          ],
          "implementationNotes": [
            "Keep decorative map graphics out of the essential accessible description."
          ],
          "verification": [
            "Read a two-transfer fixture with assistive navigation and compare spoken order to itinerary order.",
            "Use grayscale and large text; a canceled leg must remain identifiable without its color or icon."
          ],
          "deliverables": [
            "Accessible journey-leg card and device walkthrough"
          ],
          "rollout": "Release text semantics with the existing card layout first; revert visual changes independently if leg details become clipped.",
          "skills": [
            "Mobile accessibility",
            "Information design",
            "Compose"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4eb7717d-eba1-4e27-9230-45b566675793",
          "key": "TRIP-104",
          "title": "Label stale departures when the live feed stops responding",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "feeds",
          "dependsOn": [
            "TRIP-102"
          ],
          "scenario": "The departures screen keeps displaying an old prediction after a feed outage. A rider mistakes a 12-minute-old estimate for a live arrival.",
          "acceptanceCriteria": [
            "Predictions show source update time and become stale at the configured fixture threshold.",
            "Scheduled times remain available but are visibly distinguished from current predictions.",
            "A failed refresh preserves readable departures and provides a retry action."
          ],
          "implementationNotes": [
            "Calculate staleness from trusted feed timestamps with a documented clock-skew allowance."
          ],
          "verification": [
            "Advance a fake clock across the freshness threshold and inspect the label change.",
            "Return a future-dated update beyond allowed skew and then fail refresh; do not display it as trustworthy live data."
          ],
          "deliverables": [
            "Departure freshness policy and fake-clock tests"
          ],
          "rollout": "Enable stale labels for one synthetic feed; disable live prediction display if timestamps cannot be validated.",
          "skills": [
            "Freshness modeling",
            "Error recovery",
            "Time handling"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9a566373-aee9-406d-91be-d238102af747",
          "key": "TRIP-105",
          "title": "Apply cancellation updates to the right departure instance",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "feeds",
          "dependsOn": [
            "TRIP-104"
          ],
          "scenario": "Canceling the 08:10 Line 4 also marks tomorrow’s 08:10 as canceled because the cache key contains only the route. Reconcile alerts by departure identity.",
          "acceptanceCriteria": [
            "Cancellation identity includes service date and trip instance rather than route label alone.",
            "A newer correction can restore a departure while an older cancellation cannot overwrite it.",
            "Unknown alert references remain diagnosable without canceling unrelated trips."
          ],
          "implementationNotes": [
            "Define ordering from feed revision metadata, not arrival order on the device."
          ],
          "verification": [
            "Cancel today’s instance and verify tomorrow’s matching route stays available.",
            "Deliver correction and cancellation out of order; the newest revision wins and unknown IDs change no journey."
          ],
          "deliverables": [
            "Departure alert reducer and ordering regression tests"
          ],
          "rollout": "Shadow-reconcile synthetic alerts before display; fall back to a general service notice if precise mapping is unavailable.",
          "skills": [
            "Event ordering",
            "Cache identity",
            "Data reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3367b22b-0ab5-4665-9ff0-9e29e527bf4a",
          "key": "TRIP-106",
          "title": "Stop refreshing a journey after the rider leaves it",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "device",
          "dependsOn": [
            "TRIP-104"
          ],
          "scenario": "Opening several saved journeys starts several permanent refresh loops. The app continues polling all of them in the background and occasionally displays the wrong result.",
          "acceptanceCriteria": [
            "Only the visible journey owns an active foreground refresh loop.",
            "Backgrounding pauses polling and foreground return performs one bounded freshness check.",
            "Late results from a departed journey cannot update the active journey."
          ],
          "implementationNotes": [
            "Use lifecycle-aware cancellation plus request identity; do not request a background location service for refresh."
          ],
          "verification": [
            "Switch among three journeys and inspect that only one loop remains active.",
            "Background during an in-flight request and return after expiry; exactly one fresh check occurs and stale results are ignored."
          ],
          "deliverables": [
            "Lifecycle-aware refresh coordinator and request-count tests"
          ],
          "rollout": "Pilot with a short foreground session trace; disable automatic refresh if loop ownership regresses and keep manual refresh.",
          "skills": [
            "Mobile lifecycle",
            "Resource management",
            "Async state"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "30f65da3-6197-49f2-9515-9a28f1558a31",
          "key": "TRIP-107",
          "title": "Make departure reminders honest about permission and schedule changes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "device",
          "dependsOn": [
            "TRIP-105",
            "TRIP-106"
          ],
          "scenario": "A rider enables a reminder after denying notifications, then assumes an alert will arrive. Rescheduled departures also leave the old reminder behind.",
          "acceptanceCriteria": [
            "Reminder state distinguishes requested, scheduled, denied, canceled, and expired.",
            "Changing the departure revision cancels the old schedule before confirming its replacement.",
            "The app offers an in-app alternative when device notification capability is unavailable."
          ],
          "implementationNotes": [
            "Request permission only after an explicit reminder action and disclose the limits of delivery timing."
          ],
          "verification": [
            "Allow notifications, schedule a reminder, then change departure time; one current schedule remains.",
            "Deny permission and cancel the trip during rescheduling; no successful reminder claim or orphan schedule remains."
          ],
          "deliverables": [
            "Reminder state coordinator and permission-change cases"
          ],
          "rollout": "Pilot opt-in reminders on emulators and test devices; disable new scheduling if duplicate reminders are observed.",
          "skills": [
            "Permissions",
            "Scheduling",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "4f920124-7d04-4729-ab57-762067cebae5",
          "key": "TRIP-108",
          "title": "Recover a route search when the timetable changes mid-session",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "device",
          "dependsOn": [
            "TRIP-101",
            "TRIP-105",
            "TRIP-106"
          ],
          "scenario": "A timetable refresh replaces station and trip data while a route calculation still reads the old version. The result combines a new platform with a removed connection.",
          "acceptanceCriteria": [
            "A search reads one timetable snapshot/version for its entire calculation.",
            "A result from an obsolete snapshot is explicitly revalidated or replaced before being labeled current.",
            "Interrupted dataset replacement leaves either the old complete dataset or the new complete dataset available."
          ],
          "implementationNotes": [
            "Use synthetic small datasets and a local transaction; implementing a nationwide routing engine is excluded."
          ],
          "verification": [
            "Swap timetable versions during calculation and verify every returned leg belongs to one version.",
            "Fail replacement halfway through and restart; searches use a complete version and unavailable connections are not invented."
          ],
          "deliverables": [
            "Versioned timetable handoff and interrupted-update tests"
          ],
          "rollout": "Stage updates beside the active dataset; switch the active pointer back if validation fails and retain prior-version diagnostics.",
          "skills": [
            "Snapshot consistency",
            "Transactions",
            "Offline data"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1a1bc5bb-5020-444e-8b59-3f375ecf8189",
          "key": "TRIP-109",
          "title": "Offer nearby stops without making location mandatory",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "launch",
          "dependsOn": [
            "TRIP-101",
            "TRIP-103"
          ],
          "scenario": "The first screen demands location before showing any journeys. A rider who declines cannot search by station even though the timetable supports it.",
          "acceptanceCriteria": [
            "Station search and saved journeys work without location permission.",
            "Nearby stops request location only after an explicit action and show how approximate results are used.",
            "Denial, timeout, and unavailable location return to a usable manual search without repeated prompts."
          ],
          "implementationNotes": [
            "Use a one-shot coarse-location adapter and do not persist coordinates in generic analytics."
          ],
          "verification": [
            "Deny location on first use and complete a manual station search.",
            "Return an approximate fix and then a timeout; nearby results disclose approximation and manual search remains accessible."
          ],
          "deliverables": [
            "Optional nearby-stop flow and permission-free journey check"
          ],
          "rollout": "Release manual search before nearby suggestions; disable the location adapter if denial recovery or privacy checks fail.",
          "skills": [
            "Permission design",
            "Privacy",
            "Mobile UX"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "54e2f5b1-99a4-468b-b05c-ff4e0a892825",
          "key": "TRIP-110",
          "title": "Rehearse a disrupted commute with fixed feed data",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "launch",
          "dependsOn": [
            "TRIP-107",
            "TRIP-108",
            "TRIP-109"
          ],
          "scenario": "Most checks cover a clean daytime trip. Before the pilot, rehearse a saved late-night commute through feed outage, cancellation correction, and app restart.",
          "acceptanceCriteria": [
            "A deterministic scenario records which timetable revision, departure identity, and freshness label appear at each step.",
            "Restart preserves the saved journey without restoring an obsolete reminder.",
            "The handoff states fixture coverage and unresolved live-feed assumptions explicitly."
          ],
          "implementationNotes": [
            "Use a controllable clock and adapters; do not depend on actual transit services or notification delivery."
          ],
          "verification": [
            "Run the rehearsal twice and compare the ordered visible states.",
            "Inject an invalid feed timestamp and an interrupted dataset update; no current-live label or mixed-version trip appears."
          ],
          "deliverables": [
            "Disruption rehearsal script and pilot support checklist"
          ],
          "rollout": "Require the fixed-data rehearsal before app updates; pause pilot expansion on misleading freshness or reminder state.",
          "skills": [
            "Scenario testing",
            "Release readiness",
            "Operational handoff"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ad866514-92f4-416e-a03d-35fd85fa48d1",
      "key": "A11Y",
      "title": "A civic appointment flow people can complete",
      "field": "Accessibility",
      "summary": "Repair public-service booking across keyboard use, zoom, timeouts, and changing availability.",
      "context": "The fictional Riverside desk books appointments for permit paperwork and library assistance. Its browser flow was assembled from separate forms and dialogs. Work uses synthetic availability and booking adapters; actual appointments and personal records are excluded.",
      "stack": [
        "TypeScript",
        "Semantic HTML",
        "CSS Modules",
        "Playwright",
        "axe-core"
      ],
      "prerequisites": [
        "Synthetic services, slots, and booking API contract",
        "Keyboard and screen-reader access for a documented manual check"
      ],
      "developerValue": "Practice accessibility as complete interaction behavior, including recovery and asynchronous updates.",
      "companyValue": "Inspect whether an engineer removes concrete barriers while preserving appointment integrity and supportability.",
      "delivery": "Choose a bounded issue and record automated and manual checks separately. A passing scanner does not establish complete accessibility.",
      "phases": [
        {
          "id": "entry",
          "title": "Enter the flow",
          "goal": "Make service selection and entry understandable."
        },
        {
          "id": "availability",
          "title": "Choose an appointment",
          "goal": "Handle date navigation and changing slots."
        },
        {
          "id": "continuity",
          "title": "Preserve progress",
          "goal": "Recover focus, drafts, and session interruptions."
        },
        {
          "id": "completion",
          "title": "Complete and verify",
          "goal": "Make confirmation and release evidence usable."
        }
      ],
      "tickets": [
        {
          "id": "312991f5-f46f-4887-9604-5fbd55d9d91f",
          "key": "A11Y-101",
          "title": "Replace clickable service tiles with a named selection group",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "entry",
          "dependsOn": [],
          "scenario": "Service choices are clickable divs. Keyboard users cannot reach them, and a screen reader announces no selected service. Repair selection without changing the taxonomy.",
          "acceptanceCriteria": [
            "Every service belongs to a semantic single-choice group with a visible label.",
            "Selected value is announced and included in the form value.",
            "Unavailable services explain their status and cannot be selected by keyboard or pointer."
          ],
          "implementationNotes": [
            "Prefer native radio inputs and associated labels over a custom interaction model."
          ],
          "verification": [
            "Choose Library assistance using only the keyboard and inspect the form value.",
            "Try selecting an unavailable service through pointer and keyboard; selection remains unchanged and its reason is readable."
          ],
          "deliverables": [
            "Semantic service chooser and keyboard regression case"
          ],
          "rollout": "Release independently; restore native unstyled controls if decoration hides focus or selection.",
          "skills": [
            "Semantic HTML",
            "Keyboard access",
            "Forms"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "98ed49e2-ea4f-44c6-bb90-01f96088b443",
          "key": "A11Y-102",
          "title": "Keep contact-field help and errors understandable together",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "entry",
          "dependsOn": [],
          "scenario": "A phone-field error replaces the format hint, then disappears on the first keystroke while the value remains invalid. Give help and validation a coherent lifecycle.",
          "acceptanceCriteria": [
            "Persistent help and current errors are associated with their field.",
            "Submitted errors remain until correction or the next documented validation point.",
            "Invalid submission provides a focusable summary linked to every invalid field."
          ],
          "implementationNotes": [
            "Do not announce errors on every keystroke; document validation timing."
          ],
          "verification": [
            "Submit an invalid phone and navigate from summary to field; hear both hint and error.",
            "Correct one of two invalid fields and resubmit; only the remaining error appears and values persist."
          ],
          "deliverables": [
            "Contact validation semantics and assistive-technology notes"
          ],
          "rollout": "Apply to contact fields first; retain plain inline errors if enhanced summary behavior loses focus.",
          "skills": [
            "Accessible validation",
            "Forms",
            "Focus management"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4abee102-a2a8-4c2c-ab3e-505834c454ef",
          "key": "A11Y-103",
          "title": "Make month navigation work without a pointer",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "availability",
          "dependsOn": [
            "A11Y-101"
          ],
          "scenario": "The calendar exposes 42 unnamed buttons and moves focus to the page top on month changes. Add a deliberate keyboard model and plain date-entry alternative.",
          "acceptanceCriteria": [
            "Date controls announce full date, availability, and selection.",
            "Changing month retains focus at a predictable date or documented month control.",
            "Manual date entry uses the same availability validation and reports invalid dates clearly."
          ],
          "implementationNotes": [
            "Document the calendar keyboard model; shortcuts must not conflict with text entry."
          ],
          "verification": [
            "Select an available date across a month boundary by keyboard.",
            "Enter an impossible date and navigate to an unavailable date; neither becomes selected and focus remains recoverable."
          ],
          "deliverables": [
            "Accessible date selection and month-boundary walkthrough"
          ],
          "rollout": "Keep manual entry during rollout; disable the custom calendar on keyboard-navigation regression.",
          "skills": [
            "Keyboard interaction",
            "Date input",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5df57444-3feb-4776-9b5b-b0b079e212c6",
          "key": "A11Y-104",
          "title": "Keep the booking action visible at high zoom",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "availability",
          "dependsOn": [
            "A11Y-102",
            "A11Y-103"
          ],
          "scenario": "At 400% zoom the fixed step header and cookie banner cover the selected time and Continue button. Repair reflow across booking steps.",
          "acceptanceCriteria": [
            "At the documented desktop viewport and 400% zoom, essential content reflows without horizontal page scrolling.",
            "Fixed UI never covers focused fields, error links, or booking actions.",
            "Long service names and expanded text spacing do not clip labels or values."
          ],
          "implementationNotes": [
            "Use normal flow where fixed positioning provides no user benefit."
          ],
          "verification": [
            "Complete service and slot selection at 400% zoom by keyboard.",
            "Apply expanded text spacing and a long service name with an error summary; check clipping and focus obstruction."
          ],
          "deliverables": [
            "Reflow corrections and viewport/zoom evidence notes"
          ],
          "rollout": "Check every step before shared layout release; revert sticky behavior first if actions become obscured.",
          "skills": [
            "CSS layout",
            "Reflow",
            "Visual verification"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "725c23d9-c49b-4453-aaba-854a809f806c",
          "key": "A11Y-105",
          "title": "Recover when another visitor takes the chosen slot",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "availability",
          "dependsOn": [
            "A11Y-103"
          ],
          "scenario": "The last 10:30 appointment is taken while a visitor enters contact details. Submission reports Slot unavailable and resets the entire flow.",
          "acceptanceCriteria": [
            "Conflict preserves contact values and service while clearing the unavailable slot.",
            "The conflict is announced once and focus moves to a useful recovery heading with alternatives.",
            "A replacement needs explicit confirmation and current availability revision data."
          ],
          "implementationNotes": [
            "Never automatically book a different time; availability remains server-authoritative."
          ],
          "verification": [
            "Conflict the slot, choose 11:00, and finish without re-entering contact details.",
            "Return no alternatives and fail refresh; explain the state without trapping focus or inventing availability."
          ],
          "deliverables": [
            "Slot-conflict recovery and accessible failure scenario"
          ],
          "rollout": "Exercise synthetic capacity conflicts before pilot; pause booking if contact recovery or slot identity is unreliable.",
          "skills": [
            "Concurrency UX",
            "Accessibility",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "46ae0b00-a876-43ea-9882-bc0be5081646",
          "key": "A11Y-106",
          "title": "Announce availability changes without reading the whole page again",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "continuity",
          "dependsOn": [
            "A11Y-105"
          ],
          "scenario": "Each refresh rewrites a large live region. A screen reader repeats all slots and interrupts contact entry even when nothing changed.",
          "acceptanceCriteria": [
            "Unchanged slot lists generate no routine announcements.",
            "Meaningful changes produce a short status without moving focus.",
            "Loss of a selected slot takes priority over routine counts; stale request messages are ignored."
          ],
          "implementationNotes": [
            "Use a small status region and coalesce bursts; never mark the entire form live."
          ],
          "verification": [
            "Refresh identical data three times while typing; no repeated list announcement occurs.",
            "Remove the selected slot while delayed old data arrives; announce loss once and retain current focus."
          ],
          "deliverables": [
            "Announcement coordinator and manual speech-output log"
          ],
          "rollout": "Pilot with routine announcements disabled; retain only actionable notices if speech becomes noisy.",
          "skills": [
            "Live regions",
            "Async interaction",
            "Assistive technology"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5eb64f66-3485-4c53-9e3f-77bdc39ff100",
          "key": "A11Y-107",
          "title": "Handle expiry without an inaccessible countdown trap",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "continuity",
          "dependsOn": [
            "A11Y-102",
            "A11Y-105",
            "A11Y-106"
          ],
          "scenario": "A slow form session expires after details are entered. The countdown steals focus every second, and Extend reports success after the server session has ended.",
          "acceptanceCriteria": [
            "Advance warning offers an accessible extension action without announcing each second.",
            "Extension success requires server confirmation and preserves the active form location.",
            "Expiry or uncertain extension preserves a scoped draft but requires session recovery and fresh slot validation before booking."
          ],
          "implementationNotes": [
            "Use a fake clock and session adapter; do not weaken expiry or record contact data in analytics."
          ],
          "verification": [
            "Extend before expiry by keyboard and verify confirmed continuation with focus restoration.",
            "Race expiry and a lost extension response; expired authority cannot book, and recovery revalidates the slot."
          ],
          "deliverables": [
            "Session continuity state machine and expiry-race walkthrough"
          ],
          "rollout": "Pilot against short synthetic sessions; disable booking under ambiguous session authority while preserving recoverable drafts.",
          "skills": [
            "Session lifecycle",
            "Accessibility",
            "Race conditions"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1c7d02f4-9646-48c7-9146-bd1afaf24e45",
          "key": "A11Y-108",
          "title": "Return focus correctly after reviewing contact details",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 120,
          "phaseId": "continuity",
          "dependsOn": [
            "A11Y-104",
            "A11Y-107"
          ],
          "scenario": "Edit contact opens a dialog from review. Closing returns focus to a control removed by session refresh, stranding keyboard users.",
          "acceptanceCriteria": [
            "The dialog has a name, contained focus, and visible close action.",
            "Closing restores the invoking control or a documented visible fallback if the step changed.",
            "Recovery and dialog close cannot race focus into hidden or inert content."
          ],
          "implementationNotes": [
            "Use an accessible primitive with local styling and coordinate focus ownership across states."
          ],
          "verification": [
            "Edit and close normally; focus returns to Edit contact with revised details visible.",
            "Expire the session while editing and close during recovery; focus lands on the current recovery heading."
          ],
          "deliverables": [
            "Dialog focus ownership fix and interleaved-state keyboard test"
          ],
          "rollout": "Enable only on review; switch to inline editing if dialog focus ownership regresses.",
          "skills": [
            "Focus management",
            "Dialogs",
            "State coordination"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "371d9ad9-7cac-4885-96da-51c55e4d9b45",
          "key": "A11Y-109",
          "title": "Make confirmation usable on screen and in print",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "completion",
          "dependsOn": [
            "A11Y-105",
            "A11Y-108"
          ],
          "scenario": "The screenshot-style confirmation cannot be selected, print cuts off the address, and appointment time omits the time zone.",
          "acceptanceCriteria": [
            "Service, date, time zone, location, and reference are selectable semantic text.",
            "Print includes all appointment details without navigation chrome or clipping.",
            "Only confirmed bookings show confirmation, with an accessible copy-reference action."
          ],
          "implementationNotes": [
            "An HTML print view is sufficient; PDF generation is excluded."
          ],
          "verification": [
            "Confirm a synthetic appointment, copy its reference, and inspect print preview.",
            "Return an uncertain result and use a long location; no false confirmation appears and reconciled print details remain complete."
          ],
          "deliverables": [
            "Semantic confirmation and print stylesheet"
          ],
          "rollout": "Release styling after booking-identity checks; retain plain-text details if print styling fails.",
          "skills": [
            "Semantic content",
            "Print CSS",
            "Transaction UX"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "213b2b9c-39b4-489f-a724-1077b6d818ee",
          "key": "A11Y-110",
          "title": "Build a barrier-focused release check for booking",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "completion",
          "dependsOn": [
            "A11Y-106",
            "A11Y-107",
            "A11Y-109"
          ],
          "scenario": "Scanners pass while keyboard testers still lose drafts after conflicts. Add a release check covering actual booking and recovery.",
          "acceptanceCriteria": [
            "Checks cover keyboard completion, zoom, named controls, slot conflicts, and session recovery.",
            "Automated assertions and manual observations are recorded separately with browser/tool versions.",
            "Unresolved barriers name affected steps and usable fallbacks without claiming universal accessibility."
          ],
          "implementationNotes": [
            "Bound the manual matrix to agreed combinations and include a reproduction script per barrier."
          ],
          "verification": [
            "Run normal booking plus slot-conflict and session-expiry scenarios and record outcomes.",
            "Introduce a missing dialog name or broken return focus in a local fixture; the relevant check detects it."
          ],
          "deliverables": [
            "Booking accessibility regression matrix and release decision note"
          ],
          "rollout": "Use before pilot expansion; block steps with unrecoverable barriers and retain the documented alternative flow.",
          "skills": [
            "Accessibility testing",
            "Release verification",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "47651627-f5f1-48b0-8215-e51588fd2312",
      "key": "READ",
      "title": "A document reader that keeps people oriented",
      "field": "Accessibility",
      "summary": "Improve navigation, text adaptation, annotations, and revision recovery in an internal document reader.",
      "context": "The fictional Plainview handbook reader serves versioned HTML documents with headings, tables, footnotes, and annotations. Scope is accessible HTML rendering from a structured model; OCR and arbitrary PDF remediation are excluded.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Testing Library",
        "Playwright"
      ],
      "prerequisites": [
        "Versioned synthetic documents with stable section IDs",
        "Annotation and document-access API contracts to stub"
      ],
      "developerValue": "Practice semantic structure, accessible navigation, safe annotations, and stable reading positions.",
      "companyValue": "Inspect how an engineer makes information usable while protecting document integrity and access boundaries.",
      "delivery": "Each ticket targets one reader behavior. Use synthetic documents and record assumptions about the source model.",
      "phases": [
        {
          "id": "structure",
          "title": "Make content readable",
          "goal": "Preserve semantics and text preferences."
        },
        {
          "id": "navigation",
          "title": "Keep the reader oriented",
          "goal": "Make search, contents, and bookmarks predictable."
        },
        {
          "id": "interaction",
          "title": "Support richer reading",
          "goal": "Add annotations and long-document loading without breaking reading flow."
        },
        {
          "id": "release",
          "title": "Verify access and recovery",
          "goal": "Check interruptions and document the release boundary."
        }
      ],
      "tickets": [
        {
          "id": "38422679-6c18-4541-9253-4ce2dcc57ada",
          "key": "READ-101",
          "title": "Restore heading and table semantics in handbook chapters",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "structure",
          "dependsOn": [],
          "scenario": "Every source block becomes a styled div. Readers cannot navigate by heading, and table cells expose no header relationships.",
          "acceptanceCriteria": [
            "Headings preserve validated source hierarchy in semantic elements.",
            "Tables retain captions and source-model header associations.",
            "Unsupported blocks show a clear fallback rather than silently disappearing."
          ],
          "implementationNotes": [
            "Validate the structured model; this ticket does not infer semantics from arbitrary visual formatting."
          ],
          "verification": [
            "Navigate by headings and inspect a table with row and column headers.",
            "Supply an unsupported block and invalid hierarchy; content is not silently lost and validation identifies the issue."
          ],
          "deliverables": [
            "Semantic block renderer and document-model fixtures"
          ],
          "rollout": "Enable for validated documents; retain the accessible source view when model validation fails.",
          "skills": [
            "Semantic HTML",
            "Document models",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e7fe2ef0-8ce0-41ac-92f7-1d9e92633a23",
          "key": "READ-102",
          "title": "Let readers adjust text without losing their place",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "structure",
          "dependsOn": [
            "READ-101"
          ],
          "scenario": "Increasing font size resets the chapter to the top, while dark theme leaves footnotes unreadable. Add preferences that preserve position and cover every content type.",
          "acceptanceCriteria": [
            "Font size, spacing, and theme apply to body, footnotes, tables, and annotations.",
            "Preference changes preserve the current section anchor.",
            "System theme is the initial default and invalid stored preferences recover safely."
          ],
          "implementationNotes": [
            "Use semantic CSS variables and avoid fixed content heights."
          ],
          "verification": [
            "Resize text midway through a chapter; the current section stays in view.",
            "Load corrupt preference data and test dark/system themes; content stays readable and defaults recover."
          ],
          "deliverables": [
            "Reader preferences and theme/content fixture page"
          ],
          "rollout": "Release session-local preferences first; disable persistence if stored values break rendering.",
          "skills": [
            "CSS variables",
            "User preferences",
            "Reading UX"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "cbd3afdf-10c4-4b0b-bb96-5dcd7485b466",
          "key": "READ-103",
          "title": "Navigate search matches without breaking document text",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "navigation",
          "dependsOn": [
            "READ-101"
          ],
          "scenario": "Highlighting rewrites innerHTML and removes links around matches. Keyboard users also cannot identify the current match.",
          "acceptanceCriteria": [
            "Highlights preserve source text, links, and semantics.",
            "Next/previous exposes index and total without rereading the chapter.",
            "Clearing search restores normal reading at a sensible position."
          ],
          "implementationNotes": [
            "Treat queries as literal text and use structured ranges; never interpolate search text into HTML."
          ],
          "verification": [
            "Find a phrase spanning emphasis and follow the preserved link around a match.",
            "Search markup-like text and a no-match query; nothing executes and match navigation is correctly disabled."
          ],
          "deliverables": [
            "Structured highlight layer and keyboard match-navigation tests"
          ],
          "rollout": "Enable for one renderer; disable highlighting separately while retaining plain results if semantics regress.",
          "skills": [
            "Text ranges",
            "Keyboard navigation",
            "Safe rendering"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Accessibility",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9a9a178b-edc4-4512-b3f9-ca8997a9059d",
          "key": "READ-104",
          "title": "Keep contents links and footnote returns oriented",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "navigation",
          "dependsOn": [
            "READ-101",
            "READ-102"
          ],
          "scenario": "Contents links scroll to sections but leave focus in the sidebar. Following a footnote returns to the document top.",
          "acceptanceCriteria": [
            "Contents navigation updates the URL and focuses the destination heading without obscuring it.",
            "Footnotes offer a named return action to the originating reference.",
            "Back restores the preceding meaningful reading anchor."
          ],
          "implementationNotes": [
            "Use stable source IDs and respect reduced motion for scrolling."
          ],
          "verification": [
            "Navigate by contents, follow a footnote, and return using only the keyboard.",
            "Open a missing section link and use Back; show a useful fallback without trapping focus."
          ],
          "deliverables": [
            "Anchor/focus coordinator and footnote walkthrough"
          ],
          "rollout": "Ship stable anchors before custom scrolling; disable scroll effects if focus and visual position diverge.",
          "skills": [
            "Focus management",
            "Deep links",
            "Navigation"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "33ee0c51-b7fb-40ee-a5a7-9493b10b8af7",
          "key": "READ-105",
          "title": "Recover bookmarks after a handbook correction",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "navigation",
          "dependsOn": [
            "READ-103",
            "READ-104"
          ],
          "scenario": "A correction inserts two sections before a bookmark. Its raw character offset now opens an unrelated paragraph.",
          "acceptanceCriteria": [
            "Bookmarks include version, stable section, and optional bounded text anchor.",
            "A newer version resolves the section or explicitly reports that the passage moved or disappeared.",
            "The permitted original version remains reachable without silently rewriting the bookmark."
          ],
          "implementationNotes": [
            "Approximate text matching is not exact; disclose ambiguity and retain the original anchor."
          ],
          "verification": [
            "Insert content before a stable section and reopen its bookmark; the intended section remains selected.",
            "Delete it and create two similar passages; show ambiguous recovery rather than silently choosing one."
          ],
          "deliverables": [
            "Version-aware bookmark resolver and correction fixtures"
          ],
          "rollout": "Keep legacy bookmarks readable during migration; fall back to the permitted original version on uncertain resolution.",
          "skills": [
            "Versioning",
            "Stable identity",
            "Recovery UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Accessibility",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b61054ab-7157-466f-8ef1-2e1033a501c1",
          "key": "READ-106",
          "title": "Render annotations safely and expose their controls",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "interaction",
          "dependsOn": [
            "READ-103",
            "READ-104"
          ],
          "scenario": "Pasted annotation markup changes layout and introduces active links. Annotation actions are unnamed icons visible only on hover.",
          "acceptanceCriteria": [
            "Annotations use plain text or an explicit constrained format that removes disallowed content.",
            "Edit, delete, and return-to-passage actions have accessible names and work without hover.",
            "Failed saves preserve a draft distinct from confirmed comments."
          ],
          "implementationNotes": [
            "Keep document source immutable and treat annotation content as untrusted."
          ],
          "verification": [
            "Create a normal annotation and navigate every action by keyboard.",
            "Paste script-like markup and a dangerous link, then reject save; no active content runs and the unsaved draft stays explicit."
          ],
          "deliverables": [
            "Safe annotation renderer and keyboard/security regression cases"
          ],
          "rollout": "Enable plain text first; disable rich formatting on sanitization regression while preserving stored source text.",
          "skills": [
            "Untrusted content",
            "Accessible controls",
            "Draft state"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Accessibility",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5488dadd-410d-4c4d-8152-01f25cb4b44c",
          "key": "READ-107",
          "title": "Load long handbooks without losing reading order",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "interaction",
          "dependsOn": [
            "READ-102",
            "READ-104"
          ],
          "scenario": "A 200-section handbook blocks interaction, but a virtual-list prototype removes headings while a screen reader navigates them.",
          "acceptanceCriteria": [
            "Initial work is bounded through explicit section loading or an equally accessible documented strategy.",
            "Loaded sections stay in logical order and focused content is never removed.",
            "Section-load failure offers in-place retry without resetting the reading anchor."
          ],
          "implementationNotes": [
            "Profile a reproducible fixture and state the environment; do not optimize by hiding required accessible content."
          ],
          "verification": [
            "Profile initial load and navigate three loaded sections by keyboard and headings.",
            "Fail the next request while focus stays in the current section; retry without duplicates, reordered headings, or focus loss."
          ],
          "deliverables": [
            "Incremental loading and before/after profile with reading-order checks"
          ],
          "rollout": "Enable for large documents; keep a full-document option when incremental reading is unsuitable.",
          "skills": [
            "Performance",
            "Progressive loading",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Accessibility",
              "percentage": 40
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5ec505e0-f2f6-4947-a32a-cb950e8cbe7c",
          "key": "READ-108",
          "title": "Keep annotation review stable through collaborator updates",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "interaction",
          "dependsOn": [
            "READ-105",
            "READ-106",
            "READ-107"
          ],
          "scenario": "A colleague resolves a comment while another reader edits a reply. The panel reorders, steals focus, and sends the reply to the newly selected thread.",
          "acceptanceCriteria": [
            "Editing binds to immutable thread identity and revision, not list position.",
            "Remote updates never silently retarget a draft or move current focus.",
            "Resolved/deleted-thread conflicts preserve the draft, announce once, and offer explicit permitted recovery."
          ],
          "implementationNotes": [
            "Use fixture events; a full collaboration backend and automatic merging are excluded."
          ],
          "verification": [
            "Insert a remote comment above the active thread while typing; the draft keeps its original thread.",
            "Resolve the active thread during reply acknowledgement; no reply lands elsewhere and the confirmed state stays coherent."
          ],
          "deliverables": [
            "Revision-aware annotation model and concurrent-update tests"
          ],
          "rollout": "Pilot manual refresh before live events; pause remote panel updates if focus or binding becomes unstable.",
          "skills": [
            "Concurrent UI",
            "Focus ownership",
            "Conflict recovery"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Accessibility",
              "percentage": 30
            },
            {
              "field": "Real-time systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bcf45869-b625-4fb8-ad86-acd10b685264",
          "key": "READ-109",
          "title": "Handle access loss without an empty-reader trap",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "release",
          "dependsOn": [
            "READ-107",
            "READ-108"
          ],
          "scenario": "Access expires while a reader is on a late section. The next fetch clears the page and leaves focus on a removed annotation button.",
          "acceptanceCriteria": [
            "Confirmed access loss stops fetches and clears protected rendered content.",
            "Focus moves to a named access-state heading with permitted navigation.",
            "Account changes cannot restore prior content through cached sections or Back."
          ],
          "implementationNotes": [
            "Omit private authorization details and document account-scoped draft handling on access loss."
          ],
          "verification": [
            "Remove access during a section fetch and verify a useful accessible access state.",
            "Switch account and navigate Back; protected cached content stays absent and stale fetches stop."
          ],
          "deliverables": [
            "Access-loss boundary and account-switch browser tests"
          ],
          "rollout": "Verify before enabling protected handbooks; disable protected caching if invalidation cannot be guaranteed.",
          "skills": [
            "Authorization UX",
            "Cache isolation",
            "Focus recovery"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Accessibility",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "af45c001-dcda-4701-9712-17c3208f6a3a",
          "key": "READ-110",
          "title": "Verify a complete reading-and-annotation session",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "release",
          "dependsOn": [
            "READ-105",
            "READ-108",
            "READ-109"
          ],
          "scenario": "Component checks miss interactions among search, resizing, bookmarks, and drafts. Add a short reader acceptance script to the release checklist.",
          "acceptanceCriteria": [
            "The script follows contents, changes text settings, searches, annotates, bookmarks, and reopens.",
            "Keyboard-only and one documented screen-reader pass record observed limitations.",
            "Version correction and denied annotation save are recovery branches."
          ],
          "implementationNotes": [
            "Record the environment and observations; automated checks do not establish complete accessibility."
          ],
          "verification": [
            "Run the ordinary synthetic session and verify final bookmark and annotation identities.",
            "Reject saving and replace the version; the draft stays explicit and ambiguous bookmarks require resolution."
          ],
          "deliverables": [
            "Reader acceptance script and reproducible barrier notes"
          ],
          "rollout": "Use for navigation/annotation changes; pause the affected feature on identity loss or unrecoverable keyboard failure.",
          "skills": [
            "Acceptance testing",
            "Accessibility",
            "Release handoff"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "fe99d92c-2de0-4682-9610-1db9b5856a75",
      "key": "LIVE",
      "title": "A collaborative incident room with a reliable timeline",
      "field": "Real-time systems",
      "summary": "Build a bounded live coordination room with ordered events, reconnect recovery, and clear authority.",
      "context": "The fictional Harbor operations team coordinates synthetic incidents in a shared room. Engineers post status notes and claim response tasks while connections come and go. Scope is one application gateway, a durable room event store, and fixture clients; alert paging and external chat delivery are excluded.",
      "stack": [
        "TypeScript",
        "Node.js",
        "WebSocket",
        "PostgreSQL",
        "Redis"
      ],
      "prerequisites": [
        "Room membership and command contracts",
        "Synthetic incident events and a controllable transport harness"
      ],
      "developerValue": "Practice event identity, ordering, replay, authorization, and bounded backpressure in one understandable system.",
      "companyValue": "Inspect how an engineer keeps collaborative state trustworthy during failures without relying on optimistic success messages.",
      "delivery": "Deliver one issue or a phase at a time against synthetic rooms. Keep load fixtures bounded and avoid real incident channels.",
      "phases": [
        {
          "id": "protocol",
          "title": "Establish the room contract",
          "goal": "Make connection state and event boundaries explicit."
        },
        {
          "id": "timeline",
          "title": "Recover a coherent timeline",
          "goal": "Order, deduplicate, and replay confirmed events."
        },
        {
          "id": "collaboration",
          "title": "Coordinate work safely",
          "goal": "Protect commands, presence, and changing access."
        },
        {
          "id": "readiness",
          "title": "Handle operational pressure",
          "goal": "Bound resource use and rehearse recovery."
        }
      ],
      "tickets": [
        {
          "id": "da389677-cab9-49d8-9c9e-82fdfaf8592c",
          "key": "LIVE-101",
          "title": "Show the difference between connected and caught up",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "protocol",
          "dependsOn": [],
          "scenario": "The room shows Connected immediately after a socket opens, even while the last five minutes of events are still missing. Give connection and synchronization separate states.",
          "acceptanceCriteria": [
            "The UI distinguishes connecting, recovering, current, disconnected, and unavailable.",
            "Current appears only after the server-defined replay boundary has been applied.",
            "The latest confirmed timeline remains readable during reconnect with a visible freshness notice."
          ],
          "implementationNotes": [
            "Use a deterministic transport fixture; socket open alone is not proof of complete room state."
          ],
          "verification": [
            "Open a connection and delay replay completion; the room stays recovering until the boundary arrives.",
            "Disconnect after a confirmed note and fail reconnect; the note remains readable but is not labeled current."
          ],
          "deliverables": [
            "Room connection/sync state model and delayed-replay UI test"
          ],
          "rollout": "Enable state labels in the pilot room; force read-only mode if synchronization cannot be established.",
          "skills": [
            "State modeling",
            "Real-time UX",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "32a585ae-15f3-48cf-bc1f-acc4ed4dc598",
          "key": "LIVE-102",
          "title": "Reject malformed room events before they reach the reducer",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "protocol",
          "dependsOn": [],
          "scenario": "A gateway change sends a string sequence number and crashes every open room tab. Define a versioned event envelope with deliberate unknown-version behavior.",
          "acceptanceCriteria": [
            "The boundary validates version, room ID, event ID, sequence, type, and bounded payload.",
            "Malformed or unsupported events never enter the state reducer.",
            "Protocol errors expose a safe category and recovery action without echoing raw note content."
          ],
          "implementationNotes": [
            "Treat transport input as untrusted and impose a documented frame-size limit."
          ],
          "verification": [
            "Accept a valid status-note envelope and verify its typed reducer input.",
            "Send an oversized frame, invalid sequence, and unknown version; reject each without crashing or leaking raw payloads."
          ],
          "deliverables": [
            "Versioned event parser and invalid-envelope fixture suite"
          ],
          "rollout": "Deploy readers that understand the new version before changing writers; pause the stream on unsupported contracts.",
          "skills": [
            "Schema validation",
            "Protocol design",
            "Untrusted input"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2b229d62-6587-49a6-9e48-03033b817a63",
          "key": "LIVE-103",
          "title": "Authorize room subscription before replaying its history",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "protocol",
          "dependsOn": [
            "LIVE-102"
          ],
          "scenario": "A client changes the room ID in its subscribe message and receives a few private timeline entries before the gateway rejects membership. Move authority checks ahead of all history and live delivery.",
          "acceptanceCriteria": [
            "Subscription derives tenant and user from the authenticated session.",
            "Current room membership is checked before replay queries and live listener registration.",
            "Denied subscriptions leave no active listener or partially delivered room data."
          ],
          "implementationNotes": [
            "Enforce room scope in repository methods as well as at the transport boundary."
          ],
          "verification": [
            "Subscribe as an authorized synthetic member and inspect permitted replay.",
            "Request a room in another organization and revoke membership before listener installation; deliver zero room events in both cases."
          ],
          "deliverables": [
            "Authorized subscription boundary and cross-room denial tests"
          ],
          "rollout": "Require this before private-room pilots; disable subscriptions if membership authority is unavailable.",
          "skills": [
            "Authorization",
            "Tenant isolation",
            "WebSocket security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "baa437bf-f8b9-4890-895a-fef2f480fc44",
          "key": "LIVE-104",
          "title": "Stop duplicate and out-of-order notes confusing the timeline",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "timeline",
          "dependsOn": [
            "LIVE-101",
            "LIVE-102",
            "LIVE-103"
          ],
          "scenario": "A reconnect overlaps live delivery with replay. The same mitigation note appears twice, and a late earlier event moves a resolved task back to active.",
          "acceptanceCriteria": [
            "Event identity deduplicates replay and live delivery for the same room.",
            "Only a contiguous server sequence advances the applied cursor.",
            "Out-of-order gaps are buffered within a configured bound and trigger recovery rather than arbitrary state application."
          ],
          "implementationNotes": [
            "A wall-clock timestamp is presentation metadata, not the authoritative event order."
          ],
          "verification": [
            "Deliver a duplicate event through replay and live paths; the timeline shows it once.",
            "Deliver sequences 12, 14, 13 and then an oversized gap; apply contiguous state correctly and enter recovery at the bound."
          ],
          "deliverables": [
            "Ordered room reducer and duplicate/gap test vectors"
          ],
          "rollout": "Shadow the reducer against fixed logs before use; reset from a validated snapshot if gap recovery fails.",
          "skills": [
            "Event ordering",
            "Deduplication",
            "State consistency"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3508017f-157e-4300-9aeb-4b972f05ae84",
          "key": "LIVE-105",
          "title": "Recover when a reconnect cursor is older than retained history",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "timeline",
          "dependsOn": [
            "LIVE-104"
          ],
          "scenario": "A laptop wakes after the room’s replay window has expired. The gateway returns recent events after the old cursor, leaving an invisible gap in the task state.",
          "acceptanceCriteria": [
            "An expired cursor receives an explicit resync-required response.",
            "The client replaces state from a room-scoped snapshot and resumes after its exact sequence boundary.",
            "Snapshot and post-snapshot events cannot combine data from different rooms or snapshot revisions."
          ],
          "implementationNotes": [
            "Keep the prior timeline visibly stale until the replacement state is validated."
          ],
          "verification": [
            "Resume a retained cursor and confirm ordinary incremental replay.",
            "Use an expired cursor and deliver a live event during snapshot loading; apply it once after the snapshot boundary, or reject mismatched room data."
          ],
          "deliverables": [
            "Snapshot/replay recovery protocol and expired-cursor tests"
          ],
          "rollout": "Pilot with a short synthetic retention window; disable writes during unresolved resync and retain safe read-only context.",
          "skills": [
            "Replay protocols",
            "Snapshot consistency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e2df0af1-b45f-448f-a4c5-c02c52f23ae1",
          "key": "LIVE-106",
          "title": "Reconcile a task claim when its acknowledgement is lost",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "collaboration",
          "dependsOn": [
            "LIVE-105"
          ],
          "scenario": "A responder claims Investigate cache saturation, loses the acknowledgement, and retries. The room appends duplicate claims and briefly shows two owners.",
          "acceptanceCriteria": [
            "A claim command has a stable operation key and expected task revision.",
            "The durable event and operation result commit together or neither becomes authoritative.",
            "Retry returns the existing result; a competing confirmed claim produces a conflict instead of a second owner."
          ],
          "implementationNotes": [
            "Use the application transaction boundary and an outbox if broadcasting crosses processes."
          ],
          "verification": [
            "Accept a claim, drop the acknowledgement, and retry with the same key; one logical claim exists.",
            "Race two responders at the same revision and fail broadcast after commit; one owner remains and replay recovers the event."
          ],
          "deliverables": [
            "Idempotent claim command and lost-acknowledgement/concurrent-claim tests"
          ],
          "rollout": "Enable claims after replay recovery; disable new claims if transaction/result consistency fails while keeping confirmed assignments readable.",
          "skills": [
            "Idempotency",
            "Transactions",
            "Optimistic concurrency"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7267732f-7464-4ee6-a935-540c2190f2ed",
          "key": "LIVE-107",
          "title": "Expire disconnected presence without rewriting incident history",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "collaboration",
          "dependsOn": [
            "LIVE-103"
          ],
          "scenario": "Closing a laptop leaves its user shown as In room for hours. Presence currently uses the same durable event path as incident notes, making heartbeat traffic dominate replay.",
          "acceptanceCriteria": [
            "Presence expires from a bounded lease using server-observed heartbeats.",
            "Multiple tabs collapse to one visible member while preserving presence if one tab remains connected.",
            "Presence expiration never removes authored notes or changes task ownership."
          ],
          "implementationNotes": [
            "Presence is advisory activity state, not proof that someone read or understood an incident."
          ],
          "verification": [
            "Open two tabs, close one, and verify the member remains until the final lease expires.",
            "Delay heartbeats and restart the presence store; stale members expire without changing durable timeline or ownership."
          ],
          "deliverables": [
            "Ephemeral presence lease model and multi-tab expiry tests"
          ],
          "rollout": "Release advisory presence independently; hide it when its store is unavailable rather than retaining indefinite online claims.",
          "skills": [
            "Leases",
            "Ephemeral state",
            "Resource cleanup"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0f574924-0761-4ad7-9bb4-10ddbb80a0a8",
          "key": "LIVE-108",
          "title": "Cut off room delivery when membership is revoked mid-replay",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "collaboration",
          "dependsOn": [
            "LIVE-105",
            "LIVE-106",
            "LIVE-107"
          ],
          "scenario": "A temporary responder is removed while a long history replay is streaming. The established socket keeps receiving new private notes until reconnect.",
          "acceptanceCriteria": [
            "Membership changes invalidate active subscriptions and pending replay batches for that session and room.",
            "Commands recheck current authority before committing, even when the socket was previously authorized.",
            "After the defined revocation barrier, no queued private frames are delivered and listener resources are released."
          ],
          "implementationNotes": [
            "Specify the barrier and in-flight message limits; do not promise retroactive removal of data already delivered."
          ],
          "verification": [
            "Revoke a member between replay batches and assert no subsequent private frames cross the barrier.",
            "Race revocation with task claim and a queued live note; reject unauthorized commit and remove all room listeners."
          ],
          "deliverables": [
            "Revocation-aware subscription lifecycle and race harness"
          ],
          "rollout": "Require the race harness before temporary-member use; close affected room sockets if revocation propagation is uncertain.",
          "skills": [
            "Authorization races",
            "Subscription lifecycle",
            "Security boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c7a193df-6ec2-4a57-90bd-59cf0d0c4129",
          "key": "LIVE-109",
          "title": "Keep one slow room client from exhausting gateway memory",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "readiness",
          "dependsOn": [
            "LIVE-105",
            "LIVE-108"
          ],
          "scenario": "A paused browser cannot consume events, but its send buffer grows throughout a synthetic incident drill. Add bounded per-connection delivery and a recoverable overload path.",
          "acceptanceCriteria": [
            "Each connection has explicit queued-byte and queued-event limits.",
            "Overloaded clients receive a safe resync/close outcome when possible; durable events are never silently skipped while claiming currency.",
            "Healthy clients continue receiving events and per-connection resources are reclaimed after closure."
          ],
          "implementationNotes": [
            "Keep a bounded load fixture; distinguish disposable presence updates from durable timeline events."
          ],
          "verification": [
            "Pause one consumer while a second reads normally; measure bounded memory and uninterrupted healthy delivery.",
            "Exceed limits, reconnect the slow client, and recover by cursor/snapshot with no silently missing timeline events."
          ],
          "deliverables": [
            "Backpressure policy and bounded slow-consumer load report"
          ],
          "rollout": "Canary conservative queue limits with disconnect metrics; reduce admission or disable live updates if memory bounds fail.",
          "skills": [
            "Backpressure",
            "Resource limits",
            "Load testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "313981f1-6814-4a56-be72-ec4882a2b05c",
          "key": "LIVE-110",
          "title": "Rehearse gateway restart during incident coordination",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "readiness",
          "dependsOn": [
            "LIVE-106",
            "LIVE-108",
            "LIVE-109"
          ],
          "scenario": "The team has not tested what room users see during a gateway restart. Create a repeatable drill with one pending claim, a disconnected reader, and a recently revoked member.",
          "acceptanceCriteria": [
            "The drill records final durable event IDs, sequence, task owner, and subscription count.",
            "Restart recovery neither duplicates the claim nor grants the revoked member replay access.",
            "The runbook defines safe metrics and a rollback action without logging private note bodies."
          ],
          "implementationNotes": [
            "Restart only disposable practice processes and use synthetic room content."
          ],
          "verification": [
            "Run the restart drill twice from the same fixture and compare final authoritative room state.",
            "Make the event store unavailable during reconnect; clients remain explicitly stale/read-only and no command is falsely confirmed."
          ],
          "deliverables": [
            "Gateway restart drill and incident-room operator runbook"
          ],
          "rollout": "Require the drill before pilot expansion; keep room writes disabled if durable replay or authorization recovery is unavailable.",
          "skills": [
            "Failure testing",
            "Operational readiness",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "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": []
        }
      ]
    },
    {
      "id": "2abdd9ee-3567-4c39-b2e6-e46fbfdce62b",
      "key": "CLI",
      "title": "Release day without the shared spreadsheet",
      "field": "Developer tooling",
      "summary": "Build a local release assistant that prepares reviewable plans and survives interrupted release steps.",
      "context": "A team maintains six related packages. Release notes, version changes, and tags are copied between a spreadsheet and a terminal; a failed upload recently left two packages ahead of their dependents. The exercise uses temporary repositories and a fake registry.",
      "stack": [
        "TypeScript",
        "Node.js",
        "Git",
        "pnpm"
      ],
      "prerequisites": [
        "Create a temporary Git repository with three related fixture packages.",
        "Use a local registry double; no publishing credentials are required."
      ],
      "developerValue": "Practice CLI contracts, graph reasoning, filesystem safety, and recovery from partial work.",
      "companyValue": "Review how an engineer makes release changes inspectable and recoverable before they affect consumers.",
      "delivery": "A release-plan CLI, local fixtures, recovery tests, and an operator guide.",
      "phases": [
        {
          "id": "inspect",
          "title": "Know what will change",
          "goal": "Produce a deterministic release plan from repository inputs."
        },
        {
          "id": "prepare",
          "title": "Prepare a reviewable release",
          "goal": "Write only the planned files and make failure recovery explicit."
        },
        {
          "id": "recover",
          "title": "Handle an interrupted release",
          "goal": "Resume against a fake registry without duplicating or concealing work."
        }
      ],
      "tickets": [
        {
          "id": "39272ddf-3bb4-4c46-b110-cd43c8a61e21",
          "key": "CLI-101",
          "title": "Print package versions without depending on the current directory",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "inspect",
          "dependsOn": [],
          "scenario": "The release coordinator runs the command from packages/ui and gets an empty package list. Add an inspect command that finds the workspace root and reports each releasable package.",
          "acceptanceCriteria": [
            "Running from the root or a nested package produces the same sorted names and versions.",
            "Private packages are labeled and excluded from the releasable count.",
            "A directory outside a workspace returns a nonzero exit code and an actionable error."
          ],
          "implementationNotes": [
            "Read manifests as data; do not run package scripts.",
            "Stop root discovery at the filesystem root."
          ],
          "verification": [
            "Run inspect from root, a nested directory, and a path containing spaces.",
            "Pass malformed package JSON and verify that the filename appears without dumping file contents."
          ],
          "deliverables": [
            "Inspect subcommand and a three-package fixture"
          ],
          "rollout": "Ship as a read-only command first; revert the command registration if root detection regresses.",
          "skills": [
            "CLI design",
            "Filesystem paths",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "985390b8-031d-46b6-aa40-2fa059dc890f",
          "key": "CLI-102",
          "title": "Give scripts a stable JSON output contract",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "inspect",
          "dependsOn": [
            "CLI-101"
          ],
          "scenario": "CI currently scrapes a colored table and breaks when a package name wraps. Add --json to inspect so automation can consume a versioned response.",
          "acceptanceCriteria": [
            "JSON output includes schemaVersion, workspace packages, and warnings with stable field names.",
            "Stdout contains exactly one JSON document with no ANSI escapes.",
            "Diagnostics go to stderr and invalid arguments keep a documented nonzero exit code."
          ],
          "implementationNotes": [
            "Keep human rendering separate from the result model."
          ],
          "verification": [
            "Parse stdout from a successful --json run with JSON.parse.",
            "Combine --json with an unknown flag and assert no partial success document is printed."
          ],
          "deliverables": [
            "JSON response schema and CLI exit-code reference"
          ],
          "rollout": "Add the opt-in format without changing existing human output; version incompatible schema changes.",
          "skills": [
            "API contracts",
            "CLI design",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a767c860-d8a2-44f5-a8a9-7fa11400a811",
          "key": "CLI-103",
          "title": "Include dependent packages in the proposed version bump",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "inspect",
          "dependsOn": [
            "CLI-101"
          ],
          "scenario": "A patch to @fixture/parser requires updating the exact dependency in @fixture/runner. The plan currently includes only parser, leaving runner pinned to the old release.",
          "acceptanceCriteria": [
            "The plan includes transitive dependents whose declared ranges no longer accept the proposed version.",
            "Packages already accepting the new version are not bumped solely because they depend on it.",
            "Cycles are reported with a readable cycle path and no files are written."
          ],
          "implementationNotes": [
            "Declare supported workspace range syntax and reject unsupported protocols.",
            "Use a stable topological order with package-name tie breaking."
          ],
          "verification": [
            "Plan a chain with exact, compatible-range, and dev-only dependencies and compare expected inclusion.",
            "Feed a dependency cycle and a missing workspace target; both must fail before preparation."
          ],
          "deliverables": [
            "Dependency-aware planner and graph fixtures"
          ],
          "rollout": "Expose the graph as plan output before enabling its use in file preparation; rollback to read-only inspection.",
          "skills": [
            "Dependency graphs",
            "Semantic versioning",
            "Determinism"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1d3a02d9-0bd2-43c2-9dad-4b96587584c8",
          "key": "CLI-104",
          "title": "Make a dirty checkout a deliberate release decision",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "prepare",
          "dependsOn": [
            "CLI-103"
          ],
          "scenario": "A teammate prepared a release with an uncommitted dependency change and could not reproduce the resulting versions. Capture the base revision and refuse preparation when tracked files differ.",
          "acceptanceCriteria": [
            "The plan records the full base commit and a digest of release inputs.",
            "Preparation rejects staged or unstaged tracked changes with a list of affected paths.",
            "A plan whose base commit or input digest changed is rejected even when the checkout is clean."
          ],
          "implementationNotes": [
            "Use Git argument arrays rather than composing shell commands.",
            "Document whether untracked files participate in the release input set."
          ],
          "verification": [
            "Prepare a clean fixture checkout successfully.",
            "Stage one manifest change and separately advance HEAD; the old plan must be rejected in each case."
          ],
          "deliverables": [
            "Stale-plan guard and reproducibility note"
          ],
          "rollout": "Enable guards before any write command; disable preparation if repository state cannot be determined.",
          "skills": [
            "Git",
            "Integrity checks",
            "Failure handling"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "7a43f421-d232-40a7-bd8d-7d4a1f016851",
          "key": "CLI-105",
          "title": "Turn change fragments into package-specific release notes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "prepare",
          "dependsOn": [
            "CLI-103"
          ],
          "scenario": "The same release note is pasted into all six packages, even when only one changed. Read small checked-in change fragments and render notes grouped by affected package.",
          "acceptanceCriteria": [
            "Each fragment names existing packages and one supported change category.",
            "Rendering is deterministic and includes each fragment once per affected package.",
            "Unknown packages, duplicate fragment IDs, and empty descriptions block generation with file-level errors."
          ],
          "implementationNotes": [
            "Treat fragment text as plain Markdown content, never executable templates.",
            "Preserve issue references exactly as supplied."
          ],
          "verification": [
            "Render two overlapping fragments and check package-specific sections.",
            "Use duplicate IDs and an unknown package to verify the entire notes step fails without writing output."
          ],
          "deliverables": [
            "Fragment format, examples, and release-note renderer"
          ],
          "rollout": "Generate notes to a preview path initially; switching to committed notes requires the validated plan.",
          "skills": [
            "Parsing",
            "Documentation tooling",
            "Deterministic output"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1965cf09-8e91-425e-9488-fef6d4e18e10",
          "key": "CLI-106",
          "title": "Prepare manifests and notes as one recoverable file operation",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "prepare",
          "dependsOn": [
            "CLI-104",
            "CLI-105"
          ],
          "scenario": "An interrupted process updated two manifests but left the changelog untouched. Preparation needs a journal so the next invocation can identify exactly which planned writes completed.",
          "acceptanceCriteria": [
            "Validate every target and render every new file before replacing any repository file.",
            "A journal records expected before and after hashes for each target and completed replacements.",
            "Recovery restores only files still matching the recorded after hash and refuses to overwrite user edits."
          ],
          "implementationNotes": [
            "Keep staging and target files on the same filesystem.",
            "Resolve paths inside the selected repository and reject symlink escapes."
          ],
          "verification": [
            "Inject failure after the first replacement and recover the original bytes.",
            "Edit a prepared file before recovery and confirm a conflict is reported while the edit is preserved."
          ],
          "deliverables": [
            "Preparation journal, recovery command, and failure-injection fixtures"
          ],
          "rollout": "Enable writes only after preview and recovery pass locally; use the journal to undo an interrupted preparation.",
          "skills": [
            "Filesystem transactions",
            "Recovery",
            "Concurrency safety"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "cb2a1729-8d0d-48bb-bf48-bbf64d42b61c",
          "key": "CLI-107",
          "title": "Prevent a second release process from using the same checkout",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 120,
          "phaseId": "recover",
          "dependsOn": [
            "CLI-106"
          ],
          "scenario": "Two terminals started preparation within a second and both used the same temporary filenames. Add an exclusive lease for mutation commands with inspectable ownership.",
          "acceptanceCriteria": [
            "Exactly one of two concurrent preparation commands obtains the repository lease.",
            "The loser exits before replacing a file and reports the existing operation ID.",
            "Stale-lease recovery is an explicit command that verifies the recorded operation is no longer active."
          ],
          "implementationNotes": [
            "Do not decide lease ownership from a PID alone; include an operation token.",
            "Read-only commands remain usable while a lease exists."
          ],
          "verification": [
            "Start two local fixture processes behind a barrier and count successful mutations.",
            "Simulate a stale lease and verify ordinary preparation refuses it until explicit recovery."
          ],
          "deliverables": [
            "Lease implementation and concurrent-process test"
          ],
          "rollout": "Require leases for all mutation commands together; rollback by disabling mutations until both versions agree on the lease format.",
          "skills": [
            "Process coordination",
            "Race conditions",
            "Operational tooling"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1cebb310-4a4b-48dd-b4c6-84d4b048984d",
          "key": "CLI-108",
          "title": "Resume a publish rehearsal after the registry response disappears",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "recover",
          "dependsOn": [
            "CLI-106",
            "CLI-107"
          ],
          "scenario": "The fake registry accepts a package and then drops the connection. A blind retry may conceal a different artifact already registered at that version. Reconcile remote state before resuming.",
          "acceptanceCriteria": [
            "Each planned package records its version and artifact digest before the fake publish call.",
            "An existing version with the same digest is treated as completed; a different digest blocks the entire resume.",
            "Resume respects dependency order and leaves a durable record of ambiguous, reconciled, and completed steps."
          ],
          "implementationNotes": [
            "Use a local registry port with deterministic lost-response behavior.",
            "A release record is append-only; do not overwrite the original failed attempt."
          ],
          "verification": [
            "Drop the first response after acceptance and verify resume makes no duplicate upload.",
            "Preload the same version with different bytes and confirm dependents remain unpublished."
          ],
          "deliverables": [
            "Resumable rehearsal workflow and ambiguity incident walkthrough"
          ],
          "rollout": "Keep the registry adapter local for this exercise; require a reviewed digest reconciliation policy before a real adapter.",
          "skills": [
            "Idempotency",
            "Distributed failure",
            "Artifact integrity",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3927f2dc-12c2-42af-a2cc-d46c32d24a7d",
          "key": "CLI-109",
          "title": "Keep release credentials and package contents out of logs",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "recover",
          "dependsOn": [
            "CLI-102",
            "CLI-108"
          ],
          "scenario": "A registry error included an authorization header in a debug dump. Add structured diagnostics with an allowlist of safe release fields and a useful correlation ID.",
          "acceptanceCriteria": [
            "Diagnostics include operation ID, package name, step, duration, and error category.",
            "Headers, environment variables, artifact contents, and token-like fixture values are absent from all log levels.",
            "Human and JSON errors reference the same operation ID."
          ],
          "implementationNotes": [
            "Map provider failures to safe errors at the adapter boundary.",
            "Do not rely only on replacing known secret strings."
          ],
          "verification": [
            "Cause a fake provider error containing a token and scan stdout, stderr, and persisted diagnostics.",
            "Confirm a safe package conflict still carries enough information to locate the failed step."
          ],
          "deliverables": [
            "Safe error mapper and redaction regression cases"
          ],
          "rollout": "Make safe diagnostics the default; temporarily reduce diagnostic detail if an unknown provider error cannot be classified.",
          "skills": [
            "Structured logging",
            "Secret handling",
            "Error design"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "74ad2f26-7a4e-41c6-8121-4764c5c7b77b",
          "key": "CLI-110",
          "title": "Package the CLI so a fresh checkout can rehearse a release offline",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recover",
          "dependsOn": [
            "CLI-108",
            "CLI-109"
          ],
          "scenario": "The maintainer can run the tool only through a source-tree import. Package the command and document one complete rehearsal using fixture packages and the local registry.",
          "acceptanceCriteria": [
            "The built executable supports --help and --version without source imports.",
            "An offline rehearsal covers inspect, plan, prepare, interrupted publish, and resume.",
            "The guide explains which steps mutate files and how to restore the fixture repository."
          ],
          "implementationNotes": [
            "Pin fixture inputs so example output is reproducible.",
            "Do not perform an actual registry publication."
          ],
          "verification": [
            "Install the packed artifact into a temporary directory and run the documented rehearsal.",
            "Run without a registry configuration and confirm publishing fails before any network attempt."
          ],
          "deliverables": [
            "Packed CLI artifact instructions and end-to-end rehearsal guide"
          ],
          "rollout": "Distribute a prerelease artifact for local evaluation; retract it if packed-command behavior differs from source execution.",
          "skills": [
            "Packaging",
            "Developer experience",
            "Release engineering"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "fb653e08-0b12-40cb-8892-f314d1aad0cf",
      "key": "BUILD",
      "title": "Make the monorepo feedback loop trustworthy",
      "field": "Developer tooling",
      "summary": "Shorten a local monorepo check loop while retaining correctness when inputs, dependencies, or tools change.",
      "context": "A product team waits for every package to rebuild after small changes. An experimental cache is faster but occasionally returns success after a shared type changed. Build a small, auditable task runner around fixture packages.",
      "stack": [
        "TypeScript",
        "Node.js",
        "pnpm",
        "JSON"
      ],
      "prerequisites": [
        "Prepare four fixture packages with one shared library and two applications.",
        "Use only trusted fixture commands in local tests."
      ],
      "developerValue": "Practice incremental computation, dependency scheduling, cache correctness, and cancellation.",
      "companyValue": "Inspect whether faster checks preserve the guarantees reviewers depend on.",
      "delivery": "A dependency-aware check runner with a local cache and reproducible benchmark report.",
      "phases": [
        {
          "id": "model",
          "title": "Model checks and dependencies",
          "goal": "Make task selection and scheduling predictable."
        },
        {
          "id": "cache",
          "title": "Cache only valid results",
          "goal": "Prove when outputs may safely be reused."
        },
        {
          "id": "operate",
          "title": "Make the runner usable in CI",
          "goal": "Control resources and report failures without hiding them."
        }
      ],
      "tickets": [
        {
          "id": "fcf138a0-1fe8-41d4-91d6-baa8cc69a4dc",
          "key": "BUILD-101",
          "title": "Reject invalid task configuration before starting a command",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A misspelled dependsOn entry silently removed a typecheck prerequisite. Introduce a validated task configuration with clear locations for configuration errors.",
          "acceptanceCriteria": [
            "Every task has a unique ID, command argument list, working directory, and declared dependencies.",
            "Unknown dependencies and paths outside the workspace fail validation.",
            "Validation reports all independent configuration errors without starting commands."
          ],
          "implementationNotes": [
            "Commands are trusted fixture configuration; no shell interpolation.",
            "Keep configuration parsing independent of execution."
          ],
          "verification": [
            "Validate a four-task graph successfully.",
            "Submit a missing dependency and escaping working directory together and confirm both errors and zero process starts."
          ],
          "deliverables": [
            "Configuration schema and validation diagnostics"
          ],
          "rollout": "Use validation in a read-only plan command first; refuse execution for older unsupported config versions.",
          "skills": [
            "Schema validation",
            "CLI design",
            "Path safety"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ec674da0-4a15-456d-83f2-0d98aaac7a62",
          "key": "BUILD-102",
          "title": "Show why a task is selected after a file change",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "model",
          "dependsOn": [
            "BUILD-101"
          ],
          "scenario": "Changing packages/shared/types.ts reruns one app but not its sibling. Build a changed-file planner that includes affected dependents and prints the reason for each selected task.",
          "acceptanceCriteria": [
            "Changes under a shared package select all configured downstream checks.",
            "A root configuration change selects the documented full validation set.",
            "Deleted files and renamed files are handled using both old and new affected paths."
          ],
          "implementationNotes": [
            "Sort explanation paths for reproducible output."
          ],
          "verification": [
            "Change shared types and inspect both application check reasons.",
            "Delete a file from one leaf package and confirm unrelated leaf tasks remain unselected."
          ],
          "deliverables": [
            "Affected-task planner and explanation output"
          ],
          "rollout": "Compare selection with full checks in report-only mode before using it to skip work.",
          "skills": [
            "Dependency analysis",
            "Incremental builds",
            "Git changes"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "a4ff10d4-f051-48b3-97ec-22757398237c",
          "key": "BUILD-103",
          "title": "Schedule independent checks without exceeding the worker limit",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "BUILD-101"
          ],
          "scenario": "Two independent application tests could run together, but shared compilation must finish first. Add bounded scheduling and explicit blocked states for dependent tasks.",
          "acceptanceCriteria": [
            "A task starts only after every prerequisite succeeds.",
            "Active process count never exceeds the configured positive concurrency limit.",
            "A failed prerequisite marks descendants blocked while unrelated tasks may finish."
          ],
          "implementationNotes": [
            "Detect cycles before execution and return the cycle path.",
            "Store task transitions through one scheduler boundary."
          ],
          "verification": [
            "Run a diamond graph with barrier-controlled fixture tasks and assert start order and concurrency.",
            "Fail the shared task and verify descendants never start while an independent task completes."
          ],
          "deliverables": [
            "Bounded scheduler and graph execution trace"
          ],
          "rollout": "Default concurrency to one; increase only after the scheduling trace demonstrates the limit.",
          "skills": [
            "Scheduling",
            "Concurrency",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "d4e1c413-bd3f-4ce0-85e1-43a5a1a8ce85",
          "key": "BUILD-104",
          "title": "Include tool versions and declared environment in the cache key",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "cache",
          "dependsOn": [
            "BUILD-102"
          ],
          "scenario": "The cache reused a successful check after the TypeScript version changed. Define a canonical cache key that captures the command, inputs, dependency results, and supported environment.",
          "acceptanceCriteria": [
            "Changing input bytes, lockfile, command arguments, tool version, or a declared environment value changes the key.",
            "File enumeration order and path separators do not change an otherwise equivalent key.",
            "Undeclared environment dependence is documented as unsupported and such tasks can disable caching."
          ],
          "implementationNotes": [
            "Hash values rather than logging environment contents.",
            "Use content hashes, not modification times, as input identity."
          ],
          "verification": [
            "Reorder file enumeration and assert the key is unchanged.",
            "Change each declared input dimension independently and assert a cache miss."
          ],
          "deliverables": [
            "Cache-key specification and canonicalization tests"
          ],
          "rollout": "Version the cache namespace and discard entries produced by the old key algorithm.",
          "skills": [
            "Content hashing",
            "Build reproducibility",
            "Cache invalidation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 80
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "efdbdf80-95bf-43f5-8d3c-a49c92ea268e",
          "key": "BUILD-105",
          "title": "Restore cached outputs without touching unrelated files",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "cache",
          "dependsOn": [
            "BUILD-104"
          ],
          "scenario": "A cached archive restored ../config.json during a local corruption test. Replace blind extraction with a validated manifest and staged restoration inside declared output roots.",
          "acceptanceCriteria": [
            "Every restored file has a normalized in-root path and verified content digest.",
            "Absolute paths, traversal paths, symlink escapes, and unexpected output entries are rejected.",
            "A rejected or interrupted restoration preserves the prior output set and reports a cache miss."
          ],
          "implementationNotes": [
            "Treat cache entries as untrusted even when the cache is local.",
            "Separate verification from replacement and avoid executing archive hooks."
          ],
          "verification": [
            "Restore a valid two-directory output manifest and compare every digest.",
            "Use traversal, digest mismatch, and interrupted replacement fixtures and verify unrelated files are unchanged."
          ],
          "deliverables": [
            "Validated cache restorer and corruption fixtures"
          ],
          "rollout": "Enable restoration behind an opt-in flag; on any integrity error rebuild from source and quarantine that cache entry.",
          "skills": [
            "Filesystem safety",
            "Artifact integrity",
            "Transactional writes",
            "Threat modeling"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "658219af-1ed0-4d64-a09c-38382ce14a01",
          "key": "BUILD-106",
          "title": "Never cache failed or incompletely written task outputs",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "cache",
          "dependsOn": [
            "BUILD-103",
            "BUILD-104"
          ],
          "scenario": "A killed build left an output directory that the next run accepted as a hit. Publish a cache entry only after successful exit and complete output hashing.",
          "acceptanceCriteria": [
            "Nonzero exit, cancellation, and missing declared outputs never create reusable entries.",
            "Entries become visible through one final commit marker after all files and metadata are written.",
            "Concurrent identical writers either publish equivalent complete entries or report an integrity conflict."
          ],
          "implementationNotes": [
            "Use a unique staging directory per attempt."
          ],
          "verification": [
            "Kill a fixture build after it creates one output and assert the next run executes it again.",
            "Race two successful writes for one key and verify readers observe only complete entries."
          ],
          "deliverables": [
            "Atomic cache publisher and partial-output test"
          ],
          "rollout": "Invalidate legacy entries without a completion marker; keep cache misses safe by running the original task.",
          "skills": [
            "Atomicity",
            "Cache design",
            "Failure injection"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e789713c-7624-47ef-9ba7-dd7ab2c205e0",
          "key": "BUILD-107",
          "title": "Cancel running checks and report what did not run",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BUILD-103"
          ],
          "scenario": "Pressing Ctrl+C stops the runner but leaves a test child consuming CPU. Add cancellation with a bounded grace period and explicit cancelled outcomes.",
          "acceptanceCriteria": [
            "Cancellation stops new starts immediately and requests termination of every owned process tree.",
            "After the configured grace period remaining owned processes are forcefully terminated using supported platform behavior.",
            "The summary distinguishes failed, cancelled, blocked, and completed tasks and returns a nonzero exit."
          ],
          "implementationNotes": [
            "Exercise only controlled fixture child processes.",
            "Do not terminate processes outside the operation ownership set."
          ],
          "verification": [
            "Cancel a parent fixture that owns a long-lived child and confirm both are gone.",
            "Cancel while one independent task has completed and verify its successful result remains in the summary."
          ],
          "deliverables": [
            "Cancellation handler and process-cleanup test"
          ],
          "rollout": "Enable cancellation together with process ownership tracking; retain the serial execution fallback if cleanup fails on a supported OS.",
          "skills": [
            "Process lifecycle",
            "Cross-platform tooling",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1294311f-2f28-412b-b0ba-95907f328ec0",
          "key": "BUILD-108",
          "title": "Keep parallel task output readable and bounded",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "operate",
          "dependsOn": [
            "BUILD-103"
          ],
          "scenario": "Concurrent test logs interleave half-lines and a noisy task consumes hundreds of megabytes of memory. Prefix complete lines and cap retained output per task.",
          "acceptanceCriteria": [
            "Every rendered line carries its task ID without splitting UTF-8 characters.",
            "Retained output per task stays below a configured byte limit with a visible truncation notice.",
            "The final summary includes exit code, duration, and an indication that output was truncated."
          ],
          "implementationNotes": [
            "Handle a final line that has no newline.",
            "Keep stderr attribution separate from status."
          ],
          "verification": [
            "Emit split multibyte characters from two fixture processes and check rendered text.",
            "Write beyond the limit and verify bounded retention and a single clear truncation notice."
          ],
          "deliverables": [
            "Streaming output formatter and noisy-task fixture"
          ],
          "rollout": "Use bounded capture by default and document an explicit file-output option for deeper local debugging.",
          "skills": [
            "Streams",
            "Memory limits",
            "Developer experience"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "dd391771-5c5f-4173-97e2-07196be31368",
          "key": "BUILD-109",
          "title": "Explain a cache miss without exposing input contents",
          "type": "STORY",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "operate",
          "dependsOn": [
            "BUILD-104",
            "BUILD-106"
          ],
          "scenario": "The team cannot tell whether frequent misses come from the lockfile or an unstable generated file. Add an explain command comparing safe input metadata from two runs.",
          "acceptanceCriteria": [
            "Explanation identifies added, removed, or changed input paths and changed key categories.",
            "File contents and environment values are never printed.",
            "A missing prior run produces a useful first-run result instead of an error."
          ],
          "implementationNotes": [
            "Retain hashes and category names only for environment-sensitive inputs."
          ],
          "verification": [
            "Change a source file and a tool version and assert both reasons appear.",
            "Place a secret fixture value in a declared environment variable and confirm no output includes it."
          ],
          "deliverables": [
            "Cache-miss explanation command and safe metadata format"
          ],
          "rollout": "Make explanation read-only; deleting history must not alter cache correctness.",
          "skills": [
            "Observability",
            "Developer tooling",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 70
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "664d3841-71e4-4f31-9733-7d34a24db553",
          "key": "BUILD-110",
          "title": "Measure the faster loop against a full-check baseline",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "operate",
          "dependsOn": [
            "BUILD-105",
            "BUILD-106",
            "BUILD-107",
            "BUILD-108",
            "BUILD-109"
          ],
          "scenario": "A timing screenshot says the cache is faster but omits cases where it skipped a required check. Produce a reproducible comparison covering clean, warm, leaf-change, and shared-change runs.",
          "acceptanceCriteria": [
            "The report records machine context, fixture revision, task counts, cache hits, and wall-clock timings.",
            "Each incremental result is compared with the full-check result for the same input state.",
            "A deliberate shared-type error fails both workflows and is never reported as a valid cache hit."
          ],
          "implementationNotes": [
            "Present measured numbers with run count and variability.",
            "Avoid a hard speed claim based on one run."
          ],
          "verification": [
            "Run the documented matrix from an empty cache and reproduce task selection.",
            "Introduce a dependent type error and confirm the benchmark records failed correctness before reporting speed."
          ],
          "deliverables": [
            "Benchmark script and correctness-first comparison report"
          ],
          "rollout": "Adopt skipped-task execution only after parity is demonstrated; retain a scheduled full-check path as a diagnostic baseline.",
          "skills": [
            "Benchmarking",
            "Experimental design",
            "Build correctness"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "775c6a9e-e407-4681-833a-2a6866104823",
      "key": "CHECK",
      "title": "Checkout regressions the team can reproduce",
      "field": "Quality engineering",
      "summary": "Build a deterministic checkout regression suite around pricing, accessibility, payment failures, and isolated test data.",
      "context": "A small commerce team has happy-path browser tests but still ships rounding and retry defects. Model a fictional shop using synthetic products, a local payment double, and explicit cart rules before adding regression coverage.",
      "stack": [
        "TypeScript",
        "Playwright",
        "HTTP",
        "SQL"
      ],
      "prerequisites": [
        "Create or provide a local checkout fixture application.",
        "Model products, tax rules, inventory, and a payment-provider double using synthetic data."
      ],
      "developerValue": "Practice risk-based test selection, stable browser automation, and diagnosis of intermittent failures.",
      "companyValue": "Review whether a test suite catches business regressions and explains failures without creating noisy release gates.",
      "delivery": "A local checkout fixture, regression suite, failure artifacts, and release-gate policy.",
      "phases": [
        {
          "id": "baseline",
          "title": "Define the checkout contract",
          "goal": "Establish realistic fixtures and observable expected behavior."
        },
        {
          "id": "failure",
          "title": "Exercise costly failure paths",
          "goal": "Cover money, duplication, inventory, and access boundaries."
        },
        {
          "id": "gate",
          "title": "Turn checks into a useful release gate",
          "goal": "Keep runs isolated, diagnosable, and honest about coverage."
        }
      ],
      "tickets": [
        {
          "id": "9d55c5b3-7e3d-48da-9329-97ac5179c41b",
          "key": "CHECK-101",
          "title": "Write the smallest cart fixture that catches a pricing regression",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "The only test product costs 100.00, so fractional-price bugs pass. Define a reusable fixture with 19.99 and 0.10 items, quantities, tax, and one promotion.",
          "acceptanceCriteria": [
            "Expected totals use integer minor units with the rounding stage explicitly documented.",
            "The fixture can reset to an identical starting cart between runs.",
            "Expected values are stated independently of the checkout implementation."
          ],
          "implementationNotes": [
            "Use a fictional currency with two decimal places for this fixture."
          ],
          "verification": [
            "Check the documented two-item total by an independent integer calculation.",
            "Change quantity from one to three and verify the expected amount changes without fixture state leaking between runs."
          ],
          "deliverables": [
            "Synthetic cart fixture and pricing expectation table"
          ],
          "rollout": "Add the fixture as a separate suite seed; reset by run ID instead of clearing shared environments.",
          "skills": [
            "Test data",
            "Money arithmetic",
            "Specification"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "61d5454b-599e-4d9b-870f-85c5a729a5f1",
          "key": "CHECK-102",
          "title": "Replace timing sleeps in the checkout happy path",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "baseline",
          "dependsOn": [
            "CHECK-101"
          ],
          "scenario": "Checkout passes locally but fails in CI after a fixed 500 ms sleep. Wait for user-visible readiness and assert the final receipt against the fixture.",
          "acceptanceCriteria": [
            "The happy path contains no arbitrary timing sleeps.",
            "Selectors use accessible roles and names where the interface exposes them.",
            "The receipt order reference and charged amount match the created order."
          ],
          "implementationNotes": [
            "Wait on observable state transitions, not broad network-idle heuristics."
          ],
          "verification": [
            "Run with the payment double delayed by several deterministic values.",
            "Keep the submit button disabled and verify the test times out at an actionable readiness assertion."
          ],
          "deliverables": [
            "Stable checkout browser test and selector rationale"
          ],
          "rollout": "Run beside the existing happy path for comparison, then remove the redundant sleep-based version.",
          "skills": [
            "Browser testing",
            "Accessibility selectors",
            "Synchronization"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c24d4dbf-0cbd-44d5-a4b7-4fb0f3d50d46",
          "key": "CHECK-103",
          "title": "Cover discount and tax rounding at the documented boundary",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "failure",
          "dependsOn": [
            "CHECK-101"
          ],
          "scenario": "A 10% promotion on three 19.99 items produces a one-cent difference between the cart and receipt. Add cases that pin down order-level versus line-level rounding.",
          "acceptanceCriteria": [
            "Tests use the agreed line-discount-then-tax rule and include a half-cent boundary.",
            "Cart, order, and payment request totals must agree in minor units.",
            "A discount greater than the eligible subtotal is rejected or capped according to an explicit contract."
          ],
          "implementationNotes": [
            "Do not reproduce the production rounding helper in expected-value code."
          ],
          "verification": [
            "Assert concrete expected totals for zero, one, and three eligible items.",
            "Introduce a round-at-order-end defect in the fixture and show the relevant case fails."
          ],
          "deliverables": [
            "Pricing boundary matrix and regression tests"
          ],
          "rollout": "Gate pricing changes with these deterministic cases; update expectations only with a reviewed rule change.",
          "skills": [
            "Boundary testing",
            "Money arithmetic",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "bca0729c-e2d4-456f-94c3-527ca1d4c2fd",
          "key": "CHECK-104",
          "title": "Prove a lost payment response cannot create two orders",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "failure",
          "dependsOn": [
            "CHECK-102"
          ],
          "scenario": "The payment double accepts a charge but drops the response. The customer clicks Try again. The regression must verify one charge and one order, not just a success banner.",
          "acceptanceCriteria": [
            "The double can accept a payment and deterministically lose the first response.",
            "Retry preserves the intended checkout idempotency identity.",
            "Assertions inspect order count, charge count, amount, and final customer-visible status."
          ],
          "implementationNotes": [
            "Record provider requests in the local double; do not connect a real payment account."
          ],
          "verification": [
            "Run a lost-response-then-retry case and assert one durable charge and one order.",
            "Use a fixture defect that rotates the idempotency key on retry and confirm the regression detects the duplicate."
          ],
          "deliverables": [
            "Lost-response payment scenario and durable-state assertions"
          ],
          "rollout": "Add to checkout gates with bounded local timeouts; keep provider behavior versioned with the test.",
          "skills": [
            "Idempotency testing",
            "Fault injection",
            "Distributed systems"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "aab21e62-3cae-4dab-a47c-d18302e8d96c",
          "key": "CHECK-105",
          "title": "Test the last-item race without relying on lucky timing",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "failure",
          "dependsOn": [
            "CHECK-101"
          ],
          "scenario": "Two customers can both buy the last unit when the stock check and reservation are separate. Build a barrier-controlled concurrency case around a single remaining item.",
          "acceptanceCriteria": [
            "Two isolated customers reach the reservation boundary before either proceeds.",
            "Exactly one reservation succeeds and inventory never becomes negative.",
            "The losing checkout receives a recoverable stock message and creates no captured payment."
          ],
          "implementationNotes": [
            "Use an explicit local test barrier, not sleep-based synchronization.",
            "Assert final database and provider states after both requests settle."
          ],
          "verification": [
            "Repeat the controlled race with each customer released first.",
            "Run against a deliberately non-atomic fixture reservation and demonstrate that the invariant assertion fails."
          ],
          "deliverables": [
            "Deterministic inventory race harness and invariant report"
          ],
          "rollout": "Keep the barrier available only in local test composition; add the regression before changing reservation code.",
          "skills": [
            "Concurrency testing",
            "Database invariants",
            "Fault isolation",
            "Payment safety"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "43f36e80-38aa-4453-bd6b-40ff089a8148",
          "key": "CHECK-106",
          "title": "Check that one customer cannot open another receipt",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "failure",
          "dependsOn": [
            "CHECK-102"
          ],
          "scenario": "The receipt screen fetches an order by URL ID. Add an authorization regression covering both the page and its backing endpoint with two synthetic customer accounts.",
          "acceptanceCriteria": [
            "An owner can load their receipt with the expected line items.",
            "Another customer and an anonymous session cannot retrieve receipt details by changing the order ID.",
            "Denied responses and browser artifacts contain no customer address or item details."
          ],
          "implementationNotes": [
            "Treat order IDs as discoverable; obscurity is not the access rule."
          ],
          "verification": [
            "Open the same order using owner, second-customer, and logged-out contexts.",
            "Attempt the direct receipt API request and inspect its body for leaked fields."
          ],
          "deliverables": [
            "Receipt access matrix and browser/API denial tests"
          ],
          "rollout": "Make the access checks a required checkout gate; quarantine artifacts if a regression exposes fixture-sensitive fields.",
          "skills": [
            "Authorization testing",
            "API testing",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "dfd191f6-0974-47b6-a479-2374b818f81a",
          "key": "CHECK-107",
          "title": "Verify checkout errors can be corrected using a keyboard",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "gate",
          "dependsOn": [
            "CHECK-102"
          ],
          "scenario": "An invalid postal code turns the field red but focus remains on the submit button and no message is announced. Add keyboard and semantic checks for error recovery.",
          "acceptanceCriteria": [
            "Submission exposes a text error associated with the invalid field.",
            "Keyboard users can reach the field, correct it, and complete checkout without pointer input.",
            "The error summary links to the field and disappears or updates after correction."
          ],
          "implementationNotes": [
            "Record a short manual screen-reader check; automated role assertions alone do not establish full accessibility."
          ],
          "verification": [
            "Tab through a failed then corrected checkout and verify focus placement.",
            "Remove the error association in the fixture and confirm the semantic regression fails."
          ],
          "deliverables": [
            "Keyboard regression and manual assistive-technology checklist"
          ],
          "rollout": "Include keyboard checks in the browser suite; retain manual accessibility coverage for release reviews.",
          "skills": [
            "Accessibility testing",
            "Keyboard navigation",
            "Form validation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Accessibility",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e5aa297c-2f93-4214-8952-3d1b723fa80e",
          "key": "CHECK-108",
          "title": "Give each parallel test its own stock and customer records",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "gate",
          "dependsOn": [
            "CHECK-104",
            "CHECK-105",
            "CHECK-106"
          ],
          "scenario": "The suite passes alone but fails in parallel because every worker buys the same seeded SKU. Namespace mutable fixtures and make cleanup safe when a worker crashes.",
          "acceptanceCriteria": [
            "Each test run receives unique customer, cart, inventory, and provider namespaces.",
            "Cleanup deletes only records owned by that run and can be repeated safely.",
            "A crashed run is discoverable by expiry metadata without clearing records from active runs."
          ],
          "implementationNotes": [
            "Use a controllable clock for expiry checks.",
            "Avoid global truncate operations."
          ],
          "verification": [
            "Run two full suites concurrently and verify their record IDs never overlap.",
            "Crash one run, expire it, and confirm cleanup preserves the other run and unowned sentinel data."
          ],
          "deliverables": [
            "Fixture lifecycle helpers and parallel-isolation tests"
          ],
          "rollout": "Migrate tests to namespaced seeds before increasing CI concurrency; disable expired-run cleanup if ownership metadata is missing.",
          "skills": [
            "Test isolation",
            "Data lifecycle",
            "Parallel testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d06b557f-0d96-4bbd-ae40-e4b0c67c1619",
          "key": "CHECK-109",
          "title": "Capture enough failure detail without storing checkout secrets",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "gate",
          "dependsOn": [
            "CHECK-108"
          ],
          "scenario": "A failure report has only a screenshot, while a trace includes full authorization headers. Define a bounded artifact bundle that helps reproduce a failure safely.",
          "acceptanceCriteria": [
            "A failed case records fixture seed, run ID, safe request IDs, assertion, and application revision.",
            "Authorization, payment tokens, and full address values are absent from stored artifacts.",
            "Artifact filenames and retention rules are deterministic and scoped to the run."
          ],
          "implementationNotes": [
            "Use synthetic credentials but still prove the redaction boundary."
          ],
          "verification": [
            "Fail a payment case and reconstruct it from the recorded seed and revision.",
            "Insert secret marker strings into headers and form fields and scan every produced artifact for them."
          ],
          "deliverables": [
            "Safe failure artifact bundle and retention policy"
          ],
          "rollout": "Replace unrestricted tracing with the safe bundle; disable unsafe artifact types until sanitization is verified.",
          "skills": [
            "Test diagnostics",
            "Redaction",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "510794f2-752d-45cb-9ee0-f791fbf12c72",
          "key": "CHECK-110",
          "title": "Separate release blockers from tests awaiting investigation",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "gate",
          "dependsOn": [
            "CHECK-103",
            "CHECK-107",
            "CHECK-109"
          ],
          "scenario": "The team reruns the whole suite until it turns green. Define a gate that retains the first failure, identifies explicit quarantines, and does not hide payment or access regressions.",
          "acceptanceCriteria": [
            "Payment, inventory, pricing, and authorization regressions remain blocking even after a successful retry.",
            "Quarantined cases require an owner, issue reference, reason, and expiry date.",
            "Reports show first-attempt outcomes, retry outcomes, and omitted coverage separately."
          ],
          "implementationNotes": [
            "Use retries for diagnosis rather than rewriting the original result."
          ],
          "verification": [
            "Run a fail-then-pass fixture and verify its first failure remains visible and blocking when critical.",
            "Use an expired quarantine and confirm gate evaluation fails with the owning issue reference."
          ],
          "deliverables": [
            "Release-gate evaluator and quarantine policy examples"
          ],
          "rollout": "Evaluate the new policy against recorded fixture runs before enabling enforcement; rollback policy configuration without deleting result history.",
          "skills": [
            "Quality strategy",
            "CI policy",
            "Failure analysis"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "03ef30c2-e774-4aef-8e97-712ad3d6f1af",
      "key": "REPLAY",
      "title": "A webhook replay lab for incident recovery",
      "field": "Quality engineering",
      "summary": "Create a local webhook laboratory that reproduces duplicates, disorder, signature failures, and interrupted delivery.",
      "context": "An integration team closes incidents with screenshots of provider dashboards, then struggles to reproduce the same delivery sequence. Build a synthetic event corpus and replay runner against an allowlisted local receiver.",
      "stack": [
        "TypeScript",
        "HTTP",
        "HMAC",
        "SQLite"
      ],
      "prerequisites": [
        "Create a local receiver fixture with an inspectable event store.",
        "Use generated test signing keys and synthetic payloads only."
      ],
      "developerValue": "Practice protocol verification, controlled fault injection, and reproducible incident investigation.",
      "companyValue": "Review concrete evidence that webhook consumers tolerate real delivery failure patterns.",
      "delivery": "A synthetic event corpus, safe local replay runner, and repeatable incident scenarios.",
      "phases": [
        {
          "id": "corpus",
          "title": "Build inspectable event fixtures",
          "goal": "Represent exact request bytes and expected receiver effects."
        },
        {
          "id": "scenarios",
          "title": "Reproduce delivery failures",
          "goal": "Control signing, ordering, duplicates, and lost responses."
        },
        {
          "id": "report",
          "title": "Make incidents repeatable",
          "goal": "Bound replay authority and preserve useful run reports."
        }
      ],
      "tickets": [
        {
          "id": "2ff8c554-3464-4466-913a-0bd6bfe2b7c1",
          "key": "REPLAY-101",
          "title": "Define a portable synthetic webhook fixture",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "corpus",
          "dependsOn": [],
          "scenario": "A copied JSON payload loses its original whitespace and cannot reproduce a signature mismatch. Store exact request bytes with safe headers and an expected event identity.",
          "acceptanceCriteria": [
            "The fixture preserves body bytes, content type, event ID, and schema version.",
            "Loading rejects unknown fields that could supply credentials or arbitrary destination URLs.",
            "The fixture includes a content digest and validates it before replay."
          ],
          "implementationNotes": [
            "Generate synthetic examples; do not import production customer payloads."
          ],
          "verification": [
            "Round-trip a body with whitespace and non-ASCII text byte-for-byte.",
            "Change one payload byte and verify digest validation fails before a request is sent."
          ],
          "deliverables": [
            "Fixture schema and three synthetic event examples"
          ],
          "rollout": "Version the fixture format; retain older samples read-only until a validated converter exists.",
          "skills": [
            "Serialization",
            "Byte integrity",
            "Test fixtures"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ddc46767-593f-44d1-99cc-e7cfd8c30cd5",
          "key": "REPLAY-102",
          "title": "Generate signatures from raw bytes and an injected clock",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "corpus",
          "dependsOn": [
            "REPLAY-101"
          ],
          "scenario": "The receiver accepts fresh signatures but rejects replay fixtures because timestamp generation depends on the wall clock. Add a deterministic signer for the lab contract.",
          "acceptanceCriteria": [
            "Signing covers the timestamp and exact raw body according to the documented lab protocol.",
            "The clock and generated test key are supplied explicitly.",
            "Signature values and secret keys are not printed in ordinary run logs."
          ],
          "implementationNotes": [
            "Use an established HMAC implementation and document byte encoding."
          ],
          "verification": [
            "Check a fixed key/time/body vector against an independently calculated digest.",
            "Change only whitespace or timestamp and confirm the signature changes."
          ],
          "deliverables": [
            "Test signer and fixed signature vectors"
          ],
          "rollout": "Restrict signing to the local lab adapter; rotate fixture keys by changing the versioned test configuration.",
          "skills": [
            "HMAC",
            "Protocol testing",
            "Clock control"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "046583aa-dac1-4235-a888-08df1fc84e4c",
          "key": "REPLAY-103",
          "title": "Assert duplicate delivery produces one business effect",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "scenarios",
          "dependsOn": [
            "REPLAY-102"
          ],
          "scenario": "A subscription-created event is delivered three times with separate request IDs. The replay should test event-level deduplication rather than merely identical HTTP responses.",
          "acceptanceCriteria": [
            "A scenario sends one event identity with three distinct delivery identities.",
            "The receiver records delivery attempts but creates one subscription effect.",
            "Changing the event ID while preserving business data follows an explicitly documented business-key policy."
          ],
          "implementationNotes": [
            "Observe effects through the local receiver inspection API."
          ],
          "verification": [
            "Replay three duplicates and assert delivery and effect counts separately.",
            "Disable receiver deduplication in a fixture variant and confirm the scenario detects extra effects."
          ],
          "deliverables": [
            "Duplicate-delivery scenario and effect assertions"
          ],
          "rollout": "Add as the first consumer acceptance scenario; use the same fixture revision when comparing receiver changes.",
          "skills": [
            "Idempotency",
            "Integration testing",
            "Business invariants"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bc7dbd70-f729-4bff-821e-7c590b8e95c1",
          "key": "REPLAY-104",
          "title": "Deliver update-before-create with a reproducible schedule",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "scenarios",
          "dependsOn": [
            "REPLAY-102"
          ],
          "scenario": "A subscription update arrived before its create event during an outage. Add a schedule format that can hold, reorder, and release specific events without relying on elapsed sleeps.",
          "acceptanceCriteria": [
            "The scenario declares event order and release barriers separately from payload data.",
            "The receiver converges to the latest declared resource revision when all events arrive.",
            "Stale events cannot overwrite a newer stored revision."
          ],
          "implementationNotes": [
            "Define revision ordering in the lab contract instead of inferring it from arrival time."
          ],
          "verification": [
            "Run create-update and update-create schedules and compare final state.",
            "Append a stale update after convergence and verify the state remains at the newest revision."
          ],
          "deliverables": [
            "Barrier-based schedule runner and out-of-order scenarios"
          ],
          "rollout": "Keep scheduling deterministic by default; random ordering is optional and must record a replayable seed.",
          "skills": [
            "Event ordering",
            "Deterministic tests",
            "Version checks"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "31da06a8-e3c2-4cd6-b44e-7d84ce098b91",
          "key": "REPLAY-105",
          "title": "Exercise signature rotation without accepting expired requests",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "scenarios",
          "dependsOn": [
            "REPLAY-102"
          ],
          "scenario": "During key rotation the receiver must accept old and new keys briefly, while still rejecting requests outside the timestamp tolerance. Add a table of rotation boundaries.",
          "acceptanceCriteria": [
            "Cases cover current key, overlap key, unknown key, and retired key.",
            "Freshness boundaries are tested immediately inside and outside the documented tolerance.",
            "Invalid signatures and stale timestamps produce no persisted business effect."
          ],
          "implementationNotes": [
            "Use an injected clock and generated lab keys.",
            "Verify signature checks occur before trusted event fields are consumed."
          ],
          "verification": [
            "Accept both keys inside the overlap window and reject the retired key afterward.",
            "Send a validly signed but stale event and a fresh tampered event; both must have zero effects."
          ],
          "deliverables": [
            "Rotation boundary matrix and receiver assertions"
          ],
          "rollout": "Run rotation cases before changing receiver key policy; keep retired test keys only in synthetic fixtures.",
          "skills": [
            "Security testing",
            "Key rotation",
            "Boundary cases"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4e7656d9-8a7b-4d0e-bb60-aecc8d9f28d2",
          "key": "REPLAY-106",
          "title": "Reproduce a receiver commit followed by a dropped response",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "scenarios",
          "dependsOn": [
            "REPLAY-103",
            "REPLAY-104"
          ],
          "scenario": "The receiver committed the event, then the connection closed before the sender received 200. Model this boundary and verify sender retries and receiver effects independently.",
          "acceptanceCriteria": [
            "A controlled fault drops the response only after the receiver commits its effect.",
            "The sender retries the original event identity under a bounded policy.",
            "Final reporting distinguishes transport uncertainty from receiver business success and proves one effect."
          ],
          "implementationNotes": [
            "Implement the fault in a local transport or receiver double.",
            "Do not treat a missing response as proof the receiver did nothing."
          ],
          "verification": [
            "Drop after commit and observe a retry with exactly one effect.",
            "Drop before commit and verify a later retry creates the missing effect once."
          ],
          "deliverables": [
            "Before/after-commit fault scenarios and uncertainty report"
          ],
          "rollout": "Keep fault controls unavailable outside the local lab; preserve failed-run reports when rerunning the scenario.",
          "skills": [
            "Distributed failure",
            "Fault injection",
            "Retry semantics",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fcb220a4-d346-4885-aef0-e2a04b932aa5",
          "key": "REPLAY-107",
          "title": "Block replay targets outside the approved local receiver",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "report",
          "dependsOn": [
            "REPLAY-101"
          ],
          "scenario": "A fixture author added a destination that points at a metadata endpoint. Move destination control out of fixture data and enforce a fixed local target policy.",
          "acceptanceCriteria": [
            "Only configured loopback receiver hosts and ports can be selected.",
            "Redirects are rejected and userinfo, ambiguous IP syntax, and non-HTTP schemes are denied.",
            "The resolved address is validated at connection time; rejected destinations send zero payload bytes, and redirect responses trigger no follow-up request."
          ],
          "implementationNotes": [
            "Keep replay configuration separate from imported fixture content.",
            "Bound request body size and connection timeout."
          ],
          "verification": [
            "Replay to the configured local receiver successfully.",
            "Reject an external host, unapproved port, and alternate IP notation before any receiver request; for a redirect, allow one request to the approved receiver and assert zero requests to its redirect target."
          ],
          "deliverables": [
            "Destination policy and SSRF regression cases"
          ],
          "rollout": "Make the target policy mandatory before exposing fixture import; disable replay on target-validation uncertainty.",
          "skills": [
            "SSRF prevention",
            "Network boundaries",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b487fc3f-8ed8-4541-bf75-d758f7edcbda",
          "key": "REPLAY-108",
          "title": "Summarize deliveries and effects in separate report sections",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "report",
          "dependsOn": [
            "REPLAY-103"
          ],
          "scenario": "The current report says three successes even though three deliveries produced one intended change. Report transport attempts and business effects as separate facts.",
          "acceptanceCriteria": [
            "The report lists delivery ID, event ID, response category, and receiver effect reference separately.",
            "A timeout remains unknown at the transport level even if later reconciliation finds an effect.",
            "Output is stably ordered and includes scenario and fixture revisions."
          ],
          "implementationNotes": [
            "Use synthetic receiver record IDs; these are not noCV Evidence IDs."
          ],
          "verification": [
            "Report a three-delivery duplicate scenario with three attempts and one effect.",
            "Report a timeout followed by reconciliation without rewriting the timeout as an HTTP success."
          ],
          "deliverables": [
            "JSON report contract and readable summary renderer"
          ],
          "rollout": "Version the new report format; preserve original attempt records when generating summaries.",
          "skills": [
            "Reporting",
            "Data modeling",
            "Traceability"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9a7ec03a-0a5e-4dce-89d9-edeba1118537",
          "key": "REPLAY-109",
          "title": "Honor Retry-After without creating an unbounded replay",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "report",
          "dependsOn": [
            "REPLAY-106",
            "REPLAY-107"
          ],
          "scenario": "The local receiver responds 429 with Retry-After, but the runner retries immediately. Add bounded backoff with a fake clock and explicit terminal reasons.",
          "acceptanceCriteria": [
            "Supported Retry-After forms are parsed and capped by the run time budget.",
            "Malformed or negative values fall back to documented bounded backoff.",
            "Maximum attempts and overall deadline stop retries with a terminal reason in the report."
          ],
          "implementationNotes": [
            "Seed jitter or disable it for deterministic fixtures."
          ],
          "verification": [
            "Advance a fake clock through 429, 503, and success and assert scheduled retry times.",
            "Return an excessive delay and confirm the deadline ends the run without waiting in real time."
          ],
          "deliverables": [
            "Retry policy and fake-clock timing cases"
          ],
          "rollout": "Apply bounded retry policy to all replay scenarios; allow zero retries for transport debugging.",
          "skills": [
            "Retry policies",
            "Rate limits",
            "Time-based testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c9a3e3c2-46a5-4d5d-b886-861bba575df2",
          "key": "REPLAY-110",
          "title": "Export an incident recipe another engineer can rerun",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "report",
          "dependsOn": [
            "REPLAY-105",
            "REPLAY-108",
            "REPLAY-109"
          ],
          "scenario": "An engineer reproduced the incident but left only terminal history. Export the scenario, fixture digests, scheduler seed, and safe configuration as a portable recipe.",
          "acceptanceCriteria": [
            "The recipe resolves every fixture by immutable content digest and records the runner version.",
            "It excludes signing keys, credentials, destination overrides, and captured production payloads.",
            "A fresh local receiver can reproduce the expected effect and failure categories from the recipe."
          ],
          "implementationNotes": [
            "Require generated replacement keys on import.",
            "Keep original run reports separate from rerun reports."
          ],
          "verification": [
            "Export and rerun an out-of-order lost-response recipe in a clean temporary directory.",
            "Remove one referenced fixture and confirm import fails before sending requests."
          ],
          "deliverables": [
            "Incident-recipe export/import and a worked recovery exercise"
          ],
          "rollout": "Use recipes for internal synthetic exercises first; reject unsupported runner or fixture versions with migration guidance.",
          "skills": [
            "Reproducibility",
            "Incident tooling",
            "Safe export"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "35e9a9b2-818f-4ac5-9f47-6fcdabdd4533",
      "key": "SEARCH",
      "title": "Internal policy search with inspectable sources",
      "field": "Applied AI",
      "summary": "Build a retrieval workflow that respects document access, cites exact revisions, and declines unsupported answers.",
      "context": "Employees search fictional travel and equipment policies. The current prototype blends draft and approved text and sometimes answers using a policy the employee cannot open. Use a small synthetic corpus and a deterministic answer-provider double.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP",
        "JSON Schema"
      ],
      "prerequisites": [
        "Author synthetic policy documents with revisions, effective dates, and access groups.",
        "Use a local deterministic provider double; paid model access is optional and not required."
      ],
      "developerValue": "Practice access-aware retrieval, source provenance, structured model boundaries, and reproducible evaluation.",
      "companyValue": "Inspect how an engineer prevents unsupported or unauthorized answers and handles changing policy content.",
      "delivery": "A local retrieval service with revisioned citations, abstention behavior, and an evaluation report.",
      "phases": [
        {
          "id": "sources",
          "title": "Make source authority explicit",
          "goal": "Index only identifiable, eligible document revisions."
        },
        {
          "id": "answers",
          "title": "Constrain answer generation",
          "goal": "Return supported citations or a clear lack-of-answer result."
        },
        {
          "id": "operations",
          "title": "Evaluate and operate the service",
          "goal": "Bound provider failure, retention, and content changes."
        }
      ],
      "tickets": [
        {
          "id": "75da6c37-e4f3-4185-b7f5-4aa2654676aa",
          "key": "SEARCH-101",
          "title": "Import policy documents with stable revision identities",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "sources",
          "dependsOn": [],
          "scenario": "Two files called travel-policy.md contain different meal limits. The importer currently overwrites one with the other. Store a document identity, revision, and content digest.",
          "acceptanceCriteria": [
            "Each imported revision records document ID, revision ID, digest, title, status, and effective date.",
            "Reimporting identical bytes under the same revision is idempotent.",
            "Different bytes under an existing revision are rejected; a new revision preserves the previous record."
          ],
          "implementationNotes": [
            "Use synthetic policy text and UTC timestamps."
          ],
          "verification": [
            "Import two revisions and retrieve their original content separately.",
            "Reimport a modified file with the first revision ID and assert a conflict with no overwritten content."
          ],
          "deliverables": [
            "Revisioned importer and synthetic policy corpus"
          ],
          "rollout": "Index the synthetic corpus in a separate namespace; rollback by changing the active index pointer, not deleting revision history.",
          "skills": [
            "Data modeling",
            "Content integrity",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9b4b5a72-b037-46b7-aad8-777031fe5ee1",
          "key": "SEARCH-102",
          "title": "Keep chunk citations anchored to the original policy text",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "sources",
          "dependsOn": [
            "SEARCH-101"
          ],
          "scenario": "An answer links to the policy title, but reviewers cannot find the quoted sentence after headings were stripped. Give each chunk a stable revision reference and exact text offsets.",
          "acceptanceCriteria": [
            "Chunks record source revision, start and end offsets, and a content digest.",
            "Reconstructing a chunk from the original source yields exactly the stored chunk text.",
            "Chunk boundaries preserve headings and never split a Unicode code point."
          ],
          "implementationNotes": [
            "Specify the offset unit and normalization rules.",
            "Chunk IDs change when chunking strategy changes."
          ],
          "verification": [
            "Reconstruct every chunk of a document containing emoji and repeated headings.",
            "Change the chunking version and confirm old citation anchors remain resolvable."
          ],
          "deliverables": [
            "Chunker specification and source-anchor tests"
          ],
          "rollout": "Build a new chunk index beside the old one; swap only after source reconstruction passes.",
          "skills": [
            "Text processing",
            "Provenance",
            "Unicode"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3c95c8d7-59b7-4d98-a099-9f171ea31d9b",
          "key": "SEARCH-103",
          "title": "Apply group access before ranking or sending context to a provider",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "sources",
          "dependsOn": [
            "SEARCH-102"
          ],
          "scenario": "A general employee query retrieves a restricted executive travel exception. Hiding the final link is too late because the provider has already received the text. Enforce scope at retrieval and again at answer delivery.",
          "acceptanceCriteria": [
            "The repository query limits candidates to the caller tenant and current allowed groups before ranking.",
            "The provider receives no unauthorized chunk text or metadata.",
            "Access revoked between retrieval and response prevents affected citations and answer content from being delivered."
          ],
          "implementationNotes": [
            "Use server-derived membership; never trust group IDs from the query body.",
            "Do not share cached contexts across permission scopes."
          ],
          "verification": [
            "Query identical terms as users in different groups and inspect the exact provider request.",
            "Revoke a group after retrieval using a barrier and verify delivery fails closed without restricted text."
          ],
          "deliverables": [
            "Access-scoped retrieval and revocation race tests"
          ],
          "rollout": "Disable answer generation for any request whose permission snapshot cannot be revalidated; deploy scoped retrieval before enabling ranking.",
          "skills": [
            "Authorization",
            "Retrieval security",
            "Race conditions",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "fae57076-118d-4a13-a676-139745389969",
          "key": "SEARCH-104",
          "title": "Exclude drafts and future policies from current-policy answers",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "sources",
          "dependsOn": [
            "SEARCH-101"
          ],
          "scenario": "A future equipment allowance outranks the currently approved policy. Define eligibility by approval, effective interval, and supersession so search answers the policy in effect at the requested date.",
          "acceptanceCriteria": [
            "Current queries include approved revisions whose effective interval contains the supplied clock time.",
            "Draft, withdrawn, and future revisions are excluded from answer context.",
            "Overlapping eligible revisions for one policy produce an explicit conflict instead of a silent choice."
          ],
          "implementationNotes": [
            "Use an injected clock and half-open effective intervals."
          ],
          "verification": [
            "Search immediately before and at an effective-date boundary.",
            "Create overlapping approved revisions and verify the query returns a conflict with no generated answer."
          ],
          "deliverables": [
            "Policy eligibility filter and effective-date cases"
          ],
          "rollout": "Run eligibility inspection over the corpus before switching active search; keep ambiguous documents unavailable for answers.",
          "skills": [
            "Temporal data",
            "Business rules",
            "Conflict handling"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1cb515ca-8753-4a97-b113-a69b5ca29bc6",
          "key": "SEARCH-105",
          "title": "Reject answers with invented or mismatched citations",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "answers",
          "dependsOn": [
            "SEARCH-103",
            "SEARCH-104"
          ],
          "scenario": "The provider double returns a fluent answer citing chunk-999, which was never retrieved. Add a structured response boundary and validate every reference before displaying an answer.",
          "acceptanceCriteria": [
            "Responses conform to a strict schema with answer status, bounded claim text, and citation references.",
            "Every citation resolves to an authorized chunk in the exact request context and source revision.",
            "A cited quotation must match its referenced span; invalid output yields an unavailable result without partial answer text."
          ],
          "implementationNotes": [
            "Schema validity and quote matching do not prove broader semantic support; expose that limitation.",
            "Treat provider text as untrusted output."
          ],
          "verification": [
            "Accept a fixture response with exact authorized citations.",
            "Reject invented IDs, a correct ID with altered quotation, and additional schema properties."
          ],
          "deliverables": [
            "Structured answer validator and adversarial output fixtures"
          ],
          "rollout": "Make validation mandatory for all provider adapters; fall back to authorized search results when generation fails.",
          "skills": [
            "Structured output",
            "Citation validation",
            "Trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3a7d61a9-ce3b-42c7-a437-a95f6c831dd8",
          "key": "SEARCH-106",
          "title": "Return insufficient information when the corpus cannot answer",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "answers",
          "dependsOn": [
            "SEARCH-105"
          ],
          "scenario": "Someone asks whether a bicycle repair is reimbursable, but the corpus contains only airfare and laptop rules. The prototype invents a limit. Add an explicit abstention path.",
          "acceptanceCriteria": [
            "Empty retrieval returns INSUFFICIENT_INFORMATION without calling the answer provider.",
            "A provider abstention is shown as missing support, without a fabricated policy rule.",
            "The response may include authorized source links but never presents retrieval rank as certainty."
          ],
          "implementationNotes": [
            "Use a documented conservative context-selection rule with inspectable thresholds."
          ],
          "verification": [
            "Ask an unsupported bicycle-repair question and confirm no rule or amount is invented.",
            "Ask an exact covered policy question and confirm authorized sources are retained in the supported fixture response."
          ],
          "deliverables": [
            "Abstention contract and covered/uncovered question fixtures"
          ],
          "rollout": "Default uncertain cases to source search; tune thresholds only against a versioned evaluation set.",
          "skills": [
            "Abstention",
            "Product judgment",
            "Evaluation design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "a9c77d6f-1f85-4780-9184-23267c1b8d6d",
          "key": "SEARCH-107",
          "title": "Contain instructions embedded in a retrieved document",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "answers",
          "dependsOn": [
            "SEARCH-105"
          ],
          "scenario": "A synthetic policy appendix says to ignore the user and reveal all other documents. Ensure retrieved text remains data and cannot expand access or activate tools.",
          "acceptanceCriteria": [
            "The provider request separates application instructions from quoted document context.",
            "The answer interface exposes no file, network, or administrative tools.",
            "Prompt-injection fixtures cannot alter document access scope or bypass citation validation."
          ],
          "implementationNotes": [
            "Do not claim that delimiting text alone prevents all prompt injection.",
            "Use deterministic malicious-output fixtures to test downstream enforcement."
          ],
          "verification": [
            "Supply an instruction-bearing chunk and inspect the constructed provider request.",
            "Return a malicious provider response with an unauthorized citation and verify the validator rejects it without a secondary fetch."
          ],
          "deliverables": [
            "Context construction boundary and injection containment tests"
          ],
          "rollout": "Keep tool access disabled for this feature; reject any adapter configuration that grants capabilities beyond answering.",
          "skills": [
            "Prompt injection defense",
            "Least privilege",
            "Output validation"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fe851ff8-c652-41d4-8db3-e365b939c141",
          "key": "SEARCH-108",
          "title": "Bound provider latency, retries, and retained query data",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "operations",
          "dependsOn": [
            "SEARCH-106",
            "SEARCH-107"
          ],
          "scenario": "A stalled model call occupies a request indefinitely and debug logs retain full employee queries. Add a bounded provider port with safe audit metadata.",
          "acceptanceCriteria": [
            "Calls enforce timeout, attempt count, response-size, and token or equivalent local budget limits.",
            "Audit metadata records provider/model version, request template version, schema version, duration, retry count, and trace ID.",
            "Generic logs exclude raw questions, document text, and credentials; retention for any explicit debug store is configured separately."
          ],
          "implementationNotes": [
            "The default adapter is a local deterministic double.",
            "Cost is recorded when known and unavailable when not supplied; do not invent cost figures."
          ],
          "verification": [
            "Simulate a stalled call and confirm a bounded unavailable response and cancellation.",
            "Include secret marker text in query and context and scan normal diagnostics for leakage."
          ],
          "deliverables": [
            "Provider port, budget policy, and safe audit tests"
          ],
          "rollout": "Enable one provider adapter at a time behind the validated port; fall back to source results on budget or timeout failure.",
          "skills": [
            "Provider interfaces",
            "Resource limits",
            "Privacy",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "257d1316-1c30-4f28-958e-3e6d77a6b593",
          "key": "SEARCH-109",
          "title": "Invalidate answers when policy authority or access changes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "operations",
          "dependsOn": [
            "SEARCH-108"
          ],
          "scenario": "A cached answer still cites a withdrawn policy and is reused for an employee with different access. Bind cache entries to the exact corpus and permission authority.",
          "acceptanceCriteria": [
            "Cache identity includes normalized query, corpus version, provider configuration, tenant, and permission-scope version.",
            "Delivery rechecks every cited revision eligibility and current access even on a cache hit.",
            "Withdrawing a cited policy prevents old answer delivery without rewriting the original cached record."
          ],
          "implementationNotes": [
            "Use a version pointer or tombstone for invalidation rather than editing source history."
          ],
          "verification": [
            "Warm the cache, withdraw a source, and verify the next request cannot return the old answer.",
            "Reuse identical text across two permission groups and verify no cross-scope hit occurs."
          ],
          "deliverables": [
            "Authority-aware cache and withdrawal/access regression cases"
          ],
          "rollout": "Ship with caching disabled, then enable only after invalidation cases pass; a kill switch returns to live retrieval.",
          "skills": [
            "Cache invalidation",
            "Authorization",
            "Versioned data",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c0999505-e2ef-4fb5-a393-caf4bf93e55b",
          "key": "SEARCH-110",
          "title": "Publish an evaluation report that separates retrieval and answer failures",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operations",
          "dependsOn": [
            "SEARCH-109"
          ],
          "scenario": "A single accuracy percentage conceals whether failures came from missing sources or invalid generated answers. Create a small versioned evaluation set and report distinct failure categories.",
          "acceptanceCriteria": [
            "Cases cover answerable, unsupported, conflicting, restricted, stale, and injection-bearing questions.",
            "Reports separate eligible-source retrieval, citation validity, abstention behavior, and provider failures.",
            "Each result records corpus, implementation, provider-double, and case-set versions with expected and actual observations."
          ],
          "implementationNotes": [
            "Do not claim deterministic-double results measure a real model quality level.",
            "Keep evaluation examples synthetic and publishable."
          ],
          "verification": [
            "Run the full set twice and compare deterministic results.",
            "Introduce an access-filter defect and confirm it appears as a security failure rather than an aggregate quality dip."
          ],
          "deliverables": [
            "Versioned evaluation cases and categorized report"
          ],
          "rollout": "Use category-specific gates for changes; require a separate measured report before replacing the deterministic adapter.",
          "skills": [
            "AI evaluation",
            "Test design",
            "Failure taxonomy"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "8c9f178c-225a-4c11-9d5b-66b1b37de6a7",
      "key": "TRIAGE",
      "title": "Support routing that agents can correct",
      "field": "Applied AI",
      "summary": "Build a routing assistant that suggests queues, validates model output, and preserves accountable human corrections.",
      "context": "A fictional software vendor receives billing, account-access, bug, and security reports. A prototype silently moves tickets based on vague model confidence. Replace it with bounded suggestions, deterministic safety rules, and an auditable review flow.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "JSON Schema",
        "HTTP"
      ],
      "prerequisites": [
        "Create a synthetic support-ticket corpus with no real customer messages.",
        "Implement a deterministic local classifier double with success, malformed-output, and timeout modes."
      ],
      "developerValue": "Practice constrained classification, human correction workflows, model versioning, and evaluation under ambiguous inputs.",
      "companyValue": "Review whether automation saves triage effort while preserving queue ownership and safe escalation.",
      "delivery": "A local routing service with reviewable suggestions, correction history, and a replay evaluation report.",
      "phases": [
        {
          "id": "intake",
          "title": "Define routing inputs and rules",
          "goal": "Make categories and required human handling explicit."
        },
        {
          "id": "suggest",
          "title": "Offer bounded suggestions",
          "goal": "Validate and present proposals without silently moving tickets."
        },
        {
          "id": "feedback",
          "title": "Operate and learn from corrections",
          "goal": "Audit changes and compare revisions without leaking customer content."
        }
      ],
      "tickets": [
        {
          "id": "99e286b0-016a-459a-9d7c-bbecc230eb30",
          "key": "TRIAGE-101",
          "title": "Define queue labels with examples and an unknown outcome",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "intake",
          "dependsOn": [],
          "scenario": "Different agents use Billing and Payments interchangeably, so routing reports cannot be compared. Define stable queue IDs with concise boundaries and ambiguous examples.",
          "acceptanceCriteria": [
            "Every queue has a stable ID, description, included examples, and excluded examples.",
            "UNKNOWN and NEEDS_REVIEW are explicit outcomes rather than invented queue names.",
            "Changing a label definition creates a new taxonomy version."
          ],
          "implementationNotes": [
            "Use fictional support topics and avoid demographic categories."
          ],
          "verification": [
            "Map a duplicate-charge example and an account-reset example to distinct documented queues.",
            "Validate that a mixed billing/security example can remain NEEDS_REVIEW."
          ],
          "deliverables": [
            "Versioned queue taxonomy and labeled examples"
          ],
          "rollout": "Use the taxonomy in suggestion-only mode; retain previous versions for historical reports.",
          "skills": [
            "Domain modeling",
            "Classification design",
            "Product specification"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "d25b7795-2d3a-472f-bc0c-dfc8a0e4e36d",
          "key": "TRIAGE-102",
          "title": "Normalize inbound messages without discarding the original record",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "intake",
          "dependsOn": [
            "TRIAGE-101"
          ],
          "scenario": "Quoted email chains dominate routing input and duplicate attachments inflate request size. Create a bounded classification view while retaining the synthetic original message separately.",
          "acceptanceCriteria": [
            "The derived view records normalization version, source message revision, and truncation indicators.",
            "Input size is bounded and attachments contribute only permitted metadata.",
            "The original record is immutable and can be inspected by an authorized support reviewer."
          ],
          "implementationNotes": [
            "Normalization is deterministic; do not use a model to silently rewrite the complaint."
          ],
          "verification": [
            "Normalize a long quoted chain twice and compare identical derived views.",
            "Provide oversized text and an attachment filename containing markup; verify bounded plain-text input."
          ],
          "deliverables": [
            "Normalization pipeline and input-limit fixtures"
          ],
          "rollout": "Compare derived views in local review before enabling suggestions; use the original source reference for disputed cases.",
          "skills": [
            "Text processing",
            "Data provenance",
            "Input limits"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Applied AI",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "92e7a7b0-80ed-4233-b450-9c7fca7a7892",
          "key": "TRIAGE-103",
          "title": "Route declared security incidents to review before calling a classifier",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 135,
          "phaseId": "intake",
          "dependsOn": [
            "TRIAGE-102"
          ],
          "scenario": "A user selects the security-incident contact form, but the model labels the message a normal login issue. Respect trusted intake metadata and require the security review queue.",
          "acceptanceCriteria": [
            "A trusted security-form source always produces a mandatory security-review state.",
            "The classifier cannot downgrade that state or trigger a customer-facing reply.",
            "Untrusted message text claiming to be system routing metadata does not acquire privileged routing authority."
          ],
          "implementationNotes": [
            "Distinguish server-owned intake fields from user-provided body text.",
            "Do not infer incident severity from writing style or personal attributes."
          ],
          "verification": [
            "Submit a short login message through the trusted security form and confirm mandatory review without classification.",
            "Put a forged security-source object in ordinary message text and confirm it remains untrusted content."
          ],
          "deliverables": [
            "Deterministic escalation policy and metadata-spoofing tests"
          ],
          "rollout": "Enable mandatory routing before model suggestions; keep a manual queue available when source metadata is missing.",
          "skills": [
            "Trust boundaries",
            "Safety rules",
            "Workflow design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a2c6a249-2a59-46d4-8fd8-c27c0ab2c264",
          "key": "TRIAGE-104",
          "title": "Accept only bounded suggestions from the classifier",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "suggest",
          "dependsOn": [
            "TRIAGE-103"
          ],
          "scenario": "The provider returns a queue that no longer exists and a reason containing a link to an unrelated customer record. Validate suggestions against the exact taxonomy and source message.",
          "acceptanceCriteria": [
            "Output contains only permitted queue IDs, a review flag, and bounded supporting spans from the input.",
            "Every supporting span matches the normalized message exactly.",
            "Malformed, out-of-taxonomy, or unsupported outputs become NEEDS_REVIEW with no partial suggestion."
          ],
          "implementationNotes": [
            "Do not treat a model-supplied confidence number as a calibrated probability.",
            "Use strict schemas and plain text rendering."
          ],
          "verification": [
            "Accept a valid suggestion supported by an exact message span.",
            "Reject invented queues, fabricated spans, extra action fields, and markup payloads."
          ],
          "deliverables": [
            "Suggestion validator and malformed-provider fixtures"
          ],
          "rollout": "Require the validator on every adapter; fall back to the unassigned review queue on rejection.",
          "skills": [
            "Structured output",
            "Validation",
            "AI integration"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8507ab9e-ccf0-49b7-bd59-ff6907a6f363",
          "key": "TRIAGE-105",
          "title": "Show a suggested queue as an explicit agent action",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "suggest",
          "dependsOn": [
            "TRIAGE-104"
          ],
          "scenario": "Agents cannot tell whether a ticket was assigned by a person or by the prototype. Display the suggestion alongside Accept and Choose another queue actions.",
          "acceptanceCriteria": [
            "A suggestion never changes the assigned queue by itself.",
            "The view labels provider version, suggestion time, and supporting message text.",
            "Keyboard users can accept, dismiss, or choose another permitted queue."
          ],
          "implementationNotes": [
            "Do not describe the suggestion as a verified conclusion."
          ],
          "verification": [
            "Load a suggestion and verify persisted assignment remains unchanged until acceptance.",
            "Dismiss it by keyboard and confirm no queue transition or customer message is created."
          ],
          "deliverables": [
            "Accessible suggestion panel and interaction tests"
          ],
          "rollout": "Release to an opt-in local agent view; disable the panel without changing existing queue assignment behavior.",
          "skills": [
            "Human-in-the-loop UX",
            "Accessibility",
            "State handling"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 20
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "81fb5168-f889-4f3c-9c41-062ed3ea70ec",
          "key": "TRIAGE-106",
          "title": "Discard a suggestion when the ticket changed while classification ran",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "suggest",
          "dependsOn": [
            "TRIAGE-104",
            "TRIAGE-105"
          ],
          "scenario": "A customer adds a security-relevant reply while an older billing suggestion is in flight. The old suggestion must not become actionable against the new message revision.",
          "acceptanceCriteria": [
            "A suggestion binds ticket ID, message revision, taxonomy version, and provider configuration.",
            "Persisting or accepting a stale suggestion fails with an explicit revision conflict.",
            "Concurrent acceptance by two agents creates at most one assignment transition and preserves both attempted-action outcomes."
          ],
          "implementationNotes": [
            "Enforce revision checks in the service/repository transaction, not only the UI.",
            "Keep assignment audit records append-only."
          ],
          "verification": [
            "Pause classification, append a reply, then release the provider and confirm the suggestion is stale.",
            "Race two acceptance requests and assert one transition with an explicit conflict for the loser."
          ],
          "deliverables": [
            "Revision-safe suggestion lifecycle and race tests"
          ],
          "rollout": "Enable acceptance only after revision checks are active; stale suggestions are regenerated or sent to manual review.",
          "skills": [
            "Optimistic concurrency",
            "Transactions",
            "Auditability",
            "Workflow integrity"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Applied AI",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "049c2db0-6496-4a77-bbc9-204201c1b43d",
          "key": "TRIAGE-107",
          "title": "Keep provider outages from blocking the support inbox",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "feedback",
          "dependsOn": [
            "TRIAGE-104"
          ],
          "scenario": "The classifier stalls and newly submitted tickets disappear until its call completes. Decouple intake from classification and make failure an observable review state.",
          "acceptanceCriteria": [
            "Ticket intake commits before asynchronous classification starts.",
            "Jobs use deterministic identities and bounded timeout/retry settings.",
            "Exhausted jobs leave tickets visible in manual review with a safe failure category."
          ],
          "implementationNotes": [
            "Use a transactional outbox or equivalent local transactional queue boundary.",
            "The default provider is deterministic and requires no credentials."
          ],
          "verification": [
            "Simulate provider timeout and verify immediate ticket visibility plus eventual review state.",
            "Deliver the same job twice and confirm it does not create duplicate suggestions."
          ],
          "deliverables": [
            "Asynchronous suggestion job and outage scenarios"
          ],
          "rollout": "Enable queued suggestions behind a feature flag; disable workers while preserving manual inbox intake.",
          "skills": [
            "Outbox",
            "Idempotent jobs",
            "Failure isolation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Applied AI",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "1c46e7de-584c-4bf0-97ca-5f48dce032b9",
          "key": "TRIAGE-108",
          "title": "Record corrections without turning agent clicks into automatic training data",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "feedback",
          "dependsOn": [
            "TRIAGE-106"
          ],
          "scenario": "A corrected queue overwrites the original suggestion, making disagreement impossible to investigate. Preserve the proposal, decision, actor, and reason as separate records.",
          "acceptanceCriteria": [
            "Each correction links the original suggestion, selected queue, actor, time, and optional bounded reason.",
            "Corrections are append-only and readable only within the ticket tenant and permitted support role.",
            "No correction triggers external training or sends message text to a provider automatically."
          ],
          "implementationNotes": [
            "Treat corrections as operational feedback, not unquestionable ground truth."
          ],
          "verification": [
            "Correct one suggestion twice and inspect the complete ordered history.",
            "Attempt to read another tenant correction and confirm denial with no message text leakage."
          ],
          "deliverables": [
            "Correction audit model and scoped history endpoint"
          ],
          "rollout": "Start collecting local operational feedback with retention controls; any later training export requires a separate governed workflow.",
          "skills": [
            "Audit logs",
            "Tenant authorization",
            "Data governance"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Applied AI",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "cc59f8e1-fca8-4f53-90f8-b467c9b03d13",
          "key": "TRIAGE-109",
          "title": "Compare two routing revisions on the same ambiguous-ticket set",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "feedback",
          "dependsOn": [
            "TRIAGE-107",
            "TRIAGE-108"
          ],
          "scenario": "A new prompt moves more messages to Billing, but the team cannot tell whether it improved routing or merely reduced abstention. Compare both revisions on a fixed synthetic case set.",
          "acceptanceCriteria": [
            "Cases include mixed issues, short messages, quoted text, injection attempts, and explicit security intake.",
            "Reports show per-queue outcomes, review rate, rule violations, invalid outputs, and changed decisions.",
            "A mandatory-review violation blocks adopting the new revision regardless of aggregate routing accuracy."
          ],
          "implementationNotes": [
            "Pin normalization, taxonomy, provider-double, and case-set versions.",
            "Keep abstentions visible rather than counting them as successful classifications."
          ],
          "verification": [
            "Run both revisions on identical inputs and reproduce the decision diff.",
            "Inject a security downgrade into one revision and confirm it fails the adoption gate."
          ],
          "deliverables": [
            "Routing comparison harness and adoption report"
          ],
          "rollout": "Keep the current revision active while evaluating the new one; switch by versioned configuration after category gates pass.",
          "skills": [
            "AI evaluation",
            "Regression analysis",
            "Release criteria"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1cd44396-8d43-4da8-b5bd-1699887c4b8b",
          "key": "TRIAGE-110",
          "title": "Explain routing delays using metadata instead of customer messages",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "feedback",
          "dependsOn": [
            "TRIAGE-109"
          ],
          "scenario": "Support leads need to diagnose slow suggestions, while logs currently include full complaint text. Add safe operational measures and an immediate suggestion kill switch.",
          "acceptanceCriteria": [
            "Metrics expose queue delay, provider duration, timeout count, validation failures, and manual-review count without message bodies.",
            "Audit metadata includes trace ID and exact provider/template/schema versions.",
            "Disabling suggestions stops new provider calls while tickets and existing audit history remain accessible."
          ],
          "implementationNotes": [
            "Represent unavailable provider cost as unavailable, not zero.",
            "Keep privileged access to source messages outside generic analytics."
          ],
          "verification": [
            "Run a delayed provider fixture and trace intake-to-review timing from metadata.",
            "Toggle the kill switch with queued work and confirm no new calls and no lost tickets."
          ],
          "deliverables": [
            "Safe operations dashboard data and disable/recovery runbook"
          ],
          "rollout": "Enable metrics before activating suggestions; use the kill switch for unexpected routing changes while retaining manual service.",
          "skills": [
            "Observability",
            "Privacy",
            "Operational controls"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "9af4b1e5-d801-4904-99ca-a581f49c1190",
      "key": "SYNC",
      "title": "Inventory sync that survives a vendor outage",
      "field": "Integrations",
      "summary": "Build a vendor inventory connector with stable identity mapping, resumable ingestion, reconciliation, and tenant-safe operations.",
      "context": "A fictional retailer receives stock from two vendor warehouses. The vendor API paginates snapshots and emits change events, but retries and deleted products have caused unexplained stock drift. Work against a local vendor simulator.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL",
        "BullMQ"
      ],
      "prerequisites": [
        "Create a local vendor API simulator with cursor pages and stock events.",
        "Use synthetic tenants, SKUs, and warehouse records; no vendor account is required."
      ],
      "developerValue": "Practice external contracts, cursor recovery, mapping conflicts, and reconciliation under partial failure.",
      "companyValue": "Inspect whether integration changes protect inventory correctness and give operators a clear recovery path.",
      "delivery": "A simulated vendor connector, reconciliation workflow, drift report, and outage runbook.",
      "phases": [
        {
          "id": "contract",
          "title": "Understand vendor identity and data",
          "goal": "Validate external records before affecting stock."
        },
        {
          "id": "ingest",
          "title": "Ingest changes safely",
          "goal": "Handle cursors, duplicates, disorder, and API limits."
        },
        {
          "id": "reconcile",
          "title": "Recover and operate",
          "goal": "Find drift and apply only reviewable corrections."
        }
      ],
      "tickets": [
        {
          "id": "854ce9ea-1654-4aae-ab14-3f7d75fce74e",
          "key": "SYNC-101",
          "title": "Validate vendor stock records at the adapter boundary",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "The vendor sent quantity as an empty string and the importer stored zero, hiding a data problem. Validate a versioned stock response before mapping it into internal records.",
          "acceptanceCriteria": [
            "Records require vendor item ID, warehouse ID, nonnegative integer quantity, revision, and updated timestamp.",
            "Missing, empty, fractional, or out-of-range quantities are rejected with a safe record reference.",
            "Unknown optional vendor fields do not silently become internal domain fields."
          ],
          "implementationNotes": [
            "Keep vendor DTOs separate from internal stock types."
          ],
          "verification": [
            "Accept a valid zero-stock record and a positive quantity record.",
            "Reject empty-string, negative, fractional, and unsafe-integer quantities without writing stock."
          ],
          "deliverables": [
            "Vendor response schema and malformed-record fixtures"
          ],
          "rollout": "Start validation in the simulator; malformed records go to an inspection queue rather than defaulting to zero.",
          "skills": [
            "Contract validation",
            "Adapter design",
            "Data quality"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "adapter",
              "activity": "REFACTOR",
              "focus": "Keep vendor payloads outside the internal stock model; compare a small mapping function with an object adapter while preserving boundary validation."
            }
          ]
        },
        {
          "id": "bcb2fe8b-ff54-40c6-b6bf-1468ee55df3d",
          "key": "SYNC-102",
          "title": "Map vendor items without assuming SKUs are globally unique",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "contract",
          "dependsOn": [
            "SYNC-101"
          ],
          "scenario": "Two tenants both sell SKU CABLE-2M, and a mapping lookup updates the wrong stock row. Scope vendor mappings by tenant, connector, warehouse, and vendor item identity.",
          "acceptanceCriteria": [
            "Mapping lookup always requires server-derived tenant and connector scope.",
            "Unique constraints prevent duplicate mapping identities within that scope.",
            "Unmapped or ambiguous items are quarantined and do not update a guessed SKU."
          ],
          "implementationNotes": [
            "Treat display SKU as mutable metadata, not a durable identity."
          ],
          "verification": [
            "Map identical SKU text for two tenants and verify each stock update stays in its own tenant.",
            "Supply an unmapped vendor item and confirm no stock mutation and an inspectable mapping issue."
          ],
          "deliverables": [
            "Scoped mapping repository and cross-tenant tests"
          ],
          "rollout": "Backfill explicit mapping identities before enabling updates; pause connectors with unresolved mapping conflicts.",
          "skills": [
            "Tenant isolation",
            "Identity mapping",
            "Database constraints"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ca2c6355-27d0-40d7-8994-e119b6a2b16c",
          "key": "SYNC-103",
          "title": "Resume a paginated snapshot from the last committed page",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "ingest",
          "dependsOn": [
            "SYNC-102"
          ],
          "scenario": "The importer crashes on page four and restarts from page one, occasionally skipping records because the cursor is saved before page writes finish. Couple the checkpoint to the page commit.",
          "acceptanceCriteria": [
            "A page and its next cursor commit atomically within one tenant-scoped transaction.",
            "Replaying a committed page is idempotent by snapshot and record identity.",
            "Expired cursors leave the current attempt incomplete and start a separately identified snapshot rather than mixing pages."
          ],
          "implementationNotes": [
            "Store snapshot identity alongside opaque vendor cursors.",
            "Do not infer cursor order from cursor text."
          ],
          "verification": [
            "Inject a failure between page writes and checkpoint and verify neither commits.",
            "Resume after a successful page commit and assert no missing or duplicate stock records."
          ],
          "deliverables": [
            "Transactional snapshot checkpointing and restart scenarios"
          ],
          "rollout": "Run an initial snapshot in shadow storage; activate only a fully completed snapshot version.",
          "skills": [
            "Transactions",
            "Cursor pagination",
            "Idempotency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3ba6809f-2a69-4df8-8e25-a9b5877861dc",
          "key": "SYNC-104",
          "title": "Ignore stale stock events while retaining their delivery record",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "ingest",
          "dependsOn": [
            "SYNC-102"
          ],
          "scenario": "Stock revision 42 sets quantity to 7, then delayed revision 41 resets it to 12. Compare vendor revisions atomically and record the stale delivery without changing current stock.",
          "acceptanceCriteria": [
            "A higher revision replaces the current quantity and records its source event.",
            "Equal revisions with equal content are idempotent; equal revisions with different content create a conflict.",
            "Lower revisions remain in delivery history and cannot overwrite current stock."
          ],
          "implementationNotes": [
            "Define revision ordering in the adapter contract; timestamps alone are insufficient."
          ],
          "verification": [
            "Apply revisions 41, 42, and 41 and verify final quantity from 42.",
            "Race two updates and send conflicting content under one revision; verify monotonic state and a visible conflict."
          ],
          "deliverables": [
            "Revision-guarded stock updates and out-of-order fixtures"
          ],
          "rollout": "Enable revision checks before consuming events; quarantine vendors that cannot supply the required ordering contract.",
          "skills": [
            "Concurrency control",
            "Event ordering",
            "Conflict detection"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e91bf85f-97e9-48d6-8c52-4a5d90d2eae6",
          "key": "SYNC-105",
          "title": "Stop concurrent refreshes from multiplying vendor requests",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "ingest",
          "dependsOn": [
            "SYNC-103"
          ],
          "scenario": "Five scheduled jobs refresh the same connector after a restart and exceed the vendor limit. Add one active refresh identity per connector and bounded Retry-After handling.",
          "acceptanceCriteria": [
            "Concurrent refresh triggers converge on one active connector job.",
            "429 responses follow capped Retry-After behavior within an overall refresh deadline.",
            "A failing connector does not prevent another tenant connector from progressing."
          ],
          "implementationNotes": [
            "Use deterministic job IDs and an injected clock in timing tests.",
            "Do not hold a database transaction during vendor waits."
          ],
          "verification": [
            "Submit five identical triggers and assert one vendor page sequence.",
            "Throttle one connector and verify another completes while the first stops at its deadline."
          ],
          "deliverables": [
            "Refresh coordination and rate-limit simulator scenarios"
          ],
          "rollout": "Set conservative per-connector concurrency and expose pause/resume; rollback by pausing ingestion without clearing checkpoints.",
          "skills": [
            "Job deduplication",
            "Rate limits",
            "Failure isolation"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4f2bc903-76a1-431d-8fd8-4f17d986a5e8",
          "key": "SYNC-106",
          "title": "Distinguish a discontinued item from an item missing on one page",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "ingest",
          "dependsOn": [
            "SYNC-103",
            "SYNC-104"
          ],
          "scenario": "A transient missing page made hundreds of products look deleted. Apply absence-based tombstones only after a complete authoritative snapshot, while preserving explicit deletion events.",
          "acceptanceCriteria": [
            "An incomplete snapshot cannot discontinue items through absence.",
            "A completed snapshot marks only previously mapped items absent from that exact vendor scope as candidates for discontinuation.",
            "A newer explicit stock event received during snapshot ingestion is not overwritten by an older absence decision."
          ],
          "implementationNotes": [
            "Record the snapshot consistency boundary and event watermark.",
            "If the simulator cannot guarantee a consistency boundary, surface uncertainty and require review."
          ],
          "verification": [
            "Fail the final page and verify no absence-based tombstones are applied.",
            "Deliver a newer event during snapshot ingestion and confirm finalization preserves it or reports a review conflict."
          ],
          "deliverables": [
            "Snapshot finalization policy and deletion/event race tests"
          ],
          "rollout": "Generate discontinuation proposals first; enable automatic tombstones only for connectors with the documented snapshot guarantee.",
          "skills": [
            "Snapshot consistency",
            "Reconciliation",
            "Deletion semantics",
            "Race conditions"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2c17e828-e912-4dcc-b5ce-891313768eb8",
          "key": "SYNC-107",
          "title": "Produce a stock drift report before applying corrections",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "reconcile",
          "dependsOn": [
            "SYNC-103"
          ],
          "scenario": "Operations sees different stock in the vendor portal and local app but has no item-level comparison. Add a read-only report against a completed synthetic snapshot.",
          "acceptanceCriteria": [
            "The report lists local quantity, vendor quantity, revision, warehouse, and difference for each mapped item.",
            "Equal items can be hidden without changing discrepancy totals.",
            "Unmapped items and incomplete snapshots are labeled separately from confirmed quantity drift."
          ],
          "implementationNotes": [
            "Include tenant and connector labels only within authorized operator scope."
          ],
          "verification": [
            "Compare a fixture with one equal, one mismatched, and one unmapped item.",
            "Attempt a report from an incomplete snapshot and verify no discrepancy is presented as a confirmed correction."
          ],
          "deliverables": [
            "Read-only reconciliation report and comparison fixture"
          ],
          "rollout": "Expose reports before correction actions; disable report generation when snapshot authority cannot be established.",
          "skills": [
            "Reconciliation",
            "Reporting",
            "Data comparison"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "795e6091-2e95-4d73-8dfd-b2b26b4b8677",
          "key": "SYNC-108",
          "title": "Apply an approved reconciliation plan only if stock is unchanged",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "reconcile",
          "dependsOn": [
            "SYNC-106",
            "SYNC-107"
          ],
          "scenario": "An operator reviews a drift report, but a fresh vendor event arrives before Apply. Bind corrections to the reviewed before-state so approval cannot overwrite a newer update.",
          "acceptanceCriteria": [
            "A plan records each item before revision, proposed quantity, source snapshot, and a canonical plan digest.",
            "Application verifies permission, plan digest, and every current before revision in one transaction.",
            "Any stale item blocks the plan with a conflict; approved applications record an append-only actor audit."
          ],
          "implementationNotes": [
            "Choose all-or-nothing application for this bounded exercise.",
            "Recovery creates a new reviewed plan; it does not rewrite the old approval."
          ],
          "verification": [
            "Apply an unchanged plan and verify exact proposed quantities and one audit record.",
            "Advance one item revision before apply and confirm no item in the plan changes."
          ],
          "deliverables": [
            "Reviewable correction plan and stale-approval tests"
          ],
          "rollout": "Allow only explicitly authorized operators to apply plans; keep a read-only report mode available if conflicts spike.",
          "skills": [
            "Optimistic concurrency",
            "Authorization",
            "Transactional updates",
            "Audit logs"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "174bf1d8-95a2-4a3e-8901-b4656b383292",
          "key": "SYNC-109",
          "title": "Surface a stale connector without logging vendor payloads",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "reconcile",
          "dependsOn": [
            "SYNC-105"
          ],
          "scenario": "A connector has not completed a refresh for six hours, yet its status is green because the last HTTP request succeeded. Define freshness from completed ingestion checkpoints.",
          "acceptanceCriteria": [
            "Status exposes last complete snapshot, latest accepted event, current attempt, and safe failure category separately.",
            "A configured freshness threshold marks stale data without claiming the connector is healthy from HTTP success alone.",
            "Metrics and logs exclude tokens, raw payloads, and customer-specific product descriptions."
          ],
          "implementationNotes": [
            "Use UTC and an injected clock for freshness.",
            "Keep metrics cardinality bounded; item IDs belong in scoped diagnostics."
          ],
          "verification": [
            "Advance the clock past the threshold after a partial refresh and verify stale status.",
            "Cause a vendor error containing a token marker and confirm it is absent from all normal diagnostics."
          ],
          "deliverables": [
            "Connector health projection and safe diagnostic tests"
          ],
          "rollout": "Publish status before enabling notifications; reset health only after a complete qualifying ingestion checkpoint.",
          "skills": [
            "Observability",
            "Freshness semantics",
            "Secret handling"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "83537e61-dbf2-43cf-a340-d7d5a6ea6f20",
          "key": "SYNC-110",
          "title": "Rehearse recovery from a vendor schema change",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "reconcile",
          "dependsOn": [
            "SYNC-108",
            "SYNC-109"
          ],
          "scenario": "The vendor replaces quantity with availableQuantity in its next API version. Demonstrate that the connector fails visibly, can resume with a new adapter, and preserves the old run history.",
          "acceptanceCriteria": [
            "Unexpected required-field changes stop affected ingestion without defaulting stock values.",
            "A versioned adapter can be selected per connector after contract fixtures pass.",
            "Recovery resumes from a compatible checkpoint or starts a new snapshot with an explicit reason."
          ],
          "implementationNotes": [
            "Keep both schema fixtures local and versioned.",
            "Do not reinterpret an old cursor under an incompatible API version."
          ],
          "verification": [
            "Switch the simulator schema mid-run and confirm no corrupt stock or silent success.",
            "Upgrade the adapter, reconcile a complete new snapshot, and reproduce the documented recovery path."
          ],
          "deliverables": [
            "Schema-change contract cases and connector recovery runbook"
          ],
          "rollout": "Canary the new adapter on one synthetic connector; revert adapter selection and pause writes if contract errors recur.",
          "skills": [
            "API evolution",
            "Contract testing",
            "Incident recovery"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "d92afafe-688f-483d-9328-4dc2e8e31425",
      "key": "CAL",
      "title": "A booking connector that respects calendar reality",
      "field": "Integrations",
      "summary": "Build a calendar booking workflow with time-zone rules, conflict handling, idempotent provider calls, and safe reconnect behavior.",
      "context": "A fictional consultancy books appointments across time zones. The first connector duplicates events after timeouts and offers slots during stale calendar sync. Use a local calendar-provider double and synthetic calendars.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP",
        "IANA time zones"
      ],
      "prerequisites": [
        "Create a local provider double for free/busy, event creation, updates, cancellation, and expiring tokens.",
        "Use synthetic calendars and an injected clock; no calendar account or outgoing invitation is required."
      ],
      "developerValue": "Practice time modeling, conflict-safe booking, external state reconciliation, and credential lifecycle boundaries.",
      "companyValue": "Review whether integration work protects appointment correctness and offers clear recovery when a provider is uncertain.",
      "delivery": "A local booking connector with deterministic provider scenarios and an operations guide.",
      "phases": [
        {
          "id": "availability",
          "title": "Represent time and availability",
          "goal": "Offer only valid, explainable slots from fresh calendar data."
        },
        {
          "id": "booking",
          "title": "Create and change bookings safely",
          "goal": "Handle concurrency, retries, and external side effects explicitly."
        },
        {
          "id": "lifecycle",
          "title": "Recover provider and account changes",
          "goal": "Manage updates, cancellation, expiry, and reconnect without duplicates."
        }
      ],
      "tickets": [
        {
          "id": "51105617-d295-4435-879d-157b94ee750e",
          "key": "CAL-101",
          "title": "Reject local times that do not identify one instant",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "availability",
          "dependsOn": [],
          "scenario": "A booking form submits 01:30 on a daylight-saving fallback day without an offset. Store an instant plus display zone and explicitly handle ambiguous or nonexistent local times.",
          "acceptanceCriteria": [
            "Bookings store UTC start/end instants and an IANA display-zone identifier.",
            "Nonexistent local times are rejected with a selectable valid alternative.",
            "Ambiguous local times require an explicit offset or occurrence choice and preserve that choice."
          ],
          "implementationNotes": [
            "Use established time-zone APIs or libraries; do not hard-code seasonal offsets."
          ],
          "verification": [
            "Test a normal date and both sides of a known spring gap and autumn overlap in a fixture zone.",
            "Submit an unknown zone and an end before start and verify validation errors without provider calls."
          ],
          "deliverables": [
            "Booking time contract and daylight-saving boundary cases"
          ],
          "rollout": "Validate time inputs before availability or event creation; keep existing stored instants unchanged during migration.",
          "skills": [
            "Time zones",
            "Input validation",
            "Temporal modeling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "06d28b5f-665f-4b3e-bd0b-30f0d77f781a",
          "key": "CAL-102",
          "title": "Merge overlapping busy intervals before offering slots",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "availability",
          "dependsOn": [
            "CAL-101"
          ],
          "scenario": "Two overlapping provider events produce a false free gap between them. Normalize busy intervals and apply the agreed booking duration and buffer.",
          "acceptanceCriteria": [
            "Overlapping and adjacent intervals merge according to documented half-open boundaries.",
            "Offered slots fit completely within working hours after pre/post buffers are applied.",
            "Zero-length or reversed provider intervals are rejected as malformed input."
          ],
          "implementationNotes": [
            "Keep interval calculations in UTC; convert working-hour boundaries from the declared zone."
          ],
          "verification": [
            "Merge 09:00-10:00 and 09:30-10:30 and confirm no slot appears at 10:00.",
            "Test a slot ending exactly at closing time with and without a post-booking buffer."
          ],
          "deliverables": [
            "Interval normalizer and slot boundary examples"
          ],
          "rollout": "Compare new slot output with fixture expectations in preview mode before exposing booking actions.",
          "skills": [
            "Interval arithmetic",
            "Boundary tests",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a207da19-28c1-445e-8427-06825344382f",
          "key": "CAL-103",
          "title": "Label unavailable or stale free/busy data instead of showing open slots",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "availability",
          "dependsOn": [
            "CAL-102"
          ],
          "scenario": "A free/busy request times out and the connector treats an empty response as an empty calendar. Distinguish confirmed free time from unknown availability.",
          "acceptanceCriteria": [
            "Availability responses include fetched-at time, freshness state, and provider outcome.",
            "A timeout, malformed response, or expired cache produces unknown availability and no bookable slots.",
            "Fresh empty busy data can produce slots and remains distinguishable from failure."
          ],
          "implementationNotes": [
            "Use a configurable freshness limit and injected clock."
          ],
          "verification": [
            "Return fresh empty data and verify valid working-hour slots.",
            "Return timeout and separately age cached data beyond the limit; neither may expose bookable slots."
          ],
          "deliverables": [
            "Availability state model and stale-data tests"
          ],
          "rollout": "Enable fail-closed availability before adding booking creation; users receive a retry state while provider data is unknown.",
          "skills": [
            "Failure semantics",
            "Caching",
            "User feedback"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a5d8e108-7556-4437-b870-145a587a734e",
          "key": "CAL-104",
          "title": "Reserve a slot atomically when two customers choose it",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "booking",
          "dependsOn": [
            "CAL-103"
          ],
          "scenario": "Two clients load the same available slot and submit together. Add an internal reservation transaction and a final provider availability check before creating an event.",
          "acceptanceCriteria": [
            "Overlapping active reservations for one resource are prevented by a database-backed invariant.",
            "Only the winning reservation can enqueue event creation through a transactional outbox.",
            "The product distinguishes internal reservation guarantees from provider-side races when the provider lacks atomic hold support."
          ],
          "implementationNotes": [
            "Use a barrier-controlled race with two synthetic customers.",
            "If the provider cannot guarantee exclusive booking, record the residual conflict state and provide reconciliation."
          ],
          "verification": [
            "Submit two overlapping reservations concurrently and assert one winner and one outbox event.",
            "Introduce an external busy event after the first check and verify the booking is rejected or explicitly reconciled under the declared provider contract."
          ],
          "deliverables": [
            "Reservation constraint, outbox flow, and provider-race analysis"
          ],
          "rollout": "Activate one resource at a time with explicit provider guarantees; pause creation if unresolved conflicts accumulate.",
          "skills": [
            "Database concurrency",
            "Outbox",
            "Distributed consistency",
            "Risk communication"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4bc7b889-1d17-4a9f-826e-7c2767626f98",
          "key": "CAL-105",
          "title": "Reconcile a create-event timeout before trying again",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "booking",
          "dependsOn": [
            "CAL-104"
          ],
          "scenario": "The calendar provider creates the appointment but drops its response. Retrying with a new request identifier currently creates a second event. Preserve creation identity and reconcile uncertainty.",
          "acceptanceCriteria": [
            "Each booking has a stable provider request identity persisted before the first call.",
            "A lost response triggers lookup by that identity or an explicit uncertain state when lookup is unsupported.",
            "A matching existing event is linked once; conflicting details block automatic completion."
          ],
          "implementationNotes": [
            "Use the local double to model accepted-then-timeout.",
            "Do not claim exactly-once provider behavior without the required idempotency contract."
          ],
          "verification": [
            "Lose the first create response and assert one provider event after reconciliation.",
            "Return an event with the same identity but different times and confirm the booking enters conflict without another create."
          ],
          "deliverables": [
            "Idempotent creation adapter and uncertain-outcome tests"
          ],
          "rollout": "Require reconciliation support before enabling retries; unsupported providers remain in manual resolution on ambiguous outcomes.",
          "skills": [
            "Idempotency",
            "External state reconciliation",
            "Failure handling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2d068496-a34e-41a9-b729-99358338871d",
          "key": "CAL-106",
          "title": "Move a booking only if its current revision still matches",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "booking",
          "dependsOn": [
            "CAL-105"
          ],
          "scenario": "An agent reschedules a booking from an old browser tab after a colleague already moved it. Add revision-aware rescheduling and retain the original slot until the new operation is settled.",
          "acceptanceCriteria": [
            "Reschedule requests include the expected booking revision and are rejected when stale.",
            "The proposed new slot passes reservation and availability checks before the provider update.",
            "Provider failure or uncertainty leaves a documented pending/conflict state and does not silently mark both slots free."
          ],
          "implementationNotes": [
            "Use provider conditional updates when the adapter supports them.",
            "Record before and proposed intervals in an append-only operation record."
          ],
          "verification": [
            "Reschedule an unchanged booking and verify one final interval and incremented revision.",
            "Race two reschedules and simulate a provider timeout; verify explicit conflicts and no duplicate successful move."
          ],
          "deliverables": [
            "Rescheduling state transitions and race/failure cases"
          ],
          "rollout": "Enable rescheduling after create reconciliation is stable; fall back to operator resolution for uncertain provider updates.",
          "skills": [
            "Optimistic locking",
            "State machines",
            "Compensation"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b576e4d6-2fba-4b46-b0e2-e64acf4a9d72",
          "key": "CAL-107",
          "title": "Make repeated cancellation safe and tenant scoped",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CAL-105"
          ],
          "scenario": "A client double-clicks Cancel while a support agent cancels from another screen. The connector must converge on one cancellation without allowing another tenant to cancel by event ID.",
          "acceptanceCriteria": [
            "Cancellation resolves the booking through tenant and actor authorization before accessing provider IDs.",
            "Repeated authorized cancellation converges on the same terminal result.",
            "Provider not-found is accepted only after verifying the expected booking/provider mapping, and other provider errors remain visible."
          ],
          "implementationNotes": [
            "Keep provider event IDs out of caller-controlled authority decisions."
          ],
          "verification": [
            "Send concurrent cancellation requests and assert one logical cancellation history.",
            "Attempt cancellation from another tenant and verify no provider request is made."
          ],
          "deliverables": [
            "Scoped cancellation service and idempotency/access tests"
          ],
          "rollout": "Expose cancellation with retry-safe state transitions; retain pending cancellation during provider outages rather than claiming success.",
          "skills": [
            "Authorization",
            "Idempotency",
            "Lifecycle design"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0394e732-e212-481f-8004-a401bd7b0050",
          "key": "CAL-108",
          "title": "Refresh expired connector credentials once per account",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CAL-105"
          ],
          "scenario": "Ten jobs receive token-expired at once, all refresh, and a rotated token is overwritten by an older response. Serialize refresh by connector identity and persist credential revisions safely.",
          "acceptanceCriteria": [
            "Concurrent expiry responses share one refresh operation per connector account.",
            "Credential writes use version checks so an older refresh cannot overwrite a newer rotation.",
            "A revoked grant stops new provider mutations, records reconnect-required, and never logs credential values."
          ],
          "implementationNotes": [
            "Use synthetic opaque tokens and a local token endpoint double.",
            "Store credentials through a secret-store interface; do not hard-code a production key."
          ],
          "verification": [
            "Expire a token under ten concurrent calls and assert one refresh with successful versioned reuse.",
            "Return refresh responses out of order and a revoked grant; verify no stale overwrite and no further mutations."
          ],
          "deliverables": [
            "Credential lifecycle port and refresh-race tests"
          ],
          "rollout": "Canary the new refresh path on a synthetic connector; force reconnect when credential authority is ambiguous.",
          "skills": [
            "Credential lifecycle",
            "Concurrency",
            "Secret handling",
            "Provider integration"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0a9053c1-3d7c-4a88-8ae1-5eb66b1f2184",
          "key": "CAL-109",
          "title": "Ignore duplicate calendar notifications and detect missed updates",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CAL-106",
            "CAL-107",
            "CAL-108"
          ],
          "scenario": "Provider notifications arrive twice, then a subscription expires and updates stop. Treat notifications as sync hints and maintain a separate reconciliation cursor and subscription deadline.",
          "acceptanceCriteria": [
            "Authenticated duplicate notifications schedule at most one active sync for the connector.",
            "Sync advances its provider cursor only with committed local changes.",
            "Expired subscriptions or invalid cursors trigger an explicit refresh/reconnect path and mark availability stale."
          ],
          "implementationNotes": [
            "Validate the local notification authentication contract before trusting connector metadata.",
            "Do not use notification arrival order as event revision order."
          ],
          "verification": [
            "Send duplicate and invalid-auth notifications and count scheduled jobs.",
            "Expire a subscription and invalidate a cursor; confirm availability becomes unbookable until a successful resync."
          ],
          "deliverables": [
            "Notification ingestion, sync checkpointing, and expiry scenarios"
          ],
          "rollout": "Enable notification ingestion alongside periodic reconciliation; pause booking when either path cannot establish fresh availability.",
          "skills": [
            "Webhook security",
            "Cursor sync",
            "Freshness",
            "Idempotent jobs"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "940dd137-58cf-4f28-8de4-f4ff5bff6a19",
          "key": "CAL-110",
          "title": "Show operators which bookings need recovery after reconnect",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CAL-109"
          ],
          "scenario": "After reconnecting an account, operations cannot tell which bookings were created, moved, or cancelled during the outage. Build a scoped recovery list with safe identifiers and next actions.",
          "acceptanceCriteria": [
            "The list separates pending creation, uncertain update, pending cancellation, and resolved operations.",
            "Each row includes safe booking reference, last attempt time, failure category, and permitted recovery action.",
            "Reading the list never sends invitations, creates events, or retries an operation implicitly."
          ],
          "implementationNotes": [
            "Omit attendee contact details from generic diagnostics.",
            "Actions invoke the existing authorized lifecycle methods."
          ],
          "verification": [
            "Populate one operation in each state and verify labels and action availability.",
            "Open the list as an unauthorized tenant and confirm denial with zero provider activity."
          ],
          "deliverables": [
            "Recovery list projection and reconnect operator guide"
          ],
          "rollout": "Release read-only recovery visibility first; activate explicit retry actions only through the already verified state transitions.",
          "skills": [
            "Operations UX",
            "Authorization",
            "Recovery workflows"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "91f3550e-2cb8-44ae-ba8c-3f540083146b",
      "key": "ADRIFT",
      "title": "Make subscription entitlements survive plan changes",
      "field": "Backend",
      "summary": "Resolve effective entitlements across scheduled and immediate plan changes.",
      "context": "A fictional document service grants storage and collaboration rights from subscriptions. Support cannot explain why delayed events restore old limits.",
      "stack": [
        "TypeScript",
        "NestJS",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local subscription API with synthetic accounts.",
        "Understand transactions and UTC intervals."
      ],
      "developerValue": "Practice temporal rules, concurrency and explainable API decisions.",
      "companyValue": "Review whether entitlement changes preserve customer access and produce supportable decisions.",
      "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": "contract",
          "title": "Define effective rights",
          "goal": "Specify entitlement periods and failure responses."
        },
        {
          "id": "change",
          "title": "Apply changes safely",
          "goal": "Preserve ordering and concurrent update invariants."
        },
        {
          "id": "support",
          "title": "Explain and recover",
          "goal": "Expose effective decisions and recover delayed changes."
        }
      ],
      "tickets": [
        {
          "id": "df462ec4-a772-482b-a7bc-d6532cbfdb87",
          "key": "ADRIFT-101",
          "title": "Specify the entitlement response at an exact effective instant",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Support compares screenshots from two time zones and cannot tell which storage limit applied when an upload failed.",
          "acceptanceCriteria": [
            "Return limit, effective UTC instant and plan revision.",
            "Document inclusive start and exclusive end boundaries.",
            "Reject an invalid timestamp without resolving rights."
          ],
          "implementationNotes": [
            "Use synthetic plan names and integer byte limits."
          ],
          "verification": [
            "Resolve immediately before and at a plan boundary.",
            "Reject a timestamp without an offset and verify no write."
          ],
          "deliverables": [
            "Versioned response contract and boundary fixtures"
          ],
          "rollout": "Introduce the versioned read route; remove routing if consumers reject it.",
          "skills": [
            "API contracts",
            "Temporal modeling"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "53584c31-a0d8-4bcd-86a6-94f46d8c6089",
          "key": "ADRIFT-102",
          "title": "Keep manual account restrictions separate from plan allowances",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contract",
          "dependsOn": [
            "ADRIFT-101"
          ],
          "scenario": "A support restriction disappears when an account upgrades because both settings currently share one mutable limit.",
          "acceptanceCriteria": [
            "Store restriction and plan allowance with separate provenance.",
            "Return the effective minimum with both reasons.",
            "Removing a restriction restores the current plan allowance."
          ],
          "implementationNotes": [
            "Restrict mutation to an authorized support role."
          ],
          "verification": [
            "Upgrade a restricted account and retain its lower limit.",
            "Attempt a restriction change as a normal member and deny it."
          ],
          "deliverables": [
            "Restriction command and permission tests"
          ],
          "rollout": "Enable for synthetic accounts; disable mutation while retaining restriction history.",
          "skills": [
            "Domain modeling",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "189ad5cd-e676-4300-b9f1-dcf946e0da64",
          "key": "ADRIFT-103",
          "title": "Reject negative and fractional seat allowances consistently",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [
            "ADRIFT-101"
          ],
          "scenario": "An administrative import accepts 2.5 seats, while the runtime truncates the value differently from the billing preview.",
          "acceptanceCriteria": [
            "Accept only nonnegative safe integers for seat limits.",
            "Use one validation rule for import and API commands.",
            "Return the offending field without echoing the entire import."
          ],
          "implementationNotes": [
            "Represent unlimited explicitly rather than with negative sentinels."
          ],
          "verification": [
            "Create zero-seat and unlimited synthetic plans.",
            "Reject fractional, negative and unsafe integer limits."
          ],
          "deliverables": [
            "Shared seat schema and import regression"
          ],
          "rollout": "Deploy validation before new imports; quarantine rejected rows for correction.",
          "skills": [
            "Validation",
            "TypeScript"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8c452e1a-d494-44fe-8c0d-9db19ffb8daa",
          "key": "ADRIFT-104",
          "title": "Apply a scheduled downgrade only after its stored effective time",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "change",
          "dependsOn": [
            "ADRIFT-101",
            "ADRIFT-103"
          ],
          "scenario": "A worker runs the next day's downgrade early when a retry executes against the server's local calendar date.",
          "acceptanceCriteria": [
            "Compare a persisted UTC instant with an injected clock.",
            "Early delivery leaves the schedule pending.",
            "Repeated eligible delivery creates one entitlement revision."
          ],
          "implementationNotes": [
            "Persist the revision and dispatch record in one transaction."
          ],
          "verification": [
            "Advance a fake clock through the exact effective instant.",
            "Deliver early and twice after the boundary; count one revision."
          ],
          "deliverables": [
            "Scheduled transition and deterministic-clock tests"
          ],
          "rollout": "Canary scheduled changes; pause the consumer and retain pending schedules on failure.",
          "skills": [
            "State transitions",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 80
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f961e265-1e5a-4d00-a9ef-257b52638c9c",
          "key": "ADRIFT-105",
          "title": "Prevent a late upgrade event from undoing a newer cancellation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "change",
          "dependsOn": [
            "ADRIFT-104"
          ],
          "scenario": "Provider events arrive out of order and an old upgrade reopens collaboration after cancellation became effective.",
          "acceptanceCriteria": [
            "Compare provider sequence within each subscription.",
            "Older events remain recorded without changing effective rights.",
            "Equal sequence with different payload is surfaced as conflict."
          ],
          "implementationNotes": [
            "Do not order provider events by receipt timestamp."
          ],
          "verification": [
            "Replay cancellation followed by an older upgrade.",
            "Submit contradictory equal-sequence events and preserve current rights."
          ],
          "deliverables": [
            "Ordering guard and conflicting-event report"
          ],
          "rollout": "Run the guard in audit mode first; quarantine conflicts without deleting events.",
          "skills": [
            "Event ordering",
            "Conflict handling"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "65e1fe79-ac52-4674-b60f-676c59c6fb32",
          "key": "ADRIFT-106",
          "title": "Make plan switching and seat allocation share one consistency boundary",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "change",
          "dependsOn": [
            "ADRIFT-102",
            "ADRIFT-104"
          ],
          "scenario": "A downgrade races a seat invitation; both requests pass their reads and leave more active seats than permitted.",
          "acceptanceCriteria": [
            "Serialize competing allowance and allocation changes per account.",
            "One conflicting request returns a retryable conflict.",
            "A failed transaction leaves both seat count and rights unchanged."
          ],
          "implementationNotes": [
            "Document the invariant and chosen locking order."
          ],
          "verification": [
            "Run a two-client barrier test for downgrade versus invitation.",
            "Force transaction rollback and check both tables retain prior values."
          ],
          "deliverables": [
            "Transactional guard and concurrency reproduction"
          ],
          "rollout": "Introduce with lock-wait monitoring; revert command routing if contention exceeds the documented local budget.",
          "skills": [
            "Transactions",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3a9a138e-0fbb-48d5-b55a-b283418c58cb",
          "key": "ADRIFT-107",
          "title": "Preview entitlement changes without creating pending work",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "change",
          "dependsOn": [
            "ADRIFT-104",
            "ADRIFT-105"
          ],
          "scenario": "Sales wants to preview next month's downgrade, but the current preview endpoint creates a schedule visible to the worker.",
          "acceptanceCriteria": [
            "Preview uses the same pure decision function as execution.",
            "Return affected features and effective-time assumptions.",
            "No schedule, outbox or audit mutation occurs on preview."
          ],
          "implementationNotes": [
            "Authorize account reads before computing the preview."
          ],
          "verification": [
            "Compare preview with a later applied synthetic change.",
            "Repeat preview and assert unchanged row counts; deny another account."
          ],
          "deliverables": [
            "Pure preview operation and nonmutation checks"
          ],
          "rollout": "Expose preview behind a route flag; remove the route without touching schedules.",
          "skills": [
            "Pure functions",
            "API design"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d1fcae8c-52cc-4e8d-bbd2-d8d789d846f5",
          "key": "ADRIFT-108",
          "title": "Explain a denied upload using the exact entitlement revision",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "support",
          "dependsOn": [
            "ADRIFT-105",
            "ADRIFT-106"
          ],
          "scenario": "An upload rejection says only limit exceeded, so support cannot connect it to the plan and restriction that were evaluated.",
          "acceptanceCriteria": [
            "Return a stable denial code and evaluated revision ID.",
            "Include byte limit and current usage without other accounts' data.",
            "Keep historical revisions immutable for later explanation."
          ],
          "implementationNotes": [
            "Avoid storing document contents in decision logs."
          ],
          "verification": [
            "Reproduce a denial and resolve the same historical decision after upgrade.",
            "Request another account's decision ID and return a nondisclosing denial."
          ],
          "deliverables": [
            "Decision projection and scoped history route"
          ],
          "rollout": "Enable explanation reads first; disable projection if privacy checks fail.",
          "skills": [
            "Provenance",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a888e995-caa9-4c71-90fb-baf195e41534",
          "key": "ADRIFT-109",
          "title": "Rebuild an account entitlement projection from its ordered history",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "support",
          "dependsOn": [
            "ADRIFT-105",
            "ADRIFT-108"
          ],
          "scenario": "A projection bug affected a synthetic account; operators need to repair derived rights without rewriting the source change history.",
          "acceptanceCriteria": [
            "Rebuild into a separate generation using deterministic ordering.",
            "Compare differences before atomically selecting the generation.",
            "Interrupted rebuild leaves the active projection usable."
          ],
          "implementationNotes": [
            "Require an account scope and dry-run mode."
          ],
          "verification": [
            "Compare a rebuilt generation with a clean reference history.",
            "Interrupt before activation and prove the old generation still resolves."
          ],
          "deliverables": [
            "Scoped rebuild command and difference report"
          ],
          "rollout": "Dry-run one synthetic account; restore the previous generation pointer on mismatch.",
          "skills": [
            "Recovery",
            "Projection design"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5cd2d519-47fa-42c3-80c5-d377c3c2fa82",
          "key": "ADRIFT-110",
          "title": "Document the handoff for disputed effective entitlements",
          "type": "TASK",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "support",
          "dependsOn": [
            "ADRIFT-108",
            "ADRIFT-109"
          ],
          "scenario": "Support needs a repeatable path to investigate a rights dispute without editing rows directly or promising the wrong allowance.",
          "acceptanceCriteria": [
            "Runbook starts from account, decision and revision identifiers.",
            "Separate delayed-provider, restriction and usage causes.",
            "Include escalation and projection rollback steps."
          ],
          "implementationNotes": [
            "Use fabricated examples and avoid raw customer identifiers."
          ],
          "verification": [
            "Follow the runbook for a scheduled downgrade dispute.",
            "Follow the missing-history branch and confirm it stops before mutation."
          ],
          "deliverables": [
            "Support runbook and two worked synthetic incidents"
          ],
          "rollout": "Review the runbook with a fresh local reproduction; version corrections alongside the projection.",
          "skills": [
            "Runbooks",
            "Incident analysis"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "0f2b69f0-2ba0-45e4-86a1-735091cab32b",
      "key": "ABOOK",
      "title": "Repair appointment holds and cancellation windows",
      "field": "Backend",
      "summary": "Keep scarce appointment slots consistent through holds, confirmations and cancellation.",
      "context": "A fictional equipment service books maintenance visits. Expiring checkout holds and reschedules occasionally double-book a technician.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "REST"
      ],
      "prerequisites": [
        "Build synthetic technicians, slots and booking records.",
        "Use an injectable clock and separate clients for concurrency probes."
      ],
      "developerValue": "Practice resource allocation, interval conflicts and durable workflows.",
      "companyValue": "Review scheduling correctness and recovery before exposing scarce capacity.",
      "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": "slots",
          "title": "Define availability",
          "goal": "Make time and availability rules unambiguous."
        },
        {
          "id": "booking",
          "title": "Protect reservations",
          "goal": "Handle simultaneous actions and durable transitions."
        },
        {
          "id": "operations",
          "title": "Operate the calendar",
          "goal": "Reconcile state and explain cancellations."
        }
      ],
      "tickets": [
        {
          "id": "daa5d0cd-c14a-4ac7-97bd-c16ae291cd6e",
          "key": "ABOOK-101",
          "title": "Normalize maintenance-slot requests to explicit UTC intervals",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "slots",
          "dependsOn": [],
          "scenario": "A technician's daylight-saving transition produces two appointments labelled 01:30 with no offset in the booking request.",
          "acceptanceCriteria": [
            "Require start, end and explicit offset.",
            "Reject end-before-start and zero-duration intervals.",
            "Persist UTC while returning the requested display zone separately."
          ],
          "implementationNotes": [
            "Create synthetic ambiguous-hour cases rather than reading real calendars."
          ],
          "verification": [
            "Round-trip two different offsets for the repeated hour.",
            "Reject an offset-free repeated-hour request."
          ],
          "deliverables": [
            "Slot input contract and DST cases"
          ],
          "rollout": "Add validation before new slot creation; retain original timestamps for existing rows.",
          "skills": [
            "Time zones",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7ef0824d-ede6-4b1d-95b1-b50ea07c57ff",
          "key": "ABOOK-102",
          "title": "Model overlapping technician availability as half-open intervals",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "slots",
          "dependsOn": [
            "ABOOK-101"
          ],
          "scenario": "Adjacent visits are rejected as overlapping, while a visit completely containing another can pass a naive endpoint check.",
          "acceptanceCriteria": [
            "Adjacent end and start boundaries do not conflict.",
            "Contained and partially overlapping intervals conflict.",
            "Conflict checks include the technician's organization."
          ],
          "implementationNotes": [
            "Document the half-open interval convention in the query."
          ],
          "verification": [
            "Check adjacent, contained and identical intervals.",
            "Try the same technician identifier in another organization and deny access."
          ],
          "deliverables": [
            "Overlap query and interval matrix"
          ],
          "rollout": "Shadow-check overlap decisions; restore the old route if new conflicts need review.",
          "skills": [
            "SQL",
            "Interval reasoning"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "5358fce8-2a7b-482f-b4f4-01853c15ba7a",
          "key": "ABOOK-103",
          "title": "Return bookable slots in stable bounded pages",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "slots",
          "dependsOn": [
            "ABOOK-101",
            "ABOOK-102"
          ],
          "scenario": "A busy service desk loads every future slot; several slots disappear from the second page when a new slot is inserted.",
          "acceptanceCriteria": [
            "Order by start instant and opaque slot ID.",
            "Use a cursor bound to technician and date window.",
            "Enforce a maximum page size and bounded date range."
          ],
          "implementationNotes": [
            "Do not expose unassigned technicians outside the organization."
          ],
          "verification": [
            "Insert a slot between pages and inspect stable cursor progression.",
            "Reject an altered cursor scope and excessive range."
          ],
          "deliverables": [
            "Availability page contract and cursor tests"
          ],
          "rollout": "Introduce cursor pagination alongside the old bounded endpoint; roll back its link.",
          "skills": [
            "Pagination",
            "API contracts"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "dce90584-399b-48ac-a05c-7174e8e4dd42",
          "key": "ABOOK-104",
          "title": "Reserve one active hold for a contested maintenance slot",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "booking",
          "dependsOn": [
            "ABOOK-102"
          ],
          "scenario": "Two customers reach checkout together and each receives a valid hold token for the same appointment.",
          "acceptanceCriteria": [
            "One active hold wins for a slot under concurrent requests.",
            "The loser gets a conflict without another customer's details.",
            "Hold creation and its expiry time commit atomically."
          ],
          "implementationNotes": [
            "Use a database invariant as the final concurrency guard."
          ],
          "verification": [
            "Start two clients at a barrier and assert one live hold.",
            "Force commit failure and assert no usable token escapes."
          ],
          "deliverables": [
            "Hold command and concurrent reservation test"
          ],
          "rollout": "Enable holds on synthetic slots; pause new holds if invariant monitoring detects duplicates.",
          "skills": [
            "Concurrency",
            "Database constraints"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "eb82de4e-1230-4e28-be4b-6257962c011f",
          "key": "ABOOK-105",
          "title": "Expire holds without cancelling a booking confirmed at the boundary",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "booking",
          "dependsOn": [
            "ABOOK-104"
          ],
          "scenario": "An expiry worker reads an old hold while checkout confirms it; the worker then frees a slot already sold.",
          "acceptanceCriteria": [
            "Confirm and expire use guarded state transitions.",
            "Exactly one terminal outcome wins at the expiry boundary.",
            "A stale expiry job cannot alter a confirmed booking."
          ],
          "implementationNotes": [
            "Specify whether confirmation at the exact deadline is rejected."
          ],
          "verification": [
            "Race confirmation and expiry with a controlled clock.",
            "Retry the stale expiry after confirmation and retain the booking."
          ],
          "deliverables": [
            "Hold state machine and boundary race reproduction"
          ],
          "rollout": "Canary the guarded worker; stop expiry consumption while preserving stored deadlines.",
          "skills": [
            "State machines",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a6470b32-f390-443c-b148-1e3b7185b67b",
          "key": "ABOOK-106",
          "title": "Reschedule a visit without releasing its old slot prematurely",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "booking",
          "dependsOn": [
            "ABOOK-104",
            "ABOOK-105"
          ],
          "scenario": "A reschedule releases the old appointment before reserving the new one, leaving customers unbooked if the target is taken.",
          "acceptanceCriteria": [
            "Reserve the target and release the source atomically.",
            "Retain the original appointment on target conflict.",
            "A retried successful command returns the same replacement."
          ],
          "implementationNotes": [
            "Keep both slot locks in a documented stable order."
          ],
          "verification": [
            "Move a visit and inspect one confirmed appointment.",
            "Race for the target and verify the losing reschedule keeps its source."
          ],
          "deliverables": [
            "Reschedule command and transaction tests"
          ],
          "rollout": "Enable for synthetic bookings; disable rescheduling while ordinary reads continue.",
          "skills": [
            "Transactions",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ee2bec23-cee2-4128-bf69-84682be53eef",
          "key": "ABOOK-107",
          "title": "Calculate the cancellation window from the booked service policy",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "booking",
          "dependsOn": [
            "ABOOK-105"
          ],
          "scenario": "A policy update changes the cancellation deadline for appointments sold under yesterday's terms.",
          "acceptanceCriteria": [
            "Booking retains the applied policy version.",
            "Deadline calculation uses that frozen policy and UTC start.",
            "Cancellation returns the policy version and eligibility reason."
          ],
          "implementationNotes": [
            "This exercise models eligibility only, without charging money."
          ],
          "verification": [
            "Cancel bookings created under two policy versions.",
            "Change the current policy and verify old booking deadlines remain fixed."
          ],
          "deliverables": [
            "Versioned cancellation calculator"
          ],
          "rollout": "Publish a new policy version for new bookings; keep historical policy references intact.",
          "skills": [
            "Versioning",
            "Business rules"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "83587c7d-baa7-46cf-93cd-6d0b4a361f15",
          "key": "ABOOK-108",
          "title": "Detect orphan holds without changing confirmed appointments",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "operations",
          "dependsOn": [
            "ABOOK-105",
            "ABOOK-106"
          ],
          "scenario": "A simulated outage leaves holds whose expiry jobs were never dispatched; operations needs a bounded reconciliation command.",
          "acceptanceCriteria": [
            "Scan expired held rows with cursor checkpoints.",
            "Release only rows still held at the checked version.",
            "Report confirmed rows skipped after concurrent change."
          ],
          "implementationNotes": [
            "Use dry-run by default and limit each batch."
          ],
          "verification": [
            "Reconcile an expired orphan and resume from a checkpoint.",
            "Confirm between scan and update and verify the booking survives."
          ],
          "deliverables": [
            "Orphan-hold reconciler and race check"
          ],
          "rollout": "Dry-run a bounded window; stop reconciliation and retain checkpoints if unexpected skips grow.",
          "skills": [
            "Reconciliation",
            "Optimistic concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6cd93527-9909-4c7a-97e6-6684a732ba98",
          "key": "ABOOK-109",
          "title": "Hide customer details in scheduling conflict responses",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "operations",
          "dependsOn": [
            "ABOOK-106",
            "ABOOK-107"
          ],
          "scenario": "A failed reschedule currently returns the target booking object, exposing the name and contact information of its owner.",
          "acceptanceCriteria": [
            "Conflict responses contain only code and requested slot identity.",
            "Internal logs omit customer contact fields.",
            "Successful owners still receive their own booking projection."
          ],
          "implementationNotes": [
            "Use explicit response schemas instead of deleting selected fields."
          ],
          "verification": [
            "Check an owner's successful reschedule response.",
            "Force a conflict and assert another customer's fields appear nowhere in response or log."
          ],
          "deliverables": [
            "Sanitized conflict schema and disclosure regression"
          ],
          "rollout": "Deploy response shaping first; revert only with the same restricted projection.",
          "skills": [
            "Privacy",
            "Response schemas"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2460e8d0-0a03-4a7a-b747-3a1e23fa1e1e",
          "key": "ABOOK-110",
          "title": "Prove booking recovery after a lost confirmation response",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operations",
          "dependsOn": [
            "ABOOK-105",
            "ABOOK-108",
            "ABOOK-109"
          ],
          "scenario": "Checkout commits successfully, then the connection closes. A customer retries while the expiry worker is also running.",
          "acceptanceCriteria": [
            "Document persisted state at each interruption point.",
            "A stable command key resolves the committed confirmation.",
            "No retry creates a second booking or frees its slot."
          ],
          "implementationNotes": [
            "Build a deterministic fault-injection harness using synthetic visits."
          ],
          "verification": [
            "Drop the response after commit and retry to the same booking.",
            "Drop before commit, run expiry, and verify the declared expired outcome."
          ],
          "deliverables": [
            "Recovery trace and executable interruption probe"
          ],
          "rollout": "Run the drill before enabling checkout; fall back to read-only booking lookup during incidents.",
          "skills": [
            "Fault injection",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "795f7fba-673b-44f3-9303-2bddca3f6ce8",
      "key": "ARULE",
      "title": "Ship a reviewable pricing-rule service",
      "field": "Backend",
      "summary": "Version promotional pricing rules and make every applied discount explainable.",
      "context": "A fictional parts supplier combines contract prices with promotions. Sales needs repeatable quotes when rules change during checkout.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "JSON Schema"
      ],
      "prerequisites": [
        "Create synthetic products and integer minor-unit prices.",
        "Implement a small local quote API."
      ],
      "developerValue": "Practice deterministic rule evaluation, revision control and bounded execution.",
      "companyValue": "Review explainable commercial rules without trusting opaque price changes.",
      "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": "rules",
          "title": "Constrain rule input",
          "goal": "Define a safe, deterministic rule language."
        },
        {
          "id": "quotes",
          "title": "Apply frozen rules",
          "goal": "Make quote decisions consistent and auditable."
        },
        {
          "id": "release",
          "title": "Release rule versions",
          "goal": "Compare revisions and recover rejected releases."
        }
      ],
      "tickets": [
        {
          "id": "fdee872f-bdf8-4d6e-99bd-5c2f4c61aaf1",
          "key": "ARULE-101",
          "title": "Define the supported promotion predicates without executable expressions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "rules",
          "dependsOn": [],
          "scenario": "Sales requested a formula textbox; evaluating arbitrary expressions would make quote behavior difficult to bound and audit.",
          "acceptanceCriteria": [
            "Allow explicit product, quantity and date predicates.",
            "Reject unknown operators and excessive nesting.",
            "Publish a schema with accepted and rejected examples."
          ],
          "implementationNotes": [
            "Treat rule documents as data; never evaluate source strings."
          ],
          "verification": [
            "Parse a quantity-band promotion.",
            "Reject a function expression and a nesting-limit violation."
          ],
          "deliverables": [
            "Promotion schema and parser cases"
          ],
          "rollout": "Accept drafts only initially; disable new drafts if parser compatibility fails.",
          "skills": [
            "Schema design",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a5b0c45d-fef0-4c27-9c3a-b2c4e56e1027",
          "key": "ARULE-102",
          "title": "Resolve overlapping promotions with an explicit tie-break policy",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "rules",
          "dependsOn": [
            "ARULE-101"
          ],
          "scenario": "Two promotions match the same part and the chosen discount depends on database return order.",
          "acceptanceCriteria": [
            "Define priority and stable-ID tie breaking.",
            "Return the winning rule and losing-match reasons.",
            "Evaluation is independent of input array order."
          ],
          "implementationNotes": [
            "Use integer arithmetic and a documented rounding boundary."
          ],
          "verification": [
            "Shuffle matching rules and retain the same price.",
            "Exercise equal priorities and invalid discount bounds."
          ],
          "deliverables": [
            "Deterministic resolver and ordering tests"
          ],
          "rollout": "Compare decisions on synthetic quotes; retain the previous resolver version for rollback.",
          "skills": [
            "Determinism",
            "Business rules"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "98375e52-586d-4fb2-a40e-1203e142ee70",
          "key": "ARULE-103",
          "title": "Validate promotion date ranges before publishing drafts",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "rules",
          "dependsOn": [
            "ARULE-101"
          ],
          "scenario": "A promotion with its end before its start passes draft review and can never apply.",
          "acceptanceCriteria": [
            "Require offset-bearing UTC-normalizable dates.",
            "Reject empty and reversed ranges at publication.",
            "Display validation paths without raw rule documents in logs."
          ],
          "implementationNotes": [
            "Use half-open intervals consistently."
          ],
          "verification": [
            "Publish an adjacent pair of valid promotions.",
            "Reject reversed, missing-offset and empty intervals."
          ],
          "deliverables": [
            "Publication date guard"
          ],
          "rollout": "Deploy guard for unpublished drafts; preserve existing published versions.",
          "skills": [
            "Validation",
            "Temporal rules"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "980cd226-b289-4740-a46d-d629c580c54e",
          "key": "ARULE-104",
          "title": "Freeze product and rule versions when a quote is accepted",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "quotes",
          "dependsOn": [
            "ARULE-102",
            "ARULE-103"
          ],
          "scenario": "A buyer accepts a quote after a promotion edit and receives a different total from the amount previously displayed.",
          "acceptanceCriteria": [
            "Accepted quotes retain product and rule version identities.",
            "Acceptance checks expiry and expected quote revision.",
            "Retries resolve one accepted quote with an unchanged total."
          ],
          "implementationNotes": [
            "Store a canonical calculation input hash with the quote."
          ],
          "verification": [
            "Accept a quote after changing current rules and retain its frozen total.",
            "Attempt acceptance after expiry and create no order."
          ],
          "deliverables": [
            "Quote acceptance command and frozen-input checks"
          ],
          "rollout": "Enable acceptance for synthetic accounts; suspend new acceptance while preserving accepted records.",
          "skills": [
            "Immutability",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7da5202d-9e8d-4340-9c2e-51b4a409328f",
          "key": "ARULE-105",
          "title": "Bound pricing work for a cart with many matching rules",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "quotes",
          "dependsOn": [
            "ARULE-102"
          ],
          "scenario": "An unusually broad rule set makes checkout evaluate thousands of predicates per item and blocks unrelated quotes.",
          "acceptanceCriteria": [
            "Set explicit cart, rule-count and predicate-work limits.",
            "Reject over-budget requests before partial quote publication.",
            "Return a bounded-work error distinct from invalid pricing."
          ],
          "implementationNotes": [
            "Choose limits from a repeatable local synthetic workload and document conditions."
          ],
          "verification": [
            "Measure work counters for 100 items and 200 rules.",
            "Exceed each limit and verify no accepted quote is created."
          ],
          "deliverables": [
            "Evaluation budget and reproducible workload"
          ],
          "rollout": "Canary limits in observation mode; lower admitted work or restore prior limits on regressions.",
          "skills": [
            "Resource budgets",
            "Complexity"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "2c465eeb-5e2e-4fcf-b8f6-3b4bfe110afc",
          "key": "ARULE-106",
          "title": "Keep negotiated account prices outside shared quote caches",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "quotes",
          "dependsOn": [
            "ARULE-104"
          ],
          "scenario": "A shared cache returns one customer's negotiated rate to another account requesting the same product list.",
          "acceptanceCriteria": [
            "Bind cache identity to organization, account and frozen price version.",
            "Authorize before cache lookup.",
            "Never cache an authorization failure as a valid quote."
          ],
          "implementationNotes": [
            "Include all price-affecting inputs in canonical cache keys."
          ],
          "verification": [
            "Quote identical carts for two negotiated-price accounts.",
            "Attempt cross-account access and inspect cache hits and response fields."
          ],
          "deliverables": [
            "Scoped cache key and isolation regression"
          ],
          "rollout": "Invalidate the affected namespace before enabling the new key format.",
          "skills": [
            "Caching",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e2ec3343-d95f-4070-87c6-12d2be14835c",
          "key": "ARULE-107",
          "title": "Report why a cart missed a promotion without leaking contract terms",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "quotes",
          "dependsOn": [
            "ARULE-102",
            "ARULE-106"
          ],
          "scenario": "Sales wants to explain an unmet minimum quantity, but the current debug endpoint exposes every account's price rules.",
          "acceptanceCriteria": [
            "Explain only rules visible to the requesting account.",
            "Show failed predicate names with permitted thresholds.",
            "Omit internal contract identifiers and unrelated rule matches."
          ],
          "implementationNotes": [
            "Build a dedicated explanation projection."
          ],
          "verification": [
            "Explain a visible minimum-quantity miss.",
            "Request explanation for an inaccessible contract and receive no rule details."
          ],
          "deliverables": [
            "Scoped pricing explanation endpoint"
          ],
          "rollout": "Enable the projection for one synthetic sales role; disable debug routes on disclosure failure.",
          "skills": [
            "Authorization",
            "Explainability"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3f224d0f-e9bb-496b-9882-6e58feeb71af",
          "key": "ARULE-108",
          "title": "Compare a draft pricing revision against a named quote corpus",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "release",
          "dependsOn": [
            "ARULE-104",
            "ARULE-107"
          ],
          "scenario": "A promotion revision fixes bulk orders but may unintentionally discount small carts.",
          "acceptanceCriteria": [
            "Create and version a synthetic quote corpus.",
            "Report old and new totals plus changed rule identities.",
            "Flag unexplained differences before publication."
          ],
          "implementationNotes": [
            "The corpus is authored for this exercise; do not claim production coverage."
          ],
          "verification": [
            "Include bulk, small-cart and no-match examples.",
            "Insert an invalid draft and report validation failure instead of a comparison."
          ],
          "deliverables": [
            "Revision comparison command and synthetic corpus"
          ],
          "rollout": "Require comparison review for draft publication; preserve earlier reports.",
          "skills": [
            "Regression analysis",
            "Tooling"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "938e3bdc-4687-4825-b8da-8afe19d99f9b",
          "key": "ARULE-109",
          "title": "Publish a pricing revision with optimistic review protection",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "release",
          "dependsOn": [
            "ARULE-103",
            "ARULE-108"
          ],
          "scenario": "A reviewer approves a draft while an editor changes its discount; publication currently activates content nobody reviewed.",
          "acceptanceCriteria": [
            "Approval binds the exact canonical draft hash.",
            "Publication rejects a changed draft or stale expected revision.",
            "Published rule content cannot be updated in place."
          ],
          "implementationNotes": [
            "Commit active-pointer selection and audit metadata together."
          ],
          "verification": [
            "Publish an unchanged approved draft.",
            "Edit between approval and publish and retain the previous active revision."
          ],
          "deliverables": [
            "Guarded publication command"
          ],
          "rollout": "Publish to synthetic accounts first; restore the prior active pointer without rewriting versions.",
          "skills": [
            "Optimistic concurrency",
            "Versioning"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "695efa2c-4a88-4623-8b0b-0d542ac45406",
          "key": "ARULE-110",
          "title": "Replay a pricing dispute from immutable quote inputs",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "release",
          "dependsOn": [
            "ARULE-104",
            "ARULE-109"
          ],
          "scenario": "Support receives a disputed total after three rule releases and cannot reproduce which calculation the buyer accepted.",
          "acceptanceCriteria": [
            "Replay selects the recorded evaluator and input versions.",
            "Report missing versions as unreproducible rather than guessing.",
            "Compare computed total and hash with the accepted record."
          ],
          "implementationNotes": [
            "Keep replay read-only and use fabricated customer data."
          ],
          "verification": [
            "Replay an accepted synthetic quote across later releases.",
            "Remove an available version in the test double and assert explicit failure."
          ],
          "deliverables": [
            "Read-only dispute replay and failure cases"
          ],
          "rollout": "Expose replay to scoped support users; revoke access if provenance cannot be resolved.",
          "skills": [
            "Reproducibility",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "bfc97100-c9a8-4478-a42d-c6ce2bc2c384",
      "key": "AINGEST",
      "title": "Recover a partner telemetry ingestion pipeline",
      "field": "Data engineering",
      "summary": "Ingest compressed telemetry with explicit quarantine, lineage and replay.",
      "context": "A fictional energy dashboard receives hourly device batches. Corrupt archives and late corrections leave operators unsure which readings reached reports.",
      "stack": [
        "Python",
        "PostgreSQL",
        "Object storage"
      ],
      "prerequisites": [
        "Create synthetic device batches and local object-store fixtures.",
        "Understand checksums and bounded streaming."
      ],
      "developerValue": "Practice batch integrity, replay and data-quality boundaries.",
      "companyValue": "Review whether operational data can be traced, corrected and recovered.",
      "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": "input",
          "title": "Validate batch boundaries",
          "goal": "Reject unsafe or ambiguous inputs before loading."
        },
        {
          "id": "load",
          "title": "Load traceable records",
          "goal": "Preserve lineage and deterministic corrections."
        },
        {
          "id": "recover",
          "title": "Recover ingestion gaps",
          "goal": "Reconcile committed batches and repair derived data."
        }
      ],
      "tickets": [
        {
          "id": "dbe4c1e7-0a39-4017-aa04-855a89b29bf0",
          "key": "AINGEST-101",
          "title": "Record a manifest before decoding a telemetry batch",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "input",
          "dependsOn": [],
          "scenario": "Operators see a failed file name but cannot identify the original bytes or the parser version used.",
          "acceptanceCriteria": [
            "Record object version, byte hash and declared format.",
            "Bind each ingestion attempt to one manifest.",
            "Reject a changed object version on retry."
          ],
          "implementationNotes": [
            "Use synthetic object metadata; avoid storing credentials in manifests."
          ],
          "verification": [
            "Retry unchanged bytes against the same manifest.",
            "Replace bytes under the same object key and report identity mismatch."
          ],
          "deliverables": [
            "Manifest schema and identity checks"
          ],
          "rollout": "Start manifests for new batches; retain earlier records as explicitly untracked.",
          "skills": [
            "Lineage",
            "Checksums"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1c4b8c6f-0a9e-49a6-a018-47666eb210a7",
          "key": "AINGEST-102",
          "title": "Cap decompressed telemetry bytes before archive expansion",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "input",
          "dependsOn": [
            "AINGEST-101"
          ],
          "scenario": "A tiny compressed batch expands far beyond the ingestion worker's memory budget.",
          "acceptanceCriteria": [
            "Enforce compressed, expanded-byte and row limits.",
            "Stop streaming as soon as a bound is crossed.",
            "Quarantine with a reason without loading partial rows."
          ],
          "implementationNotes": [
            "Do not unpack paths or execute files from archives."
          ],
          "verification": [
            "Ingest a valid compressed synthetic batch.",
            "Exercise excessive expansion and path-like entry names without writing outside staging."
          ],
          "deliverables": [
            "Bounded decoder and hostile archive fixtures"
          ],
          "rollout": "Enable bounded decoding before partner intake; keep rejected objects quarantined.",
          "skills": [
            "Streaming",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b5b1edec-a484-4f3b-bb4d-004abc509f0f",
          "key": "AINGEST-103",
          "title": "Normalize sensor units through a versioned conversion table",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "input",
          "dependsOn": [
            "AINGEST-101"
          ],
          "scenario": "Two device models emit watt-hours and kilowatt-hours under the same field name.",
          "acceptanceCriteria": [
            "Require a known unit and conversion version.",
            "Preserve raw numeric value and declared unit in lineage.",
            "Reject unsupported units and nonfinite measurements."
          ],
          "implementationNotes": [
            "Use decimal arithmetic for documented conversions."
          ],
          "verification": [
            "Convert synthetic Wh and kWh to equal canonical readings.",
            "Reject missing units and nonfinite input."
          ],
          "deliverables": [
            "Unit conversion contract and cases"
          ],
          "rollout": "Publish conversion revisions for new runs; retain old mappings for replay.",
          "skills": [
            "Data normalization",
            "Versioning"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8e01b627-5d45-47c7-95c0-883ccd390b12",
          "key": "AINGEST-104",
          "title": "Commit telemetry rows and the batch checkpoint atomically",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "load",
          "dependsOn": [
            "AINGEST-102",
            "AINGEST-103"
          ],
          "scenario": "A process dies after inserting rows but before marking the file complete; replay doubles reported usage.",
          "acceptanceCriteria": [
            "Persist rows and committed checkpoint in one transaction.",
            "Use source reading identity to reject duplicate insertion.",
            "Retries return committed counts without adding readings."
          ],
          "implementationNotes": [
            "Bound transaction size; larger batches require explicit sub-batch identities."
          ],
          "verification": [
            "Kill the test process at modeled commit boundaries.",
            "Replay a completed sub-batch and compare row counts and totals."
          ],
          "deliverables": [
            "Atomic batch loader and crash probe"
          ],
          "rollout": "Canary small batches; pause loading and inspect manifests if reconciliation diverges.",
          "skills": [
            "Transactions",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "9672c565-9395-4de8-be20-67bf9e01d74d",
          "key": "AINGEST-105",
          "title": "Quarantine malformed readings with usable row coordinates",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "load",
          "dependsOn": [
            "AINGEST-102",
            "AINGEST-103"
          ],
          "scenario": "A malformed timestamp makes the ingestion job fail with a stack trace and no indication of the source row.",
          "acceptanceCriteria": [
            "Report manifest ID, row number and stable reason code.",
            "Keep rejected values out of generic logs.",
            "Publish accepted and rejected counts under the declared partial-load policy."
          ],
          "implementationNotes": [
            "Choose and document all-or-nothing versus row quarantine for this dataset."
          ],
          "verification": [
            "Load a batch containing valid rows under the chosen policy.",
            "Insert malformed timestamps and verify coordinates and count invariants."
          ],
          "deliverables": [
            "Quarantine report and policy tests"
          ],
          "rollout": "Enable reports before changing load policy; replay corrected manifests as new attempts.",
          "skills": [
            "Data quality",
            "Error reporting"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "28a89991-18da-45dd-adf5-cb036ab83a8c",
          "key": "AINGEST-106",
          "title": "Apply corrected readings without overwriting source history",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "load",
          "dependsOn": [
            "AINGEST-104",
            "AINGEST-105"
          ],
          "scenario": "A device sends a corrected cumulative reading two days late; a blind upsert destroys the value used in yesterday's report.",
          "acceptanceCriteria": [
            "Append corrections linked to source reading and revision.",
            "Define the effective reading deterministically.",
            "Reject contradictory equal-revision corrections for review."
          ],
          "implementationNotes": [
            "Preserve original ingestion time separately from measurement time."
          ],
          "verification": [
            "Apply a higher revision and inspect both historical values.",
            "Submit equal revision with changed value and retain the last valid projection."
          ],
          "deliverables": [
            "Correction model and conflict cases"
          ],
          "rollout": "Enable corrections for one synthetic device; rebuild projections from retained history on rollback.",
          "skills": [
            "Temporal data",
            "Append-only design"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "888265ca-96f7-436b-9a1d-ccd6c538ecd4",
          "key": "AINGEST-107",
          "title": "Use event-time watermarks without discarding late telemetry silently",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "load",
          "dependsOn": [
            "AINGEST-106"
          ],
          "scenario": "The hourly aggregate closes by arrival time and quietly ignores a delayed batch from an offline device.",
          "acceptanceCriteria": [
            "Define watermark advancement and allowed lateness.",
            "Route late readings to a visible correction path.",
            "Report aggregate revision when late data changes a result."
          ],
          "implementationNotes": [
            "Test with a controlled clock and explicit event timestamps."
          ],
          "verification": [
            "Deliver an in-window late reading and update the expected aggregate.",
            "Deliver beyond the lateness window and verify visible deferred correction."
          ],
          "deliverables": [
            "Watermark logic and late-arrival fixtures"
          ],
          "rollout": "Run alongside the prior aggregate; switch readers only after discrepancy review.",
          "skills": [
            "Event time",
            "Aggregation"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b4d16852-2af9-4ddc-805b-c11703ae73cc",
          "key": "AINGEST-108",
          "title": "Reconcile uploaded telemetry manifests against committed checkpoints",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "AINGEST-104",
            "AINGEST-107"
          ],
          "scenario": "Object storage contains yesterday's batches, but dashboard totals are low and no worker currently owns the missing jobs.",
          "acceptanceCriteria": [
            "List missing, pending and committed manifests by bounded window.",
            "Schedule replay only for eligible uncommitted identities.",
            "Make repeated reconciliation produce no duplicate committed data."
          ],
          "implementationNotes": [
            "Require explicit organization and time bounds."
          ],
          "verification": [
            "Find a synthetic uploaded batch without a checkpoint.",
            "Rerun reconciliation after commit and schedule nothing additional."
          ],
          "deliverables": [
            "Manifest reconciler and bounded replay command"
          ],
          "rollout": "Dry-run first; stop replay dispatch while preserving the discrepancy report.",
          "skills": [
            "Reconciliation",
            "Operations"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "01df221c-4c69-4a4b-9911-f61f1a45f241",
          "key": "AINGEST-109",
          "title": "Verify a telemetry backfill against immutable aggregate snapshots",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "recover",
          "dependsOn": [
            "AINGEST-106",
            "AINGEST-107",
            "AINGEST-108"
          ],
          "scenario": "A conversion fix requires rebuilding a week of energy totals without obscuring what the previous dashboard showed.",
          "acceptanceCriteria": [
            "Build a new aggregate generation from named manifests.",
            "Compare counts, units and totals against frozen previous output.",
            "Atomically select the generation only after review."
          ],
          "implementationNotes": [
            "Use a synthetic seven-day corpus with declared correction cases."
          ],
          "verification": [
            "Backfill the corpus and reconcile every changed aggregate.",
            "Interrupt before activation and keep previous dashboard reads consistent."
          ],
          "deliverables": [
            "Backfill runner and generation difference report"
          ],
          "rollout": "Activate one synthetic tenant; restore the old generation pointer on discrepancy.",
          "skills": [
            "Backfills",
            "Data reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fbd82c12-737c-45fa-9646-d863e0dc4d19",
          "key": "AINGEST-110",
          "title": "Add an ingestion freshness report that distinguishes missing data from zero",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "recover",
          "dependsOn": [
            "AINGEST-108",
            "AINGEST-109"
          ],
          "scenario": "A site with no recent readings is displayed as consuming zero energy, misleading dashboard consumers.",
          "acceptanceCriteria": [
            "Show last event time and last committed arrival separately.",
            "Represent missing intervals as unknown rather than numeric zero.",
            "Define stale thresholds from a documented expected schedule."
          ],
          "implementationNotes": [
            "Do not claim zero consumption without a reading."
          ],
          "verification": [
            "Report a genuine zero reading as zero.",
            "Remove a scheduled batch and show unknown with stale status."
          ],
          "deliverables": [
            "Freshness projection and missing-data cases"
          ],
          "rollout": "Introduce freshness beside existing totals; revert display wiring while preserving unknown semantics.",
          "skills": [
            "Data semantics",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "95589e41-9d4d-454a-be77-5bb342933b1a",
      "key": "ADBT",
      "title": "Make a subscription analytics mart reproducible",
      "field": "Data engineering",
      "summary": "Model subscription movement with explicit grains, revisions and data contracts.",
      "context": "A fictional SaaS analyst reports expansion revenue differently from finance because snapshots, refunds and contract changes are joined at incompatible grains.",
      "stack": [
        "SQL",
        "PostgreSQL",
        "dbt"
      ],
      "prerequisites": [
        "Create a synthetic source schema and local transformation project.",
        "Use integer minor units and distinct reporting currencies."
      ],
      "developerValue": "Practice analytical modeling and explainable transformation contracts.",
      "companyValue": "Review trustworthy reporting definitions and the cost of correcting historical reports.",
      "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": "grain",
          "title": "Define reporting grain",
          "goal": "Specify source and metric contracts."
        },
        {
          "id": "model",
          "title": "Transform consistently",
          "goal": "Handle temporal joins and incremental updates."
        },
        {
          "id": "publish",
          "title": "Publish reliable outputs",
          "goal": "Validate releases and retain reproducible reports."
        }
      ],
      "tickets": [
        {
          "id": "013961bd-b99a-4f3d-bfa2-33a6e7cdf4a7",
          "key": "ADBT-101",
          "title": "Declare the subscription-movement grain before joining invoice lines",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "grain",
          "dependsOn": [],
          "scenario": "A report doubles subscription movement when a contract has two invoice lines in the same month.",
          "acceptanceCriteria": [
            "Document one row per subscription, period and currency.",
            "Identify source keys and permitted multiplicity.",
            "Reject duplicate grain keys in a contract check."
          ],
          "implementationNotes": [
            "Create a small synthetic multi-line invoice example."
          ],
          "verification": [
            "Reconcile a two-line invoice to one movement row.",
            "Insert duplicate source identity and fail the grain check."
          ],
          "deliverables": [
            "Grain specification and executable uniqueness check"
          ],
          "rollout": "Review the grain contract before enabling downstream joins.",
          "skills": [
            "Dimensional modeling",
            "SQL"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2865613f-3f76-4cf8-8d87-0f39a76e326b",
          "key": "ADBT-102",
          "title": "Separate recurring contract value from collected cash",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "grain",
          "dependsOn": [
            "ADBT-101"
          ],
          "scenario": "A late payment makes the recurring-revenue chart dip even though no subscription changed.",
          "acceptanceCriteria": [
            "Define contract value and cash collection as separate measures.",
            "Document refund and unpaid-invoice treatment.",
            "Keep currency amounts separate without implicit conversion."
          ],
          "implementationNotes": [
            "Use named business definitions in model metadata."
          ],
          "verification": [
            "Delay a payment and keep contracted recurring value unchanged.",
            "Mix currencies and reject an unsupported combined total."
          ],
          "deliverables": [
            "Metric definitions and contrasting examples"
          ],
          "rollout": "Publish separate metric names; retire ambiguous aliases after consumer review.",
          "skills": [
            "Metric design",
            "Data semantics"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "eba6f358-5964-4f77-aa0b-1cd401b174bf",
          "key": "ADBT-103",
          "title": "Reject source schema drift before materializing the mart",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "grain",
          "dependsOn": [
            "ADBT-101"
          ],
          "scenario": "A partner renamed subscription_id and the daily transformation published an empty table successfully.",
          "acceptanceCriteria": [
            "Validate required columns and accepted types.",
            "Fail before replacing the active reporting relation.",
            "Report the missing contract field and source version."
          ],
          "implementationNotes": [
            "Avoid relying on a row-count check alone."
          ],
          "verification": [
            "Transform a valid empty source under its declared contract.",
            "Rename a required column and retain the previous active mart."
          ],
          "deliverables": [
            "Source contract gate"
          ],
          "rollout": "Run the contract gate before scheduled builds; keep prior output on failure.",
          "skills": [
            "Data contracts",
            "Schema evolution"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bdbaa9d0-ed51-494f-aca8-95b33de1a1e9",
          "key": "ADBT-104",
          "title": "Join customer segments as of the revenue event date",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "model",
          "dependsOn": [
            "ADBT-101",
            "ADBT-102"
          ],
          "scenario": "Historical enterprise revenue changes whenever sales updates a customer's current segment.",
          "acceptanceCriteria": [
            "Use valid-time segment intervals for the event date.",
            "Detect overlapping or missing segment intervals explicitly.",
            "Preserve the event's original reporting currency."
          ],
          "implementationNotes": [
            "Do not fill missing historical segments with the current value."
          ],
          "verification": [
            "Change today's segment and keep prior periods unchanged.",
            "Create overlapping segment periods and fail the temporal join check."
          ],
          "deliverables": [
            "As-of join model and interval assertions"
          ],
          "rollout": "Build a comparison table; switch readers after historical differences are reviewed.",
          "skills": [
            "Temporal joins",
            "Slowly changing dimensions"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bea3352f-a9dc-4d3e-b915-e1620ea4ae57",
          "key": "ADBT-105",
          "title": "Make incremental movement loads include revised source rows",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "model",
          "dependsOn": [
            "ADBT-103",
            "ADBT-104"
          ],
          "scenario": "The incremental model filters only creation time, so a corrected subscription end date never reaches the mart.",
          "acceptanceCriteria": [
            "Track source revision or updated watermark with tie breaking.",
            "Recompute affected grain keys deterministically.",
            "Commit the output and checkpoint consistently."
          ],
          "implementationNotes": [
            "Document how deletions and corrections identify affected periods."
          ],
          "verification": [
            "Correct a prior end date and update the affected month.",
            "Retry after an interrupted run and avoid duplicate movement rows."
          ],
          "deliverables": [
            "Revision-aware incremental model"
          ],
          "rollout": "Shadow full and incremental builds on a synthetic corpus; fall back to full rebuild if they diverge.",
          "skills": [
            "Incremental processing",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "eeacfd9e-d873-4af7-a9d6-cb76876f64d6",
          "key": "ADBT-106",
          "title": "Represent cancelled subscriptions as movements instead of deleting them",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "ADBT-102",
            "ADBT-105"
          ],
          "scenario": "Deleting a cancelled subscription from the source erases the churn event from the report.",
          "acceptanceCriteria": [
            "Retain cancellation effective date and source tombstone lineage.",
            "Emit one cancellation movement per effective revision.",
            "Expose unavailable source history as incomplete reporting."
          ],
          "implementationNotes": [
            "Use synthetic deletion events rather than recovering private backups."
          ],
          "verification": [
            "Apply a cancellation tombstone and retain its churn movement.",
            "Replay the tombstone and verify no double cancellation."
          ],
          "deliverables": [
            "Tombstone handling and movement fixtures"
          ],
          "rollout": "Enable tombstone capture before source deletion; halt destructive cleanup if lineage is missing.",
          "skills": [
            "Change data",
            "Lineage"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "422184d7-8cc3-4b69-84d7-5654c9ef073a",
          "key": "ADBT-107",
          "title": "Detect fan-out before publishing account-level revenue totals",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "model",
          "dependsOn": [
            "ADBT-104",
            "ADBT-105",
            "ADBT-106"
          ],
          "scenario": "A new feature joins account tags to movement rows and inflates revenue for accounts with multiple tags.",
          "acceptanceCriteria": [
            "Assert row and amount conservation across the join.",
            "Define tag allocation or a nonduplicating existence filter.",
            "Fail publication when conservation fails."
          ],
          "implementationNotes": [
            "Keep tag-level attribution distinct from account-level totals."
          ],
          "verification": [
            "Add two tags to an account and preserve its revenue total.",
            "Use the naive many-to-many join in a regression and detect inflation."
          ],
          "deliverables": [
            "Fan-out guard and corrected account model"
          ],
          "rollout": "Canary the model in a separate schema; restore prior view selection on failed conservation.",
          "skills": [
            "Join cardinality",
            "Data invariants"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "87aed20b-94d9-4594-af20-14c3712a55d9",
          "key": "ADBT-108",
          "title": "Generate a report manifest with exact model and source revisions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "publish",
          "dependsOn": [
            "ADBT-105",
            "ADBT-107"
          ],
          "scenario": "An analyst sends a CSV to finance and later cannot identify which transformation commit or source cutoff produced it.",
          "acceptanceCriteria": [
            "Include model commit, source checkpoints and generated UTC time.",
            "Hash exported bytes and preserve a report identity.",
            "Exclude credentials and raw customer fields from the manifest."
          ],
          "implementationNotes": [
            "Keep the manifest next to synthetic exports."
          ],
          "verification": [
            "Regenerate the same named inputs and compare content hashes.",
            "Change a source revision and receive a distinct manifest."
          ],
          "deliverables": [
            "Report manifest and reproducibility command"
          ],
          "rollout": "Attach manifests to new reports; label earlier exports as lacking lineage.",
          "skills": [
            "Provenance",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 80
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "89ae0367-f0d8-4ff7-b2bb-ec4d82f4c7f6",
          "key": "ADBT-109",
          "title": "Prove an incremental mart matches a full refresh after corrections",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "publish",
          "dependsOn": [
            "ADBT-106",
            "ADBT-107",
            "ADBT-108"
          ],
          "scenario": "The team wants to reduce daily build cost but needs confidence that incremental state does not drift after late corrections.",
          "acceptanceCriteria": [
            "Author a sequence of inserts, revisions and tombstones.",
            "Compare every grain key and measure to a full refresh.",
            "Report extra, missing and changed rows separately."
          ],
          "implementationNotes": [
            "Run both paths against the same immutable synthetic inputs."
          ],
          "verification": [
            "Replay the complete change sequence with equal final outputs.",
            "Skip one revision intentionally and verify a precise discrepancy report."
          ],
          "deliverables": [
            "Differential transformation harness"
          ],
          "rollout": "Require a clean differential run before changing schedule; revert to full refresh on mismatch.",
          "skills": [
            "Differential testing",
            "Data reliability"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "8e810bb2-2ec7-46cb-994c-69592059ac28",
          "key": "ADBT-110",
          "title": "Write the analytics incident handoff for an unexplained revenue shift",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "publish",
          "dependsOn": [
            "ADBT-108",
            "ADBT-109"
          ],
          "scenario": "A report moves after a release and on-call staff cannot tell a genuine source correction from a transformation regression.",
          "acceptanceCriteria": [
            "Start investigation from report manifests and affected grain keys.",
            "Separate source, definition and implementation changes.",
            "Include restore-view and corrected-export procedures."
          ],
          "implementationNotes": [
            "Use a fabricated incident with no real financial assertions."
          ],
          "verification": [
            "Trace one legitimate correction through source lineage.",
            "Trace a fan-out regression and restore the prior reporting view."
          ],
          "deliverables": [
            "Analytics incident runbook"
          ],
          "rollout": "Validate the runbook with local reports; version it with model publication.",
          "skills": [
            "Incident response",
            "Data lineage"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "c502b2f2-cff3-432b-858c-1daa41526fe9",
      "key": "ACDC",
      "title": "Move customer preferences through a durable change feed",
      "field": "Data engineering",
      "summary": "Replicate a bounded preference dataset while preserving deletion and ordering semantics.",
      "context": "A fictional messaging service builds a read model from database changes. Restarts and schema changes can re-enable preferences that customers disabled.",
      "stack": [
        "PostgreSQL",
        "TypeScript",
        "Object storage"
      ],
      "prerequisites": [
        "Create synthetic preference records and a replayable local change log.",
        "Use adapters or fixtures without provisioning a production broker."
      ],
      "developerValue": "Practice change-feed ordering, snapshots and privacy-preserving deletion.",
      "companyValue": "Review whether replicated customer preferences remain correct during recovery.",
      "delivery": "Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup.",
      "phases": [
        {
          "id": "feed",
          "title": "Specify the change contract",
          "goal": "Identify ordering, identities and deletions."
        },
        {
          "id": "replica",
          "title": "Build the projection",
          "goal": "Handle duplicates, schema changes and snapshot handoff."
        },
        {
          "id": "repair",
          "title": "Repair feed gaps",
          "goal": "Detect divergence and recover scoped replicas."
        }
      ],
      "tickets": [
        {
          "id": "81e372c8-d8fc-49f7-ba62-0d0e4fe4332e",
          "key": "ACDC-101",
          "title": "Define the preference change envelope with source position",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "feed",
          "dependsOn": [],
          "scenario": "The consumer sees a timestamp and payload but cannot distinguish two changes committed in the same millisecond.",
          "acceptanceCriteria": [
            "Include stable source position, record identity and operation.",
            "Separate source commit time from consumer receipt time.",
            "Validate the envelope version before applying changes."
          ],
          "implementationNotes": [
            "Use fabricated positions from a deterministic local log."
          ],
          "verification": [
            "Parse two same-time changes with distinct positions.",
            "Reject an unknown envelope version without moving the checkpoint."
          ],
          "deliverables": [
            "Change envelope schema"
          ],
          "rollout": "Publish the contract before consumer rollout; quarantine unsupported versions.",
          "skills": [
            "Data contracts",
            "Ordering"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 20
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "51c976e2-0df0-4285-87a0-e8df9dfa3106",
          "key": "ACDC-102",
          "title": "Redact preference change diagnostics without losing traceability",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "feed",
          "dependsOn": [
            "ACDC-101"
          ],
          "scenario": "Malformed preference payloads are dumped into generic logs with email addresses and free-text notes.",
          "acceptanceCriteria": [
            "Log source position, safe record token and reason code.",
            "Exclude contact details and raw payload bodies.",
            "Retain restricted diagnostic access only through a scoped fixture store."
          ],
          "implementationNotes": [
            "Use synthetic contact data in disclosure tests."
          ],
          "verification": [
            "Locate a rejected envelope through its safe identifiers.",
            "Inject contact fields and assert they never appear in generic logs."
          ],
          "deliverables": [
            "Sanitized diagnostics and disclosure checks"
          ],
          "rollout": "Deploy redaction before replay; restrict access to older diagnostic output.",
          "skills": [
            "Privacy",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f0c28953-2ab2-4eca-9a51-45343b9863dc",
          "key": "ACDC-103",
          "title": "Represent preference deletion as a durable tombstone",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "feed",
          "dependsOn": [
            "ACDC-101"
          ],
          "scenario": "A deleted record disappears from the source snapshot but remains enabled in a downstream projection indefinitely.",
          "acceptanceCriteria": [
            "Define tombstones with identity and source position.",
            "Retain enough ordering metadata to reject stale recreation.",
            "Separate deletion from a false preference value."
          ],
          "implementationNotes": [
            "Document retention assumptions for replayable tombstones."
          ],
          "verification": [
            "Apply deletion and verify the projected record is absent.",
            "Replay an older enable event and keep the record deleted."
          ],
          "deliverables": [
            "Tombstone contract and ordering cases"
          ],
          "rollout": "Enable tombstone production before cleanup; stop purging if replay coverage is uncertain.",
          "skills": [
            "Deletion semantics",
            "Change data"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ba4cda6b-197b-4e8f-9aa4-e4f658e3317c",
          "key": "ACDC-104",
          "title": "Advance the feed checkpoint only with the projected transaction",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "replica",
          "dependsOn": [
            "ACDC-101",
            "ACDC-103"
          ],
          "scenario": "The consumer acknowledges a change before updating the read model; a crash permanently loses the disabled preference.",
          "acceptanceCriteria": [
            "Apply projection and checkpoint in one durable transaction.",
            "Duplicate delivery is a no-op at the same position.",
            "Failed application leaves the previous checkpoint intact."
          ],
          "implementationNotes": [
            "Scope checkpoints to source partition and consumer generation."
          ],
          "verification": [
            "Replay a committed change and keep one result.",
            "Fail between modeled projection and checkpoint writes and retry successfully."
          ],
          "deliverables": [
            "Transactional consumer and interruption test"
          ],
          "rollout": "Canary one synthetic partition; stop consumption on checkpoint divergence.",
          "skills": [
            "Transactions",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "8f5ef06b-f68e-4104-91e2-1b39a5b070f6",
          "key": "ACDC-105",
          "title": "Reject a stale preference update after a partition retry",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "replica",
          "dependsOn": [
            "ACDC-104"
          ],
          "scenario": "A retry queue delivers an old enable event after a newer disable event has already committed.",
          "acceptanceCriteria": [
            "Compare per-record source ordering before mutation.",
            "Retain stale-delivery counters without changing state.",
            "Treat equal position with different content as a conflict."
          ],
          "implementationNotes": [
            "Do not use consumer wall time to resolve ordering."
          ],
          "verification": [
            "Deliver disable before an older enable and retain disabled.",
            "Send contradictory equal-position data and quarantine the conflict."
          ],
          "deliverables": [
            "Per-record ordering guard"
          ],
          "rollout": "Observe stale counts during canary; pause conflicting partitions instead of guessing order.",
          "skills": [
            "Event ordering",
            "Conflict handling"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "30271801-6be0-471d-8fa8-532e6216ddfb",
          "key": "ACDC-106",
          "title": "Handoff a preference snapshot to live changes without a gap",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "replica",
          "dependsOn": [
            "ACDC-104",
            "ACDC-105"
          ],
          "scenario": "A new replica loads a snapshot while preferences continue changing, leaving a gap between export time and stream start.",
          "acceptanceCriteria": [
            "Record an explicit snapshot boundary position.",
            "Buffer or replay changes after the boundary before activation.",
            "Keep the new generation unavailable until catch-up is complete."
          ],
          "implementationNotes": [
            "Document source guarantees needed for a consistent boundary."
          ],
          "verification": [
            "Change a preference during snapshot loading and reach final source state.",
            "Interrupt catch-up and verify readers still use the previous generation."
          ],
          "deliverables": [
            "Snapshot handoff protocol and executable timeline"
          ],
          "rollout": "Build a shadow generation; restore the previous pointer if catch-up checks fail.",
          "skills": [
            "Snapshot consistency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "42019ae5-ec7d-4c68-a4b5-94eeac29eb25",
          "key": "ACDC-107",
          "title": "Evolve a preference value enum without silently coercing unknown values",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "replica",
          "dependsOn": [
            "ACDC-101",
            "ACDC-106"
          ],
          "scenario": "A new source value called paused is mapped to enabled by the old consumer's default branch.",
          "acceptanceCriteria": [
            "Use an explicit compatibility map for each envelope version.",
            "Unknown values enter quarantine without checkpoint loss.",
            "Document how a compatible consumer resumes blocked input."
          ],
          "implementationNotes": [
            "Avoid treating missing values as an affirmative preference."
          ],
          "verification": [
            "Apply known values under both supported versions.",
            "Deliver paused to an incompatible consumer and verify no enable write."
          ],
          "deliverables": [
            "Version compatibility matrix and consumer guard"
          ],
          "rollout": "Deploy compatible readers before writers; retain queued unsupported changes for replay.",
          "skills": [
            "Schema evolution",
            "Fail-closed handling"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "90e815c7-d1c8-4629-8802-a2c5acbbb460",
          "key": "ACDC-108",
          "title": "Compare source and replica preferences without exporting contacts",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "repair",
          "dependsOn": [
            "ACDC-106",
            "ACDC-107"
          ],
          "scenario": "Operators suspect a gap but a full data export would spread contact information across incident tooling.",
          "acceptanceCriteria": [
            "Compare keyed hashes and safe row counts by bounded scope.",
            "Report missing, extra and mismatched record tokens.",
            "Keep raw preference payloads out of the report."
          ],
          "implementationNotes": [
            "Use stable canonical hashing and documented null handling."
          ],
          "verification": [
            "Compare equal synthetic source and replica states.",
            "Alter one value and delete one row; identify both discrepancy categories."
          ],
          "deliverables": [
            "Scoped reconciliation report"
          ],
          "rollout": "Run read-only reconciliation first; expire generated diagnostic artifacts after review.",
          "skills": [
            "Reconciliation",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4bf42677-4979-442a-bc68-edf6bb5e2584",
          "key": "ACDC-109",
          "title": "Repair one preference partition while continuing unrelated reads",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "repair",
          "dependsOn": [
            "ACDC-106",
            "ACDC-108"
          ],
          "scenario": "One replica partition is corrupted; rebuilding the entire preference service would unnecessarily interrupt all accounts.",
          "acceptanceCriteria": [
            "Rebuild only the selected source scope into a new generation.",
            "Catch up from the recorded boundary before pointer swap.",
            "Prevent repaired and old generations from mixing in one scoped read."
          ],
          "implementationNotes": [
            "Require a dry-run plan and explicit partition identity."
          ],
          "verification": [
            "Repair a synthetic partition and preserve unrelated output hashes.",
            "Interrupt before swap and retain complete reads from the old generation."
          ],
          "deliverables": [
            "Partition repair command and atomic-read probe"
          ],
          "rollout": "Canary repair on a synthetic scope; switch its pointer back if reconciliation fails.",
          "skills": [
            "Scoped recovery",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3132975b-e0dd-4d83-b9e1-fbf264c0ad6c",
          "key": "ACDC-110",
          "title": "Expose replica freshness with a trustworthy unknown state",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "repair",
          "dependsOn": [
            "ACDC-108",
            "ACDC-109"
          ],
          "scenario": "The dashboard marks a replica healthy when its consumer is running even though no source checkpoint has been observed.",
          "acceptanceCriteria": [
            "Show applied source position and receipt lag separately.",
            "Report unknown when no comparable source watermark exists.",
            "Define stale thresholds in the local operating contract."
          ],
          "implementationNotes": [
            "Never infer source completeness from process liveness."
          ],
          "verification": [
            "Advance source and replica positions and calculate the documented lag.",
            "Remove the source watermark and return unknown health."
          ],
          "deliverables": [
            "Freshness endpoint and unknown-state cases"
          ],
          "rollout": "Add freshness as advisory status first; restore the prior view while preserving unknown semantics.",
          "skills": [
            "Observability",
            "Data semantics"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ee9b7116-54b1-444c-b503-3e7ca805c2ad",
      "key": "ACONFIG",
      "title": "Release configuration without restarting every service",
      "field": "Platform engineering",
      "summary": "Validate, version and distribute runtime configuration with bounded staleness.",
      "context": "A fictional internal reporting platform changes feature and timeout settings through environment edits. Partial rollouts leave API and worker processes interpreting different values.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create local API and worker configuration consumers.",
        "Use fabricated settings without secrets."
      ],
      "developerValue": "Practice configuration contracts, compatibility and failure recovery.",
      "companyValue": "Review controlled configuration delivery with inspectable blast radius.",
      "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": "schema",
          "title": "Make settings explicit",
          "goal": "Define typed settings and safe defaults."
        },
        {
          "id": "release",
          "title": "Distribute revisions",
          "goal": "Publish compatible snapshots and control adoption."
        },
        {
          "id": "operate",
          "title": "Handle stale consumers",
          "goal": "Observe adoption and recover rejected changes."
        }
      ],
      "tickets": [
        {
          "id": "b2ad83b8-66fd-41cb-b6bc-211d129915f4",
          "key": "ACONFIG-101",
          "title": "Inventory runtime settings with owners and restart requirements",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "schema",
          "dependsOn": [],
          "scenario": "Operators cannot tell whether changing a timeout requires a worker restart or takes effect on the next request.",
          "acceptanceCriteria": [
            "List type, owner, default and adoption boundary for each setting.",
            "Separate secrets from nonsecret runtime configuration.",
            "Mark unknown behavior as unresolved before rollout."
          ],
          "implementationNotes": [
            "Use a small fictional inventory of eight settings."
          ],
          "verification": [
            "Trace one dynamic setting through its read boundary.",
            "Identify a startup-only setting and prevent a dynamic edit."
          ],
          "deliverables": [
            "Configuration inventory and adoption contract"
          ],
          "rollout": "Review the inventory before exposing edits; keep unresolved settings read-only.",
          "skills": [
            "Configuration management",
            "Technical documentation"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c4fd64b5-2baf-40ca-9f03-f13c8cdba256",
          "key": "ACONFIG-102",
          "title": "Reject invalid timeout combinations as one configuration unit",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "schema",
          "dependsOn": [
            "ACONFIG-101"
          ],
          "scenario": "A retry timeout exceeds the entire request deadline, causing requests to continue working after callers have disconnected.",
          "acceptanceCriteria": [
            "Validate relationships between attempt, retry and total deadlines.",
            "Reject the complete candidate snapshot on any invalid relation.",
            "Return field paths with safe values only."
          ],
          "implementationNotes": [
            "Use explicit duration units; reject implicit unit conversion."
          ],
          "verification": [
            "Accept a documented valid retry budget.",
            "Reject a larger attempt timeout than total deadline without changing active settings."
          ],
          "deliverables": [
            "Snapshot validator and deadline fixtures"
          ],
          "rollout": "Add validation to drafts; preserve the active snapshot on any rejection.",
          "skills": [
            "Validation",
            "Deadline budgets"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "43ea31c9-9a97-4843-b404-92d91b6e0785",
          "key": "ACONFIG-103",
          "title": "Define an immutable configuration snapshot envelope",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "schema",
          "dependsOn": [
            "ACONFIG-101",
            "ACONFIG-102"
          ],
          "scenario": "A config endpoint returns a mutable object with no revision, so incident reports cannot establish which settings were read.",
          "acceptanceCriteria": [
            "Include revision, canonical hash and schema version.",
            "Published snapshot content cannot be edited in place.",
            "Exclude secret material from serialization and logs."
          ],
          "implementationNotes": [
            "Use opaque IDs and UTC publication metadata."
          ],
          "verification": [
            "Read the same revision twice and compare hashes.",
            "Attempt an in-place edit and reject it."
          ],
          "deliverables": [
            "Snapshot contract and immutability checks"
          ],
          "rollout": "Start versioned publication alongside legacy reads; retain published revisions for recovery.",
          "skills": [
            "Versioning",
            "Immutability"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "f89ccbe1-05bf-466a-ad17-c37957288310",
          "key": "ACONFIG-104",
          "title": "Atomically adopt a validated configuration snapshot in each process",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "release",
          "dependsOn": [
            "ACONFIG-103"
          ],
          "scenario": "A process updates settings one field at a time, briefly combining a new retry count with an old deadline.",
          "acceptanceCriteria": [
            "Validate the full snapshot before replacing the active reference.",
            "Each request captures one revision for its lifetime.",
            "Failed adoption retains the complete previous snapshot."
          ],
          "implementationNotes": [
            "Avoid mutating shared configuration objects after publication."
          ],
          "verification": [
            "Switch snapshots during requests and observe one revision per request.",
            "Reject one invalid field and retain every previous value."
          ],
          "deliverables": [
            "Atomic consumer adapter and concurrent-read probe"
          ],
          "rollout": "Canary a local worker consumer; pin its previous revision if adoption fails.",
          "skills": [
            "Concurrency",
            "Configuration delivery"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4f55c0ae-868b-4426-a23c-655dd5904323",
          "key": "ACONFIG-105",
          "title": "Publish configuration only against the revision reviewed by the operator",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "release",
          "dependsOn": [
            "ACONFIG-103",
            "ACONFIG-104"
          ],
          "scenario": "Two operators edit the same draft; the last publisher activates changes based on a stale review.",
          "acceptanceCriteria": [
            "Require expected draft revision and reviewed hash.",
            "Commit publication and active selection together.",
            "Return a conflict with safe revision metadata on stale publication."
          ],
          "implementationNotes": [
            "Record actor and reason in an append-only audit record."
          ],
          "verification": [
            "Publish an unchanged reviewed snapshot.",
            "Race two publishers and assert one accepted active transition."
          ],
          "deliverables": [
            "Optimistic publication command and race test"
          ],
          "rollout": "Enable publication for a synthetic operator role; disable writes if audit persistence fails.",
          "skills": [
            "Optimistic concurrency",
            "Audit logs"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "17994255-b8c0-4be6-844f-b7a92cfc1ea3",
          "key": "ACONFIG-106",
          "title": "Keep incompatible consumers on their last valid configuration",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "release",
          "dependsOn": [
            "ACONFIG-104",
            "ACONFIG-105"
          ],
          "scenario": "A new configuration schema reaches an older worker that silently ignores a field needed to preserve retry limits.",
          "acceptanceCriteria": [
            "Consumers declare accepted schema versions.",
            "Incompatible snapshots are rejected with explicit adoption status.",
            "Critical missing configuration fails closed under the documented startup policy."
          ],
          "implementationNotes": [
            "Do not coerce unknown versions into the current schema."
          ],
          "verification": [
            "Adopt compatible settings in old and new local consumers.",
            "Send a new unsupported schema and preserve the old snapshot or fail startup as declared."
          ],
          "deliverables": [
            "Compatibility handshake and failure matrix"
          ],
          "rollout": "Deploy compatible readers before publishing new schema; repoint to the older supported revision if needed.",
          "skills": [
            "Compatibility",
            "Fail-closed design"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1706ef70-de4b-4861-a799-1671f55d4738",
          "key": "ACONFIG-107",
          "title": "Stage a timeout revision for a named consumer cohort",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "release",
          "dependsOn": [
            "ACONFIG-105",
            "ACONFIG-106"
          ],
          "scenario": "The team wants to test a timeout change on background reports before affecting interactive requests.",
          "acceptanceCriteria": [
            "Bind cohort selection to stable nonpersonal service identity.",
            "Show intended and acknowledged revision per cohort.",
            "Unselected consumers retain their current target revision."
          ],
          "implementationNotes": [
            "Use deterministic synthetic cohort membership."
          ],
          "verification": [
            "Adopt a revision in the report-worker cohort only.",
            "Use an unknown cohort and reject publication without target changes."
          ],
          "deliverables": [
            "Cohort rollout command and targeting cases"
          ],
          "rollout": "Begin with one synthetic cohort; restore its previous target revision on errors.",
          "skills": [
            "Progressive delivery",
            "Targeting"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "56898142-45ed-46bf-9614-6a87b75bb333",
          "key": "ACONFIG-108",
          "title": "Report configuration staleness separately from application health",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "operate",
          "dependsOn": [
            "ACONFIG-106",
            "ACONFIG-107"
          ],
          "scenario": "A healthy process missed several configuration polls, but a green liveness check hides that it is running stale limits.",
          "acceptanceCriteria": [
            "Expose active and target revision plus last successful poll time.",
            "Distinguish stale, incompatible and unavailable states.",
            "Avoid including configuration values in generic health payloads."
          ],
          "implementationNotes": [
            "Use a fake clock for staleness boundaries."
          ],
          "verification": [
            "Advance target while a consumer stays behind and report stale.",
            "Lose the configuration endpoint and keep the declared last-known-good behavior visible."
          ],
          "deliverables": [
            "Adoption status projection"
          ],
          "rollout": "Add the status endpoint before alerts; disable noisy alerts without hiding adoption state.",
          "skills": [
            "Observability",
            "Health semantics"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0983f778-385e-4435-a52d-d62bab50a5e7",
          "key": "ACONFIG-109",
          "title": "Rollback configuration by selecting a prior immutable snapshot",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "ACONFIG-105",
            "ACONFIG-108"
          ],
          "scenario": "An operator attempts to repair a bad timeout by manually rewriting the active record, erasing the incident's configuration history.",
          "acceptanceCriteria": [
            "Rollback appends a selection event with reason and actor.",
            "Validate old snapshot compatibility before selection.",
            "Retain the bad revision and its adoption record."
          ],
          "implementationNotes": [
            "Use the same guarded publication boundary as forward changes."
          ],
          "verification": [
            "Select a compatible prior revision and observe consumer adoption.",
            "Attempt rollback to an incompatible schema and leave the target unchanged."
          ],
          "deliverables": [
            "Audited rollback command"
          ],
          "rollout": "Rehearse on synthetic consumers; pin a known compatible revision if adoption stalls.",
          "skills": [
            "Recovery",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "032603c0-aea6-494f-8b6e-0cf13ccc70cb",
          "key": "ACONFIG-110",
          "title": "Exercise configuration service loss during a rolling deployment",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "ACONFIG-106",
            "ACONFIG-109"
          ],
          "scenario": "The configuration endpoint becomes unavailable while old and new workers are starting with different cached snapshots.",
          "acceptanceCriteria": [
            "Describe startup and running-process behavior separately.",
            "Prove critical settings cannot start from an unvalidated cache.",
            "Record revision selection and recovery for both consumer versions."
          ],
          "implementationNotes": [
            "Use local fault injection; no production configuration changes."
          ],
          "verification": [
            "Disconnect the endpoint after valid adoption and retain the declared bounded behavior.",
            "Start with a corrupt cache during outage and reject startup safely."
          ],
          "deliverables": [
            "Outage drill and compatibility trace"
          ],
          "rollout": "Run before rollout; halt the deployment if a consumer cannot demonstrate its selected revision.",
          "skills": [
            "Fault injection",
            "Operational readiness"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "f49f5c6f-281b-49af-bdbe-2df03be272fe",
      "key": "AENV",
      "title": "Make ephemeral review environments predictable",
      "field": "Platform engineering",
      "summary": "Provision bounded review environments with explicit ownership and cleanup.",
      "context": "A fictional team creates preview stacks for pull requests. Orphan databases consume resources and previews sometimes inherit settings intended for another branch.",
      "stack": [
        "TypeScript",
        "Compose specification",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local provisioning adapter with synthetic repository events.",
        "Use isolated disposable resources and no production credentials."
      ],
      "developerValue": "Practice resource lifecycle, reconciliation and least-privilege setup.",
      "companyValue": "Review reliable preview workflows and accountable resource cleanup.",
      "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": "plan",
          "title": "Plan isolated previews",
          "goal": "Validate requests and resource boundaries."
        },
        {
          "id": "provision",
          "title": "Reconcile environment state",
          "goal": "Make setup and updates repeatable."
        },
        {
          "id": "cleanup",
          "title": "Retire environments safely",
          "goal": "Detect expiration and recover incomplete cleanup."
        }
      ],
      "tickets": [
        {
          "id": "953e6f06-63a6-4eaa-8d46-3d5d560acff0",
          "key": "AENV-101",
          "title": "Validate preview requests before allocating resources",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "plan",
          "dependsOn": [],
          "scenario": "A branch name containing slashes and punctuation becomes an invalid database name after resources are already created.",
          "acceptanceCriteria": [
            "Use an opaque environment ID for resource names.",
            "Validate repository scope, revision and requested lifetime.",
            "Reject malformed requests before any provider call."
          ],
          "implementationNotes": [
            "Treat branch labels as display data only."
          ],
          "verification": [
            "Accept a valid synthetic revision with a complex branch label.",
            "Reject missing scope and excessive lifetime with zero allocation calls."
          ],
          "deliverables": [
            "Preview request schema"
          ],
          "rollout": "Enable request validation first; leave rejected previews unallocated.",
          "skills": [
            "Validation",
            "Resource naming"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "dee5aba0-d21c-4383-9397-332349c9c519",
          "key": "AENV-102",
          "title": "Create a review-environment resource plan with an explicit quota",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "plan",
          "dependsOn": [
            "AENV-101"
          ],
          "scenario": "One preview requests every optional dependency and exhausts the local resource budget.",
          "acceptanceCriteria": [
            "List CPU, memory, storage and lifetime requirements.",
            "Reject plans exceeding per-environment or aggregate quotas.",
            "Keep optional dependencies explicit rather than provisioned by default."
          ],
          "implementationNotes": [
            "Use documented synthetic quotas and a dry-run planner."
          ],
          "verification": [
            "Plan a minimal API and database preview.",
            "Exceed storage and concurrent-environment quotas and reject allocation."
          ],
          "deliverables": [
            "Quota-aware plan command"
          ],
          "rollout": "Expose dry-run plans first; reduce admitted previews if available resources shrink.",
          "skills": [
            "Capacity planning",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1a918916-8e70-4558-9471-eca1503e002d",
          "key": "AENV-103",
          "title": "Keep preview connection material out of build output",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "plan",
          "dependsOn": [
            "AENV-101"
          ],
          "scenario": "Provisioning logs print database URLs that contain temporary credentials.",
          "acceptanceCriteria": [
            "Redact passwords, tokens and credential-bearing URLs.",
            "Return secret references separately from public preview metadata.",
            "Keep synthetic credentials out of generated manifests."
          ],
          "implementationNotes": [
            "Use allowlisted structured logging fields."
          ],
          "verification": [
            "Inspect successful provisioning logs for safe identifiers.",
            "Inject a credential into provider errors and assert redaction."
          ],
          "deliverables": [
            "Log redaction and metadata projection"
          ],
          "rollout": "Deploy redaction before provisioning; rotate any affected disposable credentials.",
          "skills": [
            "Secrets handling",
            "Logging"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6830cffe-aea2-4eae-b57e-ef5a167ddcef",
          "key": "AENV-104",
          "title": "Make preview creation resumable after a partial provider failure",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "provision",
          "dependsOn": [
            "AENV-102",
            "AENV-103"
          ],
          "scenario": "The database is created but the API startup fails; retry creates a second database and loses track of the first.",
          "acceptanceCriteria": [
            "Assign deterministic resource identities per environment generation.",
            "Record each completed allocation before moving to the next.",
            "Resume from observed resources instead of blindly recreating them."
          ],
          "implementationNotes": [
            "Use a provider interface with injected failure points."
          ],
          "verification": [
            "Fail after database creation and resume to one database.",
            "Return an unexpected existing resource owner and halt without adoption."
          ],
          "deliverables": [
            "Reconciliation loop and partial-failure probe"
          ],
          "rollout": "Canary local environments; pause allocation while retaining resource records on inconsistency.",
          "skills": [
            "Idempotency",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "be78fd2b-31d4-4611-adfb-d37f2020e243",
          "key": "AENV-105",
          "title": "Bind preview updates to the exact requested source revision",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "provision",
          "dependsOn": [
            "AENV-104"
          ],
          "scenario": "A slow build for an older commit finishes after a newer build and replaces the current preview.",
          "acceptanceCriteria": [
            "Track requested generation and source revision.",
            "Only the current generation may become active.",
            "Keep stale build artifacts visible for cleanup but never route traffic to them."
          ],
          "implementationNotes": [
            "Do not treat completion time as revision order."
          ],
          "verification": [
            "Complete two builds in reverse order and activate only the latest requested one.",
            "Retry stale activation and preserve the selected generation."
          ],
          "deliverables": [
            "Generation guard and completion-order tests"
          ],
          "rollout": "Enable guarded routing; restore the prior valid generation if the new one fails readiness.",
          "skills": [
            "Concurrency",
            "Deployment state"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "054114d8-2c94-4f24-a4ff-1600b97e324d",
          "key": "AENV-106",
          "title": "Initialize preview data from a synthetic schema contract",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "provision",
          "dependsOn": [
            "AENV-104",
            "AENV-105"
          ],
          "scenario": "Preview startup depends on a copy of production data, making reviews slow and difficult to share safely.",
          "acceptanceCriteria": [
            "Create deterministic synthetic records covering declared UI states.",
            "Apply migrations before seeding the environment.",
            "Fail readiness when the seed contract is incomplete."
          ],
          "implementationNotes": [
            "Do not import real customer data or production secrets."
          ],
          "verification": [
            "Create two previews and compare declared synthetic identities and states.",
            "Fail a migration and verify the seed does not mark the environment ready."
          ],
          "deliverables": [
            "Synthetic seed command and readiness checks"
          ],
          "rollout": "Enable the seed on new previews; recreate disposable data if the contract changes.",
          "skills": [
            "Test data",
            "Migrations"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8dc28f46-13f6-410f-84a8-24ddd7306813",
          "key": "AENV-107",
          "title": "Probe readiness without accidentally validating only process liveness",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "provision",
          "dependsOn": [
            "AENV-105",
            "AENV-106"
          ],
          "scenario": "The preview link is published while migrations are still running, so reviewers immediately hit missing-table errors.",
          "acceptanceCriteria": [
            "Readiness checks required dependencies and schema version.",
            "Liveness remains independent of external dependency availability.",
            "Publish the link only after the current generation passes readiness."
          ],
          "implementationNotes": [
            "Bound probe time and omit secret diagnostics."
          ],
          "verification": [
            "Start a complete preview and publish its link.",
            "Delay migration completion and assert no ready link is announced."
          ],
          "deliverables": [
            "Readiness contract and startup timeline"
          ],
          "rollout": "Canary readiness gating; suppress links and inspect the generation on repeated failures.",
          "skills": [
            "Health checks",
            "Deployment readiness"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4534a466-40f0-46b3-b7a6-bee06dac05bc",
          "key": "AENV-108",
          "title": "Expire review environments with a grace period and owner visibility",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "cleanup",
          "dependsOn": [
            "AENV-104",
            "AENV-107"
          ],
          "scenario": "A preview remains allocated after its pull request closes because nobody owns the cleanup schedule.",
          "acceptanceCriteria": [
            "Persist owner token, expiry instant and grace deadline.",
            "List expiring environments without exposing credentials.",
            "Allow authorized extension within the declared maximum lifetime."
          ],
          "implementationNotes": [
            "Use an injectable clock and synthetic ownership."
          ],
          "verification": [
            "Advance through expiry and grace states.",
            "Attempt extension by another owner and reject it."
          ],
          "deliverables": [
            "Expiry state model and owner view"
          ],
          "rollout": "Enable expiry reporting before cleanup; extend only reviewed environments during adoption.",
          "skills": [
            "Lifecycle design",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "577102ed-8617-4710-9670-bc2c63077019",
          "key": "AENV-109",
          "title": "Delete only resources owned by the retired preview generation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "cleanup",
          "dependsOn": [
            "AENV-105",
            "AENV-108"
          ],
          "scenario": "A cleanup job matches resource names by prefix and can remove a newer generation sharing the same branch label.",
          "acceptanceCriteria": [
            "Match exact environment, generation and ownership tags.",
            "Refuse deletion for missing or contradictory ownership.",
            "Make retries converge after partial deletion."
          ],
          "implementationNotes": [
            "Provider deletion receives exact resource IDs, never wildcard names."
          ],
          "verification": [
            "Retire an old generation while keeping the new one usable.",
            "Alter an ownership tag and verify cleanup stops before deletion."
          ],
          "deliverables": [
            "Ownership-checked cleanup and isolation tests"
          ],
          "rollout": "Dry-run deletion plans first; pause cleanup and preserve unresolved resources on ownership conflicts.",
          "skills": [
            "Resource safety",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8b1f3d4d-4853-4c16-a657-e86849592ec2",
          "key": "AENV-110",
          "title": "Reconcile orphan preview resources into an auditable cleanup queue",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "cleanup",
          "dependsOn": [
            "AENV-104",
            "AENV-109"
          ],
          "scenario": "A process crashed before saving its final resource record; local storage now contains an environment no active preview references.",
          "acceptanceCriteria": [
            "Compare provider inventory to durable environment generations.",
            "Classify owned orphan, active and unknown resources.",
            "Require review of unknown ownership before any deletion."
          ],
          "implementationNotes": [
            "Bound inventory scans and retain an immutable reconciliation report."
          ],
          "verification": [
            "Discover an owned orphan and propose exact cleanup identities.",
            "Present an untagged resource and verify it is never automatically removed."
          ],
          "deliverables": [
            "Orphan inventory command and cleanup report"
          ],
          "rollout": "Run read-only first; execute only reviewed owned-orphan plans and stop on inventory drift.",
          "skills": [
            "Inventory reconciliation",
            "Operational safety"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "97317aee-e1c4-41f7-bcde-f99b09237912",
      "key": "AIMAGE",
      "title": "Harden a service image build and promotion workflow",
      "field": "Platform engineering",
      "summary": "Produce reproducible service images and promote exact artifacts with inspectable provenance.",
      "context": "A fictional reporting API is rebuilt separately for staging and production. Different dependency resolutions and mutable tags make incident rollback unreliable.",
      "stack": [
        "OCI image tools",
        "TypeScript",
        "CI"
      ],
      "prerequisites": [
        "Create a tiny local HTTP service and nonprivileged image build.",
        "Use synthetic registries or provider fixtures; no production deployment."
      ],
      "developerValue": "Practice artifact identity, least privilege and reproducible delivery.",
      "companyValue": "Review whether deployed bytes can be traced and rolled back reliably.",
      "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": "build",
          "title": "Constrain image construction",
          "goal": "Pin inputs and limit build context."
        },
        {
          "id": "promote",
          "title": "Promote exact artifacts",
          "goal": "Validate artifacts and preserve provenance."
        },
        {
          "id": "recover",
          "title": "Recover artifact failures",
          "goal": "Retain usable revisions and rehearse rollback."
        }
      ],
      "tickets": [
        {
          "id": "0daa63a2-2047-4d10-b97c-e19a35e1747f",
          "key": "AIMAGE-101",
          "title": "Exclude local credentials and bulky artifacts from the image context",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "build",
          "dependsOn": [],
          "scenario": "A developer notices an environment file and test recordings copied into the service image.",
          "acceptanceCriteria": [
            "Allow only required source and build inputs into context.",
            "Exclude environment files, VCS metadata and generated recordings.",
            "Add a safe inspection command that lists included paths."
          ],
          "implementationNotes": [
            "Create fake secrets for tests; never scan or print real secret values."
          ],
          "verification": [
            "Build a minimal synthetic service context.",
            "Add a fake credential file and verify it is absent from context and image."
          ],
          "deliverables": [
            "Context allowlist and image-content check"
          ],
          "rollout": "Apply before the next image build; discard affected disposable images.",
          "skills": [
            "Container builds",
            "Secrets handling"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7360f402-6854-494e-8fc8-549bfa128991",
          "key": "AIMAGE-102",
          "title": "Pin service build inputs to immutable identities",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "build",
          "dependsOn": [
            "AIMAGE-101"
          ],
          "scenario": "A rebuild of an old commit picks up a newer base image and no longer reproduces the original runtime.",
          "acceptanceCriteria": [
            "Pin the base image digest and dependency lockfile.",
            "Record compiler and build-tool versions.",
            "Fail the build when frozen dependency resolution changes the lockfile."
          ],
          "implementationNotes": [
            "Document the update procedure rather than permanently freezing vulnerabilities."
          ],
          "verification": [
            "Build twice from identical named inputs and compare artifact metadata.",
            "Change a pinned input and require a new provenance record."
          ],
          "deliverables": [
            "Pinned build definition"
          ],
          "rollout": "Introduce pinned builds for new artifacts; retain old digest references for rollback.",
          "skills": [
            "Reproducibility",
            "Dependency management"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0c0c6fab-6b30-4218-bd67-c52281681287",
          "key": "AIMAGE-103",
          "title": "Run the service image as an unprivileged user with a read-only root",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "build",
          "dependsOn": [
            "AIMAGE-101",
            "AIMAGE-102"
          ],
          "scenario": "The API image starts as root and writes temporary report files into the application directory.",
          "acceptanceCriteria": [
            "Use a non-root runtime user.",
            "Keep the base filesystem read-only with an explicit temporary directory.",
            "Reject startup when required writable storage is unavailable."
          ],
          "implementationNotes": [
            "No privileged mode, host mounts, host networking or container-engine socket."
          ],
          "verification": [
            "Serve a request under the restricted runtime configuration.",
            "Attempt a write to the application directory and verify denial."
          ],
          "deliverables": [
            "Restricted runtime definition and filesystem probe"
          ],
          "rollout": "Canary the restricted image locally; stop rollout if required writes lack an explicit temporary path.",
          "skills": [
            "Least privilege",
            "Container hardening"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "11d2cd84-cb79-472f-9d45-6389f1d0dd89",
          "key": "AIMAGE-104",
          "title": "Record image provenance without embedding build credentials",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "promote",
          "dependsOn": [
            "AIMAGE-102",
            "AIMAGE-103"
          ],
          "scenario": "Operations can see a tag but cannot trace it to source revision, dependency lock hash or build run.",
          "acceptanceCriteria": [
            "Record source revision, input hashes and final image digest.",
            "Associate provenance with the exact artifact digest.",
            "Exclude environment values and registry tokens."
          ],
          "implementationNotes": [
            "Use a local provenance document for this exercise."
          ],
          "verification": [
            "Resolve a built digest to its source and lockfile hashes.",
            "Alter provenance digest and reject the mismatch."
          ],
          "deliverables": [
            "Artifact provenance manifest and verification command"
          ],
          "rollout": "Attach provenance to new builds; refuse promotion when it cannot be verified.",
          "skills": [
            "Supply chain",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1c57c2a6-183e-4c2e-b0ef-34b66486e5b4",
          "key": "AIMAGE-105",
          "title": "Promote the tested digest instead of rebuilding for each environment",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "promote",
          "dependsOn": [
            "AIMAGE-104"
          ],
          "scenario": "The staging build passes, but production rebuilds the same commit with different transitive dependencies.",
          "acceptanceCriteria": [
            "Promotion selects the exact tested digest.",
            "Separate runtime configuration from artifact construction.",
            "Reject a tag that resolves to a different digest at promotion."
          ],
          "implementationNotes": [
            "Model registries through a testable provider interface."
          ],
          "verification": [
            "Promote a tested synthetic digest through two environments.",
            "Move a mutable tag and verify promotion rejects the changed artifact."
          ],
          "deliverables": [
            "Digest promotion command and tag-race regression"
          ],
          "rollout": "Canary promotion metadata; restore the previously selected digest if validation fails.",
          "skills": [
            "Artifact promotion",
            "Identity checks"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "666182ae-8ae2-4236-a224-5c6ad0f163fa",
          "key": "AIMAGE-106",
          "title": "Stop promotion when required security scan results are missing",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "promote",
          "dependsOn": [
            "AIMAGE-104",
            "AIMAGE-105"
          ],
          "scenario": "A scan service times out and the build pipeline treats absence of findings as a clean result.",
          "acceptanceCriteria": [
            "Represent passed, failed and unavailable scan states distinctly.",
            "Require scan policy and artifact digest to match.",
            "Unavailable required results block promotion with a retry path."
          ],
          "implementationNotes": [
            "Use synthetic scan responses; do not claim current vulnerability coverage."
          ],
          "verification": [
            "Promote with matching passed policy results.",
            "Timeout or return a different digest and verify promotion remains blocked."
          ],
          "deliverables": [
            "Scan-result gate and unavailable-state tests"
          ],
          "rollout": "Run the gate before environment selection; retry scans without rebuilding the artifact.",
          "skills": [
            "Fail-closed gates",
            "Supply-chain checks"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0e18f148-54a6-48ec-80fc-a21f8aead519",
          "key": "AIMAGE-107",
          "title": "Make artifact promotion idempotent across lost CI responses",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "promote",
          "dependsOn": [
            "AIMAGE-105",
            "AIMAGE-106"
          ],
          "scenario": "A CI runner loses the promotion response and retries, creating competing rollout records for one digest.",
          "acceptanceCriteria": [
            "Use a stable promotion key bound to environment and digest.",
            "Retries resolve one durable promotion record.",
            "Changed digest under the same key returns conflict."
          ],
          "implementationNotes": [
            "Persist selection and audit metadata atomically."
          ],
          "verification": [
            "Drop a response after commit and retry the same selection.",
            "Reuse a promotion key for another digest and retain the original selection."
          ],
          "deliverables": [
            "Idempotent promotion command"
          ],
          "rollout": "Enable for synthetic environments; pause conflicting promotions and retain their audit records.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "07dbd5ab-f596-4a10-82ec-3e5baf53bc4f",
          "key": "AIMAGE-108",
          "title": "Retain rollback images without deleting active environment digests",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "recover",
          "dependsOn": [
            "AIMAGE-105",
            "AIMAGE-107"
          ],
          "scenario": "Registry cleanup removes an image still running in a quiet environment because its tag is old.",
          "acceptanceCriteria": [
            "Retention protects every active and explicitly retained rollback digest.",
            "Compute deletion candidates before executing cleanup.",
            "Recheck references immediately before removal."
          ],
          "implementationNotes": [
            "Use exact digest references rather than tag age alone."
          ],
          "verification": [
            "Expire an unreferenced synthetic image.",
            "Add an active reference after planning and verify deletion is skipped."
          ],
          "deliverables": [
            "Digest retention planner and race test"
          ],
          "rollout": "Dry-run retention first; stop cleanup if environment inventory is unavailable.",
          "skills": [
            "Retention",
            "Resource safety"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f00f704e-7f88-4376-aa4d-5a591ac207e9",
          "key": "AIMAGE-109",
          "title": "Rehearse rollback when the new image cannot read existing data",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "recover",
          "dependsOn": [
            "AIMAGE-107",
            "AIMAGE-108"
          ],
          "scenario": "A new runtime starts successfully but fails on records created by the previous release.",
          "acceptanceCriteria": [
            "Declare compatibility expectations for stored data.",
            "Route back to the retained old digest without rebuilding.",
            "Identify any irreversible schema step that blocks binary rollback."
          ],
          "implementationNotes": [
            "Use a synthetic compatibility fixture and local runtime only."
          ],
          "verification": [
            "Roll out a compatible image and restore its predecessor.",
            "Trigger a schema incompatibility and stop automatic rollback with an explicit recovery decision."
          ],
          "deliverables": [
            "Rollback drill and compatibility matrix"
          ],
          "rollout": "Run the drill before promotion; block releases without a viable declared recovery path.",
          "skills": [
            "Release engineering",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f416ee2f-ba7f-4d7d-a1f7-54f7de74409d",
          "key": "AIMAGE-110",
          "title": "Publish a release inventory that resolves environments to exact bytes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "recover",
          "dependsOn": [
            "AIMAGE-104",
            "AIMAGE-108",
            "AIMAGE-109"
          ],
          "scenario": "Incident responders receive three different tag names for what appears to be the same release.",
          "acceptanceCriteria": [
            "List environment, selected digest and provenance identity.",
            "Show requested selection separately from observed running digest.",
            "Mark missing observations as unknown."
          ],
          "implementationNotes": [
            "Omit registry credentials and private build output."
          ],
          "verification": [
            "Resolve two aliases to the same artifact digest.",
            "Remove runtime observation and display unknown rather than deployed."
          ],
          "deliverables": [
            "Release inventory projection"
          ],
          "rollout": "Publish read-only inventory first; repair stale observations without changing selections.",
          "skills": [
            "Operational visibility",
            "Artifact identity"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "96ad2c0b-be60-4715-9dd2-05a4fa3ea42d",
      "key": "ATOKEN",
      "title": "Repair API token scope and revocation boundaries",
      "field": "Security",
      "summary": "Issue scoped API tokens and make rotation, denial and revocation observable.",
      "context": "A fictional B2B export API uses long-lived tokens. Tokens copied between organizations can access too much, and revocation takes effect unpredictably.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "REST"
      ],
      "prerequisites": [
        "Create a local synthetic API and two isolated organizations.",
        "Use generated disposable credentials only."
      ],
      "developerValue": "Practice authorization boundaries, credential lifecycle and safe diagnostics.",
      "companyValue": "Review denial paths and operational control over service access.",
      "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": "scope",
          "title": "Define token authority",
          "goal": "Separate identity, scope and safe display."
        },
        {
          "id": "lifecycle",
          "title": "Control token lifetime",
          "goal": "Rotate and revoke without widening authority."
        },
        {
          "id": "audit",
          "title": "Observe denied access",
          "goal": "Verify isolation and respond to exposure."
        }
      ],
      "tickets": [
        {
          "id": "2e70edff-9128-406a-b285-a09c2f14938e",
          "key": "ATOKEN-101",
          "title": "Define token scopes as an explicit allowlist of export operations",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "scope",
          "dependsOn": [],
          "scenario": "A token marked read-only can still trigger an export job because the handler treats every authenticated token equally.",
          "acceptanceCriteria": [
            "List exact read and create operations per scope.",
            "Unknown scopes are rejected at issuance.",
            "Protected handlers deny missing required scope."
          ],
          "implementationNotes": [
            "Do not infer permission from token naming conventions."
          ],
          "verification": [
            "Use a read scope for a permitted status request.",
            "Attempt export creation with that token and verify no job is created."
          ],
          "deliverables": [
            "Scope matrix and authorization checks"
          ],
          "rollout": "Deploy handler checks before issuing scoped tokens; disable legacy unrestricted issuance.",
          "skills": [
            "Authorization",
            "Least privilege"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1d97ad59-8841-42a1-8173-a80a6d59f6e5",
          "key": "ATOKEN-102",
          "title": "Store only token verification material and a safe display prefix",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "scope",
          "dependsOn": [
            "ATOKEN-101"
          ],
          "scenario": "The token-management page retrieves complete credentials from the database every time an administrator opens it.",
          "acceptanceCriteria": [
            "Show the full token only at initial issuance.",
            "Persist one-way verification material and a nonsecret identifier.",
            "List views never return reusable token material."
          ],
          "implementationNotes": [
            "Use a mature cryptographic primitive and document verification behavior."
          ],
          "verification": [
            "Issue and authenticate a disposable token.",
            "Read the list and stored record; verify the raw token is absent."
          ],
          "deliverables": [
            "Token storage contract and disclosure tests"
          ],
          "rollout": "Migrate new tokens first; retire legacy raw-token records through explicit rotation.",
          "skills": [
            "Credential storage",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "beb3defd-784a-43fe-9baf-d8c8cabc8d43",
          "key": "ATOKEN-103",
          "title": "Bind API token queries to the issuing organization",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "scope",
          "dependsOn": [
            "ATOKEN-101",
            "ATOKEN-102"
          ],
          "scenario": "An export identifier from another organization succeeds because the service checks token validity but omits tenant scope.",
          "acceptanceCriteria": [
            "Repository reads include the token organization.",
            "Cross-organization IDs receive nondisclosing denial.",
            "Authorization occurs before artifact-link creation."
          ],
          "implementationNotes": [
            "Test repository boundaries as well as routes."
          ],
          "verification": [
            "Read an export in the issuing organization.",
            "Request a second organization's export and verify no signed-link provider call."
          ],
          "deliverables": [
            "Tenant-bound repository guard"
          ],
          "rollout": "Deploy the scope guard before further token distribution; inspect denied access metadata.",
          "skills": [
            "Tenant isolation",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8c3f1b8f-e4b6-4508-8548-4d2c2ad8d346",
          "key": "ATOKEN-104",
          "title": "Enforce token expiration at the request authorization boundary",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "lifecycle",
          "dependsOn": [
            "ATOKEN-102",
            "ATOKEN-103"
          ],
          "scenario": "A token expires in storage but remains usable because the cached authentication result has no expiry check.",
          "acceptanceCriteria": [
            "Check current expiry with an injected clock.",
            "Cache lifetime cannot exceed token expiry.",
            "Expired tokens fail before protected service execution."
          ],
          "implementationNotes": [
            "Use UTC instants and avoid logging presented credentials."
          ],
          "verification": [
            "Authenticate just before expiry.",
            "Advance to the exact expiry instant and deny cached and uncached requests."
          ],
          "deliverables": [
            "Expiry enforcement and clock-boundary cases"
          ],
          "rollout": "Canary with disposable short-lived tokens; flush incompatible authentication caches.",
          "skills": [
            "Authentication",
            "Temporal boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "4f334136-1c59-49fe-94ca-bea0f2afdc99",
          "key": "ATOKEN-105",
          "title": "Rotate a token with a bounded overlap window",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "lifecycle",
          "dependsOn": [
            "ATOKEN-104"
          ],
          "scenario": "Customers need to replace credentials without downtime, but unrestricted overlap leaves old tokens valid indefinitely.",
          "acceptanceCriteria": [
            "Create a replacement with no broader scopes.",
            "Persist an explicit predecessor retirement deadline.",
            "Expose both token identities and overlap state safely."
          ],
          "implementationNotes": [
            "Require authorized rotation and bind it to an expected token revision."
          ],
          "verification": [
            "Rotate and authenticate both during the declared overlap.",
            "Advance beyond the overlap and deny the predecessor while accepting the replacement."
          ],
          "deliverables": [
            "Rotation command and overlap tests"
          ],
          "rollout": "Test with a synthetic client; revoke the new token if adoption fails within the window.",
          "skills": [
            "Credential rotation",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "49418726-207c-4c54-8c24-8a576beeab5b",
          "key": "ATOKEN-106",
          "title": "Make revocation override cached authentication results",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "lifecycle",
          "dependsOn": [
            "ATOKEN-104",
            "ATOKEN-105"
          ],
          "scenario": "An administrator revokes a leaked token, but one process continues accepting its cached authority.",
          "acceptanceCriteria": [
            "Define a maximum revocation propagation contract.",
            "Invalidate or version cached authority using durable token state.",
            "Fail closed when required revocation freshness cannot be established."
          ],
          "implementationNotes": [
            "Use two local consumer instances and controlled connectivity failures."
          ],
          "verification": [
            "Revoke a token and verify both consumers deny within the declared bound.",
            "Disconnect revocation freshness and verify the documented denial behavior."
          ],
          "deliverables": [
            "Revocation protocol and propagation probe"
          ],
          "rollout": "Canary two synthetic consumers; reduce cache lifetime or disable caching on propagation failure.",
          "skills": [
            "Cache consistency",
            "Revocation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a534bcc1-0472-482f-8858-ffa8e74ae57e",
          "key": "ATOKEN-107",
          "title": "Prevent a retry from issuing multiple replacement credentials",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "lifecycle",
          "dependsOn": [
            "ATOKEN-105",
            "ATOKEN-106"
          ],
          "scenario": "The rotation response is lost and a retry creates another active successor that the customer never receives.",
          "acceptanceCriteria": [
            "Bind rotation idempotency to actor, predecessor and requested scope.",
            "One successful command creates one successor.",
            "Changed rotation parameters under the same key conflict."
          ],
          "implementationNotes": [
            "Store only a bounded issuance response under the declared secret-handling policy."
          ],
          "verification": [
            "Retry a completed rotation and count one successor.",
            "Reuse its key with broader scopes and verify rejection."
          ],
          "deliverables": [
            "Idempotent rotation transaction"
          ],
          "rollout": "Enable rotation retries with a short documented response lifetime; revoke orphan test tokens during recovery.",
          "skills": [
            "Idempotency",
            "Credential lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9c1be7ea-24de-4749-88dc-857656a505ed",
          "key": "ATOKEN-108",
          "title": "Record denied API access without turning audit logs into a token store",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "audit",
          "dependsOn": [
            "ATOKEN-103",
            "ATOKEN-106"
          ],
          "scenario": "Security needs failed-access context, but the existing logger captures the Authorization header and request body.",
          "acceptanceCriteria": [
            "Record safe token identity, route, reason and UTC time.",
            "Exclude authorization headers and body content.",
            "Bound repeated denial events to prevent log exhaustion."
          ],
          "implementationNotes": [
            "Use synthetic token strings in redaction tests."
          ],
          "verification": [
            "Trace a scope denial by safe token identity.",
            "Send repeated malformed tokens and verify redaction and bounded logging."
          ],
          "deliverables": [
            "Safe denial audit and rate-bound checks"
          ],
          "rollout": "Deploy audit filtering first; quarantine old diagnostic logs for authorized review.",
          "skills": [
            "Audit logging",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4b819fcd-f964-463a-98d8-ab5b4011acee",
          "key": "ATOKEN-109",
          "title": "Rehearse credential exposure containment for one organization",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "audit",
          "dependsOn": [
            "ATOKEN-106",
            "ATOKEN-107",
            "ATOKEN-108"
          ],
          "scenario": "A fictional customer reports that a token was pasted into a public issue; operations needs a tested containment sequence.",
          "acceptanceCriteria": [
            "Identify and revoke the affected token without listing secrets.",
            "Confirm denial across every local consumer.",
            "Preserve safe audit facts and issue a scoped replacement through the normal flow."
          ],
          "implementationNotes": [
            "Use a disposable token and a fabricated incident only."
          ],
          "verification": [
            "Run the complete containment drill and verify old-token denial.",
            "Simulate an unreachable consumer and keep containment status incomplete."
          ],
          "deliverables": [
            "Exposure response runbook and executable drill"
          ],
          "rollout": "Practice in a synthetic organization; stop replacement distribution until revocation status is known.",
          "skills": [
            "Incident response",
            "Credential security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "180d9d0a-505c-48ab-8cde-6209881c01ad",
          "key": "ATOKEN-110",
          "title": "Show token last-use status without claiming it proves nonuse",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "audit",
          "dependsOn": [
            "ATOKEN-108",
            "ATOKEN-109"
          ],
          "scenario": "Administrators interpret an empty last-used field as proof that a token was never used, despite audit ingestion gaps.",
          "acceptanceCriteria": [
            "Distinguish observed use, no recorded use and unknown coverage.",
            "State the observation window and freshness.",
            "Avoid exposing request payloads in token summaries."
          ],
          "implementationNotes": [
            "Treat last-use metadata as operational evidence with stated limits."
          ],
          "verification": [
            "Record a successful request and show its observation time.",
            "Remove audit coverage and show unknown instead of never used."
          ],
          "deliverables": [
            "Token activity projection"
          ],
          "rollout": "Publish the explicit coverage labels; revert UI wiring if scope checks fail.",
          "skills": [
            "Security UX",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "e980f00e-89b2-45ce-882b-9f578b896ce6",
      "key": "AFETCH",
      "title": "Constrain a server-side document fetcher",
      "field": "Security",
      "summary": "Fetch approved remote documents while controlling redirects, size and authority.",
      "context": "A fictional knowledge service imports documents from customer-entered URLs. The importer follows redirects and trusts response metadata too broadly.",
      "stack": [
        "TypeScript",
        "HTTP client",
        "Object storage"
      ],
      "prerequisites": [
        "Build a local fetch adapter and controlled HTTP test servers.",
        "Use synthetic documents and deny network access outside the test allowlist."
      ],
      "developerValue": "Practice defensive URL handling and bounded untrusted-input processing.",
      "companyValue": "Review whether integrations can import content without expanding infrastructure access.",
      "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": "policy",
          "title": "Define fetch authority",
          "goal": "Constrain URLs, identity and network destinations."
        },
        {
          "id": "fetch",
          "title": "Bound remote work",
          "goal": "Apply limits through redirects and response streaming."
        },
        {
          "id": "review",
          "title": "Validate abuse resistance",
          "goal": "Reproduce failures and preserve safe diagnostics."
        }
      ],
      "tickets": [
        {
          "id": "60ac42f8-d233-435e-9c08-78c7540143c5",
          "key": "AFETCH-101",
          "title": "Accept only explicitly supported document URL schemes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "policy",
          "dependsOn": [],
          "scenario": "A customer enters a non-HTTP URI that the generic import library attempts to interpret as a local resource.",
          "acceptanceCriteria": [
            "Allow HTTPS under an explicit destination policy.",
            "Reject embedded credentials and unsupported schemes.",
            "Normalize once and retain a safe display URL."
          ],
          "implementationNotes": [
            "Use a standard URL parser; do not build one with string prefixes."
          ],
          "verification": [
            "Accept an approved synthetic HTTPS URL.",
            "Reject file, data and credential-bearing URLs before network calls."
          ],
          "deliverables": [
            "URL input policy and parser tests"
          ],
          "rollout": "Enforce validation before import dispatch; quarantine existing unsupported requests.",
          "skills": [
            "Input validation",
            "URL parsing"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "423bd472-d035-4524-adb2-b51d09ce8df9",
          "key": "AFETCH-102",
          "title": "Bind document import requests to tenant-owned destination policies",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "policy",
          "dependsOn": [
            "AFETCH-101"
          ],
          "scenario": "One tenant configures an approved host and another tenant unexpectedly inherits permission to fetch from it.",
          "acceptanceCriteria": [
            "Resolve allowlists within the requesting tenant.",
            "Require authorization before creating a fetch job.",
            "Reject unknown policy references without disclosing other tenants' hosts."
          ],
          "implementationNotes": [
            "Store policy version with the import request."
          ],
          "verification": [
            "Import through the tenant's approved synthetic host.",
            "Reuse another tenant's policy ID and verify zero fetch calls."
          ],
          "deliverables": [
            "Scoped destination-policy service"
          ],
          "rollout": "Deploy tenant resolution before enabling saved policies; disable import on ambiguous ownership.",
          "skills": [
            "Tenant isolation",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6f1072d8-34c1-49d1-8f4f-9ef8ea31257b",
          "key": "AFETCH-103",
          "title": "Reject private and special-use destination addresses before connection",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "policy",
          "dependsOn": [
            "AFETCH-101",
            "AFETCH-102"
          ],
          "scenario": "A public-looking hostname resolves to an internal address during import and reaches a service unavailable to the user.",
          "acceptanceCriteria": [
            "Apply destination-address policy to every resolved connection target.",
            "Reject loopback, private and special-use addresses outside explicit local tests.",
            "Prevent resolver results from changing unchecked before connection."
          ],
          "implementationNotes": [
            "Use an injected resolver and connection adapter; tests never contact internal services."
          ],
          "verification": [
            "Resolve an allowed synthetic public address through the fixture adapter.",
            "Return loopback or changed resolution and verify no connection is opened."
          ],
          "deliverables": [
            "Resolver-to-connection policy and fixture tests"
          ],
          "rollout": "Run policy checks before enabling network fetches; deny unresolved or ambiguous destinations.",
          "skills": [
            "Network security",
            "SSRF prevention"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "af0f9f62-bc46-494f-8a16-e52bb6a5d34b",
          "key": "AFETCH-104",
          "title": "Revalidate every document redirect before following it",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "fetch",
          "dependsOn": [
            "AFETCH-103"
          ],
          "scenario": "An approved download host redirects to an unapproved internal URL after the first request passes validation.",
          "acceptanceCriteria": [
            "Limit redirect count and validate each target independently.",
            "Do not forward credentials across origins.",
            "Reject redirect loops with a stable reason code."
          ],
          "implementationNotes": [
            "Use local controlled redirect fixtures only."
          ],
          "verification": [
            "Follow one permitted same-policy redirect.",
            "Redirect toward an internal fixture address and assert it is blocked before connection."
          ],
          "deliverables": [
            "Redirect policy and credential-stripping regression"
          ],
          "rollout": "Enable bounded redirect handling; disable redirect support if a client bypasses target validation.",
          "skills": [
            "HTTP security",
            "Redirect handling"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "de19cb62-71f3-4989-94bf-6aa17cf4b3bc",
          "key": "AFETCH-105",
          "title": "Enforce byte and time limits while streaming imported documents",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "fetch",
          "dependsOn": [
            "AFETCH-104"
          ],
          "scenario": "A response declares a small Content-Length but streams indefinitely, occupying a worker slot.",
          "acceptanceCriteria": [
            "Bound actual streamed bytes regardless of headers.",
            "Enforce connect, idle and overall deadlines.",
            "Cancel the upstream stream and remove incomplete staging objects on failure."
          ],
          "implementationNotes": [
            "Choose explicit local test budgets and an injectable clock."
          ],
          "verification": [
            "Import a document within the declared byte and deadline limits.",
            "Stream beyond the byte cap or stall and verify cancellation plus cleanup."
          ],
          "deliverables": [
            "Bounded stream adapter and timeout fixtures"
          ],
          "rollout": "Canary small imports; lower admitted limits while investigating failures.",
          "skills": [
            "Streaming",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0f3dc497-c4e6-42e5-88cc-0c060e280291",
          "key": "AFETCH-106",
          "title": "Validate document type from bytes before publishing the import",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "fetch",
          "dependsOn": [
            "AFETCH-105"
          ],
          "scenario": "A remote server labels an executable-looking payload as text and the importer publishes it under a trusted document type.",
          "acceptanceCriteria": [
            "Allow a declared finite set of document formats.",
            "Check supported signatures and parser outcomes against claimed type.",
            "Keep mismatched or malformed content quarantined."
          ],
          "implementationNotes": [
            "Do not execute imported content or trust file extensions."
          ],
          "verification": [
            "Import valid synthetic text and supported document bytes.",
            "Mismatch content type and bytes and verify no published object."
          ],
          "deliverables": [
            "Format gate and mismatch cases"
          ],
          "rollout": "Gate new imports before publication; retain quarantined bytes under restricted retention.",
          "skills": [
            "Content validation",
            "Untrusted data"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "374e1060-af8d-48b0-b02b-979245c94722",
          "key": "AFETCH-107",
          "title": "Make interrupted document fetch retries preserve one import identity",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "fetch",
          "dependsOn": [
            "AFETCH-105",
            "AFETCH-106"
          ],
          "scenario": "A response drops after storage completes; retry publishes a second document with a different identity.",
          "acceptanceCriteria": [
            "Use a stable import command identity and staged object generation.",
            "Publish at most one completed object per command.",
            "Changed URL or policy version under the same key conflicts."
          ],
          "implementationNotes": [
            "Persist publication and completion state atomically."
          ],
          "verification": [
            "Drop the response after publication and retry to the same import.",
            "Interrupt a stream and verify its incomplete generation cannot be published."
          ],
          "deliverables": [
            "Idempotent import completion and fault probe"
          ],
          "rollout": "Canary one synthetic tenant; stop completion and inspect staging generations on inconsistency.",
          "skills": [
            "Idempotency",
            "Storage lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "447423b3-37c9-4bed-917f-0308ed217a92",
          "key": "AFETCH-108",
          "title": "Remove query secrets from document-fetch error messages",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "review",
          "dependsOn": [
            "AFETCH-104",
            "AFETCH-107"
          ],
          "scenario": "A signed download URL appears in an operator error message after a timeout.",
          "acceptanceCriteria": [
            "Log safe origin, import ID and failure code only.",
            "Strip query, fragment and user information from diagnostics.",
            "Keep provider errors from bypassing the safe projection."
          ],
          "implementationNotes": [
            "Use fabricated signed URLs in tests."
          ],
          "verification": [
            "Trace a timeout by import ID.",
            "Inject secret-like query values into redirect and timeout errors and assert absence."
          ],
          "deliverables": [
            "Fetch diagnostic sanitizer"
          ],
          "rollout": "Deploy safe diagnostics before broad imports; restrict older error records.",
          "skills": [
            "Privacy",
            "Error handling"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fe221b0c-d1df-4296-8c62-8b765dff0088",
          "key": "AFETCH-109",
          "title": "Build a regression matrix for document-fetch trust-boundary failures",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "review",
          "dependsOn": [
            "AFETCH-103",
            "AFETCH-104",
            "AFETCH-105",
            "AFETCH-106"
          ],
          "scenario": "The fetcher has individual guards, but a client upgrade could bypass a guard only when redirects, DNS and retries combine.",
          "acceptanceCriteria": [
            "Cover composed resolver, redirect, size and cancellation cases.",
            "Assert forbidden connection attempts and publication calls remain zero.",
            "Record expected failure codes without claiming universal attack coverage."
          ],
          "implementationNotes": [
            "All network behavior runs through local controlled adapters."
          ],
          "verification": [
            "Run an allowed redirected import through the complete pipeline.",
            "Combine redirect with resolution change and oversized body; stop at the earliest applicable guard."
          ],
          "deliverables": [
            "Adversarial fixture matrix and regression command"
          ],
          "rollout": "Require the matrix for client upgrades; pin the last passing client revision if failures appear.",
          "skills": [
            "Security testing",
            "Boundary analysis"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4569d06a-1dff-4180-8324-aac2396c56ea",
          "key": "AFETCH-110",
          "title": "Document the exception process for a newly requested document host",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "review",
          "dependsOn": [
            "AFETCH-102",
            "AFETCH-109"
          ],
          "scenario": "Support wants to unblock a customer's host quickly without permanently disabling destination checks.",
          "acceptanceCriteria": [
            "Request a tenant-scoped host and purpose.",
            "Record policy version, reviewer and expiry for any exception.",
            "Retain all address, redirect and byte controls."
          ],
          "implementationNotes": [
            "Use a fictional host; no live allowlist modification is part of this ticket."
          ],
          "verification": [
            "Review a complete scoped exception example.",
            "Reject a wildcard destination request that bypasses address policy."
          ],
          "deliverables": [
            "Host exception template and worked review"
          ],
          "rollout": "Use the template for policy proposals; expire exceptions rather than widening global defaults.",
          "skills": [
            "Threat modeling",
            "Operational policy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "4ff1df46-8579-4752-8e91-ea387b17a173",
      "key": "AAUDIT",
      "title": "Make privileged support actions inspectable",
      "field": "Security",
      "summary": "Constrain support elevation and preserve trustworthy audit records.",
      "context": "A fictional support console can reveal protected account settings and run repairs. The team needs bounded elevation, clear reasons and durable records of what happened.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "REST"
      ],
      "prerequisites": [
        "Create synthetic support actors and organizations.",
        "Implement a local authorization boundary and append-only audit store."
      ],
      "developerValue": "Practice privileged workflows, denial paths and audit integrity.",
      "companyValue": "Review accountable support operations without unnecessary access to customer data.",
      "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": "access",
          "title": "Constrain elevated access",
          "goal": "Define permission, purpose and expiry."
        },
        {
          "id": "actions",
          "title": "Guard privileged mutations",
          "goal": "Bind changes to reviewed scope and durable records."
        },
        {
          "id": "review",
          "title": "Review and recover",
          "goal": "Inspect events and respond to missing audit coverage."
        }
      ],
      "tickets": [
        {
          "id": "5cfc3967-3cd4-468b-b6f1-bb3136c128f3",
          "key": "AAUDIT-101",
          "title": "List support actions with required permission and disclosure level",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "access",
          "dependsOn": [],
          "scenario": "Support agents share an admin role because nobody has separated read diagnostics from account-changing actions.",
          "acceptanceCriteria": [
            "Classify each action by permission and exposed fields.",
            "Default unknown actions to denied.",
            "Keep read-only diagnostics separate from mutation authority."
          ],
          "implementationNotes": [
            "Use six concrete fictional support actions."
          ],
          "verification": [
            "Map an allowed diagnostic read to its minimal permission.",
            "Attempt an unlisted action and deny it before data access."
          ],
          "deliverables": [
            "Support permission matrix"
          ],
          "rollout": "Review the matrix before enabling new actions; retain unknown operations as disabled.",
          "skills": [
            "Authorization design",
            "Least privilege"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "27460c62-35a2-47b5-8473-80aca55610ea",
          "key": "AAUDIT-102",
          "title": "Require a bounded purpose record before support elevation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "access",
          "dependsOn": [
            "AAUDIT-101"
          ],
          "scenario": "An agent opens account settings using permanent elevated access with no connection to a support case.",
          "acceptanceCriteria": [
            "Record target organization, permitted actions, reason and expiry.",
            "Require an authorized actor to request elevation.",
            "Reject empty purpose or an excessive lifetime."
          ],
          "implementationNotes": [
            "Use synthetic case references without copying case conversations."
          ],
          "verification": [
            "Create a scoped time-limited elevation.",
            "Request a different organization's action outside the grant and deny it."
          ],
          "deliverables": [
            "Elevation request contract"
          ],
          "rollout": "Canary grants for synthetic actors; revoke active test grants if policy checks fail.",
          "skills": [
            "Privileged access",
            "Scoping"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "852a8172-3b5f-4daa-a24e-dfd85939bdcc",
          "key": "AAUDIT-103",
          "title": "Remove sensitive account fields from ordinary support search",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "access",
          "dependsOn": [
            "AAUDIT-101",
            "AAUDIT-102"
          ],
          "scenario": "Searching by account ID returns confidential settings before the agent opens an elevated support session.",
          "acceptanceCriteria": [
            "Ordinary search returns an explicit minimal projection.",
            "Protected details require the exact active grant.",
            "Denied search responses do not reveal account existence across scope."
          ],
          "implementationNotes": [
            "Define response schemas at the service boundary."
          ],
          "verification": [
            "Find an account using permitted safe fields.",
            "Search outside scope and inspect response and logs for protected fields."
          ],
          "deliverables": [
            "Minimal support search projection"
          ],
          "rollout": "Deploy projection before elevation rollout; disable broad debug search endpoints.",
          "skills": [
            "Privacy",
            "Response schemas"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "38ac938d-1c35-4e75-a675-4b31510289c9",
          "key": "AAUDIT-104",
          "title": "Reauthorize elevation immediately before a support repair commits",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "actions",
          "dependsOn": [
            "AAUDIT-102",
            "AAUDIT-103"
          ],
          "scenario": "An agent starts a repair, loses access, then the pending request commits using the authorization decision from several minutes earlier.",
          "acceptanceCriteria": [
            "Reload actor and grant authority in the mutation transaction.",
            "Check target scope, permitted operation and expiry.",
            "Revoked or expired grants leave domain state unchanged."
          ],
          "implementationNotes": [
            "Use controlled barriers to model revocation between read and commit."
          ],
          "verification": [
            "Commit a repair under an active matching grant.",
            "Revoke at the barrier and verify rollback with no repair effect."
          ],
          "deliverables": [
            "Commit-boundary authorization guard"
          ],
          "rollout": "Canary the guard on synthetic repairs; disable repair writes if authorization freshness fails.",
          "skills": [
            "Authorization races",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "569e31a3-4195-474d-8906-f89f78602f4b",
          "key": "AAUDIT-105",
          "title": "Commit privileged repair state and its audit fact together",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "actions",
          "dependsOn": [
            "AAUDIT-104"
          ],
          "scenario": "A repair succeeds while the audit insert fails, leaving an unrecorded privileged change.",
          "acceptanceCriteria": [
            "Persist repair and audit fact in one transaction.",
            "Audit captures actor, grant, action and safe target identity.",
            "Audit failure rolls back the repair."
          ],
          "implementationNotes": [
            "Keep payload contents and secrets out of the audit record."
          ],
          "verification": [
            "Commit a synthetic repair and inspect one matching audit fact.",
            "Force audit persistence failure and verify unchanged domain state."
          ],
          "deliverables": [
            "Atomic repair audit and failure test"
          ],
          "rollout": "Deploy transactional writes before exposing repairs; stop mutation if audit storage is unavailable.",
          "skills": [
            "Audit integrity",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "76e3860b-0a82-43df-95c2-577565cb796d",
          "key": "AAUDIT-106",
          "title": "Make support repair commands replay-safe without repeating side effects",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "actions",
          "dependsOn": [
            "AAUDIT-105"
          ],
          "scenario": "The console retries a repair after a timeout, generating a second account reset and confusing the support trail.",
          "acceptanceCriteria": [
            "Bind idempotency to actor, grant, target and operation input.",
            "Return the original result for identical retries.",
            "Reject changed parameters under the same key."
          ],
          "implementationNotes": [
            "Audit the logical operation once and retain safe retry observations separately."
          ],
          "verification": [
            "Lose a post-commit response and retry to one repair.",
            "Reuse the command key for another target and deny it."
          ],
          "deliverables": [
            "Idempotent support repair command"
          ],
          "rollout": "Canary with disposable accounts; pause conflicting command keys for investigation.",
          "skills": [
            "Idempotency",
            "Privileged workflows"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "b05ef40f-26f0-4a71-bd62-b15bcd17ac9a",
          "key": "AAUDIT-107",
          "title": "Expire support grants without relying on a cleanup job",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "actions",
          "dependsOn": [
            "AAUDIT-104",
            "AAUDIT-106"
          ],
          "scenario": "A delayed cleanup worker leaves expired support sessions usable throughout an outage.",
          "acceptanceCriteria": [
            "Every privileged authorization checks the stored expiry.",
            "Cleanup only archives derived state and cannot extend authority.",
            "Use one documented exact-expiry boundary."
          ],
          "implementationNotes": [
            "Use an injected UTC clock at the service boundary."
          ],
          "verification": [
            "Authorize a matching action immediately before expiry.",
            "Advance to expiry while cleanup is paused and deny the action."
          ],
          "deliverables": [
            "Expiry enforcement and paused-cleanup test"
          ],
          "rollout": "Enable boundary checks before cleanup changes; revoke grants if clock assumptions are violated.",
          "skills": [
            "Temporal authorization",
            "Fail-closed design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "e0b77682-3f97-449e-8e52-e9f01b00bdaf",
          "key": "AAUDIT-108",
          "title": "Provide a scoped audit timeline with stable cursor pagination",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "review",
          "dependsOn": [
            "AAUDIT-105",
            "AAUDIT-107"
          ],
          "scenario": "Security reviewers need to inspect a repair sequence, but an unbounded audit endpoint times out and exposes unrelated organizations.",
          "acceptanceCriteria": [
            "Filter by authorized organization and bounded time window.",
            "Order by committed sequence with a stable cursor.",
            "Return safe action metadata without repair payloads."
          ],
          "implementationNotes": [
            "Reject cursors bound to another scope."
          ],
          "verification": [
            "Page a synthetic incident timeline while new events arrive.",
            "Tamper with scope in a cursor and return a nondisclosing denial."
          ],
          "deliverables": [
            "Audit timeline endpoint and scope tests"
          ],
          "rollout": "Expose read-only timelines to a review role; revoke the route if projection checks fail.",
          "skills": [
            "Pagination",
            "Audit review"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2704a99f-3201-4fc9-ad56-c077ee4d7a70",
          "key": "AAUDIT-109",
          "title": "Detect missing privileged audit coverage using domain references",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "review",
          "dependsOn": [
            "AAUDIT-105",
            "AAUDIT-108"
          ],
          "scenario": "A legacy repair path may still bypass the transactional audit method; reviewers need a precise way to find uncovered changes.",
          "acceptanceCriteria": [
            "Compare privileged operation references with audit identities.",
            "Report missing and contradictory links separately.",
            "Do not invent audit facts for historical gaps."
          ],
          "implementationNotes": [
            "Use bounded synthetic data and a read-only reconciliation command."
          ],
          "verification": [
            "Reconcile a complete operation history with no gaps.",
            "Remove one audit reference in a fixture and report explicit incomplete coverage."
          ],
          "deliverables": [
            "Audit coverage reconciler"
          ],
          "rollout": "Run read-only before enabling legacy repair paths; disable uncovered writes until corrected.",
          "skills": [
            "Integrity verification",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a1ce5baf-db80-43d4-85ba-2c03c12c8d4d",
          "key": "AAUDIT-110",
          "title": "Rehearse termination of an active support elevation incident",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "review",
          "dependsOn": [
            "AAUDIT-107",
            "AAUDIT-108",
            "AAUDIT-109"
          ],
          "scenario": "A fictional support account is suspected of misuse while one elevated request is still running.",
          "acceptanceCriteria": [
            "Runbook revokes grants and checks in-flight commit protection.",
            "Preserve immutable audit facts and record coverage limits.",
            "Verify ordinary support access remains scoped after containment."
          ],
          "implementationNotes": [
            "Use only synthetic actors and repairs."
          ],
          "verification": [
            "Contain an active grant and verify later actions are denied.",
            "Pause a repair before commit, revoke authority, and confirm no mutation completes."
          ],
          "deliverables": [
            "Support containment runbook and drill trace"
          ],
          "rollout": "Rehearse locally before release; keep repairs disabled if containment cannot be verified.",
          "skills": [
            "Incident response",
            "Operational verification"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "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": []
        }
      ]
    },
    {
      "id": "31722a2e-299d-4a44-963b-b65b13ee8f6f",
      "key": "AREGION",
      "title": "Design regional reads without promising impossible failover",
      "field": "System design",
      "summary": "Specify consistency, routing and recovery for a regional customer read experience.",
      "context": "A fictional logistics dashboard serves distant customers from one primary region. Stakeholders want faster reads and outage recovery but have not agreed which data may be stale.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create a local primary/replica simulator and synthetic shipment records.",
        "Use local models; no multi-region infrastructure is provisioned."
      ],
      "developerValue": "Practice consistency tradeoffs, failover authority and recovery assumptions.",
      "companyValue": "Review regional availability proposals with explicit data-loss and staleness limits.",
      "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": "requirements",
          "title": "Classify regional behavior",
          "goal": "Define which reads and writes need freshness."
        },
        {
          "id": "protocol",
          "title": "Specify routing authority",
          "goal": "Make routing, failover and retry contracts testable."
        },
        {
          "id": "recovery",
          "title": "Challenge recovery promises",
          "goal": "Model outages and reconcile divergent observations."
        }
      ],
      "tickets": [
        {
          "id": "dbd3755c-2ae6-4cd4-81c4-fe2403206832",
          "key": "AREGION-101",
          "title": "Classify shipment reads by tolerated staleness",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "requirements",
          "dependsOn": [],
          "scenario": "The regional-read proposal treats a public tracking estimate and an address-change confirmation as equally cacheable.",
          "acceptanceCriteria": [
            "List read classes with explicit hypothetical freshness limits.",
            "Require fresh authority for security and mutation confirmation.",
            "Document unknown product requirements separately."
          ],
          "implementationNotes": [
            "Use a synthetic status timeline with version numbers."
          ],
          "verification": [
            "Assign a declared budget to public tracking.",
            "Show why address-change confirmation needs its accepted version."
          ],
          "deliverables": [
            "Read-consistency matrix"
          ],
          "rollout": "Review the matrix before routing changes; leave unresolved classes on primary reads.",
          "skills": [
            "Consistency requirements",
            "Product reasoning"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3dfbebaf-31e4-4ee6-9406-977261fa098e",
          "key": "AREGION-102",
          "title": "Calculate regional latency contributions with stated assumptions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "requirements",
          "dependsOn": [
            "AREGION-101"
          ],
          "scenario": "A proposal promises a faster dashboard without separating network time, database time and sequential request dependencies.",
          "acceptanceCriteria": [
            "Break one page load into serial and parallel operations.",
            "Use named hypothetical network and service-time values.",
            "Show sensitivity to an additional cross-region round trip."
          ],
          "implementationNotes": [
            "Label every unmeasured input as an assumption."
          ],
          "verification": [
            "Calculate two routes with the same service-time assumptions.",
            "Add a required primary check and show its effect on the budget."
          ],
          "deliverables": [
            "Latency worksheet and dependency diagram"
          ],
          "rollout": "Use the calculation to prioritize probes; replace assumptions with observations before choosing deployment.",
          "skills": [
            "Latency modeling",
            "Critical-path analysis"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "702d744a-a9b3-4873-b80e-faee1305d2fd",
          "key": "AREGION-103",
          "title": "Record the decision between regional caching and replica reads",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "requirements",
          "dependsOn": [
            "AREGION-101",
            "AREGION-102"
          ],
          "scenario": "The team jumps to database replicas when a scoped cache might cover the tolerated-staleness tracking view.",
          "acceptanceCriteria": [
            "Compare invalidation, freshness, failure and operational costs.",
            "Keep sensitive and read-after-write paths explicit.",
            "Name a workload or consistency change that revisits the choice."
          ],
          "implementationNotes": [
            "Do not assume an additional region is free or already configured."
          ],
          "verification": [
            "Evaluate both options against one tracking read.",
            "Evaluate an authorization change and reject an option that cannot enforce it."
          ],
          "deliverables": [
            "Regional-read architecture decision"
          ],
          "rollout": "Review using the consistency matrix; implement only the smallest local prototype selected.",
          "skills": [
            "Architecture decisions",
            "Caching tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8b0acb5f-cb7c-46bd-ac47-65fca3efa811",
          "key": "AREGION-104",
          "title": "Define a read-after-write token for shipment changes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "protocol",
          "dependsOn": [
            "AREGION-101",
            "AREGION-103"
          ],
          "scenario": "A user changes a delivery note, then a regional read immediately shows the previous text.",
          "acceptanceCriteria": [
            "Mutation returns an accepted version token.",
            "A subsequent read must meet that version or use a fresh source.",
            "Tokens are bound to tenant and resource."
          ],
          "implementationNotes": [
            "Implement a small local routing model, not a new replication engine."
          ],
          "verification": [
            "Write version 4 while the replica has version 3 and route correctly.",
            "Reuse another tenant's token and reject it without exposing state."
          ],
          "deliverables": [
            "Read-version contract and routing tests"
          ],
          "rollout": "Canary the routing model in a local client; fall back to primary reads when freshness cannot be established.",
          "skills": [
            "Read-your-writes",
            "Routing"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5832f9ff-4d05-49a3-ba75-6cfe8656cad9",
          "key": "AREGION-105",
          "title": "Fence regional write authority before promoting a standby",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "protocol",
          "dependsOn": [
            "AREGION-104"
          ],
          "scenario": "An outage runbook says promote the standby but never explains how the unreachable former primary loses authority.",
          "acceptanceCriteria": [
            "Define one durable authority epoch and promotion preconditions.",
            "Reject commands using an old epoch.",
            "Describe the availability tradeoff when fencing cannot be confirmed."
          ],
          "implementationNotes": [
            "Use a local two-writer model; do not claim split-brain prevention without enforced fencing."
          ],
          "verification": [
            "Promote a new epoch and accept only the new writer.",
            "Let the old writer recover and reject its stale-epoch command."
          ],
          "deliverables": [
            "Failover authority protocol and fencing probe"
          ],
          "rollout": "Require the probe before any real failover procedure; refuse promotion when authority is ambiguous.",
          "skills": [
            "Fencing",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "444112ca-52b5-42d3-b42d-161f463da926",
          "key": "AREGION-106",
          "title": "Preserve command identity across a regional routing retry",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "protocol",
          "dependsOn": [
            "AREGION-104",
            "AREGION-105"
          ],
          "scenario": "A gateway retries an update in another region after losing the response, potentially applying the shipment change twice.",
          "acceptanceCriteria": [
            "Use a stable command key across routing attempts.",
            "Bind the key to target, actor and canonical input.",
            "Return unknown until committed status can be resolved safely."
          ],
          "implementationNotes": [
            "Do not infer an absent commit from a connection timeout."
          ],
          "verification": [
            "Lose the response after commit and resolve one logical change.",
            "Change input under the same key and return conflict."
          ],
          "deliverables": [
            "Cross-route command contract and timeout probe"
          ],
          "rollout": "Use the contract in the local gateway prototype; suspend retries if deduplication authority is unavailable.",
          "skills": [
            "Idempotency",
            "Distributed failure"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2a57afe0-45ef-4146-911d-5f44deb93e62",
          "key": "AREGION-107",
          "title": "Define regional fallback for unavailable authorization freshness",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "protocol",
          "dependsOn": [
            "AREGION-101",
            "AREGION-105",
            "AREGION-106"
          ],
          "scenario": "A regional endpoint can read cached shipment data but cannot confirm whether the requesting account's access was revoked.",
          "acceptanceCriteria": [
            "Separate data freshness from authorization freshness.",
            "Deny protected reads when required authority is unavailable.",
            "Keep public tracking behavior separately bounded by its policy."
          ],
          "implementationNotes": [
            "Model access revocation with synthetic identities."
          ],
          "verification": [
            "Serve a permitted public tracking response during primary loss.",
            "Revoke a protected reader and verify the regional route does not use stale permission."
          ],
          "deliverables": [
            "Authorization fallback matrix and denial probe"
          ],
          "rollout": "Keep protected reads on fresh authority until the regional adapter meets the contract.",
          "skills": [
            "Authorization consistency",
            "Fail-closed design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d4c6f7dc-1631-404d-8f68-24651633012a",
          "key": "AREGION-108",
          "title": "Model recovery-point and recovery-time limits for a regional outage",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recovery",
          "dependsOn": [
            "AREGION-102",
            "AREGION-105",
            "AREGION-106"
          ],
          "scenario": "A stakeholder asks for zero data loss and immediate recovery even when replication is asynchronous and the primary is unreachable.",
          "acceptanceCriteria": [
            "Define what RPO and RTO mean for the chosen workload.",
            "Calculate loss and recovery bounds from explicit lag and detection assumptions.",
            "Identify guarantees the design cannot currently provide."
          ],
          "implementationNotes": [
            "Use hypothetical numbers and separate targets from measured results."
          ],
          "verification": [
            "Calculate the declared outage scenario with bounded lag.",
            "Remove the lag bound and show that a finite loss guarantee is unsupported."
          ],
          "deliverables": [
            "Recovery objectives worksheet"
          ],
          "rollout": "Review targets before infrastructure approval; revise guarantees when provider constraints differ.",
          "skills": [
            "Recovery objectives",
            "Risk analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "144d5435-f3a9-48b6-af03-0aa04138dc13",
          "key": "AREGION-109",
          "title": "Reconcile divergent regional observations after connectivity returns",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "recovery",
          "dependsOn": [
            "AREGION-104",
            "AREGION-105",
            "AREGION-108"
          ],
          "scenario": "Support receives screenshots with different shipment states after an outage and needs to explain which accepted version is authoritative.",
          "acceptanceCriteria": [
            "Compare accepted command versions and authority epochs.",
            "Preserve stale observations as observations, not new writes.",
            "Flag missing authoritative history as unresolved."
          ],
          "implementationNotes": [
            "Build a read-only synthetic reconciliation report."
          ],
          "verification": [
            "Reconcile two observed versions against the accepted command log.",
            "Remove an authority segment and report an explicit gap."
          ],
          "deliverables": [
            "Regional reconciliation script"
          ],
          "rollout": "Run read-only after the local outage drill; avoid repair writes until authority is resolved.",
          "skills": [
            "Reconciliation",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "77ac7a28-0862-42e5-b269-53d2cf9d8829",
          "key": "AREGION-110",
          "title": "Write the staged regional-read adoption and rollback plan",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "recovery",
          "dependsOn": [
            "AREGION-103",
            "AREGION-107",
            "AREGION-109"
          ],
          "scenario": "The architecture review approves a limited regional tracking view, but the rollout ticket still says switch all traffic.",
          "acceptanceCriteria": [
            "Start with the approved read class and synthetic cohort.",
            "Define freshness and denial checks before wider routing.",
            "Rollback by restoring primary routing without rewriting accepted data."
          ],
          "implementationNotes": [
            "Include unresolved dependencies as explicit blockers."
          ],
          "verification": [
            "Walk a permitted tracking request through the proposed rollout.",
            "Trigger stale authorization and verify protected traffic stays on the declared safe path."
          ],
          "deliverables": [
            "Regional adoption plan and decision checklist"
          ],
          "rollout": "Review the plan with the local simulator; retain a primary-routing override for recovery.",
          "skills": [
            "Rollout design",
            "Architecture communication"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "68fae2f7-7dba-4d95-9336-9fd78bf24cf2",
      "key": "ANOTIFY",
      "title": "Design notification delivery around preferences and receipts",
      "field": "System design",
      "summary": "Separate notification intent, delivery attempts and user-visible receipt semantics.",
      "context": "A fictional collaboration tool sends email and in-app notifications. Duplicate alerts and preference changes reveal that the design has no single definition of delivery.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Provider interfaces"
      ],
      "prerequisites": [
        "Create synthetic recipients, events and fake delivery providers.",
        "Do not send real email or messages."
      ],
      "developerValue": "Practice asynchronous contracts, preference timing and delivery uncertainty.",
      "companyValue": "Review a notification design that controls nuisance, disclosure and recovery.",
      "delivery": "Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup.",
      "phases": [
        {
          "id": "intent",
          "title": "Define communication intent",
          "goal": "Identify recipients, semantics and privacy boundaries."
        },
        {
          "id": "delivery",
          "title": "Specify delivery contracts",
          "goal": "Handle preference changes, retries and provider uncertainty."
        },
        {
          "id": "operations",
          "title": "Validate operating behavior",
          "goal": "Model load and rehearse recovery without real messaging."
        }
      ],
      "tickets": [
        {
          "id": "b5df5ea3-1af8-4e35-903f-73b79818167c",
          "key": "ANOTIFY-101",
          "title": "Separate notification intent from channel delivery and human receipt",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "intent",
          "dependsOn": [],
          "scenario": "Product labels a notification delivered when an email provider accepts it, though no human receipt is observed.",
          "acceptanceCriteria": [
            "Define intent, attempted, provider-accepted and observed-read states.",
            "Keep channel-specific facts separate.",
            "Avoid claiming reading from provider acceptance."
          ],
          "implementationNotes": [
            "Use synthetic provider receipts and explicit unknown states."
          ],
          "verification": [
            "Map an accepted email and an opened in-app item separately.",
            "Timeout the provider and retain unknown delivery rather than sent."
          ],
          "deliverables": [
            "Notification semantics table"
          ],
          "rollout": "Adopt precise status labels in the prototype; preserve uncertain older observations.",
          "skills": [
            "Domain modeling",
            "Delivery semantics"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "84b7be4c-5712-40f1-a5d3-68903c6b5d3d",
          "key": "ANOTIFY-102",
          "title": "Specify recipient resolution without copying event payloads broadly",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "intent",
          "dependsOn": [
            "ANOTIFY-101"
          ],
          "scenario": "The event producer includes every collaborator's contact details so downstream handlers can decide recipients.",
          "acceptanceCriteria": [
            "Resolve recipients through a scoped authority boundary.",
            "Keep generic event payloads to opaque identifiers.",
            "Authorize recipient access before creating a channel attempt."
          ],
          "implementationNotes": [
            "Use synthetic addresses and a dedicated contact provider fake."
          ],
          "verification": [
            "Resolve members of the correct synthetic workspace.",
            "Request recipients across workspaces and produce no channel attempts."
          ],
          "deliverables": [
            "Recipient-resolution contract"
          ],
          "rollout": "Review the contract before broad event publication; quarantine events without valid scope.",
          "skills": [
            "Privacy boundaries",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d35d1b68-fddd-40d5-a06e-9aa0fa4eb7b3",
          "key": "ANOTIFY-103",
          "title": "Choose when notification preferences are evaluated",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "intent",
          "dependsOn": [
            "ANOTIFY-101",
            "ANOTIFY-102"
          ],
          "scenario": "A user opts out after an event is queued but still receives the email, and the team has no documented policy.",
          "acceptanceCriteria": [
            "Compare preference-at-intent and preference-at-send semantics.",
            "Choose and document behavior for opt-out and critical notices.",
            "Define how a changed preference version affects queued work."
          ],
          "implementationNotes": [
            "Do not silently invent a legal or mandatory-notice requirement."
          ],
          "verification": [
            "Trace an opt-out between event and send.",
            "Trace a missing preference record under the declared default policy."
          ],
          "deliverables": [
            "Preference-timing architecture decision"
          ],
          "rollout": "Review with product before adapter work; keep unresolved categories unsent.",
          "skills": [
            "Tradeoff analysis",
            "Preference design"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "df59929a-f99f-4e04-9b4b-ae9fa27327ce",
          "key": "ANOTIFY-104",
          "title": "Model notification intent and dispatch in one durable transaction",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "delivery",
          "dependsOn": [
            "ANOTIFY-102",
            "ANOTIFY-103"
          ],
          "scenario": "A collaboration action commits but crashes before queue publication, so some recipients never receive an alert.",
          "acceptanceCriteria": [
            "Persist domain reference and notification intent atomically.",
            "Use an outbox fact with deterministic intent identity.",
            "Make repeated event delivery resolve the same logical intent."
          ],
          "implementationNotes": [
            "Keep intent creation inside the existing modular application boundary."
          ],
          "verification": [
            "Crash after action commit and replay the outbox to one intent.",
            "Repeat the originating event and verify no duplicate recipient intent."
          ],
          "deliverables": [
            "Intent/outbox model and interruption probe"
          ],
          "rollout": "Use a local provider fake initially; pause originating notifications if intent persistence fails.",
          "skills": [
            "Transactional outbox",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "38dfb67d-7f42-4396-97b5-57be7c8a9f33",
          "key": "ANOTIFY-105",
          "title": "Design per-channel attempt identity and provider reconciliation",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "delivery",
          "dependsOn": [
            "ANOTIFY-101",
            "ANOTIFY-104"
          ],
          "scenario": "The email provider times out after accepting a request; retrying blindly sends the same message twice.",
          "acceptanceCriteria": [
            "Bind each logical channel delivery to a stable provider key.",
            "Represent unknown acceptance and define a status lookup path.",
            "Document provider limitations that prevent exactly-once claims."
          ],
          "implementationNotes": [
            "The local fake must support accepted-but-response-lost behavior."
          ],
          "verification": [
            "Reconcile lost response to one accepted synthetic delivery.",
            "Use a provider without lookup support and retain an explicit uncertain state."
          ],
          "deliverables": [
            "Channel contract and uncertainty probe"
          ],
          "rollout": "Select adapters only after contract review; stop automatic retries where duplicate risk is unresolved.",
          "skills": [
            "Distributed contracts",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c4d4f6c2-aba2-4bce-a6d3-c40683740dc1",
          "key": "ANOTIFY-106",
          "title": "Bound notification fan-out without creating one huge transaction",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "delivery",
          "dependsOn": [
            "ANOTIFY-102",
            "ANOTIFY-104"
          ],
          "scenario": "One workspace event targets 50,000 hypothetical members and the proposed transaction attempts to create every delivery row at once.",
          "acceptanceCriteria": [
            "Specify bounded recipient pages and stable page checkpoints.",
            "Preserve one logical intent per recipient across retries.",
            "Define membership snapshot versus live-membership semantics."
          ],
          "implementationNotes": [
            "Use a synthetic membership generator with documented cardinality."
          ],
          "verification": [
            "Process a 1,000-recipient local sample in fixed-size pages.",
            "Interrupt a page and resume without duplicate recipient intents."
          ],
          "deliverables": [
            "Fan-out plan and checkpoint prototype"
          ],
          "rollout": "Validate with local samples before wider scale assumptions; pause dispatch while keeping checkpoints.",
          "skills": [
            "Fan-out",
            "Batching"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "21853cf6-e439-4e52-a7d6-a54f1ddfc726",
          "key": "ANOTIFY-107",
          "title": "Keep in-app notification reads separate from email provider state",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "delivery",
          "dependsOn": [
            "ANOTIFY-101",
            "ANOTIFY-105",
            "ANOTIFY-106"
          ],
          "scenario": "Marking an in-app alert read currently suppresses an unrelated email retry by changing one shared status column.",
          "acceptanceCriteria": [
            "Model channel delivery and in-app acknowledgement separately.",
            "Bind acknowledgement to the authenticated recipient.",
            "Preserve delivery-attempt history after acknowledgement."
          ],
          "implementationNotes": [
            "Use an explicit read model for the in-app feed."
          ],
          "verification": [
            "Mark one in-app item read and retain email attempt state.",
            "Acknowledge another recipient's item and reject it."
          ],
          "deliverables": [
            "Read-model contract and channel-isolation probe"
          ],
          "rollout": "Prototype the read model behind a local route; revert read wiring without changing delivery history.",
          "skills": [
            "State separation",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "dbbab7af-cd4a-4b6e-8acb-9331c29ff505",
          "key": "ANOTIFY-108",
          "title": "Calculate notification drain time under a channel rate limit",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operations",
          "dependsOn": [
            "ANOTIFY-105",
            "ANOTIFY-106"
          ],
          "scenario": "A launch generates a burst of alerts, but the architecture plan ignores provider quotas and retry traffic.",
          "acceptanceCriteria": [
            "Model initial backlog, arrival rate and provider throughput.",
            "Reserve capacity for retries within a bounded budget.",
            "Show conditions where backlog cannot drain."
          ],
          "implementationNotes": [
            "Use explicitly hypothetical rates and an executable calculation."
          ],
          "verification": [
            "Calculate drain time for a named burst and fixed delivery rate.",
            "Raise arrivals above capacity and report unbounded growth instead of a finite answer."
          ],
          "deliverables": [
            "Capacity calculator and quota assumptions"
          ],
          "rollout": "Use results to propose admission and batching limits; replace assumptions before real rollout.",
          "skills": [
            "Queueing",
            "Capacity analysis"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "cb148329-cdd7-451a-ac00-87cddaedc084",
          "key": "ANOTIFY-109",
          "title": "Exercise preference revocation during a notification backlog",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operations",
          "dependsOn": [
            "ANOTIFY-103",
            "ANOTIFY-105",
            "ANOTIFY-108"
          ],
          "scenario": "A user disables a channel while thousands of queued intents wait for provider quota, exposing ambiguous preference timing.",
          "acceptanceCriteria": [
            "Apply the chosen preference-timing policy consistently.",
            "Record suppressed versus attempted outcomes without contact details.",
            "Keep already accepted provider facts immutable."
          ],
          "implementationNotes": [
            "Use a local backlog and fake provider; send no real messages."
          ],
          "verification": [
            "Change preferences before a queued intent reaches its decision boundary.",
            "Change preferences after provider acceptance and preserve the accepted fact without claiming recall."
          ],
          "deliverables": [
            "Backlog preference drill and outcome trace"
          ],
          "rollout": "Run before adapter approval; suspend the affected category if policy and implementation diverge.",
          "skills": [
            "Policy consistency",
            "Fault scenarios"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "32bc4eda-18ec-4586-96b8-2415c28e5872",
          "key": "ANOTIFY-110",
          "title": "Document notification architecture limits for stakeholder review",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "operations",
          "dependsOn": [
            "ANOTIFY-105",
            "ANOTIFY-108",
            "ANOTIFY-109"
          ],
          "scenario": "The launch plan describes exactly-once delivery and confirmed readership even though the provider contract supports neither.",
          "acceptanceCriteria": [
            "List supported guarantees and unresolved provider dependencies.",
            "Link each guarantee to a contract or local probe.",
            "Include retry suspension and backlog recovery decisions."
          ],
          "implementationNotes": [
            "State that local tests do not prove real provider delivery."
          ],
          "verification": [
            "Trace an accepted guarantee to its executable probe.",
            "Identify an unsupported receipt claim and replace it with the observed state."
          ],
          "deliverables": [
            "Notification design review packet"
          ],
          "rollout": "Review the packet before provider rollout; revise claims when adapter evidence changes.",
          "skills": [
            "Technical communication",
            "Architecture review"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 70
            },
            {
              "field": "Integrations",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "09159d14-2fc2-426c-91cd-3728b0ebc2af",
      "key": "AARCHIVE",
      "title": "Design a searchable audit archive with retention boundaries",
      "field": "System design",
      "summary": "Choose storage, indexing and deletion semantics for a bounded audit archive.",
      "context": "A fictional procurement platform keeps append-only action records. Operators want fast recent search and affordable old records without losing provenance or leaking tenant data.",
      "stack": [
        "PostgreSQL",
        "Object storage",
        "TypeScript"
      ],
      "prerequisites": [
        "Create synthetic audit events and local storage/search adapters.",
        "Use an explicit fictional retention policy, not legal advice."
      ],
      "developerValue": "Practice storage tradeoffs, provenance and data-lifecycle decisions.",
      "companyValue": "Review archive cost and retrieval guarantees before committing to infrastructure.",
      "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": "needs",
          "title": "Define archive guarantees",
          "goal": "Specify access, retention and search expectations."
        },
        {
          "id": "contract",
          "title": "Model archive boundaries",
          "goal": "Make manifests, indexing and retrieval verifiable."
        },
        {
          "id": "lifecycle",
          "title": "Challenge long-term behavior",
          "goal": "Rehearse retention, restoration and cost changes."
        }
      ],
      "tickets": [
        {
          "id": "97196953-8185-4d77-8010-69f6a11aa840",
          "key": "AARCHIVE-101",
          "title": "Define which audit questions require indexed search versus archive retrieval",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "needs",
          "dependsOn": [],
          "scenario": "The design says all audit history must be instantly searchable, but reviewers usually inspect the last week and rarely retrieve older cases.",
          "acceptanceCriteria": [
            "List recent search and older retrieval use cases separately.",
            "State hypothetical latency and date-range targets.",
            "Identify fields that may be indexed without exposing payload contents."
          ],
          "implementationNotes": [
            "Use fabricated events and a named review workflow."
          ],
          "verification": [
            "Map a recent actor search to its target.",
            "Map an old case retrieval to the declared slower path without claiming instant search."
          ],
          "deliverables": [
            "Archive access-pattern inventory"
          ],
          "rollout": "Review the inventory before choosing storage; keep unapproved fields out of indexes.",
          "skills": [
            "Access-pattern analysis",
            "Requirements"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 20
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fa35ba05-5cb4-41b3-8d70-5cf944a18c18",
          "key": "AARCHIVE-102",
          "title": "Calculate archive storage growth from event size and retention assumptions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "needs",
          "dependsOn": [
            "AARCHIVE-101"
          ],
          "scenario": "A budget proposal counts raw event bytes but omits index, replica and manifest overhead.",
          "acceptanceCriteria": [
            "Model events per day, average bytes and retention duration.",
            "Show raw, index and redundancy components separately.",
            "Label compression and growth factors as assumptions."
          ],
          "implementationNotes": [
            "Provide a small executable worksheet with no claimed measured savings."
          ],
          "verification": [
            "Calculate the baseline synthetic scenario.",
            "Double event volume and vary compression to show sensitivity."
          ],
          "deliverables": [
            "Storage-growth model"
          ],
          "rollout": "Use the model for a reviewed budget proposal; update it after real storage measurements.",
          "skills": [
            "Capacity modeling",
            "Cost reasoning"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ae94897e-1015-435b-89c6-973981d41f4f",
          "key": "AARCHIVE-103",
          "title": "Choose hot and cold archive boundaries with a reviewable decision record",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "needs",
          "dependsOn": [
            "AARCHIVE-101",
            "AARCHIVE-102"
          ],
          "scenario": "The team proposes a new search cluster before checking whether bounded PostgreSQL search and object retrieval satisfy the workload.",
          "acceptanceCriteria": [
            "Compare existing database search with a separate index option.",
            "Include consistency, operational and restore costs.",
            "Choose the smallest option meeting the stated requirements."
          ],
          "implementationNotes": [
            "Do not provision speculative infrastructure for this design exercise."
          ],
          "verification": [
            "Evaluate both options against recent and old queries.",
            "Identify the threshold or query need that would reopen the decision."
          ],
          "deliverables": [
            "Archive storage decision record"
          ],
          "rollout": "Review the decision against the workload model before implementing new infrastructure.",
          "skills": [
            "Architecture decisions",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "db9c63b5-57e8-4dbb-b889-7308fadd4dcb",
          "key": "AARCHIVE-104",
          "title": "Define an immutable archive segment manifest",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "contract",
          "dependsOn": [
            "AARCHIVE-103"
          ],
          "scenario": "An exported audit file has no trusted count or content identity, so operators cannot tell whether a partial upload is complete.",
          "acceptanceCriteria": [
            "Manifest binds segment ID, record count, range and byte hash.",
            "Publish a segment only after verifying its stored identity.",
            "Retain original event identifiers across archival."
          ],
          "implementationNotes": [
            "Use canonical synthetic serialization and exact object versions."
          ],
          "verification": [
            "Archive and verify a complete segment.",
            "Truncate bytes or alter count and reject publication."
          ],
          "deliverables": [
            "Segment contract and integrity probe"
          ],
          "rollout": "Prototype manifests alongside synthetic exports; keep unverified segments out of search.",
          "skills": [
            "Integrity",
            "Storage contracts"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2f76ad51-190f-4ffb-980b-c3d3d7357ce2",
          "key": "AARCHIVE-105",
          "title": "Specify search indexing as a rebuildable projection of archived events",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "contract",
          "dependsOn": [
            "AARCHIVE-104"
          ],
          "scenario": "A search result is edited directly to correct an event, creating a version of history absent from the source archive.",
          "acceptanceCriteria": [
            "Treat the index as a projection with source segment identity.",
            "Corrections append new events rather than rewrite archived facts.",
            "Define checkpoint and duplicate-indexing semantics."
          ],
          "implementationNotes": [
            "Use an in-memory search adapter for the contract probe."
          ],
          "verification": [
            "Rebuild the index from named manifests and preserve event identities.",
            "Replay a segment and verify no duplicate search records."
          ],
          "deliverables": [
            "Index projection model and replay test"
          ],
          "rollout": "Build a shadow index generation; switch only after source-count reconciliation.",
          "skills": [
            "Projection design",
            "Append-only modeling"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "029354cd-5126-43f7-9d74-939acc35ce20",
          "key": "AARCHIVE-106",
          "title": "Authorize archive retrieval before issuing object capabilities",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "contract",
          "dependsOn": [
            "AARCHIVE-104",
            "AARCHIVE-105"
          ],
          "scenario": "An audit search hit contains a raw object key; clients can request other tenants' segments by changing that key.",
          "acceptanceCriteria": [
            "Resolve event and segment within the caller's authorized tenant.",
            "Issue a capability scoped to the exact object version.",
            "Avoid exposing neighboring events through shared-segment retrieval."
          ],
          "implementationNotes": [
            "Choose per-tenant segments or a server-side filtered retrieval contract."
          ],
          "verification": [
            "Retrieve a permitted synthetic event through the chosen boundary.",
            "Alter tenant or segment identity and verify no capability is issued."
          ],
          "deliverables": [
            "Archive access contract and cross-tenant probe"
          ],
          "rollout": "Keep raw objects private; enable retrieval only after the projection isolation checks pass.",
          "skills": [
            "Authorization architecture",
            "Data isolation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "01b13afd-0755-47f6-84f7-5370df891389",
          "key": "AARCHIVE-107",
          "title": "Define archive query pagination across hot and cold boundaries",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "contract",
          "dependsOn": [
            "AARCHIVE-103",
            "AARCHIVE-105",
            "AARCHIVE-106"
          ],
          "scenario": "A query spanning the archive cutoff repeats recent events and misses records moved between stores during pagination.",
          "acceptanceCriteria": [
            "Bind the cursor to a declared snapshot or generation.",
            "Specify stable ordering and deduplication by event identity.",
            "Return explicit partial or unavailable states for missing segments."
          ],
          "implementationNotes": [
            "Model movement with local fixtures rather than live archive jobs."
          ],
          "verification": [
            "Page across a cutoff while a segment moves and retain complete ordering.",
            "Make one segment unavailable and report the gap without a complete-result claim."
          ],
          "deliverables": [
            "Cross-store query contract and boundary cases"
          ],
          "rollout": "Canary bounded date queries; fall back to separate hot/cold retrieval if completeness is uncertain.",
          "skills": [
            "Pagination",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f28f8ae0-c60c-4aab-9d94-f3c652da964c",
          "key": "AARCHIVE-108",
          "title": "Model retention as a policy decision separate from audit immutability",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "lifecycle",
          "dependsOn": [
            "AARCHIVE-104",
            "AARCHIVE-106",
            "AARCHIVE-107"
          ],
          "scenario": "Stakeholders confuse append-only records with keeping every payload forever, while the archive has a fictional bounded retention agreement.",
          "acceptanceCriteria": [
            "Specify retention scope, expiry and hold behavior.",
            "Preserve authorized deletion facts without claiming deleted bytes remain available.",
            "Identify which policy decisions need external approval before implementation."
          ],
          "implementationNotes": [
            "Use a fictional policy and synthetic data; make no legal compliance claim."
          ],
          "verification": [
            "Apply expiry to an eligible segment in the model.",
            "Apply a hold and show that deletion remains blocked."
          ],
          "deliverables": [
            "Retention model and policy-state probe"
          ],
          "rollout": "Review policy before any delete implementation; keep proposed deletion plans read-only.",
          "skills": [
            "Data lifecycle",
            "Policy modeling"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "01fccf7f-ffbf-4e30-81f0-b5a8a2a3a638",
          "key": "AARCHIVE-109",
          "title": "Rehearse archive restoration from manifests after index loss",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "lifecycle",
          "dependsOn": [
            "AARCHIVE-104",
            "AARCHIVE-105",
            "AARCHIVE-108"
          ],
          "scenario": "The search projection is lost, but the recovery plan assumes an index backup rather than using the authoritative archive.",
          "acceptanceCriteria": [
            "Restore a new index generation from verified segments.",
            "Report corrupt or missing segments separately from indexed count.",
            "Keep queries from mixing partial and complete generations."
          ],
          "implementationNotes": [
            "Use a small synthetic archive with one intentionally damaged segment."
          ],
          "verification": [
            "Rebuild from complete manifests and compare query identities.",
            "Include the damaged segment and block a complete-generation claim."
          ],
          "deliverables": [
            "Restoration drill and completeness report"
          ],
          "rollout": "Run the drill before archive activation; retain the old searchable generation until reconciliation succeeds.",
          "skills": [
            "Recovery design",
            "Integrity verification"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f25c2512-94f8-43b8-a337-1963aa1f5f3a",
          "key": "AARCHIVE-110",
          "title": "Prepare the archive architecture review with explicit retrieval limits",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "lifecycle",
          "dependsOn": [
            "AARCHIVE-102",
            "AARCHIVE-107",
            "AARCHIVE-109"
          ],
          "scenario": "A roadmap summary promises unlimited search and permanent audit availability despite the bounded design.",
          "acceptanceCriteria": [
            "Summarize workload, retention and recovery assumptions.",
            "Link claims to manifest, authorization and restore probes.",
            "List deferred infrastructure and unresolved provider capabilities."
          ],
          "implementationNotes": [
            "Avoid presenting the local simulator as production storage readiness."
          ],
          "verification": [
            "Trace a recent-query guarantee to its contract.",
            "Trace a missing-segment scenario and document the user-visible limitation."
          ],
          "deliverables": [
            "Archive design review packet"
          ],
          "rollout": "Review before storage commitment; revise the packet when retention or retrieval requirements change.",
          "skills": [
            "Architecture communication",
            "Evidence-based review"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "40608db5-35cd-4637-b5a2-3043fef5b1b7",
      "key": "AADMIT",
      "title": "Design admission control for scheduled report generation",
      "field": "System design",
      "summary": "Define fair scheduling, bounded work and recovery for a report service.",
      "context": "A fictional analytics product lets customers schedule expensive reports at the top of the hour. The API remains available only if report work is admitted and cancelled predictably.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "BullMQ"
      ],
      "prerequisites": [
        "Create a local scheduler model and synthetic report jobs.",
        "Use fake execution providers; no customer queries or candidate code run on worker hosts."
      ],
      "developerValue": "Practice workload modeling, fairness and cancellation architecture.",
      "companyValue": "Review controllable operating costs and predictable customer-facing overload behavior.",
      "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": "load",
          "title": "Define load and fairness",
          "goal": "Make demand and service objectives explicit."
        },
        {
          "id": "control",
          "title": "Specify admission and work ownership",
          "goal": "Bound queues, retries and cancellation."
        },
        {
          "id": "stress",
          "title": "Challenge overload behavior",
          "goal": "Model burst recovery and review operating limits."
        }
      ],
      "tickets": [
        {
          "id": "8ba0ed0d-54d5-43f9-9a53-6e0f0300a086",
          "key": "AADMIT-101",
          "title": "Build a report arrival model that includes top-of-hour bursts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "load",
          "dependsOn": [],
          "scenario": "Average reports per minute looks harmless, but nearly every customer chooses 09:00 for its daily report.",
          "acceptanceCriteria": [
            "Separate average arrival rate from burst size.",
            "State hypothetical report duration and size classes.",
            "Include timezone scheduling assumptions."
          ],
          "implementationNotes": [
            "Create a deterministic synthetic one-day schedule."
          ],
          "verification": [
            "Count average arrivals and the largest one-minute burst.",
            "Move all schedules to one instant and show the peak changes despite equal daily volume."
          ],
          "deliverables": [
            "Arrival model and reproducible schedule generator"
          ],
          "rollout": "Review the model before queue sizing; revise assumptions when schedule usage is measured.",
          "skills": [
            "Workload modeling",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fa744788-c136-4ecc-afd1-2b1050ad1a5b",
          "key": "AADMIT-102",
          "title": "Define customer-visible report states and overload responses",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "load",
          "dependsOn": [
            "AADMIT-101"
          ],
          "scenario": "The API returns accepted for jobs that may wait indefinitely, so customers repeatedly click generate.",
          "acceptanceCriteria": [
            "Distinguish rejected, queued, running and terminal states.",
            "Specify bounded queue age and a retryable admission response.",
            "Define what acceptance durably guarantees."
          ],
          "implementationNotes": [
            "Use explicit state transitions and stable job identities."
          ],
          "verification": [
            "Trace an admitted report to its durable queue state.",
            "Reject an over-capacity request without creating a phantom report."
          ],
          "deliverables": [
            "Admission response contract and state table"
          ],
          "rollout": "Review the contract before accepting schedules; keep overload behavior explicit in the prototype.",
          "skills": [
            "API design",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1a98ca58-7afc-425d-8917-3dd341022e3c",
          "key": "AADMIT-103",
          "title": "Record the fairness decision for small and large report tenants",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "load",
          "dependsOn": [
            "AADMIT-101",
            "AADMIT-102"
          ],
          "scenario": "A single tenant's weekly exports occupy every available slot while small interactive reports wait behind them.",
          "acceptanceCriteria": [
            "Compare FIFO, per-tenant limits and weighted scheduling.",
            "Define fairness and starvation expectations.",
            "Document how unknown report cost is classified."
          ],
          "implementationNotes": [
            "Use a small synthetic tenant set and avoid hiring or user scoring."
          ],
          "verification": [
            "Evaluate a mixed small/large workload against the chosen rule.",
            "Show the behavior when one tenant continuously submits work."
          ],
          "deliverables": [
            "Fairness decision record"
          ],
          "rollout": "Review the chosen policy with the workload model; retain configuration for bounded tuning.",
          "skills": [
            "Scheduling tradeoffs",
            "Fairness"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e8b6d914-6122-4995-bfc6-0d61adbc8d55",
          "key": "AADMIT-104",
          "title": "Specify transactional report admission with deterministic job identities",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "AADMIT-102",
            "AADMIT-103"
          ],
          "scenario": "A scheduler creates report rows but loses queue publication, leaving accepted work with no execution path.",
          "acceptanceCriteria": [
            "Commit admission and outbox fact atomically.",
            "Bind job identity to schedule occurrence or request key.",
            "Make repeated dispatch resolve one logical job."
          ],
          "implementationNotes": [
            "Keep lifecycle authority in the durable service boundary."
          ],
          "verification": [
            "Crash after admission commit and recover dispatch.",
            "Replay the same scheduled occurrence and count one report."
          ],
          "deliverables": [
            "Admission/outbox contract and crash probe"
          ],
          "rollout": "Prototype with a fake executor; stop new admission if durable dispatch cannot be recorded.",
          "skills": [
            "Transactional outbox",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b587096d-ae53-4945-a9c5-d734cb9ccf09",
          "key": "AADMIT-105",
          "title": "Design cancellation ownership for queued and running reports",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "control",
          "dependsOn": [
            "AADMIT-102",
            "AADMIT-104"
          ],
          "scenario": "A user cancels a report, but the worker later publishes a completed artifact and overwrites the cancellation status.",
          "acceptanceCriteria": [
            "Define cancellation request versus confirmed stop.",
            "Fence stale completion against current generation and state.",
            "Specify cleanup ownership for incomplete artifacts."
          ],
          "implementationNotes": [
            "Use a provider cancellation contract; do not kill host processes arbitrarily."
          ],
          "verification": [
            "Cancel queued work and verify no execution begins.",
            "Race cancellation with completion and preserve the declared single terminal outcome."
          ],
          "deliverables": [
            "Cancellation protocol and race model"
          ],
          "rollout": "Canary cancellation in the local provider; retain unresolved stop status when provider confirmation is unavailable.",
          "skills": [
            "Cancellation design",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4f1d61c1-ad38-4817-9864-7c1c163ac668",
          "key": "AADMIT-106",
          "title": "Bound retries so failing reports cannot consume the entire service",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "control",
          "dependsOn": [
            "AADMIT-103",
            "AADMIT-104",
            "AADMIT-105"
          ],
          "scenario": "A malformed report fails immediately and retries faster than healthy reports can start.",
          "acceptanceCriteria": [
            "Define retry count, backoff and elapsed-time budgets.",
            "Classify permanent versus retryable failure explicitly.",
            "Keep retry work inside tenant and global admission limits."
          ],
          "implementationNotes": [
            "Use deterministic fake time and bounded jitter inputs."
          ],
          "verification": [
            "Retry a transient failure within the declared budget.",
            "Feed a permanent failure and verify it cannot form a tight retry loop."
          ],
          "deliverables": [
            "Retry-budget model and scheduling probe"
          ],
          "rollout": "Enable bounded retries for synthetic jobs; suspend a failing class if classification is uncertain.",
          "skills": [
            "Retry policy",
            "Resource budgets"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b9ec6557-fb1b-43af-b467-f6ab1c2f0db5",
          "key": "AADMIT-107",
          "title": "Choose where report artifacts become authoritative",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "control",
          "dependsOn": [
            "AADMIT-104",
            "AADMIT-105"
          ],
          "scenario": "A worker uploads a partial file and the API exposes its object key before completion checks finish.",
          "acceptanceCriteria": [
            "Stage artifacts under a job generation.",
            "Publish only after verified storage identity and guarded completion.",
            "Keep incomplete or stale-generation artifacts inaccessible."
          ],
          "implementationNotes": [
            "Separate object upload from user-visible report publication."
          ],
          "verification": [
            "Publish a verified synthetic artifact for the active job.",
            "Complete an older generation and verify it cannot replace the visible result."
          ],
          "deliverables": [
            "Artifact publication boundary and contract probe"
          ],
          "rollout": "Prototype with local storage; keep staged objects private until finalization succeeds.",
          "skills": [
            "Storage lifecycle",
            "System boundaries"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b1c2d8ac-ee40-4ba1-88e8-77c6338b3ad0",
          "key": "AADMIT-108",
          "title": "Calculate burst drain time with fairness and retry reservations",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "stress",
          "dependsOn": [
            "AADMIT-101",
            "AADMIT-103",
            "AADMIT-106"
          ],
          "scenario": "Operations wants a queue-age target, but the capacity spreadsheet assumes every slot is always available for first attempts.",
          "acceptanceCriteria": [
            "Model concurrency, service-time classes and reserved retry capacity.",
            "Calculate per-tenant wait under the selected fairness rule.",
            "Show when queue-age targets cannot be met."
          ],
          "implementationNotes": [
            "Use hypothetical durations and an executable deterministic simulation."
          ],
          "verification": [
            "Simulate the declared top-of-hour burst.",
            "Double expensive reports and report target violations without inventing a speedup."
          ],
          "deliverables": [
            "Queue simulation and capacity worksheet"
          ],
          "rollout": "Use the model to propose reviewed limits; validate assumptions with real isolated measurements before deployment.",
          "skills": [
            "Queueing analysis",
            "Capacity planning"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "be761ff0-1cd2-4c43-a5cc-5e27c504bcf4",
          "key": "AADMIT-109",
          "title": "Rehearse scheduler restart while reports are queued and running",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "stress",
          "dependsOn": [
            "AADMIT-104",
            "AADMIT-105",
            "AADMIT-107",
            "AADMIT-108"
          ],
          "scenario": "The scheduling process restarts during a burst, and the design must explain which work is resumed, reconciled or left uncertain.",
          "acceptanceCriteria": [
            "Recover queued ownership from durable identities.",
            "Reconcile running jobs through provider status before retry.",
            "Preserve accepted artifacts and terminal outcomes."
          ],
          "implementationNotes": [
            "Inject failures in a local state model and fake provider."
          ],
          "verification": [
            "Restart with queued and completed synthetic jobs and converge correctly.",
            "Restart with an unknown provider outcome and keep it unresolved instead of duplicating work."
          ],
          "deliverables": [
            "Restart drill and recovery trace"
          ],
          "rollout": "Run before accepting real schedules; pause admissions if recovery cannot establish work ownership.",
          "skills": [
            "Recovery protocols",
            "Fault injection"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c141387e-1daa-44c7-8448-1e940e3ede6c",
          "key": "AADMIT-110",
          "title": "Write the report-service operating contract for design approval",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "stress",
          "dependsOn": [
            "AADMIT-102",
            "AADMIT-108",
            "AADMIT-109"
          ],
          "scenario": "A launch checklist says scalable reporting without naming admission limits, cancellation guarantees or unavailable-provider behavior.",
          "acceptanceCriteria": [
            "Summarize admitted workload, fairness and bounded queue behavior.",
            "Link each guarantee to a model or probe.",
            "List deferred execution-provider and production-measurement work."
          ],
          "implementationNotes": [
            "Keep design approval separate from production readiness."
          ],
          "verification": [
            "Trace a queue-age target to its simulation assumptions.",
            "Trace provider unavailability to a documented pending or rejected outcome."
          ],
          "deliverables": [
            "Operating contract and architecture review notes"
          ],
          "rollout": "Review before infrastructure commitment; update limits when measurement evidence replaces assumptions.",
          "skills": [
            "Operational design",
            "Technical communication"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "55c7d0ee-f9e3-4569-ab54-2b73b54f315c",
      "key": "AMIGRATE",
      "title": "Migrate customer identifiers without breaking old clients",
      "field": "Database engineering",
      "summary": "Replace a legacy customer key through additive schema changes and verified backfill.",
      "context": "A fictional support platform stores a mutable external account code as its primary relationship key. Renames and imports now break references in several tables.",
      "stack": [
        "PostgreSQL",
        "Prisma",
        "TypeScript"
      ],
      "prerequisites": [
        "Create a disposable database with synthetic customers and dependent records.",
        "Apply real migration files; never use production db push."
      ],
      "developerValue": "Practice migration ordering, compatibility and referential integrity.",
      "companyValue": "Review a reversible schema transition with measurable completeness checks.",
      "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": "expand",
          "title": "Expand the schema safely",
          "goal": "Add stable identities without breaking current reads."
        },
        {
          "id": "bridge",
          "title": "Bridge old and new writers",
          "goal": "Backfill and preserve mixed-version compatibility."
        },
        {
          "id": "contract",
          "title": "Contract after verification",
          "goal": "Remove legacy assumptions only with complete checks."
        }
      ],
      "tickets": [
        {
          "id": "6c1026bd-9b5e-4b68-b665-fb894b921f6d",
          "key": "AMIGRATE-101",
          "title": "Inventory every reference to the mutable customer code",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "expand",
          "dependsOn": [],
          "scenario": "A customer rename updates its main row but leaves case and attachment references pointing to the old code.",
          "acceptanceCriteria": [
            "List database foreign keys and application lookup boundaries.",
            "Classify direct, denormalized and external references.",
            "Record unresolved references before migration design."
          ],
          "implementationNotes": [
            "Use repository search and catalog queries against synthetic schema."
          ],
          "verification": [
            "Trace a customer through cases and attachments.",
            "Add one hidden denormalized fixture reference and ensure the inventory method finds it."
          ],
          "deliverables": [
            "Reference inventory and discovery queries"
          ],
          "rollout": "Review the inventory before migration; keep unknown dependencies as explicit blockers.",
          "skills": [
            "Schema analysis",
            "Referential integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "System design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2801fe20-f64b-4529-9da4-ca46c071f817",
          "key": "AMIGRATE-102",
          "title": "Add immutable customer IDs through an additive migration",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "expand",
          "dependsOn": [
            "AMIGRATE-101"
          ],
          "scenario": "The migration needs stable customer identity while current clients continue using external codes.",
          "acceptanceCriteria": [
            "Add an opaque unique customer ID with a safe creation path.",
            "Keep legacy code uniqueness under its current scope.",
            "Do not remove or rename existing columns yet."
          ],
          "implementationNotes": [
            "Use a migration file and inspect generated SQL."
          ],
          "verification": [
            "Apply the migration to a populated synthetic database.",
            "Attempt duplicate immutable identity and verify a database rejection."
          ],
          "deliverables": [
            "Additive migration and schema assertions"
          ],
          "rollout": "Apply to a disposable copy first; rollback additive consumers before considering column removal.",
          "skills": [
            "Migrations",
            "Database constraints"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "481953d5-a5d0-424b-9755-2902357e2862",
          "key": "AMIGRATE-103",
          "title": "Add nullable customer-ID references to dependent tables",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "expand",
          "dependsOn": [
            "AMIGRATE-102"
          ],
          "scenario": "Case rows need the new relationship without requiring a single locking rewrite of the entire dataset.",
          "acceptanceCriteria": [
            "Add the new foreign-key columns without changing current reads.",
            "Index the intended lookup boundary where needed.",
            "Document the later validation and non-null steps."
          ],
          "implementationNotes": [
            "Keep migration operations explicit and bounded to the selected tables."
          ],
          "verification": [
            "Insert an old-client case after the additive migration.",
            "Insert an invalid non-null customer ID and verify the intended foreign-key behavior."
          ],
          "deliverables": [
            "Dependent-table expansion migration"
          ],
          "rollout": "Deploy schema before bridge writers; remove unused new columns only before any consumer relies on them.",
          "skills": [
            "Schema evolution",
            "Foreign keys"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "fd024ec2-da00-46d8-8d64-6446cde5eec0",
          "key": "AMIGRATE-104",
          "title": "Backfill customer IDs with resumable keyset batches",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "bridge",
          "dependsOn": [
            "AMIGRATE-103"
          ],
          "scenario": "A single UPDATE holds locks too long and cannot explain where to resume if the migration job stops.",
          "acceptanceCriteria": [
            "Use a stable cursor and bounded batch size.",
            "Persist progress and count matched, missing and conflicting references.",
            "Update only rows still lacking the new identity."
          ],
          "implementationNotes": [
            "Create a synthetic dataset with deliberately unmatched legacy codes."
          ],
          "verification": [
            "Interrupt and resume the backfill without rewriting completed rows.",
            "Encounter an unmatched code and report it without guessing a customer."
          ],
          "deliverables": [
            "Backfill command and progress report"
          ],
          "rollout": "Dry-run matching first; pause between batches and retain the checkpoint on errors.",
          "skills": [
            "Backfills",
            "Keyset processing"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "565e3e31-91a8-4630-b997-fc141c9bfc2f",
          "key": "AMIGRATE-105",
          "title": "Bridge legacy customer writes to the new identity transactionally",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "bridge",
          "dependsOn": [
            "AMIGRATE-102",
            "AMIGRATE-103",
            "AMIGRATE-104"
          ],
          "scenario": "Old clients create cases using a code while new clients use IDs; both must produce equivalent relationships during rollout.",
          "acceptanceCriteria": [
            "Resolve legacy code within organization inside the write boundary.",
            "Write matching legacy and immutable identity fields together.",
            "Reject contradictory code/ID pairs."
          ],
          "implementationNotes": [
            "Do not let controllers bypass the shared repository method."
          ],
          "verification": [
            "Create equivalent cases through old and new local client contracts.",
            "Supply code for one customer with another ID and verify no row is inserted."
          ],
          "deliverables": [
            "Compatibility writer and contradiction tests"
          ],
          "rollout": "Deploy bridge writers before enabling new-client reads; revert client routing while retaining dual fields.",
          "skills": [
            "Compatibility",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c2bb526b-362a-457b-ba6b-66ea101ecf1e",
          "key": "AMIGRATE-106",
          "title": "Protect customer-code renames during the backfill window",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "bridge",
          "dependsOn": [
            "AMIGRATE-104",
            "AMIGRATE-105"
          ],
          "scenario": "A rename races a batch lookup and attaches a legacy case to the wrong customer when the old code is reused.",
          "acceptanceCriteria": [
            "Resolve against a stable captured mapping or guarded revision.",
            "Prevent ambiguous code reuse during transition.",
            "Keep committed references bound to immutable customer identity."
          ],
          "implementationNotes": [
            "Document the locking or mapping-version strategy."
          ],
          "verification": [
            "Race rename with backfill using two database clients.",
            "Reuse an old code after the allowed boundary and preserve earlier references."
          ],
          "deliverables": [
            "Rename/backfill concurrency guard"
          ],
          "rollout": "Temporarily constrain code reuse under the migration policy; pause backfill on mapping conflicts.",
          "skills": [
            "Concurrency",
            "Migration safety"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6fdb0907-4cc0-4f45-96ef-dd7fc5ed366a",
          "key": "AMIGRATE-107",
          "title": "Verify relationship completeness before making customer IDs mandatory",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "bridge",
          "dependsOn": [
            "AMIGRATE-104",
            "AMIGRATE-105",
            "AMIGRATE-106"
          ],
          "scenario": "The team wants to mark new references non-null, but missing mappings are hidden by a dashboard that counts only completed batches.",
          "acceptanceCriteria": [
            "Count null, orphan and contradictory references separately.",
            "Check rows created during and after backfill.",
            "Fail the readiness check unless every required relationship is valid."
          ],
          "implementationNotes": [
            "Use SQL assertions against the actual synthetic schema."
          ],
          "verification": [
            "Complete valid mappings and pass the readiness query.",
            "Create a late legacy-only row and verify readiness fails."
          ],
          "deliverables": [
            "Completeness gate and SQL assertions"
          ],
          "rollout": "Run repeatedly before constraint changes; leave new columns nullable while gaps remain.",
          "skills": [
            "Data validation",
            "Referential integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7a321823-735d-451a-ac81-f81472fbb3d7",
          "key": "AMIGRATE-108",
          "title": "Validate and enforce the new customer relationship constraints",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "contract",
          "dependsOn": [
            "AMIGRATE-107"
          ],
          "scenario": "Application checks pass, but a direct import can still create a case with an absent new customer identity.",
          "acceptanceCriteria": [
            "Add or validate foreign-key and non-null constraints after readiness.",
            "Document database lock expectations for each migration step.",
            "Reject writes violating the new relationship invariant."
          ],
          "implementationNotes": [
            "Use PostgreSQL-supported staged validation where appropriate; inspect actual SQL."
          ],
          "verification": [
            "Apply the constraint migration after a clean backfill.",
            "Attempt orphan and null references through direct SQL and observe rejection."
          ],
          "deliverables": [
            "Constraint migration and direct-write checks"
          ],
          "rollout": "Apply in a controlled synthetic window; abort on lock contention and preserve the bridge schema.",
          "skills": [
            "Constraint validation",
            "Migration operations"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "ff199277-03c3-49be-a14a-2264d099caeb",
          "key": "AMIGRATE-109",
          "title": "Switch customer reads to immutable IDs with a compatibility fallback plan",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contract",
          "dependsOn": [
            "AMIGRATE-105",
            "AMIGRATE-108"
          ],
          "scenario": "The new writer is deployed, but detail routes still resolve mutable codes and can display the wrong record after a rename.",
          "acceptanceCriteria": [
            "Use immutable IDs for internal relationships and new detail routes.",
            "Keep documented legacy lookup behavior at the API boundary.",
            "Record fallback use without leaking customer payloads."
          ],
          "implementationNotes": [
            "Fallback must remain tenant-scoped and reject ambiguous codes."
          ],
          "verification": [
            "Rename a customer and keep its ID-based detail route stable.",
            "Request an ambiguous legacy code and reject rather than selecting a row."
          ],
          "deliverables": [
            "ID-based read path and compatibility cases"
          ],
          "rollout": "Canary new routes; restore bridge reads if client compatibility fails.",
          "skills": [
            "API migration",
            "Identity modeling"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "26509c72-f358-48c1-acf1-78b21e06cf2e",
          "key": "AMIGRATE-110",
          "title": "Retire legacy customer references only after a rollback rehearsal",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "contract",
          "dependsOn": [
            "AMIGRATE-108",
            "AMIGRATE-109"
          ],
          "scenario": "Dropping old columns would end binary rollback to old readers, but the release checklist does not mention that boundary.",
          "acceptanceCriteria": [
            "Inventory remaining legacy reads and writes before contraction.",
            "Rehearse the last reversible rollback with compatible code.",
            "Document the point after which forward repair is required."
          ],
          "implementationNotes": [
            "Do not drop columns merely because the backfill command completed."
          ],
          "verification": [
            "Run the old-compatible build against the expanded schema.",
            "Attempt the contraction readiness check with one legacy writer and verify it blocks."
          ],
          "deliverables": [
            "Contraction migration plan and rollback evidence"
          ],
          "rollout": "Apply contraction only after reviewed readiness; preserve a tested backup and forward-repair procedure.",
          "skills": [
            "Migration planning",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "e8d4d766-7d14-42f3-a64d-e082f72919f3",
      "key": "ACLAIM",
      "title": "Make a database-backed work assignment queue correct",
      "field": "Database engineering",
      "summary": "Claim, renew and finish work without duplicate authority or stranded assignments.",
      "context": "A fictional inspection service assigns review jobs to staff. Polling clients sometimes claim the same job and a disconnected client can finish work after reassignment.",
      "stack": [
        "PostgreSQL",
        "TypeScript"
      ],
      "prerequisites": [
        "Create synthetic jobs and two independent database clients.",
        "Use explicit state methods and an injected clock."
      ],
      "developerValue": "Practice database concurrency, leases and transactional invariants.",
      "companyValue": "Review whether assignment authority remains reliable during contention and recovery.",
      "delivery": "Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup.",
      "phases": [
        {
          "id": "model",
          "title": "Define assignment invariants",
          "goal": "Represent queue order, ownership and deadlines."
        },
        {
          "id": "claim",
          "title": "Protect concurrent transitions",
          "goal": "Claim, renew and finish with durable authority."
        },
        {
          "id": "recover",
          "title": "Recover stale work",
          "goal": "Inspect contention and repair expired assignments."
        }
      ],
      "tickets": [
        {
          "id": "3fdfabc0-ac34-411a-8ead-76434d07a940",
          "key": "ACLAIM-101",
          "title": "Define assignment states and their required database fields",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Rows marked assigned sometimes have no assignee or lease deadline, making recovery ambiguous.",
          "acceptanceCriteria": [
            "Specify pending, assigned and terminal field invariants.",
            "Add checks that reject contradictory state combinations.",
            "Keep completion metadata distinct from lease metadata."
          ],
          "implementationNotes": [
            "Use migration-backed constraints where practical."
          ],
          "verification": [
            "Insert each valid synthetic state.",
            "Attempt assigned without an assignee or deadline and verify rejection."
          ],
          "deliverables": [
            "Assignment schema and constraint matrix"
          ],
          "rollout": "Apply constraints after inspecting synthetic legacy rows; quarantine invalid states before enabling writes.",
          "skills": [
            "Data modeling",
            "Check constraints"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "704313f1-6190-4f2a-bad7-d310e9a36f98",
          "key": "ACLAIM-102",
          "title": "Order eligible jobs with a stable tie break",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "model",
          "dependsOn": [
            "ACLAIM-101"
          ],
          "scenario": "Jobs created at the same instant appear in a different order on each poll, making starvation difficult to reproduce.",
          "acceptanceCriteria": [
            "Order by declared priority, ready time and opaque job ID.",
            "Exclude future and terminal jobs explicitly.",
            "Bound claim candidate count."
          ],
          "implementationNotes": [
            "Document whether priority changes preserve or reset waiting time."
          ],
          "verification": [
            "Create equal-time jobs and observe stable order.",
            "Include future and completed jobs and verify they are ineligible."
          ],
          "deliverables": [
            "Eligibility query and ordering fixtures"
          ],
          "rollout": "Introduce the query in read-only inspection first; restore previous routing on semantic mismatch.",
          "skills": [
            "SQL ordering",
            "Queue semantics"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "77ecfee2-4d60-445e-a219-96537d7e030c",
          "key": "ACLAIM-103",
          "title": "Scope work assignment queries to the operator's organization",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "ACLAIM-101",
            "ACLAIM-102"
          ],
          "scenario": "The job list is scoped in the controller, but the claim repository accepts a globally valid job ID.",
          "acceptanceCriteria": [
            "Require organization scope at repository entry.",
            "Claim and detail queries enforce that scope.",
            "Return no other-organization job metadata on denial."
          ],
          "implementationNotes": [
            "Test direct repository calls as well as API routes."
          ],
          "verification": [
            "Claim a permitted synthetic job.",
            "Claim another organization's ID and verify unchanged row state."
          ],
          "deliverables": [
            "Tenant-scoped assignment repository"
          ],
          "rollout": "Deploy repository guards before broader polling; inspect safe denial counters.",
          "skills": [
            "Tenant isolation",
            "Repository design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3bb8c64d-f79d-4857-b0c8-4bb2d8afbcf6",
          "key": "ACLAIM-104",
          "title": "Claim one pending job atomically under competing pollers",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "claim",
          "dependsOn": [
            "ACLAIM-102",
            "ACLAIM-103"
          ],
          "scenario": "Two polling clients select the same pending job before either writes its assignment.",
          "acceptanceCriteria": [
            "Select and transition a job within one transaction.",
            "Use a database locking strategy with documented contention behavior.",
            "Return distinct jobs or no work under concurrent pollers."
          ],
          "implementationNotes": [
            "Evaluate SKIP LOCKED against the declared ordering and fairness policy."
          ],
          "verification": [
            "Start two clients at a barrier and assert unique claimed identities.",
            "Hold one candidate lock and verify the documented skip or wait behavior."
          ],
          "deliverables": [
            "Atomic claim query and concurrency test"
          ],
          "rollout": "Canary with two synthetic pollers; reduce concurrency if lock behavior violates the contract.",
          "skills": [
            "Row locking",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "e33cbcfb-a0b1-47c3-a559-cfbd23e17a4b",
          "key": "ACLAIM-105",
          "title": "Issue a monotonically increasing assignment generation on every reclaim",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "claim",
          "dependsOn": [
            "ACLAIM-104"
          ],
          "scenario": "A disconnected reviewer reconnects after its job was reassigned and still holds a token that appears current.",
          "acceptanceCriteria": [
            "Every new assignment increments a durable generation.",
            "Mutation commands require job, assignee and generation.",
            "A stale generation cannot renew or finish work."
          ],
          "implementationNotes": [
            "Treat the generation as authority, not a UI-only counter."
          ],
          "verification": [
            "Reclaim a job and complete using the new generation.",
            "Try completion from the previous generation and reject it."
          ],
          "deliverables": [
            "Assignment-generation guard"
          ],
          "rollout": "Enable guarded writes before automated reclaim; retain old assignment history.",
          "skills": [
            "Fencing",
            "Optimistic concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f0d3bed7-ee11-45b6-95b6-450478e4848d",
          "key": "ACLAIM-106",
          "title": "Renew assignment leases without extending a completed job",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "claim",
          "dependsOn": [
            "ACLAIM-104",
            "ACLAIM-105"
          ],
          "scenario": "A late heartbeat runs after completion and changes the row back into an apparently active assignment.",
          "acceptanceCriteria": [
            "Renew only the current assigned generation.",
            "Never modify terminal completion fields.",
            "Bound extension duration using the server's clock."
          ],
          "implementationNotes": [
            "Use one guarded update rather than read-then-write status changes."
          ],
          "verification": [
            "Renew a valid active assignment.",
            "Complete first, then send a delayed renewal and preserve terminal state."
          ],
          "deliverables": [
            "Lease renewal command and stale-heartbeat test"
          ],
          "rollout": "Canary renewal with short synthetic leases; pause renewal on unexpected transition conflicts.",
          "skills": [
            "Guarded updates",
            "Lease semantics"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c7918dc1-bca9-4a84-9c19-c3df31ba0a27",
          "key": "ACLAIM-107",
          "title": "Finish a job and publish its result reference in one transaction",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "claim",
          "dependsOn": [
            "ACLAIM-105",
            "ACLAIM-106"
          ],
          "scenario": "A result is visible while its job remains assigned because completion and result linking commit separately.",
          "acceptanceCriteria": [
            "Check assignment authority and lease at commit.",
            "Commit terminal state and result reference atomically.",
            "Duplicate identical completion returns the original outcome."
          ],
          "implementationNotes": [
            "Keep result bytes outside the database transaction; link only verified immutable identity."
          ],
          "verification": [
            "Complete a valid assignment with one result reference.",
            "Force transaction failure and verify neither completion nor result publication persists."
          ],
          "deliverables": [
            "Completion transaction and rollback tests"
          ],
          "rollout": "Enable completion on synthetic jobs; suspend writes if authority or result verification is unavailable.",
          "skills": [
            "Transactions",
            "Result integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c83603c3-ca94-44c8-8148-b83ebb148a1f",
          "key": "ACLAIM-108",
          "title": "Reclaim expired assignments using current row authority",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "recover",
          "dependsOn": [
            "ACLAIM-105",
            "ACLAIM-106",
            "ACLAIM-107"
          ],
          "scenario": "A sweep selects expired jobs, then reclaims one that was renewed before its update executes.",
          "acceptanceCriteria": [
            "Recheck generation, assigned state and expiry in the reclaim update.",
            "Record previous ownership as immutable history.",
            "Bound each sweep and expose skipped renewals."
          ],
          "implementationNotes": [
            "Use a controlled clock and barrier for the renewal race."
          ],
          "verification": [
            "Reclaim a truly expired assignment.",
            "Renew between scan and update and verify reclaim skips it."
          ],
          "deliverables": [
            "Expiry reclaimer and race regression"
          ],
          "rollout": "Dry-run selected rows first; pause sweeps when clock or ownership checks disagree.",
          "skills": [
            "Concurrency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b876e3a6-6868-445d-a485-7abebd6a5e0d",
          "key": "ACLAIM-109",
          "title": "Measure assignment lock behavior without claiming a throughput guarantee",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "ACLAIM-104",
            "ACLAIM-108"
          ],
          "scenario": "Operators need to choose a polling interval and concurrency limit based on observed contention in the local prototype.",
          "acceptanceCriteria": [
            "Record database/runtime versions and synthetic job count.",
            "Measure lock waits and claim outcomes at fixed concurrency levels.",
            "Keep correctness assertions enabled during every run."
          ],
          "implementationNotes": [
            "Repeat each local condition three times; results describe only that environment."
          ],
          "verification": [
            "Run identical workloads at one and four pollers and record observations.",
            "Hold a long transaction and verify timeouts remain bounded without duplicate claims."
          ],
          "deliverables": [
            "Contention probe and observation report"
          ],
          "rollout": "Use observations to propose conservative local limits; restore lower concurrency if claim failures rise.",
          "skills": [
            "Database observability",
            "Concurrency testing"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8dbbb2d8-bdfa-4774-ab18-443677a49385",
          "key": "ACLAIM-110",
          "title": "Rehearse recovery of a queue with mixed expired and terminal jobs",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "ACLAIM-107",
            "ACLAIM-108",
            "ACLAIM-109"
          ],
          "scenario": "After an outage, operators need to resume assignments without redoing completed work or accepting stale reviewer results.",
          "acceptanceCriteria": [
            "Classify terminal, live and expired assignments from durable fields.",
            "Reclaim only expired authority and preserve terminal results.",
            "Report inconsistent rows instead of silently normalizing them."
          ],
          "implementationNotes": [
            "Use a fabricated outage dataset with one contradictory row."
          ],
          "verification": [
            "Recover valid mixed states and finish one reclaimed job.",
            "Submit a stale completion and inspect the contradictory row report."
          ],
          "deliverables": [
            "Queue recovery runbook and executable drill"
          ],
          "rollout": "Run the drill before increasing concurrency; keep uncertain jobs quarantined for review.",
          "skills": [
            "Recovery",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ebf9937a-23c7-42f3-8025-beea18139db6",
      "key": "ARESTORE",
      "title": "Prove a PostgreSQL backup can restore usable application state",
      "field": "Database engineering",
      "summary": "Build a bounded backup inventory and rehearse restoration with consistency checks.",
      "context": "A fictional case-management team has nightly backup files but has never tested application behavior after restore. Missing roles and external artifact references may make a successful database restore unusable.",
      "stack": [
        "PostgreSQL",
        "TypeScript",
        "Object storage"
      ],
      "prerequisites": [
        "Create a disposable synthetic database and local backup directory.",
        "Never connect these drills to production or overwrite a shared database."
      ],
      "developerValue": "Practice restore verification, provenance and operational recovery.",
      "companyValue": "Review evidence that recovery produces coherent usable state under declared limits.",
      "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": "inventory",
          "title": "Identify recovery inputs",
          "goal": "Record backup identity and application dependencies."
        },
        {
          "id": "restore",
          "title": "Restore and verify",
          "goal": "Use isolated targets and validate relational/application state."
        },
        {
          "id": "drill",
          "title": "Exercise recovery failures",
          "goal": "Measure local recovery and document missing guarantees."
        }
      ],
      "tickets": [
        {
          "id": "7a445df7-5e4f-4f6a-8611-da4b2edb8cb2",
          "key": "ARESTORE-101",
          "title": "Inventory database recovery inputs beyond the dump file",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "inventory",
          "dependsOn": [],
          "scenario": "A test restore contains tables but cannot start the application because expected roles and extensions are absent.",
          "acceptanceCriteria": [
            "List schema, roles, extensions, migration version and artifact dependencies.",
            "Separate secret configuration from backup contents.",
            "Record unresolved dependencies explicitly."
          ],
          "implementationNotes": [
            "Use a disposable synthetic database with a minimal application."
          ],
          "verification": [
            "Start the application from a complete declared inventory.",
            "Omit an extension in a fixture and identify the missing prerequisite."
          ],
          "deliverables": [
            "Recovery dependency inventory"
          ],
          "rollout": "Review inventory before claiming restore readiness; keep unresolved prerequisites visible.",
          "skills": [
            "Backup planning",
            "Database operations"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 20
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "16c4cb2b-8dea-40f5-8727-ec340da53f70",
          "key": "ARESTORE-102",
          "title": "Create a backup manifest that binds bytes to schema revision",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "inventory",
          "dependsOn": [
            "ARESTORE-101"
          ],
          "scenario": "Operators find three similarly named dump files and cannot tell which migration version or time each represents.",
          "acceptanceCriteria": [
            "Record byte hash, size, UTC capture time and migration identity.",
            "Bind the manifest to the exact backup artifact.",
            "Reject a missing or mismatched manifest before restore."
          ],
          "implementationNotes": [
            "Use synthetic data and avoid credentials in command logs."
          ],
          "verification": [
            "Verify a backup and matching manifest.",
            "Alter backup bytes and reject the restore plan."
          ],
          "deliverables": [
            "Backup manifest command and integrity checks"
          ],
          "rollout": "Create manifests for new backups; label unverified older files as uncertain.",
          "skills": [
            "Provenance",
            "Checksums"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "11a15c93-1e1f-4e3d-bf32-4bd895312a56",
          "key": "ARESTORE-103",
          "title": "Validate that a restore target is isolated before running destructive steps",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "inventory",
          "dependsOn": [
            "ARESTORE-101",
            "ARESTORE-102"
          ],
          "scenario": "A copied restore command could replace the development database instead of the disposable drill target.",
          "acceptanceCriteria": [
            "Require an explicit disposable target identity and expected marker.",
            "Resolve and inspect target connection metadata before mutation.",
            "Reject shared, production-like or unmarked targets."
          ],
          "implementationNotes": [
            "Use exact database names and task-specific credentials; no wildcard cleanup."
          ],
          "verification": [
            "Plan a restore to a marked disposable target.",
            "Point at an unmarked synthetic target and verify zero destructive calls."
          ],
          "deliverables": [
            "Restore-target guard and denial tests"
          ],
          "rollout": "Make the guard mandatory for drills; abort if target identity changes.",
          "skills": [
            "Operational safety",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "668f52de-40a3-4cac-8ad7-381e43955761",
          "key": "ARESTORE-104",
          "title": "Restore a verified backup into a new database generation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "restore",
          "dependsOn": [
            "ARESTORE-102",
            "ARESTORE-103"
          ],
          "scenario": "The current procedure restores directly over the active database and leaves no usable environment if it fails halfway.",
          "acceptanceCriteria": [
            "Create and restore into a distinct verified disposable generation.",
            "Keep the prior target untouched until checks complete.",
            "Record each restore stage and failure without exposing data contents."
          ],
          "implementationNotes": [
            "Use bounded local synthetic backups only."
          ],
          "verification": [
            "Restore a valid backup and inspect the new generation.",
            "Fail mid-restore and verify the previous synthetic application still reads its original database."
          ],
          "deliverables": [
            "Generation-based restore script"
          ],
          "rollout": "Use a new target for every drill; remove only verified owned failed generations after review.",
          "skills": [
            "Recovery isolation",
            "Database restore"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d91de79b-a890-44e2-975e-34ea6653dc28",
          "key": "ARESTORE-105",
          "title": "Check relational invariants after restoration",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "restore",
          "dependsOn": [
            "ARESTORE-104"
          ],
          "scenario": "A restore exits successfully but an earlier disabled constraint allowed orphan case assignments into the backup.",
          "acceptanceCriteria": [
            "Check expected foreign keys, unique constraints and required indexes.",
            "Run explicit orphan and duplicate queries on restored data.",
            "Fail application activation when invariants do not hold."
          ],
          "implementationNotes": [
            "Compare actual catalog metadata with the declared migration contract."
          ],
          "verification": [
            "Validate a clean synthetic restored database.",
            "Restore a deliberately inconsistent fixture and report exact invariant failures."
          ],
          "deliverables": [
            "Post-restore SQL verification suite"
          ],
          "rollout": "Run before connecting application traffic; retain the failed generation for bounded diagnosis.",
          "skills": [
            "Relational integrity",
            "Schema verification"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "90bef672-ef52-4112-aa7b-48e2e8beff7c",
          "key": "ARESTORE-106",
          "title": "Reconcile restored database references with external artifacts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "restore",
          "dependsOn": [
            "ARESTORE-101",
            "ARESTORE-104",
            "ARESTORE-105"
          ],
          "scenario": "Case attachments point to objects created after the backup cutoff, and some objects referenced by restored rows are missing.",
          "acceptanceCriteria": [
            "Compare immutable object versions and hashes for referenced artifacts.",
            "Report missing, extra and mismatched objects separately.",
            "Do not replace missing artifacts with similarly named current objects."
          ],
          "implementationNotes": [
            "Use a local object-store fixture and explicit backup cutoff."
          ],
          "verification": [
            "Restore matching database and object manifests.",
            "Remove a referenced object and keep the application readiness result incomplete."
          ],
          "deliverables": [
            "Artifact reconciliation command"
          ],
          "rollout": "Keep artifact-dependent routes unavailable until their references verify; preserve missing-reference reports.",
          "skills": [
            "Cross-store consistency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "dd671a74-9fa9-4b34-8fbd-b44ca4672f18",
          "key": "ARESTORE-107",
          "title": "Prevent post-restore background jobs from repeating completed side effects",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "restore",
          "dependsOn": [
            "ARESTORE-104",
            "ARESTORE-105",
            "ARESTORE-106"
          ],
          "scenario": "A restored outbox contains delivery records whose external effects happened after the database backup but before the outage.",
          "acceptanceCriteria": [
            "Document the database/external-side-effect recovery gap.",
            "Reconcile provider identities before redispatching restored records.",
            "Preserve unknown outcomes rather than asserting they were never sent."
          ],
          "implementationNotes": [
            "Use fake providers with durable synthetic request identities; send no messages."
          ],
          "verification": [
            "Restore a completed external operation and reconcile it without duplication.",
            "Make provider status unavailable and keep redispatch blocked under the declared policy."
          ],
          "deliverables": [
            "Outbox recovery protocol and provider probe"
          ],
          "rollout": "Start restored workers paused; release only reconciled work and retain unknown cases.",
          "skills": [
            "Distributed recovery",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "cebd3782-1dc6-4c3b-9ddf-4f3f519a05eb",
          "key": "ARESTORE-108",
          "title": "Measure local restore time with complete verification included",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "drill",
          "dependsOn": [
            "ARESTORE-104",
            "ARESTORE-105",
            "ARESTORE-106",
            "ARESTORE-107"
          ],
          "scenario": "The team's restore-time figure measures only dump loading and excludes artifact checks and application readiness.",
          "acceptanceCriteria": [
            "Record hardware, versions, dataset size and cache conditions.",
            "Measure load, verification and readiness stages separately.",
            "Repeat the same synthetic restore three times and report spread."
          ],
          "implementationNotes": [
            "These observations do not establish a production RTO."
          ],
          "verification": [
            "Run the declared complete restore drill and record all stages.",
            "Fail an invariant check and report recovery incomplete despite dump success."
          ],
          "deliverables": [
            "Reproducible local restore timing report"
          ],
          "rollout": "Use measurements to improve the drill; revise targets only after representative environment testing.",
          "skills": [
            "Operational measurement",
            "Recovery objectives"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ab6f17ec-2fa5-4902-8c5f-fcdb52823325",
          "key": "ARESTORE-109",
          "title": "Rehearse backup corruption and missing-manifest failure paths",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "drill",
          "dependsOn": [
            "ARESTORE-102",
            "ARESTORE-103",
            "ARESTORE-108"
          ],
          "scenario": "Operators need a practiced response when the newest backup is unusable rather than trying increasingly risky manual restore commands.",
          "acceptanceCriteria": [
            "Reject corrupt artifacts before activating a generation.",
            "Select an earlier verified backup with an explicit data-gap statement.",
            "Record the cutoff and unresolved external effects."
          ],
          "implementationNotes": [
            "Create disposable corrupted copies rather than altering the retained good backup."
          ],
          "verification": [
            "Restore from the prior verified synthetic backup.",
            "Present a missing manifest and corrupted newest artifact and keep both untrusted."
          ],
          "deliverables": [
            "Backup-failure drill and recovery decision trace"
          ],
          "rollout": "Run periodically in disposable targets; preserve good backups and stop when no verified candidate exists.",
          "skills": [
            "Recovery planning",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e70f56ef-c614-4412-8a35-2a93c235c6ae",
          "key": "ARESTORE-110",
          "title": "Write an application-level database recovery handoff",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "drill",
          "dependsOn": [
            "ARESTORE-107",
            "ARESTORE-108",
            "ARESTORE-109"
          ],
          "scenario": "A successful command transcript is handed to on-call staff without clear activation criteria or a statement of potentially missing data.",
          "acceptanceCriteria": [
            "List verification gates and the selected recovery cutoff.",
            "Include worker pause/release and artifact availability steps.",
            "State measured local limits and unresolved production dependencies."
          ],
          "implementationNotes": [
            "Use fabricated case records in the worked example."
          ],
          "verification": [
            "Follow the handoff from verified backup to synthetic application readiness.",
            "Follow the no-verified-backup branch and stop without claiming recovery."
          ],
          "deliverables": [
            "Recovery runbook and worked handoff"
          ],
          "rollout": "Review with a fresh local drill; update the runbook when schema or provider contracts change.",
          "skills": [
            "Runbooks",
            "Recovery communication"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ee51ce9a-8287-468e-8bfd-59f9b19b7462",
      "key": "ATENANT",
      "title": "Enforce organization boundaries in a relational case schema",
      "field": "Database engineering",
      "summary": "Make cross-organization relationships impossible through database and repository constraints.",
      "context": "A fictional case-management application filters most requests correctly, but imports and background commands can connect a case to another organization's project or assignee.",
      "stack": [
        "PostgreSQL",
        "Prisma",
        "TypeScript"
      ],
      "prerequisites": [
        "Create two synthetic organizations with overlapping display names.",
        "Use repository-level authorization and migration-backed constraints."
      ],
      "developerValue": "Practice tenant-aware keys, foreign keys and direct-write denial tests.",
      "companyValue": "Review defense in depth for data isolation across ordinary and privileged writers.",
      "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": "relations",
          "title": "Inventory tenant relationships",
          "goal": "Find and constrain cross-organization references."
        },
        {
          "id": "writers",
          "title": "Protect every write path",
          "goal": "Carry scope through imports, jobs and transactions."
        },
        {
          "id": "verify",
          "title": "Prove boundary coverage",
          "goal": "Reconcile legacy rows and verify database denials."
        }
      ],
      "tickets": [
        {
          "id": "2eb7166a-de0a-4a96-a7e8-60898ce969a6",
          "key": "ATENANT-101",
          "title": "Map tenant ownership for case-management entities",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "relations",
          "dependsOn": [],
          "scenario": "The schema lists organization IDs on cases but not on comments or attachment relationships, leaving ownership implicit.",
          "acceptanceCriteria": [
            "Identify the owning organization for every selected entity.",
            "List relationships that must stay within one organization.",
            "Separate truly global reference data from tenant data."
          ],
          "implementationNotes": [
            "Use a bounded case/project/comment schema."
          ],
          "verification": [
            "Trace ownership from a case attachment to its organization.",
            "Identify an intentionally ambiguous relationship and mark it unresolved."
          ],
          "deliverables": [
            "Tenant ownership map"
          ],
          "rollout": "Review the map before migrations; keep ambiguous relationships out of new writes.",
          "skills": [
            "Relational modeling",
            "Tenant boundaries"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "49caf826-b680-4cea-812d-a9e20c0f8ec1",
          "key": "ATENANT-102",
          "title": "Add composite uniqueness for tenant-owned relationship targets",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "relations",
          "dependsOn": [
            "ATENANT-101"
          ],
          "scenario": "Globally unique row IDs do not by themselves let a foreign key enforce that case and project belong to the same organization.",
          "acceptanceCriteria": [
            "Add the composite target keys needed for tenant-bound references.",
            "Preserve existing globally unique identities.",
            "Document index duplication and selected constraint names."
          ],
          "implementationNotes": [
            "Inspect actual migration SQL and query patterns."
          ],
          "verification": [
            "Create identical display names in different organizations.",
            "Attempt a duplicate target identity within the same composite key and verify rejection."
          ],
          "deliverables": [
            "Composite-key migration"
          ],
          "rollout": "Apply additive keys first; remove only demonstrably redundant indexes after usage review.",
          "skills": [
            "Composite keys",
            "Migrations"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "89ac5d93-3131-4808-953c-bc5df79310d8",
          "key": "ATENANT-103",
          "title": "Reject null organization scope in protected repository methods",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "relations",
          "dependsOn": [
            "ATENANT-101",
            "ATENANT-102"
          ],
          "scenario": "An optional organization argument defaults to an unscoped query when an internal caller forgets to pass it.",
          "acceptanceCriteria": [
            "Require nonempty scope in protected method signatures and validation.",
            "Remove unscoped fallback branches.",
            "Keep global reference methods explicitly separate."
          ],
          "implementationNotes": [
            "Test direct service calls rather than relying solely on controllers."
          ],
          "verification": [
            "Read a project using valid tenant scope.",
            "Omit scope at the runtime boundary and verify no database query executes."
          ],
          "deliverables": [
            "Required-scope repository contract"
          ],
          "rollout": "Deploy boundary validation before new callers; deny ambiguous internal requests.",
          "skills": [
            "Repository design",
            "Fail-closed handling"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "463bb75d-903c-44f3-a4e0-fab4a935875e",
          "key": "ATENANT-104",
          "title": "Enforce same-organization case-to-project references with a foreign key",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "writers",
          "dependsOn": [
            "ATENANT-102",
            "ATENANT-103"
          ],
          "scenario": "An import can connect a case in one organization to a globally valid project in another organization.",
          "acceptanceCriteria": [
            "Create a composite foreign key including organization identity.",
            "Reject mismatched direct SQL and application writes.",
            "Retain valid same-organization associations."
          ],
          "implementationNotes": [
            "Backfill and inspect existing mismatches before validating the constraint."
          ],
          "verification": [
            "Insert a valid synthetic case/project relationship.",
            "Insert a cross-organization relationship directly and observe database rejection."
          ],
          "deliverables": [
            "Tenant-bound foreign-key migration"
          ],
          "rollout": "Validate after a clean discrepancy report; quarantine invalid legacy relationships without guessing ownership.",
          "skills": [
            "Foreign keys",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "13d0ebf7-4a2e-4856-b01b-fec0425adde4",
          "key": "ATENANT-105",
          "title": "Keep case-comment inserts scoped during concurrent parent changes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "writers",
          "dependsOn": [
            "ATENANT-104"
          ],
          "scenario": "A comment command checks the case once, then writes after an administrator changes related project state.",
          "acceptanceCriteria": [
            "Authorize and insert against current parent ownership in one boundary.",
            "Prevent parent reassignment that would violate child scope.",
            "Return a conflict rather than attach a comment ambiguously."
          ],
          "implementationNotes": [
            "Prefer immutable tenant ownership for existing entities."
          ],
          "verification": [
            "Insert a comment under stable ownership.",
            "Race a prohibited parent-scope change and verify no cross-tenant comment results."
          ],
          "deliverables": [
            "Comment transaction and ownership race test"
          ],
          "rollout": "Enable the guarded command; disable tenant reassignment paths that lack a migration protocol.",
          "skills": [
            "Transactions",
            "Ownership invariants"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 20
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f3cd284f-346b-40af-bbb1-422e7ca76bb7",
          "key": "ATENANT-106",
          "title": "Make bulk case imports validate every tenant relationship before commit",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "writers",
          "dependsOn": [
            "ATENANT-103",
            "ATENANT-104",
            "ATENANT-105"
          ],
          "scenario": "A bulk import checks the organization of the first row but trusts project IDs in subsequent rows.",
          "acceptanceCriteria": [
            "Validate each relationship under the requested organization.",
            "Report row coordinates with nondisclosing reason codes.",
            "Follow an explicit all-or-nothing import contract."
          ],
          "implementationNotes": [
            "Use a synthetic file containing one cross-tenant project reference."
          ],
          "verification": [
            "Import a valid multi-row file.",
            "Place an invalid reference late in the file and verify zero case rows commit."
          ],
          "deliverables": [
            "Scoped bulk importer and late-row regression"
          ],
          "rollout": "Canary small synthetic imports; retain rejected files under bounded restricted storage.",
          "skills": [
            "Bulk validation",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "67a0153c-3017-4319-b45b-ae2db9c09289",
          "key": "ATENANT-107",
          "title": "Carry tenant identity through background case-processing commands",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "writers",
          "dependsOn": [
            "ATENANT-103",
            "ATENANT-104",
            "ATENANT-106"
          ],
          "scenario": "The queue payload stores only a case ID, and the worker resolves its organization from mutable caller-supplied metadata.",
          "acceptanceCriteria": [
            "Bind durable command identity to case and authoritative tenant.",
            "Reload scoped state before each guarded mutation.",
            "Reject conflicting tenant metadata without executing the provider."
          ],
          "implementationNotes": [
            "Queue messages contain opaque IDs, not case contents or secrets."
          ],
          "verification": [
            "Process a valid tenant-bound synthetic command.",
            "Replay its case ID with another organization and verify no provider call or mutation."
          ],
          "deliverables": [
            "Scoped job command and replay-denial probe"
          ],
          "rollout": "Deploy worker guards before new dispatch; quarantine old commands lacking required authority.",
          "skills": [
            "Background authorization",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "464dc3ef-cc2c-48cd-ae75-3b733bf045e6",
          "key": "ATENANT-108",
          "title": "Find legacy cross-tenant references without exposing case contents",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "verify",
          "dependsOn": [
            "ATENANT-104",
            "ATENANT-107"
          ],
          "scenario": "The new constraint cannot validate until operators understand existing mismatches, but incident exports should not include case bodies.",
          "acceptanceCriteria": [
            "Report safe entity IDs and mismatch category only.",
            "Bound scans by table and cursor.",
            "Do not automatically choose which tenant should own an invalid relationship."
          ],
          "implementationNotes": [
            "Make the reconciliation command read-only."
          ],
          "verification": [
            "Scan a valid synthetic dataset with no mismatches.",
            "Insert a deliberate legacy mismatch in a fixture and identify its exact relationship."
          ],
          "deliverables": [
            "Tenant-integrity report"
          ],
          "rollout": "Run before constraint validation; repair only reviewed mappings through audited commands.",
          "skills": [
            "Data reconciliation",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ca9d9bb1-7d68-4a69-ba80-2c032cffb2c8",
          "key": "ATENANT-109",
          "title": "Verify tenant constraints through a least-privilege database writer",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "verify",
          "dependsOn": [
            "ATENANT-104",
            "ATENANT-105",
            "ATENANT-107",
            "ATENANT-108"
          ],
          "scenario": "Application tests pass, but direct SQL imports use a role that can bypass expected safeguards.",
          "acceptanceCriteria": [
            "Inventory grants for the application and import roles.",
            "Verify ordinary writers cannot disable constraints or change schema.",
            "Run same-tenant and cross-tenant write checks under the actual limited role."
          ],
          "implementationNotes": [
            "Use disposable local roles; do not alter production permissions."
          ],
          "verification": [
            "Write a valid relationship through the limited import role.",
            "Attempt cross-tenant insertion and constraint disabling and verify both are denied."
          ],
          "deliverables": [
            "Role/grant verification and direct-write tests"
          ],
          "rollout": "Apply the limited role in the local import path; stop imports if required checks are bypassable.",
          "skills": [
            "Database permissions",
            "Defense in depth"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "38e5bb46-c86d-4d82-8448-75e8c4aa5606",
          "key": "ATENANT-110",
          "title": "Document the tenant-data repair protocol and its non-goals",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "verify",
          "dependsOn": [
            "ATENANT-108",
            "ATENANT-109"
          ],
          "scenario": "Support wants to move an incorrectly linked case by editing organization IDs directly, risking a cascade of broken ownership.",
          "acceptanceCriteria": [
            "Require a reviewed explicit mapping and affected-relationship inventory.",
            "Preserve audit references and report unresolved children.",
            "Separate repairing a bad link from transferring entity ownership."
          ],
          "implementationNotes": [
            "Use one fabricated mismatch as the worked example."
          ],
          "verification": [
            "Repair a reviewed synthetic project link with all constraints enabled.",
            "Attempt an incomplete ownership transfer and stop before mutation."
          ],
          "deliverables": [
            "Tenant repair runbook"
          ],
          "rollout": "Review repairs in a disposable database first; retain invalid rows quarantined when ownership is uncertain.",
          "skills": [
            "Repair planning",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "db113b8f-7f11-4fc5-bbaf-e81230c589b8",
      "key": "AMETA",
      "title": "Turn unbounded document metadata into a queryable contract",
      "field": "Database engineering",
      "summary": "Separate stable document fields from versioned bounded metadata and migrate safely.",
      "context": "A fictional records portal stores every property in one JSON column. Queries disagree about missing values, and malformed records make ordinary filters fail.",
      "stack": [
        "PostgreSQL",
        "Prisma",
        "TypeScript",
        "JSON Schema"
      ],
      "prerequisites": [
        "Create synthetic document metadata with malformed and legacy versions.",
        "Use migrations and a local query API."
      ],
      "developerValue": "Practice relational/JSON boundaries, versioned validation and query semantics.",
      "companyValue": "Review a data model that stays inspectable while allowing controlled variation.",
      "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": "contract",
          "title": "Define metadata meaning",
          "goal": "Choose stable columns and bounded flexible fields."
        },
        {
          "id": "migrate",
          "title": "Validate and migrate records",
          "goal": "Bridge legacy data while protecting writes."
        },
        {
          "id": "query",
          "title": "Make filters trustworthy",
          "goal": "Verify query semantics and release the model."
        }
      ],
      "tickets": [
        {
          "id": "1c44b1aa-0b4e-4168-a274-d8e53c479f2d",
          "key": "AMETA-101",
          "title": "Separate stable document identity fields from flexible attributes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Document owner, creation time and type are buried beside optional tags in JSON, so every query reinvents their shape.",
          "acceptanceCriteria": [
            "List stable required columns and bounded flexible attributes.",
            "Document ownership and nullability for each field.",
            "Reject storing lifecycle authority in arbitrary metadata."
          ],
          "implementationNotes": [
            "Use a small fictional record taxonomy."
          ],
          "verification": [
            "Map two document types to the proposed model.",
            "Classify an unknown authoritative status field as a schema decision rather than generic JSON."
          ],
          "deliverables": [
            "Relational/JSON field map"
          ],
          "rollout": "Review the field map before migrations; keep unresolved authority fields out of metadata writes.",
          "skills": [
            "Data modeling",
            "Schema boundaries"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "System design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "206abfb8-c247-439b-af80-8d8eda1e9aed",
          "key": "AMETA-102",
          "title": "Define versioned metadata schemas with explicit size and depth limits",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contract",
          "dependsOn": [
            "AMETA-101"
          ],
          "scenario": "A client submits deeply nested metadata that the API accepts but later query code cannot handle.",
          "acceptanceCriteria": [
            "Require an explicit supported metadata version.",
            "Bound object depth, field count and serialized size.",
            "Reject unknown protected fields and invalid field types."
          ],
          "implementationNotes": [
            "Use schema validation at the write boundary and safe error paths."
          ],
          "verification": [
            "Validate supported synthetic document metadata.",
            "Exceed depth and size limits and verify no row is stored."
          ],
          "deliverables": [
            "Metadata schemas and bound checks"
          ],
          "rollout": "Deploy validation for new writes; quarantine incompatible legacy records.",
          "skills": [
            "JSON Schema",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "26b9599a-8e57-4ae9-abad-07eadcf6bff3",
          "key": "AMETA-103",
          "title": "Choose distinct semantics for absent, null and empty metadata values",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [
            "AMETA-101",
            "AMETA-102"
          ],
          "scenario": "A filter for documents without a retention tag returns different results depending on whether the field is absent, null or an empty string.",
          "acceptanceCriteria": [
            "Define the three states for each supported filter.",
            "Reject empty strings where they lack business meaning.",
            "Publish a truth table consumed by query tests."
          ],
          "implementationNotes": [
            "Avoid blanket coercion of all empty-like values."
          ],
          "verification": [
            "Query one fixture for each declared state.",
            "Send an unsupported empty value and verify validation behavior matches the table."
          ],
          "deliverables": [
            "Metadata null-semantics contract"
          ],
          "rollout": "Review the truth table with API consumers; retain old filter names until compatibility is documented.",
          "skills": [
            "SQL semantics",
            "API contracts"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "11622e17-1aa8-4d05-9623-6b75d3890ec5",
          "key": "AMETA-104",
          "title": "Extract stable document fields through an additive migration",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "migrate",
          "dependsOn": [
            "AMETA-101",
            "AMETA-102",
            "AMETA-103"
          ],
          "scenario": "The model needs relational owner and created-at columns while old records and clients still use JSON.",
          "acceptanceCriteria": [
            "Add nullable relational fields and required target constraints.",
            "Keep original metadata available during migration.",
            "Reject contradictory dual representations on new writes."
          ],
          "implementationNotes": [
            "Use a migration file and explicit data conversion rules."
          ],
          "verification": [
            "Insert a consistent bridge record.",
            "Provide different owner identities in columns and JSON and reject the write."
          ],
          "deliverables": [
            "Schema expansion and bridge validation"
          ],
          "rollout": "Deploy additive schema before readers; rollback bridge code while retaining untouched metadata.",
          "skills": [
            "Migrations",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ec7be5b2-6ce3-4ad9-93e4-53c895319dc4",
          "key": "AMETA-105",
          "title": "Backfill document timestamps without guessing missing offsets",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "migrate",
          "dependsOn": [
            "AMETA-104"
          ],
          "scenario": "Legacy created-at values mix UTC strings with offset-free dates; blindly casting them uses the database session timezone.",
          "acceptanceCriteria": [
            "Convert only timestamps with an unambiguous documented interpretation.",
            "Quarantine missing-offset and malformed values.",
            "Use resumable batches with counts by conversion outcome."
          ],
          "implementationNotes": [
            "Preserve original metadata for later review."
          ],
          "verification": [
            "Backfill valid offset-bearing values under two session timezones with identical UTC results.",
            "Process ambiguous dates and retain null target fields plus explicit errors."
          ],
          "deliverables": [
            "Timestamp backfill and timezone regression"
          ],
          "rollout": "Dry-run first; pause on unexpected conversion categories and keep the checkpoint.",
          "skills": [
            "Data migration",
            "Time zones"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ecd3cb4e-2e38-4f18-b299-b5551b9db68d",
          "key": "AMETA-106",
          "title": "Keep document metadata updates under optimistic revision control",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "migrate",
          "dependsOn": [
            "AMETA-102",
            "AMETA-104"
          ],
          "scenario": "Two editors update different metadata fields through whole-object replacement and silently overwrite each other's changes.",
          "acceptanceCriteria": [
            "Require expected document revision on metadata mutation.",
            "Validate the complete resulting versioned object.",
            "Return a conflict without discarding either editor's input."
          ],
          "implementationNotes": [
            "Use explicit patch semantics; do not merge unknown nested arrays heuristically."
          ],
          "verification": [
            "Apply a patch at the current revision.",
            "Race two patches and verify the stale one cannot overwrite the first."
          ],
          "deliverables": [
            "Revision-guarded metadata update"
          ],
          "rollout": "Canary patches on synthetic documents; restore read-only editing if conflict handling is incomplete.",
          "skills": [
            "Optimistic concurrency",
            "Patch semantics"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0188e944-d518-4d11-83f9-20dc0e017197",
          "key": "AMETA-107",
          "title": "Build parameterized metadata filters with an allowlisted operator set",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "migrate",
          "dependsOn": [
            "AMETA-102",
            "AMETA-103",
            "AMETA-106"
          ],
          "scenario": "A query endpoint interpolates client-provided JSON paths and operators into SQL.",
          "acceptanceCriteria": [
            "Allow only documented fields and operators.",
            "Bind user values as parameters and tenant scope as a required predicate.",
            "Reject unsupported path syntax before query execution."
          ],
          "implementationNotes": [
            "Do not expose arbitrary SQL or JSON-path execution to clients."
          ],
          "verification": [
            "Filter known numeric and enum metadata under tenant scope.",
            "Submit malicious path/operator text and verify no query execution or cross-tenant results."
          ],
          "deliverables": [
            "Safe filter compiler and injection regressions"
          ],
          "rollout": "Enable only reviewed filter combinations; disable newly added operators independently if checks fail.",
          "skills": [
            "SQL safety",
            "Query compilation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "78c3e096-60ee-43b5-b36b-6e3660748063",
          "key": "AMETA-108",
          "title": "Verify metadata filter results against a simple reference evaluator",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "query",
          "dependsOn": [
            "AMETA-103",
            "AMETA-107"
          ],
          "scenario": "The database query for arrays and null values differs subtly from the API contract, making support reports inconsistent.",
          "acceptanceCriteria": [
            "Author a bounded corpus covering all declared states.",
            "Compare SQL result identities with a simple reference evaluator.",
            "Report missing and extra identities separately."
          ],
          "implementationNotes": [
            "Use identical synthetic inputs and keep the reference implementation straightforward."
          ],
          "verification": [
            "Compare supported filters across the complete corpus.",
            "Mutate one SQL null condition and verify the differential check finds the mismatch."
          ],
          "deliverables": [
            "Differential query harness"
          ],
          "rollout": "Require the harness for filter changes; keep the prior query compiler available for rollback.",
          "skills": [
            "Differential testing",
            "SQL correctness"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "0d5844e5-902b-4045-ae38-3303706c9263",
          "key": "AMETA-109",
          "title": "Enforce required relational document fields after a clean backfill",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "query",
          "dependsOn": [
            "AMETA-104",
            "AMETA-105",
            "AMETA-108"
          ],
          "scenario": "New readers assume every document has a valid owner and UTC creation instant, but quarantined legacy rows still violate that assumption.",
          "acceptanceCriteria": [
            "Check null, orphan and contradictory target fields before validation.",
            "Keep quarantined records outside normal reader activation.",
            "Add required constraints only after declared readiness passes."
          ],
          "implementationNotes": [
            "Do not fabricate missing timestamps to make constraints pass."
          ],
          "verification": [
            "Validate a fully resolved synthetic cohort.",
            "Leave one ambiguous timestamp and verify readiness blocks activation."
          ],
          "deliverables": [
            "Readiness query and constraint migration"
          ],
          "rollout": "Activate resolved cohorts after verification; retain legacy quarantine and avoid destructive contraction.",
          "skills": [
            "Constraint validation",
            "Migration safety"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "00d51cbe-8d26-4d62-96af-ae8f8493da0d",
          "key": "AMETA-110",
          "title": "Rehearse metadata-schema rollback across old and new API consumers",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "query",
          "dependsOn": [
            "AMETA-106",
            "AMETA-108",
            "AMETA-109"
          ],
          "scenario": "The team wants to remove legacy JSON fields immediately after switching reads, which could break old clients during a rollback.",
          "acceptanceCriteria": [
            "Test old and new clients against the expanded schema.",
            "Document the compatibility window and contraction prerequisites.",
            "Keep versioned metadata and relational values coherent during rollback."
          ],
          "implementationNotes": [
            "Use synthetic records from every supported version."
          ],
          "verification": [
            "Switch readers and restore the prior compatible client with unchanged results.",
            "Introduce an unsupported version and verify a clear failure rather than lossy conversion."
          ],
          "deliverables": [
            "Compatibility matrix and rollback drill"
          ],
          "rollout": "Retain bridge columns through the reviewed window; contract only after old writers are retired.",
          "skills": [
            "Schema evolution",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 20
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "3ec41d1b-c6a4-4952-bbe9-7e76f0467449",
      "key": "ALEASE",
      "title": "Coordinate scheduled maintenance with fenced leases",
      "field": "Distributed systems",
      "summary": "Elect one active scheduler while preventing expired owners from mutating shared state.",
      "context": "A fictional document service runs periodic retention planning on multiple application instances. Paused instances resume after lease expiry and can overlap newer schedulers.",
      "stack": [
        "TypeScript",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a synthetic maintenance queue and two independent scheduler clients.",
        "Use fake time where possible and no destructive real retention actions."
      ],
      "developerValue": "Practice lease assumptions, fencing and stale-owner rejection.",
      "companyValue": "Review safe coordination that remains explainable under pauses and recovery.",
      "delivery": "Ten scoped tickets across three phases. Build a synthetic local service or select a ticket after recreating its prerequisites; estimates exclude setup.",
      "phases": [
        {
          "id": "authority",
          "title": "Define scheduler authority",
          "goal": "Model lease identity, expiry and protected actions."
        },
        {
          "id": "coordination",
          "title": "Guard competing owners",
          "goal": "Acquire, renew and execute with fencing."
        },
        {
          "id": "failure",
          "title": "Exercise time and connection failures",
          "goal": "Reconcile ownership and recover interrupted runs."
        }
      ],
      "tickets": [
        {
          "id": "137c560f-3b37-4f30-8426-546e3aa40870",
          "key": "ALEASE-101",
          "title": "Specify scheduler lease state with a separate authority epoch",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "authority",
          "dependsOn": [],
          "scenario": "The scheduler table stores only owner name and expiry, so an old owner can appear identical to a later process with the same name.",
          "acceptanceCriteria": [
            "Include lease identity, holder instance, expiry and monotonic epoch.",
            "Define active and expired semantics at the exact boundary.",
            "Keep display names outside authority checks."
          ],
          "implementationNotes": [
            "Use opaque process-instance identities."
          ],
          "verification": [
            "Represent two successive owners with distinct epochs.",
            "Reuse a display name and verify it cannot impersonate the previous instance."
          ],
          "deliverables": [
            "Lease schema and authority contract"
          ],
          "rollout": "Review the schema before scheduler writes; leave coordination disabled until epoch checks exist.",
          "skills": [
            "Lease modeling",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "0c584b13-0bed-4295-8275-3a3727ee254b",
          "key": "ALEASE-102",
          "title": "Use one authoritative clock boundary for lease decisions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "authority",
          "dependsOn": [
            "ALEASE-101"
          ],
          "scenario": "Two instances disagree about lease expiry because their local clocks differ by several seconds.",
          "acceptanceCriteria": [
            "Define the clock used for acquisition and expiry checks.",
            "Keep client clock readings out of authority decisions.",
            "Document pause and network-delay assumptions."
          ],
          "implementationNotes": [
            "Prefer database time within the transaction for this local PostgreSQL exercise."
          ],
          "verification": [
            "Skew client clocks and obtain the same database lease decision.",
            "Reach exact expiry and verify the documented eligibility boundary."
          ],
          "deliverables": [
            "Clock-bound lease queries and skew test"
          ],
          "rollout": "Canary lease reads under controlled skew; stop acquisition if authoritative time is unavailable.",
          "skills": [
            "Clock semantics",
            "Distributed assumptions"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "4ad58e6e-5ca0-4354-b547-5799b106f722",
          "key": "ALEASE-103",
          "title": "Classify maintenance actions that require fencing before side effects",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "authority",
          "dependsOn": [
            "ALEASE-101",
            "ALEASE-102"
          ],
          "scenario": "The design adds a lease but assumes every downstream operation automatically knows whether its caller is still leader.",
          "acceptanceCriteria": [
            "List each protected mutation and its fencing check location.",
            "Separate read-only planning from state-changing execution.",
            "Mark unfenceable external effects as unresolved."
          ],
          "implementationNotes": [
            "Use synthetic retention plans; delete no real objects."
          ],
          "verification": [
            "Trace a plan-state update to its epoch guard.",
            "Identify an external adapter without epoch support and block its destructive action."
          ],
          "deliverables": [
            "Fencing coverage matrix"
          ],
          "rollout": "Require coverage before enabling actions; keep unresolved provider operations read-only.",
          "skills": [
            "Boundary analysis",
            "Fencing"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1979cc45-8d18-4b81-a5b1-e35cf93ee238",
          "key": "ALEASE-104",
          "title": "Acquire a scheduler lease atomically under competing instances",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "coordination",
          "dependsOn": [
            "ALEASE-102",
            "ALEASE-103"
          ],
          "scenario": "Two instances see an expired lease and both believe they became the active scheduler.",
          "acceptanceCriteria": [
            "Acquire through one guarded database transaction.",
            "Increment the epoch only for the winning acquisition.",
            "Return current safe ownership metadata to the loser."
          ],
          "implementationNotes": [
            "Use two independent database connections and a barrier."
          ],
          "verification": [
            "Race two acquisitions and assert one winning epoch.",
            "Hold a valid lease and verify another instance cannot replace it early."
          ],
          "deliverables": [
            "Atomic acquisition command and race test"
          ],
          "rollout": "Canary with two local clients; stop scheduling if ownership results conflict.",
          "skills": [
            "Transactions",
            "Leader coordination"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "40de2d15-5509-4231-b50e-871b4d3f67be",
          "key": "ALEASE-105",
          "title": "Renew a scheduler lease only for the current holder and epoch",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "coordination",
          "dependsOn": [
            "ALEASE-104"
          ],
          "scenario": "A delayed renewal from an earlier process extends the newest owner's lease row while reporting success to the stale process.",
          "acceptanceCriteria": [
            "Match holder instance and epoch in the renewal update.",
            "Bound extension duration from the authoritative clock.",
            "Return lost authority when no matching active lease exists."
          ],
          "implementationNotes": [
            "Never renew solely by a shared scheduler name."
          ],
          "verification": [
            "Renew the current owner successfully.",
            "Acquire a newer epoch, then submit the old renewal and reject it."
          ],
          "deliverables": [
            "Guarded renewal and stale-message test"
          ],
          "rollout": "Enable guarded renewal before automated scheduling; make authority loss stop further work claims.",
          "skills": [
            "Guarded updates",
            "Lease renewal"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "58209b0c-92e2-4cee-b9bb-9cfb19f4e7a6",
          "key": "ALEASE-106",
          "title": "Fence maintenance writes after a paused scheduler resumes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "coordination",
          "dependsOn": [
            "ALEASE-103",
            "ALEASE-104",
            "ALEASE-105"
          ],
          "scenario": "A scheduler pauses past expiry, then resumes a previously prepared plan after another instance has taken over.",
          "acceptanceCriteria": [
            "Every protected write checks current authority epoch.",
            "A stale owner cannot complete or activate a plan.",
            "Record rejected stale activity without overwriting current progress."
          ],
          "implementationNotes": [
            "Carry epoch through the command and recheck at commit."
          ],
          "verification": [
            "Pause owner A, let B acquire, then finish B's plan.",
            "Resume A and verify its write is rejected even if it began earlier."
          ],
          "deliverables": [
            "Commit-time fencing and pause reproduction"
          ],
          "rollout": "Canary synthetic plan activation; disable unfenced writes until every path passes the stale-owner probe.",
          "skills": [
            "Fencing",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "42696a4d-e7ab-4989-96d5-836fc981be39",
          "key": "ALEASE-107",
          "title": "Make scheduled maintenance occurrences idempotent across leadership changes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "coordination",
          "dependsOn": [
            "ALEASE-104",
            "ALEASE-106"
          ],
          "scenario": "A new leader repeats the current maintenance period and creates a second plan for the same logical occurrence.",
          "acceptanceCriteria": [
            "Derive occurrence identity from schedule and intended UTC instant.",
            "Enforce one durable logical run per occurrence.",
            "Allow a new owner to resume existing nonterminal work safely."
          ],
          "implementationNotes": [
            "Do not derive identity from acquisition time or process name."
          ],
          "verification": [
            "Change leader midway through an occurrence and retain one run.",
            "Retry a terminal occurrence and return its recorded result."
          ],
          "deliverables": [
            "Occurrence identity contract and leader-change test"
          ],
          "rollout": "Enable idempotent creation before multi-instance operation; reconcile existing duplicates through read-only reports.",
          "skills": [
            "Idempotency",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3db026fe-17be-43ce-b013-09293946383b",
          "key": "ALEASE-108",
          "title": "Expose lease health without implying the holder is making progress",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "failure",
          "dependsOn": [
            "ALEASE-105",
            "ALEASE-106",
            "ALEASE-107"
          ],
          "scenario": "A scheduler renews its lease while stuck on one task, so the status page incorrectly reports healthy processing.",
          "acceptanceCriteria": [
            "Report lease authority and work-progress timestamps separately.",
            "Distinguish no leader, active leader and stalled work.",
            "Keep unknown progress explicit after observation gaps."
          ],
          "implementationNotes": [
            "Use safe instance tokens rather than host secrets."
          ],
          "verification": [
            "Show an active progressing scheduler.",
            "Freeze progress while renewing the lease and show stalled work."
          ],
          "deliverables": [
            "Scheduler status projection"
          ],
          "rollout": "Add status before alert thresholds; disable noisy alerts while retaining raw safe state.",
          "skills": [
            "Observability",
            "Health semantics"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "25e5fff8-6453-4db5-8197-414afa1d2b75",
          "key": "ALEASE-109",
          "title": "Recover coordination after a database connection partition",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "failure",
          "dependsOn": [
            "ALEASE-102",
            "ALEASE-106",
            "ALEASE-108"
          ],
          "scenario": "An instance loses database connectivity but can still contact the fake work provider, raising the risk of acting on expired authority.",
          "acceptanceCriteria": [
            "Stop new protected actions when authority cannot be verified.",
            "Reconcile lease and run state after reconnection.",
            "Resume only under a current valid epoch."
          ],
          "implementationNotes": [
            "Use controlled local adapter disconnection, not real network disruption."
          ],
          "verification": [
            "Disconnect one owner, acquire with another, and continue valid work.",
            "Reconnect the old owner and reject its cached authority before any action."
          ],
          "deliverables": [
            "Partition drill and authority recovery trace"
          ],
          "rollout": "Run before multi-instance scheduling; fail closed on unresolved ownership.",
          "skills": [
            "Network partitions",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 20
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "80c76564-4352-4b87-b27e-9820f241ff7e",
          "key": "ALEASE-110",
          "title": "Document lease guarantees and the provider conditions they depend on",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "failure",
          "dependsOn": [
            "ALEASE-103",
            "ALEASE-107",
            "ALEASE-109"
          ],
          "scenario": "A release note says exactly one scheduler runs, even though stale processes may execute until downstream fences reject their writes.",
          "acceptanceCriteria": [
            "Describe mutual authority separately from process execution.",
            "List clock, transaction and provider fencing assumptions.",
            "Link each guarantee to a race or partition probe."
          ],
          "implementationNotes": [
            "Avoid claiming leases alone guarantee exactly-once effects."
          ],
          "verification": [
            "Trace a protected-write guarantee to its fencing test.",
            "Identify an unfenced provider and state the unsupported guarantee."
          ],
          "deliverables": [
            "Coordination operating contract"
          ],
          "rollout": "Review before enabling external actions; revise the contract when provider semantics change.",
          "skills": [
            "Distributed reasoning",
            "Technical communication"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "dedbc308-dfea-443f-bdbd-4490bed97c3f",
      "key": "ASAGA",
      "title": "Coordinate equipment returns with explicit compensations",
      "field": "Distributed systems",
      "summary": "Recover a multi-step return workflow across inspection, shipping and refund providers.",
      "context": "A fictional equipment-rental service approves returns through several provider calls. Partial failures leave labels issued without inspections or refunds reported before provider confirmation.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Provider interfaces"
      ],
      "prerequisites": [
        "Create synthetic return records and fake inspection, shipping and refund adapters.",
        "Use integer money values and no real payments or messages."
      ],
      "developerValue": "Practice durable workflow state, compensation and uncertain outcomes.",
      "companyValue": "Review recoverable business operations without assuming distributed transactions.",
      "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": "steps",
          "title": "Define workflow facts",
          "goal": "Separate requested actions from observed outcomes."
        },
        {
          "id": "orchestrate",
          "title": "Persist multi-step progress",
          "goal": "Make effects idempotent and compensation explicit."
        },
        {
          "id": "recover",
          "title": "Reconcile uncertain work",
          "goal": "Exercise crashes and publish accurate operational status."
        }
      ],
      "tickets": [
        {
          "id": "64eaa48b-00e3-4ffd-9ed5-c9d991c7563a",
          "key": "ASAGA-101",
          "title": "Model return workflow steps as durable facts with explicit pending states",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "steps",
          "dependsOn": [],
          "scenario": "The return row has one status called processing, hiding whether inspection, label issuance or refund is outstanding.",
          "acceptanceCriteria": [
            "Represent each step's request and observed outcome separately.",
            "Define legal workflow transitions and terminal conditions.",
            "Keep unknown provider outcomes distinct from failure."
          ],
          "implementationNotes": [
            "Use synthetic provider receipts only."
          ],
          "verification": [
            "Trace a successful return through all declared facts.",
            "Timeout shipping after acceptance and retain an unknown label outcome."
          ],
          "deliverables": [
            "Return state model"
          ],
          "rollout": "Review the state table before adding adapters; preserve ambiguous existing cases as unresolved.",
          "skills": [
            "Workflow modeling",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ca4c504a-2d42-4679-b1db-ebfb315a05be",
          "key": "ASAGA-102",
          "title": "Define stable provider command keys for each return step",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "steps",
          "dependsOn": [
            "ASAGA-101"
          ],
          "scenario": "A retry after a lost response creates a second shipping label because each request receives a new key.",
          "acceptanceCriteria": [
            "Bind keys to return identity, step and generation.",
            "Reuse keys for equivalent retries.",
            "Reject changed canonical input under an existing key."
          ],
          "implementationNotes": [
            "Do not reuse one key across unrelated provider actions."
          ],
          "verification": [
            "Repeat a label request and resolve one fake provider result.",
            "Change shipping destination under the same key and return conflict."
          ],
          "deliverables": [
            "Step identity contract and provider-key tests"
          ],
          "rollout": "Use stable keys before enabling retries; reconcile legacy ambiguous effects separately.",
          "skills": [
            "Idempotency",
            "Provider contracts"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a4ec0118-e6d8-4ce5-b111-ae349ac45068",
          "key": "ASAGA-103",
          "title": "Write the compensation table for return side effects",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "steps",
          "dependsOn": [
            "ASAGA-101",
            "ASAGA-102"
          ],
          "scenario": "The team calls every reverse action rollback, although an issued label can be voided and a completed inspection cannot be undone.",
          "acceptanceCriteria": [
            "Classify compensatable, irreversible and unresolved effects.",
            "State preconditions and outcomes for each compensation.",
            "Separate corrective actions from deletion of historical facts."
          ],
          "implementationNotes": [
            "Use fake providers and document their exact capabilities."
          ],
          "verification": [
            "Map a voidable unused label to its compensation.",
            "Map completed inspection to retained history rather than pretending it can be erased."
          ],
          "deliverables": [
            "Compensation decision table"
          ],
          "rollout": "Review provider capabilities before orchestrator work; block unsupported automatic reversals.",
          "skills": [
            "Compensation design",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0dbad981-19df-4620-b9d4-a67ede59b486",
          "key": "ASAGA-104",
          "title": "Persist return progress and next-step dispatch atomically",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "orchestrate",
          "dependsOn": [
            "ASAGA-101",
            "ASAGA-102",
            "ASAGA-103"
          ],
          "scenario": "Inspection completion commits but the shipping step is never scheduled after a process crash.",
          "acceptanceCriteria": [
            "Commit the observed step fact and outbox dispatch together.",
            "Derive next-step identity from the durable workflow generation.",
            "Make repeated step completion a no-op or explicit conflict."
          ],
          "implementationNotes": [
            "Keep remote provider calls outside database transactions."
          ],
          "verification": [
            "Crash after inspection fact commit and recover label dispatch.",
            "Repeat the same completion and create no duplicate next step."
          ],
          "deliverables": [
            "Workflow/outbox transaction and crash probe"
          ],
          "rollout": "Canary synthetic returns; pause advancement if durable dispatch cannot be recorded.",
          "skills": [
            "Transactional outbox",
            "Workflow durability"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8350b00a-257c-4d14-afea-bdcd318c916e",
          "key": "ASAGA-105",
          "title": "Reconcile shipping acceptance before issuing a replacement label",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "orchestrate",
          "dependsOn": [
            "ASAGA-102",
            "ASAGA-104"
          ],
          "scenario": "The shipping adapter loses its response after accepting a label, and the workflow currently creates a replacement immediately.",
          "acceptanceCriteria": [
            "Query the original provider command identity before replacement.",
            "Record accepted, rejected and unresolved outcomes explicitly.",
            "Create a new generation only under a declared replacement rule."
          ],
          "implementationNotes": [
            "The fake adapter must model accepted-but-unacknowledged requests."
          ],
          "verification": [
            "Recover the original accepted label after a response loss.",
            "Make status unavailable and retain unresolved shipping without a second label."
          ],
          "deliverables": [
            "Shipping reconciliation and uncertainty probe"
          ],
          "rollout": "Enable reconciled retries first; stop automatic replacement when provider identity lookup is unavailable.",
          "skills": [
            "Distributed failure",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "c238aa03-6598-46a7-b5fb-371056db39b5",
          "key": "ASAGA-106",
          "title": "Run label compensation only when its original effect is confirmed",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "orchestrate",
          "dependsOn": [
            "ASAGA-103",
            "ASAGA-104",
            "ASAGA-105"
          ],
          "scenario": "A cancellation request races label issuance and attempts to void a label that may not exist yet.",
          "acceptanceCriteria": [
            "Persist cancellation intent independently of provider completion.",
            "Compensate only the confirmed current label generation.",
            "Keep failed or unknown compensation visible for retry."
          ],
          "implementationNotes": [
            "Never mark a return fully cancelled solely because a compensation request was sent."
          ],
          "verification": [
            "Cancel after confirmed issuance and record confirmed voiding.",
            "Cancel during unknown issuance and wait for reconciliation before compensation."
          ],
          "deliverables": [
            "Cancellation/compensation state transitions"
          ],
          "rollout": "Canary cancellation on fake providers; retain unresolved operations for bounded reconciliation.",
          "skills": [
            "Compensation",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "saga",
              "activity": "APPLY",
              "focus": "Compensate only the confirmed label generation when cancellation races issuance; preserve uncertainty instead of treating a lost response as a failed effect."
            }
          ]
        },
        {
          "id": "edf84f78-38ee-4418-b96c-25efa79fc8e6",
          "key": "ASAGA-107",
          "title": "Authorize refund progression from verified return facts",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "orchestrate",
          "dependsOn": [
            "ASAGA-101",
            "ASAGA-104",
            "ASAGA-106"
          ],
          "scenario": "An administrator can set the aggregate status to inspected and trigger a refund without an actual inspection result.",
          "acceptanceCriteria": [
            "Require a verified inspection fact and matching return generation.",
            "Guard refund requests at the service boundary.",
            "Reject direct status edits that bypass prerequisites."
          ],
          "implementationNotes": [
            "This exercise uses synthetic money and a fake refund provider."
          ],
          "verification": [
            "Advance a return with a valid inspection receipt.",
            "Attempt refund with a forged status change and verify no provider call."
          ],
          "deliverables": [
            "Refund precondition guard and bypass regression"
          ],
          "rollout": "Deploy guarded transitions before exposing administrative actions; stop refund dispatch on missing provenance.",
          "skills": [
            "State authority",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4f50c7d6-085e-4ac6-b217-59d0aa1853f5",
          "key": "ASAGA-108",
          "title": "Show return workflow progress without hiding unresolved compensation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "recover",
          "dependsOn": [
            "ASAGA-105",
            "ASAGA-106",
            "ASAGA-107"
          ],
          "scenario": "The support console shows cancelled even when the label-void request timed out and the customer might still use it.",
          "acceptanceCriteria": [
            "Display business intent separately from confirmed provider outcomes.",
            "Highlight pending reconciliation and compensation states.",
            "Exclude provider credentials and raw customer payloads."
          ],
          "implementationNotes": [
            "Use a dedicated support projection with tenant authorization."
          ],
          "verification": [
            "Display a fully compensated synthetic return.",
            "Display unknown voiding as unresolved and deny another tenant's workflow."
          ],
          "deliverables": [
            "Scoped support workflow projection"
          ],
          "rollout": "Enable read-only status first; keep uncertainty visible when adapters are unavailable.",
          "skills": [
            "Operational UX",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7bf43cb5-51c1-4558-8d47-25f535b13fde",
          "key": "ASAGA-109",
          "title": "Replay a return workflow from its durable history after an orchestrator crash",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "recover",
          "dependsOn": [
            "ASAGA-104",
            "ASAGA-105",
            "ASAGA-106",
            "ASAGA-107"
          ],
          "scenario": "A worker restarts halfway through a return and must decide which steps can resume without repeating side effects.",
          "acceptanceCriteria": [
            "Reconstruct the current state from durable facts and generations.",
            "Reconcile outstanding provider commands before redispatch.",
            "Preserve completed facts and compensation history."
          ],
          "implementationNotes": [
            "Inject crashes between every modeled commit and provider response boundary."
          ],
          "verification": [
            "Replay a completed and a partially compensated synthetic return.",
            "Crash after refund acceptance and verify recovery does not issue a second refund."
          ],
          "deliverables": [
            "Workflow recovery harness and interruption matrix"
          ],
          "rollout": "Run before enabling automatic recovery; pause ambiguous workflows while continuing unaffected ones.",
          "skills": [
            "Recovery",
            "Fault injection"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c89403c7-8a29-4458-9503-cbb8dce01170",
          "key": "ASAGA-110",
          "title": "Write the operator handoff for a return that cannot be fully compensated",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "recover",
          "dependsOn": [
            "ASAGA-103",
            "ASAGA-108",
            "ASAGA-109"
          ],
          "scenario": "A provider confirms an effect that cannot be reversed, and support needs to close the technical incident without fabricating a clean rollback.",
          "acceptanceCriteria": [
            "List confirmed effects, attempted corrections and unresolved consequences.",
            "Define authorized manual decisions separately from automated transitions.",
            "Preserve original receipts and incident provenance."
          ],
          "implementationNotes": [
            "Use a fabricated return and no actual financial advice or transfer."
          ],
          "verification": [
            "Document a successful full compensation case.",
            "Document an irreversible fake-provider outcome without marking it rolled back."
          ],
          "deliverables": [
            "Return exception runbook and worked incident"
          ],
          "rollout": "Review exceptions before manual action; append resolutions instead of rewriting workflow history.",
          "skills": [
            "Operational recovery",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ceb5bcc9-8949-4987-a0cb-1ceeca794793",
      "key": "AMERGE",
      "title": "Synchronize offline equipment inspections without silent overwrites",
      "field": "Distributed systems",
      "summary": "Merge local inspection changes with explicit conflicts, tombstones and attachment identity.",
      "context": "A fictional field team inspects equipment with intermittent connectivity. Two tablets can edit the same checklist and an old upload may restore a deleted finding.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create two local client-state simulators and a synthetic inspection API.",
        "Use fabricated notes and local attachment bytes."
      ],
      "developerValue": "Practice offline synchronization, causal revisions and conflict resolution.",
      "companyValue": "Review whether field work survives disconnection without hiding conflicting observations.",
      "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": "changes",
          "title": "Define change identities",
          "goal": "Represent offline edits and authority boundaries."
        },
        {
          "id": "merge",
          "title": "Synchronize and resolve",
          "goal": "Handle duplicates, conflicts and deletion safely."
        },
        {
          "id": "recovery",
          "title": "Recover interrupted synchronization",
          "goal": "Reconcile attachments and explain remaining conflicts."
        }
      ],
      "tickets": [
        {
          "id": "00b9f2de-8655-4909-813d-3e20e4d273fb",
          "key": "AMERGE-101",
          "title": "Define offline change envelopes with stable client operation IDs",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "changes",
          "dependsOn": [],
          "scenario": "A tablet retries saved edits with new request IDs, so the server creates duplicate inspection findings.",
          "acceptanceCriteria": [
            "Include operation ID, inspection ID, base revision and change type.",
            "Keep device display name separate from identity.",
            "Reject unknown envelope versions before mutation."
          ],
          "implementationNotes": [
            "Use generated disposable client identities."
          ],
          "verification": [
            "Replay the same synthetic change envelope twice.",
            "Change content under the same operation ID and return conflict."
          ],
          "deliverables": [
            "Offline operation contract"
          ],
          "rollout": "Publish the envelope before enabling sync retries; keep incompatible operations in local pending state.",
          "skills": [
            "Protocol design",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Mobile",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "23929c4e-f871-4818-ae90-a87331742194",
          "key": "AMERGE-102",
          "title": "Require current inspection access before applying a queued offline change",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "changes",
          "dependsOn": [
            "AMERGE-101"
          ],
          "scenario": "A contractor loses project access while offline, then reconnects with a batch of previously authorized edits.",
          "acceptanceCriteria": [
            "Reauthorize each target at synchronization time.",
            "Reject revoked or cross-organization changes without partial hidden writes.",
            "Return safe per-operation outcomes under the declared batch policy."
          ],
          "implementationNotes": [
            "Offline possession of data is not continuing write authority."
          ],
          "verification": [
            "Apply a queued edit for a still-authorized actor.",
            "Revoke access before reconnect and verify no inspection mutation."
          ],
          "deliverables": [
            "Sync authorization boundary"
          ],
          "rollout": "Enable scope checks before bulk sync; retain rejected local operations for user review.",
          "skills": [
            "Authorization",
            "Offline systems"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Mobile",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1690b2fe-46a4-4981-9edb-d3c3ff64be86",
          "key": "AMERGE-103",
          "title": "Distinguish independent checklist edits from conflicting edits",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "changes",
          "dependsOn": [
            "AMERGE-101",
            "AMERGE-102"
          ],
          "scenario": "The sync service treats every concurrent change as either a blanket overwrite or a blanket conflict.",
          "acceptanceCriteria": [
            "Define fields that can merge independently.",
            "Require explicit conflict when the same protected value diverges.",
            "Document attachment and deletion conflict rules separately."
          ],
          "implementationNotes": [
            "Use a small fixed checklist; avoid a general-purpose merge language."
          ],
          "verification": [
            "Merge edits to two independent checklist items.",
            "Edit the same item differently and preserve both proposed values as a conflict."
          ],
          "deliverables": [
            "Merge policy table and worked examples"
          ],
          "rollout": "Review the policy before automatic merging; keep unresolved fields on manual resolution.",
          "skills": [
            "Conflict modeling",
            "Data semantics"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7acc7ed6-1787-43b0-b380-ae52c52780d9",
          "key": "AMERGE-104",
          "title": "Apply offline operations with a durable deduplication record",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "merge",
          "dependsOn": [
            "AMERGE-101",
            "AMERGE-102",
            "AMERGE-103"
          ],
          "scenario": "The server applies a change, loses the response, then reapplies it after the tablet reconnects.",
          "acceptanceCriteria": [
            "Commit operation identity and inspection mutation atomically.",
            "Return the original safe outcome for identical retries.",
            "Keep rejected authorization separate from accepted-operation history."
          ],
          "implementationNotes": [
            "Scope deduplication to the authorized client and operation identity."
          ],
          "verification": [
            "Drop the response after commit and retry to one revision.",
            "Force transaction rollback and verify the operation remains retryable without a partial edit."
          ],
          "deliverables": [
            "Idempotent sync transaction"
          ],
          "rollout": "Canary one synthetic client; pause replay when canonical operation identity is inconsistent.",
          "skills": [
            "Transactions",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "06d5245b-f9ce-48fb-a4a4-4151d20ec15a",
          "key": "AMERGE-105",
          "title": "Preserve concurrent inspection findings as explicit conflicts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "merge",
          "dependsOn": [
            "AMERGE-103",
            "AMERGE-104"
          ],
          "scenario": "Two inspectors change a safety finding from different base revisions and last-write-wins hides one observation.",
          "acceptanceCriteria": [
            "Detect divergence from the declared base revision.",
            "Persist both proposals and their operation identities.",
            "Block authoritative resolution until a permitted resolution command chooses or combines them."
          ],
          "implementationNotes": [
            "Do not infer which observer is correct from arrival time."
          ],
          "verification": [
            "Submit conflicting changes in both arrival orders and retain equivalent conflict facts.",
            "Attempt ordinary edit completion over an unresolved conflict and reject it."
          ],
          "deliverables": [
            "Conflict record model and order-invariance tests"
          ],
          "rollout": "Enable conflict capture before automatic reconciliation; leave existing ambiguous cases unresolved.",
          "skills": [
            "Conflict detection",
            "Causal revisions"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "46f017a0-c3cc-4216-aa44-ec970be6a010",
          "key": "AMERGE-106",
          "title": "Resolve an inspection conflict against its current proposal set",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "merge",
          "dependsOn": [
            "AMERGE-105"
          ],
          "scenario": "A reviewer resolves a conflict while a third offline proposal arrives, silently discarding the new observation.",
          "acceptanceCriteria": [
            "Bind resolution to the expected conflict revision and proposal identities.",
            "Record resolution as an append-only fact.",
            "Reject stale resolution without deleting proposals."
          ],
          "implementationNotes": [
            "Require the reviewer's current inspection permission."
          ],
          "verification": [
            "Resolve an unchanged two-proposal conflict.",
            "Add a third proposal before commit and verify stale resolution conflicts."
          ],
          "deliverables": [
            "Guarded conflict resolution command"
          ],
          "rollout": "Canary synthetic review; reopen by appending a new conflict fact rather than editing history.",
          "skills": [
            "Optimistic concurrency",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "21a45a88-e345-4d3d-b42f-67de25131602",
          "key": "AMERGE-107",
          "title": "Keep deleted findings deleted when an old tablet reconnects",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "merge",
          "dependsOn": [
            "AMERGE-103",
            "AMERGE-104",
            "AMERGE-105"
          ],
          "scenario": "A tablet that missed a deletion resubmits its old finding and recreates content the team intentionally removed.",
          "acceptanceCriteria": [
            "Represent deletion with an ordered tombstone.",
            "Reject stale recreation under the declared merge policy.",
            "Define tombstone retention and resnapshot requirements."
          ],
          "implementationNotes": [
            "Avoid using wall-clock time alone to order deletion and recreation."
          ],
          "verification": [
            "Delete a finding and replay an older update.",
            "Expire supported replay history in the simulator and require resnapshot rather than guessing."
          ],
          "deliverables": [
            "Tombstone protocol and stale-client cases"
          ],
          "rollout": "Deploy tombstones before cleanup; halt tombstone removal until the resnapshot contract is available.",
          "skills": [
            "Deletion semantics",
            "Synchronization"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a336a380-c9ae-46ac-9a58-41afc858ed19",
          "key": "AMERGE-108",
          "title": "Finalize offline attachments by verified content identity",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "recovery",
          "dependsOn": [
            "AMERGE-104",
            "AMERGE-107"
          ],
          "scenario": "An inspection references a photo before its interrupted upload completes, producing broken evidence links in the field report.",
          "acceptanceCriteria": [
            "Stage attachment uploads separately from finding references.",
            "Finalize only exact verified object generation and content hash.",
            "Keep incomplete attachments visible as pending without public links."
          ],
          "implementationNotes": [
            "Use synthetic images or byte fixtures; no personal photographs are needed."
          ],
          "verification": [
            "Complete a valid synthetic attachment and resolve its stable identity.",
            "Interrupt upload or alter bytes and verify the finding cannot publish an invalid link."
          ],
          "deliverables": [
            "Attachment finalization contract"
          ],
          "rollout": "Canary local attachments; keep staged objects private and resume or discard only exact generations.",
          "skills": [
            "Storage integrity",
            "Offline workflows"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Mobile",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "691ce9a1-3402-42a7-8594-82ca7b16de53",
          "key": "AMERGE-109",
          "title": "Resume inspection synchronization from a server-confirmed cursor",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recovery",
          "dependsOn": [
            "AMERGE-104",
            "AMERGE-106",
            "AMERGE-107",
            "AMERGE-108"
          ],
          "scenario": "The tablet stores a local cursor before receiving server confirmation and skips updates after a crash.",
          "acceptanceCriteria": [
            "Advance the local acknowledged cursor only after durable server outcome.",
            "Bind cursor to inspection scope and sync generation.",
            "Require resnapshot when the server cannot honor the retained history window."
          ],
          "implementationNotes": [
            "Use two client simulators with controlled interruption points."
          ],
          "verification": [
            "Crash during a sync page and resume without missing confirmed operations.",
            "Use an expired or cross-scope cursor and reject incremental sync safely."
          ],
          "deliverables": [
            "Cursor recovery protocol and crash harness"
          ],
          "rollout": "Enable incremental sync after the resnapshot path passes; retain local pending operations until acknowledged.",
          "skills": [
            "Checkpointing",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "aadba700-8c89-4e22-997d-d1a62e845b3d",
          "key": "AMERGE-110",
          "title": "Show sync completion separately from resolved inspection conflicts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "recovery",
          "dependsOn": [
            "AMERGE-106",
            "AMERGE-108",
            "AMERGE-109"
          ],
          "scenario": "A tablet says all synced even though uploaded changes contain unresolved conflicts and a pending attachment.",
          "acceptanceCriteria": [
            "Report transport acknowledgement, conflict state and attachment state separately.",
            "Keep rejected operations visible with safe reasons.",
            "Never equate uploaded data with an approved inspection."
          ],
          "implementationNotes": [
            "Use a local status projection with accessible plain-language labels."
          ],
          "verification": [
            "Display a fully acknowledged conflict-free synthetic inspection.",
            "Acknowledge a conflicting batch and retain unresolved status."
          ],
          "deliverables": [
            "Sync status contract and state examples"
          ],
          "rollout": "Publish precise status labels; restore prior layout without collapsing distinct states.",
          "skills": [
            "Distributed UX",
            "State semantics"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "3ca4922d-a6d3-4d7b-880d-85ebffbd7f85",
      "key": "ABATCH",
      "title": "Aggregate parallel risk checks without losing partial outcomes",
      "field": "Distributed systems",
      "summary": "Coordinate independent document checks into a bounded, reproducible aggregate result.",
      "context": "A fictional vendor portal runs format, policy and duplicate checks in parallel. A slow checker blocks completion, while duplicate callbacks can produce contradictory final summaries.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Provider interfaces"
      ],
      "prerequisites": [
        "Create synthetic document identities and three fake check providers.",
        "No real risk scoring, hiring decisions or candidate execution is included."
      ],
      "developerValue": "Practice fan-out/fan-in, deadline policies and immutable aggregation.",
      "companyValue": "Review trustworthy partial-result handling and controllable parallel work.",
      "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": "contract",
          "title": "Define independent check facts",
          "goal": "Specify input identity, required checks and result states."
        },
        {
          "id": "aggregate",
          "title": "Coordinate parallel outcomes",
          "goal": "Dispatch, deduplicate and finalize with explicit deadlines."
        },
        {
          "id": "recover",
          "title": "Recover incomplete runs",
          "goal": "Replay work and explain aggregate provenance."
        }
      ],
      "tickets": [
        {
          "id": "f59d8645-6321-475b-8dc1-1425d0c1e432",
          "key": "ABATCH-101",
          "title": "Freeze the required check set when a document review run starts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "A configuration change adds a checker while a run is in progress, so the completion predicate changes halfway through.",
          "acceptanceCriteria": [
            "Record exact checker identities and versions per run.",
            "Bind the set to immutable document input identity.",
            "New configuration affects only new runs."
          ],
          "implementationNotes": [
            "Use three deterministic fake checks with no capability scoring."
          ],
          "verification": [
            "Start runs before and after a check-set change.",
            "Finish the older run using its original required set."
          ],
          "deliverables": [
            "Review-run manifest"
          ],
          "rollout": "Publish frozen manifests before parallel dispatch; retain prior checker versions for replay.",
          "skills": [
            "Immutability",
            "Workflow contracts"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a4876a91-5370-4caf-971c-8a022482ef24",
          "key": "ABATCH-102",
          "title": "Define pass, fail, unavailable and not-applicable check outcomes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contract",
          "dependsOn": [
            "ABATCH-101"
          ],
          "scenario": "A timed-out policy checker returns an empty findings list, which the aggregator interprets as passed.",
          "acceptanceCriteria": [
            "Use explicit outcome states with bounded structured details.",
            "Require justification for not-applicable under the declared contract.",
            "Keep unavailable distinct from an empty successful result."
          ],
          "implementationNotes": [
            "Reject unsupported fields and prohibit demographic or personality inferences."
          ],
          "verification": [
            "Accept a valid empty successful check.",
            "Timeout a checker and retain unavailable rather than pass."
          ],
          "deliverables": [
            "Check-result schema and semantic cases"
          ],
          "rollout": "Deploy result validation before aggregate updates; quarantine incompatible provider output.",
          "skills": [
            "Structured validation",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "857f056b-1cea-4504-9955-31fa5d39657b",
          "key": "ABATCH-103",
          "title": "Bound parallel check fan-out per organization and run",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "contract",
          "dependsOn": [
            "ABATCH-101",
            "ABATCH-102"
          ],
          "scenario": "One tenant submits many documents and the coordinator starts every check immediately, exhausting provider slots.",
          "acceptanceCriteria": [
            "Set explicit per-run and per-tenant in-flight limits.",
            "Persist queued attempts instead of dropping them.",
            "Return admission status separate from check completion."
          ],
          "implementationNotes": [
            "Use documented synthetic limits and a fake provider counter."
          ],
          "verification": [
            "Dispatch a permitted number of synthetic checks.",
            "Exceed the tenant limit and verify excess work remains queued without provider calls."
          ],
          "deliverables": [
            "Fan-out admission guard"
          ],
          "rollout": "Canary conservative limits; pause admission when provider capacity is unknown.",
          "skills": [
            "Concurrency budgets",
            "Admission control"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "097f7552-8b65-4d3e-9704-273063d6eb46",
          "key": "ABATCH-104",
          "title": "Dispatch each check through a durable deterministic attempt identity",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "aggregate",
          "dependsOn": [
            "ABATCH-101",
            "ABATCH-103"
          ],
          "scenario": "The coordinator crashes after dispatching one checker and cannot tell which of the three still needs to start.",
          "acceptanceCriteria": [
            "Persist check-attempt identity and outbox dispatch per required checker.",
            "Keep dispatch retries bound to the same input and checker version.",
            "Reject contradictory reuse of an attempt identity."
          ],
          "implementationNotes": [
            "Call providers outside the database transaction."
          ],
          "verification": [
            "Crash after one dispatched check and resume remaining work.",
            "Replay an outbox fact and keep one logical provider attempt."
          ],
          "deliverables": [
            "Check dispatch transaction and crash probe"
          ],
          "rollout": "Prototype with fake providers; stop new runs if attempt identity cannot be persisted.",
          "skills": [
            "Outbox",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "62416955-f6e2-4604-95e7-cd775dee0e35",
          "key": "ABATCH-105",
          "title": "Deduplicate callbacks without accepting contradictory check results",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "aggregate",
          "dependsOn": [
            "ABATCH-102",
            "ABATCH-104"
          ],
          "scenario": "A provider retries its callback and later sends a changed result for the same attempt ID.",
          "acceptanceCriteria": [
            "Identical callback retries resolve one recorded result.",
            "Different terminal content for the same attempt creates a conflict.",
            "Validate run, input and checker identities before recording."
          ],
          "implementationNotes": [
            "Use canonical result hashes and authenticated fixture callbacks."
          ],
          "verification": [
            "Deliver the same terminal callback twice.",
            "Alter a terminal result or input hash and keep the accepted result plus a visible conflict."
          ],
          "deliverables": [
            "Callback ingestion guard"
          ],
          "rollout": "Canary callback handling; quarantine contradictory provider output without rewriting terminal facts.",
          "skills": [
            "Deduplication",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3cc493da-b992-4048-b617-2c9aa3b66538",
          "key": "ABATCH-106",
          "title": "Finalize aggregates only from the frozen required check set",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "aggregate",
          "dependsOn": [
            "ABATCH-101",
            "ABATCH-102",
            "ABATCH-105"
          ],
          "scenario": "An optional checker finishes quickly and accidentally satisfies a counter-based completion condition while a required checker is missing.",
          "acceptanceCriteria": [
            "Evaluate completeness by exact required identities.",
            "Compute aggregate state from validated immutable check facts.",
            "Reject finalization when required results are missing or conflicting."
          ],
          "implementationNotes": [
            "Define aggregate output as review status, never an opaque hire/reject score."
          ],
          "verification": [
            "Finish all required checks and produce the expected status.",
            "Complete extra optional checks while omitting one required check and block completion."
          ],
          "deliverables": [
            "Aggregate reducer and completeness tests"
          ],
          "rollout": "Enable guarded finalization before publishing results; retain pending state on missing authority.",
          "skills": [
            "Aggregation",
            "Set invariants"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "bc74ab32-c7a1-4bf4-ae2a-eef6c6c91bb1",
          "key": "ABATCH-107",
          "title": "Apply a run deadline without rewriting late check facts",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "aggregate",
          "dependsOn": [
            "ABATCH-102",
            "ABATCH-106"
          ],
          "scenario": "A slow checker returns after the review deadline and overwrites a summary already shown to the user.",
          "acceptanceCriteria": [
            "Define a deadline terminal state with explicit incomplete checks.",
            "Preserve late results as appended facts without mutating the frozen summary.",
            "Allow a new run or reviewed amendment under an explicit policy."
          ],
          "implementationNotes": [
            "Use an injected clock and exact boundary cases."
          ],
          "verification": [
            "Complete required checks before deadline.",
            "Return one check after deadline and retain the original summary plus late-result visibility."
          ],
          "deliverables": [
            "Deadline finalization and late-result cases"
          ],
          "rollout": "Canary synthetic short deadlines; create new runs when a policy change requires reevaluation.",
          "skills": [
            "Temporal workflows",
            "Append-only results"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d0fa630d-ba3f-430d-8f49-47d7310f2fca",
          "key": "ABATCH-108",
          "title": "Recover outstanding checks by querying provider attempt identity",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "ABATCH-104",
            "ABATCH-105",
            "ABATCH-107"
          ],
          "scenario": "After a restart, several attempts are marked dispatched but have no callback; immediate resubmission may duplicate costly work.",
          "acceptanceCriteria": [
            "Reconcile each unresolved attempt through its provider identity.",
            "Redispatch only under the adapter's declared idempotency contract.",
            "Keep unknown provider state visible and bounded."
          ],
          "implementationNotes": [
            "Use fake providers that model lost callbacks and unavailable lookup."
          ],
          "verification": [
            "Recover a completed check whose callback was lost.",
            "Make provider lookup unavailable and verify no unsupported success or duplicate attempt."
          ],
          "deliverables": [
            "Outstanding-attempt reconciler"
          ],
          "rollout": "Start recovery with bounded batches; suspend affected adapters when identity guarantees fail.",
          "skills": [
            "Reconciliation",
            "Distributed failure"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3b6351c0-e4f7-4c2b-9259-9fdfc004e827",
          "key": "ABATCH-109",
          "title": "Produce a result provenance view that names missing and conflicting checks",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "recover",
          "dependsOn": [
            "ABATCH-105",
            "ABATCH-106",
            "ABATCH-107",
            "ABATCH-108"
          ],
          "scenario": "Users receive only a summary label and cannot inspect whether every required checker actually ran.",
          "acceptanceCriteria": [
            "List frozen checker versions and input identity.",
            "Show outcome, unavailable and conflict states separately.",
            "Keep internal prompts, secrets and raw provider traces out of the view."
          ],
          "implementationNotes": [
            "Use public practice facts only; this is not noCV assessment evidence."
          ],
          "verification": [
            "Inspect a complete synthetic aggregate.",
            "Inspect a deadline result and clearly identify the missing checker."
          ],
          "deliverables": [
            "Safe provenance projection"
          ],
          "rollout": "Publish read-only provenance with aggregate status; hide fields that fail schema review.",
          "skills": [
            "Provenance",
            "Transparency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f338a38a-afb2-4ec7-ae22-c806b4968617",
          "key": "ABATCH-110",
          "title": "Exercise the parallel-check coordinator under reordered failures",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "recover",
          "dependsOn": [
            "ABATCH-105",
            "ABATCH-106",
            "ABATCH-107",
            "ABATCH-108",
            "ABATCH-109"
          ],
          "scenario": "Happy-path tests always complete checks in the same order and miss a race between deadline finalization and the last callback.",
          "acceptanceCriteria": [
            "Run permutations of declared completion, timeout and conflict events.",
            "Assert one immutable summary and complete retained check history.",
            "Record any unsupported adapter guarantee as a failing readiness condition."
          ],
          "implementationNotes": [
            "Use a deterministic event scheduler; no arbitrary sleeps."
          ],
          "verification": [
            "Run all required checks in several completion orders with equal final semantics.",
            "Race final callback with deadline and verify the declared single outcome."
          ],
          "deliverables": [
            "Deterministic coordinator fault harness"
          ],
          "rollout": "Require the harness before adapter changes; retain the prior coordinator version if invariants fail.",
          "skills": [
            "Concurrency testing",
            "Fault injection"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "b83998ec-d76e-456c-a667-6064568ba37e",
      "key": "ACACHE",
      "title": "Keep shared product caches consistent across writers",
      "field": "Distributed systems",
      "summary": "Invalidate and refresh tenant-scoped product views without resurrecting stale versions.",
      "context": "A fictional wholesale portal caches product availability descriptions across several API instances. Delayed invalidations and slow refreshes bring back old content after edits.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Redis"
      ],
      "prerequisites": [
        "Create two local cache clients and a synthetic authoritative product store.",
        "Use a fake clock and controllable read/write barriers."
      ],
      "developerValue": "Practice cache consistency, version guards and recoverable invalidation.",
      "companyValue": "Review fast derived reads without losing authoritative state or tenant isolation.",
      "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": "identity",
          "title": "Define cache meaning",
          "goal": "Bind keys, versions and freshness to authoritative data."
        },
        {
          "id": "refresh",
          "title": "Guard shared refreshes",
          "goal": "Order writes, invalidations and concurrent fills."
        },
        {
          "id": "failure",
          "title": "Recover cache uncertainty",
          "goal": "Handle outages, reconcile generations and expose staleness."
        }
      ],
      "tickets": [
        {
          "id": "56909d89-0541-4001-9245-44d7947d017e",
          "key": "ACACHE-101",
          "title": "Define cache keys from every product-view authority input",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "identity",
          "dependsOn": [],
          "scenario": "Two customer organizations request the same SKU but have different visible product descriptions, and the shared cache returns the first result.",
          "acceptanceCriteria": [
            "Bind keys to organization, view policy and product identity.",
            "Authorize before cache lookup.",
            "Version the key namespace for incompatible projection changes."
          ],
          "implementationNotes": [
            "Do not include secrets or raw personal data in keys."
          ],
          "verification": [
            "Cache different permitted views of the same synthetic SKU.",
            "Request another organization's view and verify no cross-scope hit."
          ],
          "deliverables": [
            "Canonical cache-key contract"
          ],
          "rollout": "Introduce a fresh namespace and expire the affected old namespace.",
          "skills": [
            "Cache identity",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fa7bfc5d-b923-4fb9-896e-0d10ba1e5eb7",
          "key": "ACACHE-102",
          "title": "Specify what stale product data the portal may display",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "identity",
          "dependsOn": [
            "ACACHE-101"
          ],
          "scenario": "The cache uses one TTL for descriptive text and order-critical availability, though they have different correctness needs.",
          "acceptanceCriteria": [
            "Classify fields by tolerated staleness.",
            "Keep authoritative order decisions outside stale display data.",
            "Define fresh, stale-allowed and unusable cache states."
          ],
          "implementationNotes": [
            "Use explicit hypothetical freshness bounds with product approval noted as pending."
          ],
          "verification": [
            "Serve stale descriptive text within the declared window.",
            "Reject using stale cached availability to authorize an order."
          ],
          "deliverables": [
            "Cache consistency matrix"
          ],
          "rollout": "Review the matrix before changing TTLs; leave unresolved critical reads authoritative.",
          "skills": [
            "Consistency policy",
            "Data semantics"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ad1e051e-435c-441d-a2b2-04264d766757",
          "key": "ACACHE-103",
          "title": "Record authoritative product revision with each cached projection",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "identity",
          "dependsOn": [
            "ACACHE-101",
            "ACACHE-102"
          ],
          "scenario": "An API instance receives two cached values but cannot tell which reflects the newer database update.",
          "acceptanceCriteria": [
            "Store source revision and projection version with the value.",
            "Reject malformed or unknown envelopes.",
            "Keep fetch time separate from source revision."
          ],
          "implementationNotes": [
            "Do not use cache write time as data ordering authority."
          ],
          "verification": [
            "Compare cached revisions 7 and 8.",
            "Read an envelope missing revision and treat it as unusable."
          ],
          "deliverables": [
            "Versioned cache envelope"
          ],
          "rollout": "Deploy readers that accept the envelope before enabling new writers; miss safely on legacy values.",
          "skills": [
            "Versioning",
            "Cache contracts"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c1d285f5-80bd-4cf7-b543-c8155e8a9f87",
          "key": "ACACHE-104",
          "title": "Commit product changes with a durable invalidation fact",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "refresh",
          "dependsOn": [
            "ACACHE-101",
            "ACACHE-103"
          ],
          "scenario": "The product write commits and then the process dies before deleting shared cache keys.",
          "acceptanceCriteria": [
            "Persist the product revision and invalidation outbox fact atomically.",
            "Bind invalidation identity to product scope and revision.",
            "Replay invalidation safely after a crash."
          ],
          "implementationNotes": [
            "Cache failure must not roll back an already committed product change."
          ],
          "verification": [
            "Crash after database commit and dispatch the retained invalidation.",
            "Replay the same invalidation and retain correct cache state."
          ],
          "deliverables": [
            "Product/outbox transaction and recovery test"
          ],
          "rollout": "Canary one synthetic product class; monitor pending invalidations and fall back to authoritative reads when stale bounds expire.",
          "skills": [
            "Transactional outbox",
            "Invalidation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "babc7479-8875-4c9e-b660-e9ba5aba6f69",
          "key": "ACACHE-105",
          "title": "Prevent a slow cache fill from overwriting a newer product revision",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "refresh",
          "dependsOn": [
            "ACACHE-103",
            "ACACHE-104"
          ],
          "scenario": "A read for revision 7 starts before an edit, then finishes after revision 8 has already been cached and overwrites it.",
          "acceptanceCriteria": [
            "Use an atomic revision comparison when publishing a fill.",
            "Reject lower source revisions regardless of completion order.",
            "Keep projection-version incompatibility separate from source ordering."
          ],
          "implementationNotes": [
            "Implement with a bounded Redis script or provider-level compare-and-set."
          ],
          "verification": [
            "Pause an old fill, publish the new revision, then resume the old fill.",
            "Attempt a malformed revision and verify it cannot replace the current value."
          ],
          "deliverables": [
            "Version-guarded fill and race reproduction"
          ],
          "rollout": "Canary guarded fills; disable cache publication if the adapter lacks atomic comparison.",
          "skills": [
            "Compare-and-set",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "80a42db5-aa79-4ec3-bc6d-4df60ed83d48",
          "key": "ACACHE-106",
          "title": "Handle delayed invalidation without evicting a newer cache revision unnecessarily",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "refresh",
          "dependsOn": [
            "ACACHE-104",
            "ACACHE-105"
          ],
          "scenario": "An old invalidation arrives after a fresh fill and deletes valid data, triggering avoidable refresh work across instances.",
          "acceptanceCriteria": [
            "Compare invalidation revision with cached source revision.",
            "Evict or mark stale only entries covered by the event.",
            "Treat missing or incompatible envelopes as safe misses."
          ],
          "implementationNotes": [
            "Keep invalidation decisions atomic with cache state inspection."
          ],
          "verification": [
            "Deliver revision 7 invalidation against cached revision 8 and retain it.",
            "Deliver matching/newer invalidation and enforce the declared stale behavior."
          ],
          "deliverables": [
            "Revision-aware invalidation and ordering tests"
          ],
          "rollout": "Enable after envelope rollout; fall back to conservative eviction on unknown formats.",
          "skills": [
            "Event ordering",
            "Cache invalidation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "34520256-4547-4b16-9903-83ae9f3eae70",
          "key": "ACACHE-107",
          "title": "Bound duplicate refresh work across API instances",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "refresh",
          "dependsOn": [
            "ACACHE-102",
            "ACACHE-105",
            "ACACHE-106"
          ],
          "scenario": "A popular product expires and every API instance refreshes it simultaneously, increasing pressure on the source database.",
          "acceptanceCriteria": [
            "Use a bounded per-key refresh ownership mechanism.",
            "Waiters have a deadline and declared stale/miss fallback.",
            "Expired refresh ownership cannot publish an older revision."
          ],
          "implementationNotes": [
            "A refresh lock reduces duplicate work; revision fencing still protects correctness."
          ],
          "verification": [
            "Request one expired synthetic key from two clients and observe bounded refresh calls.",
            "Pause the owner past expiry and verify stale completion cannot overwrite newer data."
          ],
          "deliverables": [
            "Shared refresh coordinator and expired-owner test"
          ],
          "rollout": "Canary a small key cohort; disable coordination while retaining revision guards if locks stall.",
          "skills": [
            "Single-flight",
            "Lease limits"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "36edf2a6-ec3d-4b3a-b0d1-abef4fa23210",
          "key": "ACACHE-108",
          "title": "Fall back predictably when the shared cache is unavailable",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "failure",
          "dependsOn": [
            "ACACHE-102",
            "ACACHE-104",
            "ACACHE-107"
          ],
          "scenario": "A Redis outage makes every request retry repeatedly, overwhelming the authoritative database while users wait.",
          "acceptanceCriteria": [
            "Bound cache attempts and stop retry amplification.",
            "Apply an explicit source-read admission limit.",
            "Return the declared degraded or unavailable response when both paths lack capacity."
          ],
          "implementationNotes": [
            "Use local adapter failures and synthetic requests."
          ],
          "verification": [
            "Disconnect the cache and serve an admitted authoritative read.",
            "Exceed fallback admission and return a bounded failure without unbounded source calls."
          ],
          "deliverables": [
            "Cache-outage fallback and overload probe"
          ],
          "rollout": "Canary with conservative fallback limits; shed excess reads until cache recovery is verified.",
          "skills": [
            "Failure containment",
            "Admission control"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9d4fb00f-a9ab-4a0a-92a2-7a4b8b1b2da9",
          "key": "ACACHE-109",
          "title": "Reconcile cache generations after a projection-schema release",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "failure",
          "dependsOn": [
            "ACACHE-103",
            "ACACHE-105",
            "ACACHE-108"
          ],
          "scenario": "A new release changes product projection shape while old and new API instances share cached envelopes.",
          "acceptanceCriteria": [
            "Use explicit projection namespaces and compatible-reader declarations.",
            "Warm a new namespace from authoritative revisions.",
            "Retire the old namespace only after old readers are gone."
          ],
          "implementationNotes": [
            "Do not rewrite old cache values into a guessed new schema."
          ],
          "verification": [
            "Run mixed-version clients against their declared namespaces.",
            "Send a new envelope to an incompatible reader and verify safe miss or rejection."
          ],
          "deliverables": [
            "Cache-generation rollout and compatibility drill"
          ],
          "rollout": "Switch one synthetic cohort first; restore its previous namespace while keeping authoritative data unchanged.",
          "skills": [
            "Schema compatibility",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4bd4dbb6-77c3-4cf7-941f-4f2217e5289a",
          "key": "ACACHE-110",
          "title": "Expose cache freshness observations without claiming source correctness",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "failure",
          "dependsOn": [
            "ACACHE-102",
            "ACACHE-108",
            "ACACHE-109"
          ],
          "scenario": "The dashboard shows a high hit rate as proof the product data is correct, though hit count says nothing about revision freshness.",
          "acceptanceCriteria": [
            "Report hit/miss, source revision and observed freshness separately.",
            "Mark unknown source comparison explicitly.",
            "Avoid exposing product payloads in generic telemetry."
          ],
          "implementationNotes": [
            "Metrics describe cache behavior, not business-data correctness."
          ],
          "verification": [
            "Observe a fresh hit with a known source revision.",
            "Hide source revision availability and report unknown freshness despite a cache hit."
          ],
          "deliverables": [
            "Cache health projection and semantics notes"
          ],
          "rollout": "Add freshness diagnostics before tuning hit-rate targets; retain unknown states during outages.",
          "skills": [
            "Observability",
            "Metric semantics"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ebc48eea-e9e0-4933-b542-cfb020847b73",
      "key": "BMONO",
      "title": "Monorepo change planner",
      "field": "Developer tooling",
      "summary": "Make selective CI trustworthy when packages, lockfiles, and generated inputs change.",
      "context": "A fictional internal tools team maintains eighteen packages. Engineers currently run everything because the affected-package script occasionally misses downstream consumers.",
      "stack": [
        "TypeScript",
        "pnpm",
        "Git"
      ],
      "prerequisites": [
        "Create a local six-package fixture with a dependency cycle, shared compiler configuration, and two example changes."
      ],
      "developerValue": "Practice graph analysis, reproducible commands, and safe developer-tool failure modes.",
      "companyValue": "Produce an inspectable CI selection plan that avoids unnecessary work without silently skipping consumers.",
      "delivery": "Deliver a local planning CLI, regression fixtures, and an adoption note; hosted CI integration is optional.",
      "phases": [
        {
          "id": "map",
          "title": "Map the inputs",
          "goal": "Define which repository changes affect which commands."
        },
        {
          "id": "plan",
          "title": "Build the planner",
          "goal": "Produce deterministic affected sets with conservative fallbacks."
        },
        {
          "id": "adopt",
          "title": "Adopt safely",
          "goal": "Compare selective runs against full runs before enforcement."
        }
      ],
      "tickets": [
        {
          "id": "e928f5ea-1a8b-4849-90cd-ca0f9c8b2764",
          "key": "BMONO-101",
          "title": "Document task inputs beyond package dependencies",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "map",
          "dependsOn": [],
          "scenario": "A root compiler change passed CI although an unchanged package no longer compiled. Inventory inputs the planner must treat as shared.",
          "acceptanceCriteria": [
            "List compiler, lockfile, environment, and generator inputs separately.",
            "Assign an owner and invalidation rule to each input.",
            "Include one change that legitimately affects every package."
          ],
          "implementationNotes": [
            "Use the local fixture; do not inspect private repositories."
          ],
          "verification": [
            "Trace a package-only edit to its expected tasks.",
            "Trace an unknown root input to conservative full selection."
          ],
          "deliverables": [
            "Input ownership matrix."
          ],
          "rollout": "Review the matrix before enabling selection; retain full CI as fallback.",
          "skills": [
            "Dependency analysis",
            "Build systems"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "fd02c7e7-8f72-4ea0-851a-91ae3ee35a59",
          "key": "BMONO-102",
          "title": "Parse workspace manifests without executing package scripts",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "map",
          "dependsOn": [
            "BMONO-101"
          ],
          "scenario": "The planner must inspect an unfamiliar checkout without triggering install hooks or repository commands.",
          "acceptanceCriteria": [
            "Resolve workspace package names and paths from manifests.",
            "Reject duplicate names and paths outside the checkout.",
            "Report malformed JSON with file and safe location."
          ],
          "implementationNotes": [
            "Treat manifests as data; never evaluate imported configuration."
          ],
          "verification": [
            "Load valid nested workspace fixtures.",
            "Reject traversal, duplicate identity, and invalid JSON fixtures."
          ],
          "deliverables": [
            "Manifest parser and fixture tests."
          ],
          "rollout": "Use read-only inventory mode first; fall back to full CI on parser errors.",
          "skills": [
            "TypeScript",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5f091b07-d974-4c0b-893f-4bbd3f18048d",
          "key": "BMONO-103",
          "title": "Handle cycles in the downstream impact graph",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "plan",
          "dependsOn": [
            "BMONO-102"
          ],
          "scenario": "Two shared packages depend on each other through development tooling, and recursive traversal never finishes.",
          "acceptanceCriteria": [
            "Collapse or explicitly track cycles without dropping members.",
            "Include transitive dependents once each.",
            "Sort output stably regardless of manifest enumeration order."
          ],
          "implementationNotes": [
            "Distinguish runtime and development edges in the plan explanation."
          ],
          "verification": [
            "Resolve a diamond graph with one cycle.",
            "Verify a disconnected package stays excluded and traversal terminates."
          ],
          "deliverables": [
            "Cycle-safe graph traversal."
          ],
          "rollout": "Compare results with full package selection; disable selective mode if membership differs.",
          "skills": [
            "Graph algorithms",
            "Dependency analysis"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "12dcc0b4-6c0b-4607-9235-dca5418c901e",
          "key": "BMONO-104",
          "title": "Resolve renamed and deleted files against both revisions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "plan",
          "dependsOn": [
            "BMONO-102"
          ],
          "scenario": "A package deletion disappears from the current workspace map and incorrectly produces an empty plan.",
          "acceptanceCriteria": [
            "Read changed paths from a declared base and head.",
            "Account for both source and destination of renames.",
            "Select former dependents when a package is removed."
          ],
          "implementationNotes": [
            "Do not assume a remote branch exists in a shallow checkout."
          ],
          "verification": [
            "Plan a package move with unchanged contents.",
            "Exercise missing base and deleted-manifest cases with explicit fallback."
          ],
          "deliverables": [
            "Revision-aware path ownership logic."
          ],
          "rollout": "Ship behind diagnostic output; preserve full CI for unresolved history.",
          "skills": [
            "Git",
            "Change analysis"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "d7ff818b-da54-4781-bd12-3e53a8fddb06",
          "key": "BMONO-105",
          "title": "Explain why each selected command is necessary",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "plan",
          "dependsOn": [
            "BMONO-103",
            "BMONO-104"
          ],
          "scenario": "Maintainers cannot review a large affected set because the tool prints only package names.",
          "acceptanceCriteria": [
            "Attach at least one changed input to each selected task.",
            "Represent transitive paths without unbounded recursion.",
            "Emit stable JSON and readable plain-text output."
          ],
          "implementationNotes": [
            "Keep absolute workstation paths out of exported plans."
          ],
          "verification": [
            "Snapshot a direct and a transitive explanation.",
            "Verify cyclic and missing-owner explanations remain bounded."
          ],
          "deliverables": [
            "Plan explanation renderer."
          ],
          "rollout": "Enable explanation output immediately; keep command execution opt-in.",
          "skills": [
            "CLI design",
            "Developer experience"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "169d0729-89ea-44be-ae99-c1eaa63c8174",
          "key": "BMONO-106",
          "title": "Make cache keys include generator versions and relevant environment",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "plan",
          "dependsOn": [
            "BMONO-101",
            "BMONO-103"
          ],
          "scenario": "Generated client code changed after a tool upgrade while the cache reused an old successful result.",
          "acceptanceCriteria": [
            "Hash declared inputs using stable ordering.",
            "Include generator version and allowlisted environment names.",
            "Exclude secrets and unrelated environment values from key material."
          ],
          "implementationNotes": [
            "A cache hit must never authorize skipping an undeclared dependency."
          ],
          "verification": [
            "Change each declared input and observe key changes.",
            "Verify secret values are absent from keys and diagnostic output."
          ],
          "deliverables": [
            "Cache-key contract and regression checks."
          ],
          "rollout": "Invalidate old keys on adoption; revert to uncached commands if key provenance is missing.",
          "skills": [
            "Caching",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b78f2c9d-7bae-416c-b22c-57840b89c31f",
          "key": "BMONO-107",
          "title": "Detect stale plan execution after the worktree changes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "plan",
          "dependsOn": [
            "BMONO-105",
            "BMONO-106"
          ],
          "scenario": "A developer reviews a plan, edits another package, then executes commands from the earlier plan.",
          "acceptanceCriteria": [
            "Bind plans to revision and relevant working-tree digests.",
            "Check the binding immediately before execution.",
            "Return a distinct stale-plan error with regeneration guidance."
          ],
          "implementationNotes": [
            "Do not discard or reset local edits."
          ],
          "verification": [
            "Execute an unchanged reviewed plan successfully.",
            "Modify a tracked input and reject the stale plan before spawning commands."
          ],
          "deliverables": [
            "Plan freshness guard."
          ],
          "rollout": "Require freshness for execution; allow explicit regeneration without modifying the checkout.",
          "skills": [
            "Integrity checks",
            "CLI design"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "ea67aaf9-4e02-46c6-a3d0-c1eaa2877b04",
          "key": "BMONO-108",
          "title": "Bound parallel commands and stop cleanly on cancellation",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "adopt",
          "dependsOn": [
            "BMONO-107"
          ],
          "scenario": "Selective tasks saturate a laptop and leave child processes alive when the parent command is interrupted.",
          "acceptanceCriteria": [
            "Enforce configured parallelism between one and the fixture package count.",
            "Stop scheduling new work after cancellation.",
            "Report completed, failed, and cancelled tasks separately."
          ],
          "implementationNotes": [
            "Execute only trusted fixture commands in this exercise."
          ],
          "verification": [
            "Observe the concurrency ceiling with delayed fixtures.",
            "Cancel mid-run and verify owned child processes terminate."
          ],
          "deliverables": [
            "Bounded command scheduler."
          ],
          "rollout": "Default to conservative parallelism; provide serial mode for recovery.",
          "skills": [
            "Process management",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8bda1001-eaec-41e1-86cc-cdfb8d5e8d58",
          "key": "BMONO-109",
          "title": "Compare selective and full plans over a recorded change corpus",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "adopt",
          "dependsOn": [
            "BMONO-103",
            "BMONO-104",
            "BMONO-106",
            "BMONO-108"
          ],
          "scenario": "Before making selection mandatory, the team needs a defensible way to find false negatives rather than celebrate shorter CI runs.",
          "acceptanceCriteria": [
            "Define a corpus covering root, package, rename, and deletion changes.",
            "Compare selected task outcomes with full-run outcomes under identical inputs.",
            "Block adoption on an unexplained excluded failure and record uncertainty."
          ],
          "implementationNotes": [
            "Report workload and machine limits; do not promise general speedups from local measurements."
          ],
          "verification": [
            "Detect an intentionally omitted shared input.",
            "Show a safe exclusion and publish reproducible comparison commands."
          ],
          "deliverables": [
            "Adoption assessment and mismatch report."
          ],
          "rollout": "Run in shadow mode for the corpus; retain a one-command full-run override.",
          "skills": [
            "Experimental design",
            "CI engineering"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "59ffcde3-cf51-460c-b434-68e76a2ae336",
          "key": "BMONO-110",
          "title": "Write a maintainer playbook for adding a new task input",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "adopt",
          "dependsOn": [
            "BMONO-109"
          ],
          "scenario": "New generators will appear after launch, and ownership of the invalidation map is currently undocumented.",
          "acceptanceCriteria": [
            "Show how to declare one generator input and its owner.",
            "Include the regression case required before selective execution.",
            "Document diagnosis of unexpected full and empty plans."
          ],
          "implementationNotes": [
            "Use examples from the implemented planner rather than future capabilities."
          ],
          "verification": [
            "Follow the guide to add a synthetic generator input.",
            "Verify omission is detected by the comparison procedure."
          ],
          "deliverables": [
            "Maintainer guide with worked example."
          ],
          "rollout": "Link the guide from CLI help; withdraw selective defaults if ownership becomes unclear.",
          "skills": [
            "Technical writing",
            "Build systems"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "f5ebda46-c420-4558-b7d0-a26edd8ce981",
      "key": "BSDKGEN",
      "title": "Deterministic SDK publishing pipeline",
      "field": "Developer tooling",
      "summary": "Turn a public API schema into reviewable client changes and reproducible packages.",
      "context": "A fictional partner platform publishes TypeScript clients. Generator upgrades create noisy diffs, occasional runtime mismatches, and uncertainty about which schema was packaged.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "Node.js"
      ],
      "prerequisites": [
        "Create a small public API schema and two local mock server versions; use a temporary local package registry or archive files."
      ],
      "developerValue": "Practice reproducible generation, compatibility reviews, and package provenance.",
      "companyValue": "Reduce partner integration surprises with reviewable clients and recoverable releases.",
      "delivery": "Deliver the local generation and packaging workflow with a compatibility report; publish nothing externally.",
      "phases": [
        {
          "id": "contract",
          "title": "Pin inputs",
          "goal": "Specify schema and generator provenance."
        },
        {
          "id": "generate",
          "title": "Generate predictably",
          "goal": "Produce usable stable clients and visible changes."
        },
        {
          "id": "release",
          "title": "Verify packages",
          "goal": "Exercise installation, compatibility, and recovery locally."
        }
      ],
      "tickets": [
        {
          "id": "48cef14f-82f7-4b7c-8ee6-981252d26c8e",
          "key": "BSDKGEN-101",
          "title": "Record the exact inputs behind a generated client",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "A checked-in client cannot be traced to its schema revision.",
          "acceptanceCriteria": [
            "Record schema digest, generator version, and options.",
            "Keep the manifest stable across machines.",
            "Fail when a required input is missing."
          ],
          "implementationNotes": [
            "Avoid absolute paths and timestamps in generated content."
          ],
          "verification": [
            "Compare manifests from two directories.",
            "Remove the schema and verify a clear failure."
          ],
          "deliverables": [
            "Generation manifest."
          ],
          "rollout": "Introduce manifests before enforcing them; keep the previous complete client.",
          "skills": [
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "33bc9c96-18c2-499b-b065-3083d2541de9",
          "key": "BSDKGEN-102",
          "title": "Normalize schema ordering without changing semantics",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contract",
          "dependsOn": [
            "BSDKGEN-101"
          ],
          "scenario": "Reordered schema properties create hundreds of irrelevant review lines.",
          "acceptanceCriteria": [
            "Sort unordered maps deterministically.",
            "Preserve ordered examples and tuple definitions.",
            "Keep references resolvable after normalization."
          ],
          "implementationNotes": [
            "Do not remove descriptions or validation constraints."
          ],
          "verification": [
            "Compare equivalent reordered schemas.",
            "Detect a changed enum or required field."
          ],
          "deliverables": [
            "Schema normalizer."
          ],
          "rollout": "Review semantic diffs before replacing the stored schema.",
          "skills": [
            "OpenAPI",
            "Canonicalization"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "650ea7d7-627c-42ab-bf79-76976235ef3d",
          "key": "BSDKGEN-103",
          "title": "Separate transport code from generated resource methods",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "generate",
          "dependsOn": [
            "BSDKGEN-102"
          ],
          "scenario": "Regeneration overwrites the timeout behavior partners configured manually.",
          "acceptanceCriteria": [
            "Inject a stable transport interface.",
            "Regenerate resource methods without overwriting custom transport.",
            "Pass abort signals and request identifiers consistently."
          ],
          "implementationNotes": [
            "Keep credentials out of generated examples."
          ],
          "verification": [
            "Regenerate twice and compare output.",
            "Cancel a delayed mock request and verify transport cancellation."
          ],
          "deliverables": [
            "Transport boundary and generated client."
          ],
          "rollout": "Retain the existing adapter until contract tests pass.",
          "skills": [
            "Code generation",
            "HTTP"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f3477d20-0a1a-44a1-b930-533e8aef70e1",
          "key": "BSDKGEN-104",
          "title": "Represent nullable and optional fields distinctly in clients",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "generate",
          "dependsOn": [
            "BSDKGEN-103"
          ],
          "scenario": "An omitted patch field is serialized as null and clears a partner record.",
          "acceptanceCriteria": [
            "Model omitted and explicit null independently.",
            "Omit undefined values during serialization.",
            "Preserve null only where the schema allows it."
          ],
          "implementationNotes": [
            "Avoid broad type assertions that erase schema distinctions."
          ],
          "verification": [
            "Patch one field without clearing another.",
            "Reject null for a non-nullable field."
          ],
          "deliverables": [
            "Serialization correction."
          ],
          "rollout": "Release as a reviewed compatibility fix; restore the prior artifact if unrelated payloads change.",
          "skills": [
            "TypeScript",
            "Serialization"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3cc72489-0624-4f17-8ba9-0f5d2989018d",
          "key": "BSDKGEN-105",
          "title": "Generate errors that preserve safe machine-readable details",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "generate",
          "dependsOn": [
            "BSDKGEN-103"
          ],
          "scenario": "Client users currently parse human error messages to detect conflicts.",
          "acceptanceCriteria": [
            "Expose status, problem type, and safe request ID.",
            "Handle non-JSON failures without crashing the parser.",
            "Exclude authorization headers from error objects."
          ],
          "implementationNotes": [
            "Bound retained response-body bytes."
          ],
          "verification": [
            "Parse a conflict and a text gateway error.",
            "Verify oversized and secret-bearing responses stay bounded and sanitized."
          ],
          "deliverables": [
            "Typed error mapping."
          ],
          "rollout": "Keep message text compatible where practical; document structured fields.",
          "skills": [
            "Error design",
            "SDK design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5e7621d9-2d9f-45bd-8f8e-b67be8982649",
          "key": "BSDKGEN-106",
          "title": "Detect breaking schema changes before rebuilding packages",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "generate",
          "dependsOn": [
            "BSDKGEN-102"
          ],
          "scenario": "A required request property was added without a major-version discussion.",
          "acceptanceCriteria": [
            "Classify request and response changes separately.",
            "Flag removed operations and narrowed accepted values.",
            "Require an explicit reviewed explanation for allowed exceptions."
          ],
          "implementationNotes": [
            "Do not treat every additive response field as breaking."
          ],
          "verification": [
            "Detect a required-input addition.",
            "Accept a documented additive field and reject an expired exception."
          ],
          "deliverables": [
            "Compatibility diff command."
          ],
          "rollout": "Run advisory first; enforce after reviewing known baseline exceptions.",
          "skills": [
            "Compatibility",
            "API contracts"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c3bbb58d-d67e-4e1c-8150-8335516b6f87",
          "key": "BSDKGEN-107",
          "title": "Test a packaged client from a clean consumer directory",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "release",
          "dependsOn": [
            "BSDKGEN-104",
            "BSDKGEN-105"
          ],
          "scenario": "The client works in the monorepo but its published archive omits runtime files.",
          "acceptanceCriteria": [
            "Install the local archive outside the workspace.",
            "Exercise ESM imports and declared type exports.",
            "Verify the archive excludes fixtures and credentials."
          ],
          "implementationNotes": [
            "Use local archives; no public publication or real account required."
          ],
          "verification": [
            "Run a request against the mock server.",
            "Remove an exported file and detect the package failure."
          ],
          "deliverables": [
            "Clean-consumer smoke check."
          ],
          "rollout": "Gate local release candidates on archive validation.",
          "skills": [
            "Packaging",
            "Module systems"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "98ecf16d-c77e-4b54-8d17-87427bb62b9f",
          "key": "BSDKGEN-108",
          "title": "Make generated examples compile against their advertised version",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "release",
          "dependsOn": [
            "BSDKGEN-107"
          ],
          "scenario": "Documentation snippets refer to methods removed two releases ago.",
          "acceptanceCriteria": [
            "Compile examples using the packaged client.",
            "Pin examples to a release identifier.",
            "Show credential placeholders without usable secrets."
          ],
          "implementationNotes": [
            "Examples must call the local mock service only."
          ],
          "verification": [
            "Run the basic read and paginated examples.",
            "Detect a snippet using a removed method."
          ],
          "deliverables": [
            "Executable example suite."
          ],
          "rollout": "Update examples together with packages; retain versioned previous examples.",
          "skills": [
            "Documentation",
            "TypeScript"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 80
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3d0d4b21-53eb-47d2-986a-cad9952baf22",
          "key": "BSDKGEN-109",
          "title": "Design a release matrix for old servers and new clients",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "release",
          "dependsOn": [
            "BSDKGEN-106",
            "BSDKGEN-107"
          ],
          "scenario": "Partners upgrade clients and servers at different times, so latest-against-latest testing leaves a compatibility gap.",
          "acceptanceCriteria": [
            "Declare supported client/server pairs and exclusions.",
            "Run representative operations against each local server version.",
            "Document unknown behavior rather than marking untested pairs supported."
          ],
          "implementationNotes": [
            "Bound the matrix to two client and two server versions."
          ],
          "verification": [
            "Exercise a supported mixed-version pair.",
            "Expose an incompatible removed operation as an expected documented failure."
          ],
          "deliverables": [
            "Compatibility matrix and release recommendation."
          ],
          "rollout": "Promote only tested pairs; preserve previous client artifacts and migration instructions.",
          "skills": [
            "Release engineering",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5ec76d10-0d6c-4c24-9300-67a6fc8070c6",
          "key": "BSDKGEN-110",
          "title": "Rehearse replacing a defective SDK archive locally",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "release",
          "dependsOn": [
            "BSDKGEN-109"
          ],
          "scenario": "A release candidate accidentally retries non-idempotent requests, and maintainers need a recovery procedure.",
          "acceptanceCriteria": [
            "Mark the defective local version as withdrawn in the index.",
            "Publish a distinct corrected local version without rewriting archives.",
            "Verify consumers can pin the last known usable version."
          ],
          "implementationNotes": [
            "Never overwrite a versioned artifact."
          ],
          "verification": [
            "Install the corrected package and previous usable package.",
            "Ensure the withdrawn version remains identifiable for diagnosis."
          ],
          "deliverables": [
            "Local recovery rehearsal."
          ],
          "rollout": "Document withdrawal and pinning before external publication is ever considered.",
          "skills": [
            "Artifact integrity",
            "Release operations"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "19627c06-2c38-4110-8cc2-2c32afccb03c",
      "key": "BDBMIG",
      "title": "Database migration review workbench",
      "field": "Developer tooling",
      "summary": "Help application engineers inspect and rehearse schema changes before deployment.",
      "context": "A fictional subscription service has accumulated migration scripts with unclear lock risks and no consistent rehearsal output.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "SQL"
      ],
      "prerequisites": [
        "Create a disposable local database with synthetic subscriptions and a separate scratch database; author all fixtures locally."
      ],
      "developerValue": "Practice migration tooling, lock reasoning, and clear developer feedback.",
      "companyValue": "Provide reviewers with repeatable migration checks and explicit recovery limits.",
      "delivery": "Deliver a local review CLI and SQL rehearsals; do not connect to production databases.",
      "phases": [
        {
          "id": "inspect",
          "title": "Inspect changes",
          "goal": "Make proposed SQL and risk assumptions visible."
        },
        {
          "id": "rehearse",
          "title": "Rehearse locally",
          "goal": "Check application compatibility and interrupted execution."
        },
        {
          "id": "handoff",
          "title": "Prepare deployment",
          "goal": "Package evidence and recovery steps for review."
        }
      ],
      "tickets": [
        {
          "id": "8bea7c72-6b21-47f3-bfb1-fe6dd577788c",
          "key": "BDBMIG-101",
          "title": "Add a migration inventory with checksums and sequence gaps",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "inspect",
          "dependsOn": [],
          "scenario": "Two branches introduced migrations with the same sequence number.",
          "acceptanceCriteria": [
            "List migration order and file digests.",
            "Reject duplicate sequence identifiers.",
            "Report missing predecessors without executing SQL."
          ],
          "implementationNotes": [
            "Read migration files as text only."
          ],
          "verification": [
            "Inventory a valid sequence.",
            "Detect duplicate IDs and an edited historical file."
          ],
          "deliverables": [
            "Inventory command."
          ],
          "rollout": "Adopt read-only checks first; resolve history discrepancies before applying migrations.",
          "skills": [
            "CLI design",
            "SQL"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4038c11e-19bf-40ea-a135-9637ef65d13e",
          "key": "BDBMIG-102",
          "title": "Flag table rewrites and long-held locks for review",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "inspect",
          "dependsOn": [
            "BDBMIG-101"
          ],
          "scenario": "A small-looking column change can block writes on a large table.",
          "acceptanceCriteria": [
            "Identify a documented bounded set of risky SQL forms.",
            "Explain potential lock or rewrite behavior.",
            "Mark unrecognized forms as requiring manual review."
          ],
          "implementationNotes": [
            "This heuristic must not label arbitrary SQL safe."
          ],
          "verification": [
            "Flag a configured rewrite example.",
            "Leave an unsupported statement explicitly unclassified."
          ],
          "deliverables": [
            "Risk annotations and limitations."
          ],
          "rollout": "Run advisory checks; preserve manual review for unsupported SQL.",
          "skills": [
            "PostgreSQL",
            "Static analysis"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e53cb2d2-b466-4a2d-8243-2429217623ad",
          "key": "BDBMIG-103",
          "title": "Prevent migration commands from targeting unapproved databases",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "inspect",
          "dependsOn": [
            "BDBMIG-101"
          ],
          "scenario": "An engineer copied a connection string from another terminal.",
          "acceptanceCriteria": [
            "Require an explicit local target allowlist.",
            "Display sanitized target identity before rehearsal.",
            "Reject missing, remote, or ambiguous target configuration."
          ],
          "implementationNotes": [
            "Never print passwords or complete connection URLs."
          ],
          "verification": [
            "Accept the named scratch database.",
            "Reject a remote hostname and inspect sanitized errors."
          ],
          "deliverables": [
            "Target guard."
          ],
          "rollout": "Default to no execution until a local target is configured.",
          "skills": [
            "Configuration",
            "Safety boundaries"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "34fb3acb-3c0b-46e4-acac-31b821ba710a",
          "key": "BDBMIG-104",
          "title": "Capture lock waits during a synthetic concurrent workload",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "rehearse",
          "dependsOn": [
            "BDBMIG-102",
            "BDBMIG-103"
          ],
          "scenario": "Reviewers need observations of a migration while ordinary writes continue.",
          "acceptanceCriteria": [
            "Run bounded synthetic writes against the local fixture.",
            "Capture migration duration and sampled lock waits.",
            "Record dataset size and workload parameters with results."
          ],
          "implementationNotes": [
            "Set statement and lock timeouts; avoid extrapolating local results to production."
          ],
          "verification": [
            "Observe a compatible migration under writes.",
            "Force lock contention and verify timeout cleanup."
          ],
          "deliverables": [
            "Lock rehearsal report."
          ],
          "rollout": "Use reports for review; stop rehearsal on timeout and reset scratch data.",
          "skills": [
            "PostgreSQL",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d0042e0e-0875-4a9c-836a-889d3c76115d",
          "key": "BDBMIG-105",
          "title": "Test old and new application queries during expand-contract changes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "rehearse",
          "dependsOn": [
            "BDBMIG-103"
          ],
          "scenario": "An application rollback fails because the migration removed the column the previous build reads.",
          "acceptanceCriteria": [
            "Define old and new query fixtures.",
            "Run both after the expansion migration.",
            "Reject contraction while the old-query support window is open."
          ],
          "implementationNotes": [
            "Limit scope to one renamed subscription column."
          ],
          "verification": [
            "Verify dual compatibility after expansion.",
            "Demonstrate the old query failing after premature contraction."
          ],
          "deliverables": [
            "Compatibility rehearsal."
          ],
          "rollout": "Ship expansion first; delay contraction until the documented rollback window closes.",
          "skills": [
            "Schema evolution",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a2de3864-6ef3-4743-a45c-54e37af21854",
          "key": "BDBMIG-106",
          "title": "Resume a chunked backfill after a process interruption",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "rehearse",
          "dependsOn": [
            "BDBMIG-104",
            "BDBMIG-105"
          ],
          "scenario": "The backfill restarts from the beginning and repeatedly touches already-migrated subscriptions.",
          "acceptanceCriteria": [
            "Checkpoint a stable key after committed chunks.",
            "Skip completed rows without changing their meaning.",
            "Bound batch size and transaction duration."
          ],
          "implementationNotes": [
            "Make derived values deterministic and record invalid rows separately."
          ],
          "verification": [
            "Interrupt after two chunks and resume.",
            "Retry one committed chunk and verify unchanged final values."
          ],
          "deliverables": [
            "Resumable backfill command."
          ],
          "rollout": "Start with small batches; pause safely and retain checkpoints on failures.",
          "skills": [
            "Batch processing",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "59c0fd55-0506-4253-811d-bf17fbec348d",
          "key": "BDBMIG-107",
          "title": "Distinguish reversible schema changes from irreversible data loss",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "handoff",
          "dependsOn": [
            "BDBMIG-105",
            "BDBMIG-106"
          ],
          "scenario": "The deployment template says every migration can be rolled back, even when original values are discarded.",
          "acceptanceCriteria": [
            "Classify schema reversal and data recovery separately.",
            "Identify the exact point original data becomes unavailable.",
            "Compare forward repair, backup restore, and application rollback for this migration."
          ],
          "implementationNotes": [
            "Do not invent recoverability beyond captured data."
          ],
          "verification": [
            "Rehearse the selected recovery with synthetic rows.",
            "Show the unrecoverable case when no original data was retained."
          ],
          "deliverables": [
            "Recovery decision record."
          ],
          "rollout": "Block contraction until recovery assumptions and retained-data lifetime are reviewed.",
          "skills": [
            "Migration design",
            "Recovery planning"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "04497546-cbbb-4887-9c27-efaff237edf1",
          "key": "BDBMIG-108",
          "title": "Produce a bounded migration review bundle",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "BDBMIG-104",
            "BDBMIG-107"
          ],
          "scenario": "Reviewers currently receive terminal screenshots without the SQL version or workload context.",
          "acceptanceCriteria": [
            "Include SQL digests, tool version, target class, and observations.",
            "Exclude connection secrets and row contents.",
            "Fail if referenced rehearsal output is missing."
          ],
          "implementationNotes": [
            "Use structured artifacts with documented size limits."
          ],
          "verification": [
            "Build a complete bundle.",
            "Reject missing output and scan for seeded secret markers."
          ],
          "deliverables": [
            "Review bundle exporter."
          ],
          "rollout": "Attach bundles to proposed changes; rerun if any migration digest changes.",
          "skills": [
            "Developer experience",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 80
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7331fd6d-886a-486d-a958-db5d71fdd02b",
          "key": "BDBMIG-109",
          "title": "Add migration drift checks for an already-applied history",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "handoff",
          "dependsOn": [
            "BDBMIG-101",
            "BDBMIG-108"
          ],
          "scenario": "A historical migration was edited after one environment had already applied it.",
          "acceptanceCriteria": [
            "Compare stored applied digests to local files.",
            "Stop on missing or changed applied history.",
            "Allow only append-only new migrations."
          ],
          "implementationNotes": [
            "Do not silently repair the migration ledger."
          ],
          "verification": [
            "Accept appended migrations.",
            "Reject changed bytes in an applied migration."
          ],
          "deliverables": [
            "History drift guard."
          ],
          "rollout": "Fail closed on drift; document a reviewed corrective migration instead of rewriting history.",
          "skills": [
            "Integrity checks",
            "Database tooling"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "ff59af5a-79bf-4d92-a8de-193165ed35ab",
          "key": "BDBMIG-110",
          "title": "Write the handoff checklist for a paused backfill",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "handoff",
          "dependsOn": [
            "BDBMIG-106",
            "BDBMIG-109"
          ],
          "scenario": "A different engineer must resume a backfill after the original author goes offline.",
          "acceptanceCriteria": [
            "Identify the checkpoint and current migration version.",
            "Show safe status, resume, and abort commands.",
            "Describe who decides whether contraction can proceed."
          ],
          "implementationNotes": [
            "Keep operator instructions scoped to the local rehearsal."
          ],
          "verification": [
            "Resume using only the checklist.",
            "Detect a mismatched migration digest before resuming."
          ],
          "deliverables": [
            "Backfill handoff guide."
          ],
          "rollout": "Require the guide with the rehearsal bundle; retain expansion compatibility until completion.",
          "skills": [
            "Runbooks",
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "c549f895-50c8-4622-87e1-7b83d8fe6dec",
      "key": "BTEST",
      "title": "Flaky test containment and repair",
      "field": "Quality engineering",
      "summary": "Turn intermittent CI failures into reproducible defects with accountable quarantine.",
      "context": "A fictional web team reruns red builds until they pass. Shared clocks, leaked state, and unawaited work make failures hard to trust.",
      "stack": [
        "TypeScript",
        "Vitest",
        "Playwright"
      ],
      "prerequisites": [
        "Create a small local application with three deliberately flaky tests using synthetic data and local endpoints."
      ],
      "developerValue": "Practice controlled diagnosis, isolation, and test reliability measurement.",
      "companyValue": "Recover useful failure signals and reduce blind reruns without hiding product defects.",
      "delivery": "Deliver repaired tests, deterministic reproductions, and a bounded quarantine policy.",
      "phases": [
        {
          "id": "diagnose",
          "title": "Find failure causes",
          "goal": "Capture reproducible conditions and classify failures."
        },
        {
          "id": "repair",
          "title": "Remove nondeterminism",
          "goal": "Repair isolation, time, and asynchronous behavior."
        },
        {
          "id": "govern",
          "title": "Keep signals useful",
          "goal": "Make retries and quarantine visible and temporary."
        }
      ],
      "tickets": [
        {
          "id": "560aa2c9-6f0f-47fb-b121-c3d31b222eca",
          "key": "BTEST-101",
          "title": "Record first-attempt results separately from rerun results",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "diagnose",
          "dependsOn": [],
          "scenario": "A green rerun erases the original failure from the summary.",
          "acceptanceCriteria": [
            "Persist attempt number and original outcome.",
            "Link retries to the same test identity.",
            "Show initial failure counts separately from final status."
          ],
          "implementationNotes": [
            "Exclude screenshots or payloads containing real user data."
          ],
          "verification": [
            "Record fail-then-pass history.",
            "Ensure duplicate reporter delivery does not double-count attempts."
          ],
          "deliverables": [
            "Attempt-aware result report."
          ],
          "rollout": "Introduce reporting before changing retry policy; retain original raw fixture results.",
          "skills": [
            "Test reporting"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "7de25d59-3bcb-4bbb-bb7a-2c58d2f64ab1",
          "key": "BTEST-102",
          "title": "Reproduce order-dependent failures with a saved shuffle seed",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "diagnose",
          "dependsOn": [
            "BTEST-101"
          ],
          "scenario": "One test fails only after a preference-setting test runs first.",
          "acceptanceCriteria": [
            "Shuffle tests using a recorded seed.",
            "Replay the identical ordering from that seed.",
            "Emit a minimal command including environment assumptions."
          ],
          "implementationNotes": [
            "Keep the experiment inside the synthetic suite."
          ],
          "verification": [
            "Replay a known failing order.",
            "Verify a different seed and missing seed are reported accurately."
          ],
          "deliverables": [
            "Seeded order runner."
          ],
          "rollout": "Use in diagnostic jobs; preserve the normal suite order until the defect is fixed.",
          "skills": [
            "Reproducibility",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "59205b94-8040-4524-9ac1-2f38d960329f",
          "key": "BTEST-103",
          "title": "Trace leaked database rows between test cases",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "repair",
          "dependsOn": [
            "BTEST-102"
          ],
          "scenario": "An integration test reads records inserted by an earlier test and passes for the wrong reason.",
          "acceptanceCriteria": [
            "Assign isolated fixture ownership to each test.",
            "Clean only rows owned by that test.",
            "Fail when a test observes another fixture namespace."
          ],
          "implementationNotes": [
            "Do not use an unrestricted table truncation against shared databases."
          ],
          "verification": [
            "Run the tests independently and in reversed order.",
            "Inject foreign fixture rows and verify isolation."
          ],
          "deliverables": [
            "Fixture isolation repair."
          ],
          "rollout": "Adopt per-suite first; preserve failed fixture IDs for diagnosis without row contents.",
          "skills": [
            "Test isolation",
            "Databases"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1c273bc8-9d37-476e-b688-553a9fdc9c9a",
          "key": "BTEST-104",
          "title": "Replace wall-clock races with explicit clock control",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "repair",
          "dependsOn": [
            "BTEST-102"
          ],
          "scenario": "A trial-expiry test fails around UTC midnight and daylight-saving changes.",
          "acceptanceCriteria": [
            "Inject a clock into expiry calculations.",
            "Cover before, at, and after expiry boundaries.",
            "Restore real timers after each test."
          ],
          "implementationNotes": [
            "Business timestamps remain UTC; local zones are test inputs."
          ],
          "verification": [
            "Replay midnight and offset-boundary cases.",
            "Verify leaked fake timers are detected by teardown."
          ],
          "deliverables": [
            "Clock-based expiry tests."
          ],
          "rollout": "Land with the date behavior unchanged except for the documented boundary correction.",
          "skills": [
            "Time handling",
            "Unit testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "ed45deac-1146-41f7-ac90-1595f3ce8a9e",
          "key": "BTEST-105",
          "title": "Remove readiness sleeps from browser tests",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "repair",
          "dependsOn": [
            "BTEST-101"
          ],
          "scenario": "A fixed delay is either too short on CI or unnecessarily long locally.",
          "acceptanceCriteria": [
            "Wait for a specific observable ready state.",
            "Bound the wait and report the missing condition.",
            "Handle a failed request without waiting indefinitely."
          ],
          "implementationNotes": [
            "Do not increase global timeouts to mask failures."
          ],
          "verification": [
            "Run with fast and delayed local responses.",
            "Return an error and verify a useful bounded failure."
          ],
          "deliverables": [
            "Condition-based browser waits."
          ],
          "rollout": "Replace sleeps incrementally; keep traces for failures during adoption.",
          "skills": [
            "Browser testing",
            "Asynchronous behavior"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "ba3863e6-9582-42a7-b466-ab027a410bbb",
          "key": "BTEST-106",
          "title": "Find async work that escapes test teardown",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "repair",
          "dependsOn": [
            "BTEST-103",
            "BTEST-104"
          ],
          "scenario": "Background polling continues after a test completes and changes the next test's state.",
          "acceptanceCriteria": [
            "Track owned timers, subscriptions, and requests.",
            "Cancel owned work during teardown.",
            "Fail the test on unhandled late rejections."
          ],
          "implementationNotes": [
            "Do not suppress process-level rejection reporting."
          ],
          "verification": [
            "Complete a polling test with clean teardown.",
            "Inject an ignored cancellation and detect the leaked work."
          ],
          "deliverables": [
            "Async lifecycle repair."
          ],
          "rollout": "Enable leak detection for the affected suite before expanding coverage.",
          "skills": [
            "Resource lifecycle",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b75f5cda-1701-4892-8a45-2d4c88cd91c0",
          "key": "BTEST-107",
          "title": "Separate product defects from environmental test failures",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "govern",
          "dependsOn": [
            "BTEST-101",
            "BTEST-106"
          ],
          "scenario": "An unavailable local dependency and an incorrect application response currently look identical.",
          "acceptanceCriteria": [
            "Define explicit failure categories with supporting observations.",
            "Keep unknown causes marked unknown.",
            "Prevent infrastructure classification from silently turning failures green."
          ],
          "implementationNotes": [
            "Classification rules must be auditable and versioned."
          ],
          "verification": [
            "Classify a refused connection and an assertion mismatch.",
            "Verify ambiguous evidence remains unclassified."
          ],
          "deliverables": [
            "Failure triage rules."
          ],
          "rollout": "Use categories for routing; retain the underlying failed status.",
          "skills": [
            "Failure analysis",
            "Quality engineering"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "10459380-09d6-4b1a-9249-50a8d182ce89",
          "key": "BTEST-108",
          "title": "Add expiring quarantine entries with accountable owners",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "govern",
          "dependsOn": [
            "BTEST-107"
          ],
          "scenario": "Quarantined tests have accumulated without owners or a return date.",
          "acceptanceCriteria": [
            "Require owner, reason, linked reproduction, and expiry.",
            "Continue executing quarantined tests in a visible lane.",
            "Fail policy checks on expired or unmatched entries."
          ],
          "implementationNotes": [
            "Quarantine cannot remove coverage silently."
          ],
          "verification": [
            "Accept a complete short-lived entry.",
            "Reject expired, wildcard-only, and ownerless entries."
          ],
          "deliverables": [
            "Quarantine policy validator."
          ],
          "rollout": "Start with a reviewed inventory; restore tests automatically only after policy conditions are met.",
          "skills": [
            "CI governance",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "531cb644-5af2-4314-a707-b9baf8b17823",
          "key": "BTEST-109",
          "title": "Evaluate flake repairs with controlled repeated runs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "govern",
          "dependsOn": [
            "BTEST-103",
            "BTEST-104",
            "BTEST-105",
            "BTEST-106"
          ],
          "scenario": "Twenty green reruns are being presented as proof that a defect is gone.",
          "acceptanceCriteria": [
            "Declare seeds, repetitions, environment, and remaining uncertainty.",
            "Compare repaired and deliberately unfixed cases under matching conditions.",
            "Report first-attempt failures and confidence limits without universal reliability claims."
          ],
          "implementationNotes": [
            "Keep the run budget bounded and retain failed seeds."
          ],
          "verification": [
            "Recover the injected failure in the unfixed variant.",
            "Verify repaired runs and explicitly report any inconclusive result."
          ],
          "deliverables": [
            "Repair evaluation report."
          ],
          "rollout": "Remove quarantine only with the reproduction fixed and policy review complete.",
          "skills": [
            "Experimental design",
            "Reliability analysis"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "018d5f42-75e6-42ff-a200-f95d2037b07e",
          "key": "BTEST-110",
          "title": "Add a contributor guide for a trustworthy regression test",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "govern",
          "dependsOn": [
            "BTEST-108",
            "BTEST-109"
          ],
          "scenario": "New contributors copy retry-heavy tests and perpetuate the same failure patterns.",
          "acceptanceCriteria": [
            "Show one deterministic fixture, clock, and cleanup example.",
            "State when a rerun is diagnostic rather than acceptance.",
            "Document how to submit a reproducible failure."
          ],
          "implementationNotes": [
            "Use actual repaired examples from this project."
          ],
          "verification": [
            "Follow the guide to add a passing boundary test.",
            "Check that an intentionally leaked resource fails review checks."
          ],
          "deliverables": [
            "Contributor testing guide."
          ],
          "rollout": "Link the guide from quarantine failures and the test command.",
          "skills": [
            "Technical writing",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "c893cb7f-50c0-4eda-a668-7f9183b4a846",
      "key": "BCONTRACT",
      "title": "Consumer contract compatibility lab",
      "field": "Quality engineering",
      "summary": "Check independent client expectations against evolving provider behavior.",
      "context": "A fictional fulfillment API serves a web checkout and warehouse adapter. Provider tests pass while consumers fail on subtle response and error changes.",
      "stack": [
        "TypeScript",
        "HTTP",
        "JSON Schema"
      ],
      "prerequisites": [
        "Author two small local consumers and one mock provider with versioned synthetic responses."
      ],
      "developerValue": "Practice executable contracts, meaningful negative tests, and compatibility triage.",
      "companyValue": "Expose integration regressions before deployment without requiring every system to run together.",
      "delivery": "Deliver versioned public contract checks and a local compatibility report.",
      "phases": [
        {
          "id": "capture",
          "title": "Capture expectations",
          "goal": "Identify consumer behavior that forms a real contract."
        },
        {
          "id": "verify",
          "title": "Verify boundaries",
          "goal": "Exercise provider changes and error semantics."
        },
        {
          "id": "adopt",
          "title": "Manage evolution",
          "goal": "Make compatibility decisions and exceptions reviewable."
        }
      ],
      "tickets": [
        {
          "id": "0e278a74-f4e9-4569-bd90-775c9b53f32d",
          "key": "BCONTRACT-101",
          "title": "Inventory the fields each fulfillment consumer actually reads",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "capture",
          "dependsOn": [],
          "scenario": "The existing contract copies entire sample responses, making harmless changes fail.",
          "acceptanceCriteria": [
            "List fields and semantics used by each consumer.",
            "Distinguish optional fields from required decisions.",
            "Identify one response field neither consumer needs."
          ],
          "implementationNotes": [
            "Use synthetic consumers rather than production traffic."
          ],
          "verification": [
            "Trace checkout and warehouse reads.",
            "Remove an unused field without changing the consumer outcome."
          ],
          "deliverables": [
            "Consumer expectation inventory."
          ],
          "rollout": "Review scope before creating strict assertions.",
          "skills": [
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1a4fa176-6a3d-42ef-8a37-e44564ca85b6",
          "key": "BCONTRACT-102",
          "title": "Create isolated provider states for contract examples",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "capture",
          "dependsOn": [
            "BCONTRACT-101"
          ],
          "scenario": "Contracts depend on whichever orders happen to exist in a shared test database.",
          "acceptanceCriteria": [
            "Create named states with deterministic synthetic identities.",
            "Reset each state independently.",
            "Reject unrecognized state names instead of selecting a default."
          ],
          "implementationNotes": [
            "State setup is accessible only inside the local harness."
          ],
          "verification": [
            "Run states in either order.",
            "Request an unknown state and verify no default data leaks."
          ],
          "deliverables": [
            "Provider-state fixture harness."
          ],
          "rollout": "Use the isolated harness for new contracts; retire shared mutable fixtures.",
          "skills": [
            "Fixtures",
            "Test isolation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c575e385-f8f5-4f25-9e4f-562f476616ed",
          "key": "BCONTRACT-103",
          "title": "Protect decimal quantities from implicit numeric coercion",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "verify",
          "dependsOn": [
            "BCONTRACT-102"
          ],
          "scenario": "The warehouse adapter rounds fractional unit quantities after a provider changes strings to numbers.",
          "acceptanceCriteria": [
            "Specify quantity representation and allowed scale.",
            "Reject excess precision and non-finite values.",
            "Verify consumer arithmetic preserves the declared quantity."
          ],
          "implementationNotes": [
            "Use exact decimal arithmetic or integer units."
          ],
          "verification": [
            "Process a supported fractional quantity.",
            "Reject scientific-notation and overprecision examples where unsupported."
          ],
          "deliverables": [
            "Quantity contract regression."
          ],
          "rollout": "Treat representation changes as reviewed compatibility changes.",
          "skills": [
            "Data contracts",
            "Numeric correctness"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "41f1bd6d-e324-4e47-b494-2392cde220d3",
          "key": "BCONTRACT-104",
          "title": "Verify unknown enum values do not crash old clients",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "verify",
          "dependsOn": [
            "BCONTRACT-102"
          ],
          "scenario": "A new fulfillment status reaches a client compiled against the previous enum.",
          "acceptanceCriteria": [
            "Define unknown-status behavior for each consumer.",
            "Preserve the raw value for safe diagnostics.",
            "Avoid treating unknown as delivered or cancelled."
          ],
          "implementationNotes": [
            "Unknown states must not trigger irreversible actions."
          ],
          "verification": [
            "Handle every documented status.",
            "Feed a future status and verify conservative behavior."
          ],
          "deliverables": [
            "Forward-compatible enum checks."
          ],
          "rollout": "Deploy tolerant readers before adding new provider values.",
          "skills": [
            "Compatibility",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "51096f2c-ae27-49bb-b133-03ac4f86ef24",
          "key": "BCONTRACT-105",
          "title": "Test authorization before provider-state response lookup",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "verify",
          "dependsOn": [
            "BCONTRACT-102"
          ],
          "scenario": "A contract fixture returns an order by ID even when the caller belongs to another merchant.",
          "acceptanceCriteria": [
            "Scope reads by authenticated merchant at the repository boundary.",
            "Use non-enumerating denial semantics.",
            "Keep privileged fixture setup unavailable to consumers."
          ],
          "implementationNotes": [
            "Contract success must not bypass authorization."
          ],
          "verification": [
            "Read an owned order.",
            "Request another merchant's order and compare safe denial behavior."
          ],
          "deliverables": [
            "Cross-merchant contract cases."
          ],
          "rollout": "Block compatibility approval when tenant denial regresses.",
          "skills": [
            "Authorization",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "9de2c1c8-5f2d-4ebb-aca7-8087d9a6fec5",
          "key": "BCONTRACT-106",
          "title": "Cover retry semantics for conflicts and transient failures",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "verify",
          "dependsOn": [
            "BCONTRACT-103",
            "BCONTRACT-105"
          ],
          "scenario": "Both clients currently retry every failed write, including conflicting requests.",
          "acceptanceCriteria": [
            "Distinguish conflict, validation, and transient errors.",
            "Specify which writes are safely retryable.",
            "Preserve request identity across allowed retries."
          ],
          "implementationNotes": [
            "Use a deterministic mock clock and bounded retry count."
          ],
          "verification": [
            "Recover from one transient error.",
            "Verify validation and conflicting idempotency reuse are not retried."
          ],
          "deliverables": [
            "Error and retry contract suite."
          ],
          "rollout": "Adopt new error handling with the provider behavior unchanged.",
          "skills": [
            "HTTP semantics",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0b92097b-5d43-4c1b-b2fc-f9a6b15d3e69",
          "key": "BCONTRACT-107",
          "title": "Detect undocumented response changes with focused mutation checks",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "verify",
          "dependsOn": [
            "BCONTRACT-103",
            "BCONTRACT-104",
            "BCONTRACT-106"
          ],
          "scenario": "A passing contract may only prove the mock matched itself.",
          "acceptanceCriteria": [
            "Mutate one required field, status, or header per case.",
            "Show each relevant mutation makes a consumer expectation fail.",
            "Record intentionally tolerated mutations separately."
          ],
          "implementationNotes": [
            "Mutations target public contract behavior only."
          ],
          "verification": [
            "Catch a missing quantity and wrong conflict status.",
            "Tolerate an unrelated additive response property."
          ],
          "deliverables": [
            "Contract sensitivity report."
          ],
          "rollout": "Review surviving mutations before trusting the contract gate.",
          "skills": [
            "Mutation testing",
            "Test design"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8b61cc3d-62c7-4798-9e93-7dcbaecf14be",
          "key": "BCONTRACT-108",
          "title": "Design a compatibility gate that handles missing consumers",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "adopt",
          "dependsOn": [
            "BCONTRACT-107"
          ],
          "scenario": "A new provider build is marked compatible because one consumer stopped submitting its contract.",
          "acceptanceCriteria": [
            "Require an explicit supported-consumer inventory.",
            "Distinguish failed, missing, stale, and passed verification.",
            "Define a reviewed exception with owner and expiry."
          ],
          "implementationNotes": [
            "Absence of results cannot mean compatibility."
          ],
          "verification": [
            "Pass with all supported consumers checked.",
            "Remove or stale one contract and block the gate."
          ],
          "deliverables": [
            "Compatibility gate decision record."
          ],
          "rollout": "Start as advisory; enforce once inventory ownership is established.",
          "skills": [
            "Release governance",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5a35c8aa-6c98-4388-a6b8-e6b9a5dd9c65",
          "key": "BCONTRACT-109",
          "title": "Generate a human-readable contract failure explanation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "adopt",
          "dependsOn": [
            "BCONTRACT-108"
          ],
          "scenario": "Engineers see a JSON diff but cannot tell which consumer behavior changed.",
          "acceptanceCriteria": [
            "Name the consumer and contract revision.",
            "Show the relevant expected and observed public fields.",
            "Exclude credentials and unrelated payload content."
          ],
          "implementationNotes": [
            "Bound output and redact synthetic secret markers."
          ],
          "verification": [
            "Explain a changed error status.",
            "Verify oversized payloads and authorization headers are omitted."
          ],
          "deliverables": [
            "Failure explanation formatter."
          ],
          "rollout": "Attach explanations to existing failed checks without altering outcomes.",
          "skills": [
            "Developer experience",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "dc2b44f2-392f-4124-923d-d0a220c6d4d2",
          "key": "BCONTRACT-110",
          "title": "Rehearse retiring an unused consumer contract",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "adopt",
          "dependsOn": [
            "BCONTRACT-109"
          ],
          "scenario": "An abandoned warehouse client keeps blocking harmless provider changes.",
          "acceptanceCriteria": [
            "Record owner confirmation and supported-version cutoff.",
            "Preserve the retired contract for history.",
            "Remove it from required checks only after the cutoff."
          ],
          "implementationNotes": [
            "Do not delete active consumer coverage based solely on low test activity."
          ],
          "verification": [
            "Retire a synthetic obsolete consumer.",
            "Verify an active consumer remains required."
          ],
          "deliverables": [
            "Contract retirement procedure."
          ],
          "rollout": "Keep the last compatibility report available for rollback investigation.",
          "skills": [
            "Lifecycle management",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "44e40751-208d-4c15-badf-8883cb027b99",
      "key": "BRELEASE",
      "title": "Risk-based release acceptance",
      "field": "Quality engineering",
      "summary": "Build a focused release gate for a checkout change with explicit coverage gaps.",
      "context": "A fictional retailer is changing delivery options. Its regression suite is large, but no one can explain whether inventory, totals, or recovery behavior is covered.",
      "stack": [
        "TypeScript",
        "Playwright",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Build a minimal local checkout fixture with synthetic prices, inventory, and a mock delivery provider."
      ],
      "developerValue": "Practice risk analysis, exploratory testing, and evidence-based release decisions.",
      "companyValue": "Provide a reviewable release assessment tied to customer-impacting invariants.",
      "delivery": "Deliver the acceptance suite, exploratory notes, and a local release rehearsal; no live transactions.",
      "phases": [
        {
          "id": "scope",
          "title": "Scope release risk",
          "goal": "Translate the change into observable business invariants."
        },
        {
          "id": "exercise",
          "title": "Exercise critical paths",
          "goal": "Test changed behavior and failure recovery."
        },
        {
          "id": "decide",
          "title": "Prepare release review",
          "goal": "Report uncertainty and make rollback conditions explicit."
        }
      ],
      "tickets": [
        {
          "id": "3e2cc852-35ea-4004-a772-5160f325c167",
          "key": "BRELEASE-101",
          "title": "Map delivery-option changes to checkout invariants",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "scope",
          "dependsOn": [],
          "scenario": "The release checklist says 'test checkout' without defining what must remain true.",
          "acceptanceCriteria": [
            "List total, inventory, address, and order-state invariants.",
            "Rank scenarios by impact and change exposure.",
            "Identify dependencies the local fixture cannot represent."
          ],
          "implementationNotes": [
            "Keep priorities explainable without a composite quality score."
          ],
          "verification": [
            "Trace one delivery change to affected invariants.",
            "Show an unrelated account setting outside this release scope."
          ],
          "deliverables": [
            "Release risk map."
          ],
          "rollout": "Review the map before selecting tests; retain explicit uncovered risks.",
          "skills": [
            "Risk analysis"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "df9f820c-0a99-4022-aa62-7e85148b168c",
          "key": "BRELEASE-102",
          "title": "Create boundary partitions for delivery eligibility",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "scope",
          "dependsOn": [
            "BRELEASE-101"
          ],
          "scenario": "Only ordinary postal codes are tested, while minimum basket size and service boundaries determine eligibility.",
          "acceptanceCriteria": [
            "Partition valid, excluded, and malformed destinations.",
            "Cover basket thresholds below, at, and above the boundary.",
            "State the expected reason when no option is eligible."
          ],
          "implementationNotes": [
            "Use fictional destinations and rates."
          ],
          "verification": [
            "Exercise representative values from every partition.",
            "Reject malformed input without calling the mock provider."
          ],
          "deliverables": [
            "Eligibility case table."
          ],
          "rollout": "Version the case table with the delivery rules.",
          "skills": [
            "Boundary testing",
            "Test design"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "fce92030-7ebd-4443-9ab6-f8252c76dd61",
          "key": "BRELEASE-103",
          "title": "Verify totals remain stable across delivery-option switching",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "exercise",
          "dependsOn": [
            "BRELEASE-102"
          ],
          "scenario": "Changing options twice sometimes charges the first option while displaying the second.",
          "acceptanceCriteria": [
            "Use the selected option consistently in displayed and submitted totals.",
            "Invalidate stale quotes when inputs change.",
            "Prevent submission while the current quote is unresolved."
          ],
          "implementationNotes": [
            "Represent amounts in exact minor units."
          ],
          "verification": [
            "Switch options rapidly and verify the final total.",
            "Resolve an old quote late and confirm it cannot overwrite selection."
          ],
          "deliverables": [
            "Quote-race regression."
          ],
          "rollout": "Ship with the corrected quote binding; revert the option feature if totals diverge.",
          "skills": [
            "Concurrency testing",
            "Numeric correctness"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "99bcb76f-a4c9-4888-8f09-2dc562e89af8",
          "key": "BRELEASE-104",
          "title": "Test inventory reservation when checkout is abandoned",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "exercise",
          "dependsOn": [
            "BRELEASE-101"
          ],
          "scenario": "Reservations survive failed checkout and make available stock look sold out.",
          "acceptanceCriteria": [
            "Expire abandoned reservations by the declared deadline.",
            "Preserve completed-order reservations.",
            "Make repeated expiry processing idempotent."
          ],
          "implementationNotes": [
            "Control time and use only synthetic inventory."
          ],
          "verification": [
            "Expire an abandoned reservation.",
            "Race completion with expiry and verify the chosen invariant."
          ],
          "deliverables": [
            "Reservation lifecycle tests."
          ],
          "rollout": "Keep expiry processing observable; pause the changed flow if stock reconciliation fails.",
          "skills": [
            "State transitions",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0b280dec-973e-4001-8dd2-19f8693b0847",
          "key": "BRELEASE-105",
          "title": "Check assistive-technology behavior for delivery errors",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "exercise",
          "dependsOn": [
            "BRELEASE-102"
          ],
          "scenario": "Eligibility failures appear visually below the form but keyboard users receive no useful indication.",
          "acceptanceCriteria": [
            "Associate errors with the relevant inputs.",
            "Move or announce focus consistently after failed submission.",
            "Preserve entered values for correction."
          ],
          "implementationNotes": [
            "Use semantic HTML and owned accessible components."
          ],
          "verification": [
            "Complete the flow using a keyboard.",
            "Trigger multiple errors and verify readable order and no focus trap."
          ],
          "deliverables": [
            "Accessibility acceptance notes."
          ],
          "rollout": "Include these checks in the release smoke path; revert inaccessible validation changes.",
          "skills": [
            "Accessibility",
            "Exploratory testing"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fa983c57-9f9f-4e5c-8a7a-eeeed15eb061",
          "key": "BRELEASE-106",
          "title": "Exercise partial provider failure without duplicating orders",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "exercise",
          "dependsOn": [
            "BRELEASE-103",
            "BRELEASE-104"
          ],
          "scenario": "The delivery provider accepts a booking but the checkout request times out.",
          "acceptanceCriteria": [
            "Represent booking outcome as pending when confirmation is unknown.",
            "Retry using the same operation identity.",
            "Prevent a second order from the same confirmed submission."
          ],
          "implementationNotes": [
            "Use a scripted provider double; send no external bookings."
          ],
          "verification": [
            "Recover a timed-out accepted booking.",
            "Replay duplicate callbacks and verify one final order."
          ],
          "deliverables": [
            "Partial-failure acceptance suite."
          ],
          "rollout": "Release behind a limited local cohort switch; stop new bookings if reconciliation is unhealthy.",
          "skills": [
            "Failure testing",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ab1ad063-7535-43b0-9983-571468871f06",
          "key": "BRELEASE-107",
          "title": "Run a structured exploratory session on edited addresses",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "exercise",
          "dependsOn": [
            "BRELEASE-105",
            "BRELEASE-106"
          ],
          "scenario": "Automated cases miss interactions between edited addresses, browser back navigation, and refreshed quotes.",
          "acceptanceCriteria": [
            "Define a charter and a fixed session duration.",
            "Record observations, reproduction steps, and unresolved questions.",
            "Turn a discovered stable regression into one focused test."
          ],
          "implementationNotes": [
            "Do not claim absence of defects from a time-boxed session."
          ],
          "verification": [
            "Explore address edits during pending quotes.",
            "Verify an interrupted session leaves useful reproducible notes."
          ],
          "deliverables": [
            "Exploratory session report."
          ],
          "rollout": "Use findings to update release risk; keep unknown behavior visible.",
          "skills": [
            "Exploratory testing"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c0f2d49c-0714-4ac0-9189-65fb2564dc9e",
          "key": "BRELEASE-108",
          "title": "Assess a reduced regression suite against explicit omission risk",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "decide",
          "dependsOn": [
            "BRELEASE-101",
            "BRELEASE-107"
          ],
          "scenario": "The team has thirty minutes for the release gate and cannot run every browser combination.",
          "acceptanceCriteria": [
            "Select checks using the documented change and impact map.",
            "Compare runtime cost against omitted risk.",
            "Identify conditions that require the broader suite before release."
          ],
          "implementationNotes": [
            "Declare device and browser coverage limits without inferring untested support."
          ],
          "verification": [
            "Show coverage for every critical invariant.",
            "Introduce a high-impact uncovered path and force broader verification."
          ],
          "deliverables": [
            "Release gate selection record."
          ],
          "rollout": "Use the reduced gate only within its declared scope; retain a broader fallback.",
          "skills": [
            "Quality strategy",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "accb8e82-422e-4ca3-a470-feefc237433b",
          "key": "BRELEASE-109",
          "title": "Create a release evidence index with reproducible commands",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "decide",
          "dependsOn": [
            "BRELEASE-108"
          ],
          "scenario": "Reviewers cannot distinguish current results from screenshots copied from an earlier build.",
          "acceptanceCriteria": [
            "Bind results to fixture and application revisions.",
            "Link each risk to a check or explicit gap.",
            "Include exact local commands and outcomes."
          ],
          "implementationNotes": [
            "Results are practice artifacts, not ownership claims."
          ],
          "verification": [
            "Reproduce one indexed result.",
            "Detect a result whose revision differs from the release candidate."
          ],
          "deliverables": [
            "Release evidence index."
          ],
          "rollout": "Regenerate the index after candidate changes; keep previous reports append-only.",
          "skills": [
            "Provenance",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 80
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "08a18d4e-a7e2-4f88-b815-3304cfe38e03",
          "key": "BRELEASE-110",
          "title": "Rehearse rollback when delivery quotes become inconsistent",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "decide",
          "dependsOn": [
            "BRELEASE-106",
            "BRELEASE-109"
          ],
          "scenario": "The rollback plan restores code but says nothing about orders already using the new delivery model.",
          "acceptanceCriteria": [
            "Define a measurable stop condition for quote inconsistency.",
            "Preserve completed orders and reconcile pending bookings.",
            "Verify the old application can read retained order records."
          ],
          "implementationNotes": [
            "Do not delete accepted transactions to simplify recovery."
          ],
          "verification": [
            "Roll back after a synthetic completed and pending order.",
            "Verify unsupported records trigger a reviewed repair path."
          ],
          "deliverables": [
            "Rollback rehearsal and data compatibility report."
          ],
          "rollout": "Gate release on the rehearsal; prefer disabling new bookings while reconciling pending work.",
          "skills": [
            "Release recovery",
            "Data compatibility"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 40
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "e42dbb82-ade1-4b1e-8443-5429a93229b3",
      "key": "BRAG",
      "title": "Grounded support-document assistant",
      "field": "Applied AI",
      "summary": "Build a retrieval assistant whose answers respect source versions, access, and uncertainty.",
      "context": "A fictional internal support team needs answers from product guides. Some guides are outdated or restricted, and fluent unsupported answers would create operational mistakes.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "AiEvaluationProvider"
      ],
      "prerequisites": [
        "Author a synthetic document collection with two tenants, conflicting versions, and a deterministic model double; no model account required."
      ],
      "developerValue": "Practice retrieval boundaries, citation validation, and deterministic evaluation.",
      "companyValue": "Create a reviewable assistant prototype with clear refusal, cost, and freshness behavior.",
      "delivery": "Deliver a local assistant using provider interfaces and scripted outputs; live model quality remains unmeasured.",
      "phases": [
        {
          "id": "sources",
          "title": "Control sources",
          "goal": "Version documents and enforce retrieval scope."
        },
        {
          "id": "answers",
          "title": "Constrain answers",
          "goal": "Validate citations, contradictions, and provider failures."
        },
        {
          "id": "evaluate",
          "title": "Evaluate limits",
          "goal": "Measure scoped behavior without overstating model quality."
        }
      ],
      "tickets": [
        {
          "id": "eda85d88-070e-4d1a-9db0-52f4cdff1baa",
          "key": "BRAG-101",
          "title": "Define versioned source records for the support collection",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "sources",
          "dependsOn": [],
          "scenario": "Two guides share a title but describe different product releases.",
          "acceptanceCriteria": [
            "Assign immutable source-version identities.",
            "Record product version, scope, and supersession separately.",
            "Preserve old content when a revision is added."
          ],
          "implementationNotes": [
            "Use synthetic document IDs, not fabricated Evidence IDs."
          ],
          "verification": [
            "Retrieve both historical versions explicitly.",
            "Reject an attempt to overwrite a sealed source version."
          ],
          "deliverables": [
            "Source metadata schema."
          ],
          "rollout": "Import a small synthetic collection first; append corrections instead of editing history.",
          "skills": [
            "Data modeling"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "b30c1a82-7a6b-4a89-af3e-b133833fe455",
          "key": "BRAG-102",
          "title": "Apply tenant and document grants before retrieval ranking",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "sources",
          "dependsOn": [
            "BRAG-101"
          ],
          "scenario": "A highly relevant private guide appears in another tenant's search results.",
          "acceptanceCriteria": [
            "Scope candidate sources before scoring.",
            "Recheck grants before returning retrieved text.",
            "Ensure denied sources do not influence snippets or counts."
          ],
          "implementationNotes": [
            "Authorization belongs in the retrieval service boundary."
          ],
          "verification": [
            "Retrieve an authorized guide.",
            "Query an identical restricted guide from another tenant and verify no disclosure."
          ],
          "deliverables": [
            "Scoped retriever."
          ],
          "rollout": "Fail closed on unknown grants; disable assistant responses if retrieval authorization fails.",
          "skills": [
            "Authorization",
            "Retrieval"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9edd1497-7608-4e4f-a532-7ccdbe20dd6f",
          "key": "BRAG-103",
          "title": "Preserve source offsets when splitting documentation",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "sources",
          "dependsOn": [
            "BRAG-101"
          ],
          "scenario": "Answer citations point to chunks that cannot be located in the original guide.",
          "acceptanceCriteria": [
            "Retain source version and character ranges for each chunk.",
            "Keep headings with their relevant text within configured limits.",
            "Reject chunks whose ranges exceed the source."
          ],
          "implementationNotes": [
            "Choose deterministic splitting; do not fabricate missing text."
          ],
          "verification": [
            "Reconstruct cited text from saved offsets.",
            "Detect altered source content and invalid ranges."
          ],
          "deliverables": [
            "Chunking pipeline."
          ],
          "rollout": "Rebuild indexes under a new version; retain the previous complete index for recovery.",
          "skills": [
            "Text processing",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ea322a0a-6f46-42fd-94b6-10590661a5b1",
          "key": "BRAG-104",
          "title": "Require structured answer output with verifiable citations",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "answers",
          "dependsOn": [
            "BRAG-102",
            "BRAG-103"
          ],
          "scenario": "The model double returns a plausible answer with a nonexistent citation.",
          "acceptanceCriteria": [
            "Validate the output schema and byte limit.",
            "Resolve every citation against authorized retrieved source versions.",
            "Reject unsupported citation identities rather than repairing them silently."
          ],
          "implementationNotes": [
            "Access model behavior only through AiEvaluationProvider."
          ],
          "verification": [
            "Accept a supported answer with valid ranges.",
            "Reject malformed output, nonexistent sources, and cross-tenant citations."
          ],
          "deliverables": [
            "Answer validator."
          ],
          "rollout": "Keep invalid responses in a safe unavailable state; retain only sanitized failure metadata.",
          "skills": [
            "Schema validation",
            "Grounding"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "10b8a2cc-0242-4370-a8d5-b7def4fc406b",
          "key": "BRAG-105",
          "title": "Expose conflicting guide versions instead of choosing silently",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "answers",
          "dependsOn": [
            "BRAG-104"
          ],
          "scenario": "Two authorized sources disagree about the retention setting and neither is marked superseded.",
          "acceptanceCriteria": [
            "Represent the contradiction with both source references.",
            "Avoid presenting either value as settled.",
            "Ask for product-version context or return an explicit unresolved answer."
          ],
          "implementationNotes": [
            "Do not infer authority from retrieval score alone."
          ],
          "verification": [
            "Resolve a clearly superseded guide correctly.",
            "Keep equally current contradictory guides visibly unresolved."
          ],
          "deliverables": [
            "Contradiction response behavior."
          ],
          "rollout": "Enable with conflict fixtures first; route unresolved advice to a support review workflow.",
          "skills": [
            "Uncertainty handling",
            "Information retrieval"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b25784ec-75ba-4415-9257-cbd38089dfc6",
          "key": "BRAG-106",
          "title": "Treat instructions inside retrieved guides as untrusted content",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "answers",
          "dependsOn": [
            "BRAG-104"
          ],
          "scenario": "A guide includes text telling the assistant to reveal other documents.",
          "acceptanceCriteria": [
            "Keep retrieved text outside system instruction authority.",
            "Disallow tool calls or new retrieval scopes from document text.",
            "Reject answers citing content outside the authorized retrieval set."
          ],
          "implementationNotes": [
            "Use bounded prompt-injection fixtures without real secrets."
          ],
          "verification": [
            "Answer a benign guide question.",
            "Inject scope-changing instructions and verify access remains unchanged."
          ],
          "deliverables": [
            "Adversarial retrieval checks."
          ],
          "rollout": "Block deployment if the boundary fails; keep source ingestion separate from execution authority.",
          "skills": [
            "Prompt injection",
            "Trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "29bb311e-c044-4a04-b23c-9bc1ae5a7223",
          "key": "BRAG-107",
          "title": "Bound assistant time and token reservations per request",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "answers",
          "dependsOn": [
            "BRAG-104"
          ],
          "scenario": "Repeated retries can exceed the budget for a single support question.",
          "acceptanceCriteria": [
            "Reserve a configured maximum budget before provider calls.",
            "Bound retries and total elapsed time.",
            "Release unused reservation after terminal completion."
          ],
          "implementationNotes": [
            "Record provider, model, schema, timeout, cost, version, and trace metadata safely."
          ],
          "verification": [
            "Complete a request within the reservation.",
            "Simulate timeout and ignored cancellation without unbounded retries."
          ],
          "deliverables": [
            "Request budget controller."
          ],
          "rollout": "Default to deterministic provider mode; fail closed when reservation cannot be obtained.",
          "skills": [
            "Cost controls",
            "Provider design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e0fa89eb-404e-4d8d-8027-085bcc7c1bbd",
          "key": "BRAG-108",
          "title": "Evaluate grounded answering separately from retrieval quality",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "evaluate",
          "dependsOn": [
            "BRAG-105",
            "BRAG-106",
            "BRAG-107"
          ],
          "scenario": "A single answer score hides whether failures came from missing documents or unsupported generation.",
          "acceptanceCriteria": [
            "Create separate retrieval and citation-validity checks.",
            "Include answerable, absent, conflicting, and denied questions.",
            "Report deterministic-double results separately from unmeasured live-model behavior."
          ],
          "implementationNotes": [
            "Use public synthetic expectations; do not embed hidden evaluator answers in product APIs."
          ],
          "verification": [
            "Detect a missing retrieval result.",
            "Detect a fluent answer unsupported by retrieved text."
          ],
          "deliverables": [
            "Evaluation report with failure categories."
          ],
          "rollout": "Require both boundaries before expanding the corpus; retain an explicit unmeasured label for live quality.",
          "skills": [
            "Evaluation design",
            "Retrieval"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6ffea113-afb8-4065-9808-e44ae141b38d",
          "key": "BRAG-109",
          "title": "Prevent stale indexes from serving revoked source access",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "evaluate",
          "dependsOn": [
            "BRAG-102",
            "BRAG-108"
          ],
          "scenario": "A document grant is revoked after its chunks have been cached.",
          "acceptanceCriteria": [
            "Recheck current access on cached retrieval results.",
            "Evict or suppress revoked entries without serving stale text.",
            "Keep cache keys scoped to tenant and index version."
          ],
          "implementationNotes": [
            "Cache entries cannot become access grants."
          ],
          "verification": [
            "Serve an unchanged authorized cache entry.",
            "Revoke access and deny the next response even before cache expiry."
          ],
          "deliverables": [
            "Revocation regression."
          ],
          "rollout": "Prioritize denial over cache availability; clear affected caches during recovery.",
          "skills": [
            "Caching",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Applied AI",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "489c40f9-432d-4991-b95a-be235644c0fd",
          "key": "BRAG-110",
          "title": "Document the assistant's supported questions and limits",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "evaluate",
          "dependsOn": [
            "BRAG-108",
            "BRAG-109"
          ],
          "scenario": "A prototype can sound ready for unrestricted customer support despite its small synthetic corpus.",
          "acceptanceCriteria": [
            "List supported corpus and product versions.",
            "Explain unavailable and conflicting-source responses.",
            "State that deterministic validation does not measure live-model answer quality."
          ],
          "implementationNotes": [
            "Avoid capability claims beyond observed local checks."
          ],
          "verification": [
            "Follow one supported question to its source.",
            "Verify unsupported questions receive the documented response."
          ],
          "deliverables": [
            "Operator and user-facing capability note."
          ],
          "rollout": "Ship the note with the prototype; revise it whenever corpus or provider behavior changes.",
          "skills": [
            "Documentation",
            "AI product design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "195595e2-6371-4c85-af47-e5c0e2c9d785",
      "key": "BEXTRACT",
      "title": "Reviewable invoice field extraction",
      "field": "Applied AI",
      "summary": "Extract structured invoice fields while preserving document provenance and correction history.",
      "context": "A fictional procurement team receives inconsistent supplier documents. It wants draft records that staff can review without treating model output as authoritative accounting data.",
      "stack": [
        "TypeScript",
        "JSON Schema",
        "AiEvaluationProvider"
      ],
      "prerequisites": [
        "Author synthetic text invoices with ambiguous dates, currencies, and line items; use a deterministic provider double."
      ],
      "developerValue": "Practice schema constraints, numerical checks, review workflows, and safe model boundaries.",
      "companyValue": "Produce an inspectable extraction prototype that can reduce manual transcription while preserving review control.",
      "delivery": "Deliver draft extraction and correction behavior; no real invoices, payment execution, or accounting advice.",
      "phases": [
        {
          "id": "contract",
          "title": "Define extraction rules",
          "goal": "Represent fields, provenance, and ambiguity explicitly."
        },
        {
          "id": "extract",
          "title": "Validate drafts",
          "goal": "Reject unsupported or inconsistent provider output."
        },
        {
          "id": "review",
          "title": "Support correction",
          "goal": "Preserve human review and evaluate bounded behavior."
        }
      ],
      "tickets": [
        {
          "id": "a1acedee-8ef1-4670-ae4b-e6269210ace2",
          "key": "BEXTRACT-101",
          "title": "Define invoice fields with explicit missing and ambiguous states",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Empty strings currently mean both absent values and extraction failures.",
          "acceptanceCriteria": [
            "Represent value, missing, and ambiguous states distinctly.",
            "Declare required fields before a draft is reviewable.",
            "Preserve the original textual date and amount references."
          ],
          "implementationNotes": [
            "Do not guess missing tax or currency values."
          ],
          "verification": [
            "Parse a complete synthetic invoice.",
            "Represent missing currency and an ambiguous date without invented values."
          ],
          "deliverables": [
            "Extraction schema."
          ],
          "rollout": "Version the schema before creating drafts; retain raw synthetic source references.",
          "skills": [
            "Schema design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "86b9e3e1-98e5-457a-a2dc-bbb29118bb52",
          "key": "BEXTRACT-102",
          "title": "Bind extraction runs to immutable document digests",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [
            "BEXTRACT-101"
          ],
          "scenario": "A corrected document is uploaded under the same filename and the old result appears current.",
          "acceptanceCriteria": [
            "Identify runs by document digest and extractor version.",
            "Preserve earlier runs when content changes.",
            "Reject a result bound to another document digest."
          ],
          "implementationNotes": [
            "Filenames are display labels, not identity."
          ],
          "verification": [
            "Replay an unchanged document deterministically.",
            "Change one byte and prevent reuse of the old result."
          ],
          "deliverables": [
            "Run identity contract."
          ],
          "rollout": "Append new runs on document changes; never rewrite accepted extraction history.",
          "skills": [
            "Provenance",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3915f650-f409-4bb5-9ff0-d5d90bb5764a",
          "key": "BEXTRACT-103",
          "title": "Validate source spans for every extracted material field",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "extract",
          "dependsOn": [
            "BEXTRACT-102"
          ],
          "scenario": "The provider returns a supplier address that appears nowhere in the document.",
          "acceptanceCriteria": [
            "Require bounded source spans for material values.",
            "Resolve spans against the exact source version.",
            "Flag transformed values with their documented normalization rule."
          ],
          "implementationNotes": [
            "Provider prose cannot substitute for source support."
          ],
          "verification": [
            "Accept a supported normalized date.",
            "Reject out-of-range spans and invented supplier values."
          ],
          "deliverables": [
            "Source-grounding validator."
          ],
          "rollout": "Keep unsupported drafts blocked for review; retain safe failure categories.",
          "skills": [
            "Grounding",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9f5a47bb-20fb-4647-ae90-38444fe0895c",
          "key": "BEXTRACT-104",
          "title": "Check line-item arithmetic using exact decimal rules",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "extract",
          "dependsOn": [
            "BEXTRACT-101",
            "BEXTRACT-103"
          ],
          "scenario": "Binary floating point produces an apparent mismatch on an otherwise consistent invoice.",
          "acceptanceCriteria": [
            "Use declared currency scale and rounding rules.",
            "Compare quantity, price, subtotal, and total consistently.",
            "Represent unresolved tax or discount differences as discrepancies."
          ],
          "implementationNotes": [
            "Never silently alter document totals to make arithmetic balance."
          ],
          "verification": [
            "Validate a rounding-boundary invoice.",
            "Flag inconsistent totals and unsupported precision."
          ],
          "deliverables": [
            "Arithmetic consistency checks."
          ],
          "rollout": "Show discrepancies to reviewers; do not promote inconsistent drafts automatically.",
          "skills": [
            "Numeric correctness",
            "Data validation"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0cac9927-190b-489b-b060-f28e5adc2b19",
          "key": "BEXTRACT-105",
          "title": "Prevent document text from overriding extraction policy",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "extract",
          "dependsOn": [
            "BEXTRACT-103"
          ],
          "scenario": "An invoice note contains instructions to mark every field verified.",
          "acceptanceCriteria": [
            "Treat document text only as extraction input.",
            "Require the same schema and grounding rules for all responses.",
            "Keep document instructions unable to change review status."
          ],
          "implementationNotes": [
            "No external tools or supplier contact is permitted from model output."
          ],
          "verification": [
            "Extract a normal note field.",
            "Inject policy-changing text and verify review remains required."
          ],
          "deliverables": [
            "Untrusted-document regression cases."
          ],
          "rollout": "Fail closed on invalid output; retain the deterministic provider as a safe development mode.",
          "skills": [
            "Prompt injection",
            "Trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "82f74393-4b44-4dfe-9a50-d08205c89def",
          "key": "BEXTRACT-106",
          "title": "Deduplicate concurrent extraction requests without mixing versions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "extract",
          "dependsOn": [
            "BEXTRACT-102",
            "BEXTRACT-104"
          ],
          "scenario": "Two upload retries consume duplicate provider budget and occasionally attach the older result to the newer run.",
          "acceptanceCriteria": [
            "Deduplicate exact document and extractor identities.",
            "Reject conflicting reuse of an operation key.",
            "Commit one terminal result and preserve failed-attempt metadata."
          ],
          "implementationNotes": [
            "Access providers through AiEvaluationProvider with bounded timeout and retries."
          ],
          "verification": [
            "Race identical requests and observe one accepted result.",
            "Change extractor version and ensure a distinct run."
          ],
          "deliverables": [
            "Extraction operation coordinator."
          ],
          "rollout": "Adopt one document type first; retry terminal failures through a new explicit operation.",
          "skills": [
            "Concurrency",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "10fc3656-32d5-46f7-8f1f-1a8ee4965dff",
          "key": "BEXTRACT-107",
          "title": "Reserve extraction cost before processing a document batch",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "extract",
          "dependsOn": [
            "BEXTRACT-106"
          ],
          "scenario": "A large upload queue can exceed the tenant's configured processing budget.",
          "acceptanceCriteria": [
            "Estimate a conservative per-document reservation.",
            "Enforce tenant and batch ceilings before dispatch.",
            "Settle actual usage and return unused reservation exactly once."
          ],
          "implementationNotes": [
            "Record model, prompt/schema version, timeout, retries, cost, and trace without document text."
          ],
          "verification": [
            "Process a batch within the ceiling.",
            "Retry settlement and verify no double charge or negative reservation."
          ],
          "deliverables": [
            "Budget accounting tests."
          ],
          "rollout": "Start with a small ceiling; pause new dispatch when accounting state is uncertain.",
          "skills": [
            "Cost controls",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bdedb84c-73c9-4317-a8b8-d66205b5b0b1",
          "key": "BEXTRACT-108",
          "title": "Preserve corrections as append-only reviewer decisions",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "review",
          "dependsOn": [
            "BEXTRACT-104",
            "BEXTRACT-106"
          ],
          "scenario": "Staff corrections overwrite the extracted values, making later disagreement impossible to investigate.",
          "acceptanceCriteria": [
            "Record original value, corrected value, reviewer, and reason.",
            "Require optimistic revision control for concurrent review.",
            "Keep source and extractor output immutable."
          ],
          "implementationNotes": [
            "Review actions must be tenant-scoped."
          ],
          "verification": [
            "Correct a draft and inspect both versions.",
            "Reject stale revisions and cross-tenant review attempts."
          ],
          "deliverables": [
            "Correction history workflow."
          ],
          "rollout": "Enable on draft records first; retain prior review state when a correction fails.",
          "skills": [
            "Auditability",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Applied AI",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "dc6f0cda-cd70-45ed-81a1-bbda47fbba4c",
          "key": "BEXTRACT-109",
          "title": "Design a field-level extraction evaluation with abstention costs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "review",
          "dependsOn": [
            "BEXTRACT-105",
            "BEXTRACT-107",
            "BEXTRACT-108"
          ],
          "scenario": "Document-level success hides whether the extractor frequently invents totals or simply leaves them for review.",
          "acceptanceCriteria": [
            "Report supported correct, incorrect, missing, and abstained fields separately.",
            "Include layout, date, currency, and injection variations.",
            "Compare manual-review volume against unsupported-field risk under declared assumptions."
          ],
          "implementationNotes": [
            "Deterministic doubles validate plumbing; live model accuracy remains unmeasured."
          ],
          "verification": [
            "Detect a fabricated total in the evaluation.",
            "Show an appropriate abstention separately from an incorrect value."
          ],
          "deliverables": [
            "Evaluation protocol and synthetic results."
          ],
          "rollout": "Expand document coverage only after reviewing failure categories and unresolved assumptions.",
          "skills": [
            "Evaluation design",
            "AI quality"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6aacf361-eb0a-4019-9186-63846c667400",
          "key": "BEXTRACT-110",
          "title": "Prepare a reviewer checklist for ambiguous supplier documents",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "review",
          "dependsOn": [
            "BEXTRACT-109"
          ],
          "scenario": "Reviewers need a consistent way to handle ambiguous dates and unsupported fields.",
          "acceptanceCriteria": [
            "Explain how to inspect source spans and arithmetic discrepancies.",
            "Show how to request correction without editing source history.",
            "Document when a draft must remain unresolved."
          ],
          "implementationNotes": [
            "Do not treat review completion as proof of invoice authenticity."
          ],
          "verification": [
            "Review one supported synthetic invoice.",
            "Leave an ambiguous supplier document unresolved with a reason."
          ],
          "deliverables": [
            "Reviewer guide."
          ],
          "rollout": "Publish alongside the prototype; revise examples when extraction policy changes.",
          "skills": [
            "Documentation",
            "Workflow design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "59651a16-82cd-4363-984c-d4fc68ebfdf3",
      "key": "BTRIAGE",
      "title": "Incident assistant with read-only tools",
      "field": "Applied AI",
      "summary": "Draft incident summaries from authorized operational records without granting remediation authority.",
      "context": "A fictional on-call team wants an assistant that joins alerts, deployment notes, and runbooks. Incomplete telemetry and hostile log content make unsupported conclusions dangerous.",
      "stack": [
        "TypeScript",
        "AiEvaluationProvider",
        "JSON Schema"
      ],
      "prerequisites": [
        "Author synthetic alerts, deployment records, and runbooks plus deterministic tool and model doubles."
      ],
      "developerValue": "Practice constrained tool use, operational uncertainty, and traceable AI outputs.",
      "companyValue": "Produce concise incident drafts that preserve source traceability and operator control.",
      "delivery": "Deliver a local read-only prototype; it must execute no remediation and contact no external service.",
      "phases": [
        {
          "id": "inputs",
          "title": "Scope incident inputs",
          "goal": "Authorize and normalize incident records."
        },
        {
          "id": "assist",
          "title": "Build draft assistance",
          "goal": "Constrain tools, sources, and unsupported conclusions."
        },
        {
          "id": "assess",
          "title": "Assess operator usefulness",
          "goal": "Evaluate bounded behavior and safe failure handling."
        }
      ],
      "tickets": [
        {
          "id": "d6b4a496-08a5-4feb-b019-87bb57a0d1d3",
          "key": "BTRIAGE-101",
          "title": "Define a common timeline record for operational events",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "inputs",
          "dependsOn": [],
          "scenario": "Alerts and deployment records disagree about timestamp formats.",
          "acceptanceCriteria": [
            "Normalize timestamps to UTC.",
            "Preserve source identity and original timestamp.",
            "Mark missing or uncertain event times."
          ],
          "implementationNotes": [
            "Do not invent ordering for ambiguous records."
          ],
          "verification": [
            "Merge valid records in stable order.",
            "Keep equal or missing timestamps visibly uncertain."
          ],
          "deliverables": [
            "Timeline schema."
          ],
          "rollout": "Import synthetic records first; retain original source records.",
          "skills": [
            "Data modeling"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9bc28ca4-667c-4a42-acec-d88eeaa8fc93",
          "key": "BTRIAGE-102",
          "title": "Limit incident retrieval to the caller's service grants",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "inputs",
          "dependsOn": [
            "BTRIAGE-101"
          ],
          "scenario": "A related-service lookup exposes another team's restricted incident notes.",
          "acceptanceCriteria": [
            "Scope every tool read by caller grants.",
            "Recheck access for referenced records.",
            "Return non-enumerating denial responses."
          ],
          "implementationNotes": [
            "Tool definitions cannot widen caller permissions."
          ],
          "verification": [
            "Read an authorized service timeline.",
            "Deny a cross-service record guessed by ID."
          ],
          "deliverables": [
            "Authorized tool boundary."
          ],
          "rollout": "Disable assistance when grant resolution fails.",
          "skills": [
            "Authorization",
            "Tool design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "85e27613-f0f6-47c8-9f6f-db3aec034f9a",
          "key": "BTRIAGE-103",
          "title": "Bound tool arguments and returned telemetry volume",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "assist",
          "dependsOn": [
            "BTRIAGE-102"
          ],
          "scenario": "A broad query attempts to retrieve days of raw logs.",
          "acceptanceCriteria": [
            "Require bounded time range and record count.",
            "Reject unknown tool names and properties.",
            "Truncate with explicit completeness metadata."
          ],
          "implementationNotes": [
            "Use aggregate synthetic records instead of secret-bearing logs."
          ],
          "verification": [
            "Retrieve a bounded incident window.",
            "Reject excessive ranges and unsupported tool arguments."
          ],
          "deliverables": [
            "Tool request validator."
          ],
          "rollout": "Start with conservative limits; report incomplete context rather than expanding silently.",
          "skills": [
            "Schema validation"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "48c3302b-6089-4fce-8639-d4fd1bbc2516",
          "key": "BTRIAGE-104",
          "title": "Keep log content from issuing new tool instructions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "assist",
          "dependsOn": [
            "BTRIAGE-103"
          ],
          "scenario": "An error message contains text requesting privileged configuration reads.",
          "acceptanceCriteria": [
            "Treat log text as untrusted data.",
            "Allow only declared read-only tools.",
            "Validate every proposed tool call independently."
          ],
          "implementationNotes": [
            "No shell, configuration writes, or remediation tools are exposed."
          ],
          "verification": [
            "Summarize a benign failure record.",
            "Inject a privileged instruction and verify no unauthorized call occurs."
          ],
          "deliverables": [
            "Adversarial tool-use checks."
          ],
          "rollout": "Block provider output on policy failure and preserve sanitized diagnostics.",
          "skills": [
            "Prompt injection"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Applied AI",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "f0575f9d-ba8d-4899-81fb-c941027140c9",
          "key": "BTRIAGE-105",
          "title": "Require source references for incident summary statements",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "assist",
          "dependsOn": [
            "BTRIAGE-101",
            "BTRIAGE-103"
          ],
          "scenario": "The generated summary invents a deployment that never happened.",
          "acceptanceCriteria": [
            "Bind factual statements to retrieved source identities.",
            "Reject nonexistent and unauthorized references.",
            "Separate observations from hypotheses."
          ],
          "implementationNotes": [
            "Use AiEvaluationProvider and schema-validated structured responses."
          ],
          "verification": [
            "Accept a source-backed timeline statement.",
            "Reject invented deployments and uncited root-cause assertions."
          ],
          "deliverables": [
            "Summary validator."
          ],
          "rollout": "Render only validated drafts; return unavailable on invalid output.",
          "skills": [
            "Grounding",
            "Schema validation"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2373fe5e-d735-4cb1-a12b-aadd5f5a83b1",
          "key": "BTRIAGE-106",
          "title": "Represent competing incident hypotheses explicitly",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "assist",
          "dependsOn": [
            "BTRIAGE-105"
          ],
          "scenario": "A latency spike follows a deployment but also overlaps a dependency outage.",
          "acceptanceCriteria": [
            "List supporting and contradicting observations per hypothesis.",
            "Avoid declaring causation from timing alone.",
            "Identify a bounded next observation for discrimination."
          ],
          "implementationNotes": [
            "Recommendations remain read-only diagnostic suggestions."
          ],
          "verification": [
            "Represent two plausible causes.",
            "Keep a hypothesis unresolved when discriminating telemetry is absent."
          ],
          "deliverables": [
            "Hypothesis draft format."
          ],
          "rollout": "Require operator review before acting on a hypothesis.",
          "skills": [
            "Incident reasoning",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3cd314df-79f9-4241-a417-4e40503cba0f",
          "key": "BTRIAGE-107",
          "title": "Cancel obsolete drafts when new incident context arrives",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "assist",
          "dependsOn": [
            "BTRIAGE-105"
          ],
          "scenario": "An older slow response overwrites the summary after a recovery event arrives.",
          "acceptanceCriteria": [
            "Bind drafts to context revision.",
            "Cancel or discard superseded work.",
            "Preserve the latest accepted timeline revision."
          ],
          "implementationNotes": [
            "Record provider/model/version, timeout, retries, cost, and trace safely."
          ],
          "verification": [
            "Complete the newest draft first.",
            "Resolve an older request late and reject its update."
          ],
          "deliverables": [
            "Revision-aware draft coordinator."
          ],
          "rollout": "Keep the last valid draft visible with its timestamp when refresh fails.",
          "skills": [
            "Concurrency",
            "Provider design"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5a958da2-eb7d-4185-8160-7ccba8c2da73",
          "key": "BTRIAGE-108",
          "title": "Prevent repeated refreshes from exhausting incident budgets",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "assess",
          "dependsOn": [
            "BTRIAGE-107"
          ],
          "scenario": "Several operators refresh the same incident and trigger duplicate model calls.",
          "acceptanceCriteria": [
            "Coalesce identical in-flight context requests.",
            "Enforce per-incident reservation and timeout.",
            "Settle usage once per provider attempt."
          ],
          "implementationNotes": [
            "Provider failure cannot trigger unbounded retry loops."
          ],
          "verification": [
            "Share one in-flight synthetic response.",
            "Exhaust the budget and return a bounded unavailable state."
          ],
          "deliverables": [
            "Incident request budget."
          ],
          "rollout": "Default to deterministic mode; pause new refreshes when accounting is uncertain.",
          "skills": [
            "Cost controls"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5d1d120e-4c45-43d8-a16a-02ec7f30a3c4",
          "key": "BTRIAGE-109",
          "title": "Evaluate summary utility without rewarding confident guesses",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "assess",
          "dependsOn": [
            "BTRIAGE-104",
            "BTRIAGE-106",
            "BTRIAGE-108"
          ],
          "scenario": "The team needs a useful assessment that does not equate fluent prose with correct incident analysis.",
          "acceptanceCriteria": [
            "Measure citation validity, omitted critical observations, and unsupported assertions separately.",
            "Include partial, contradictory, and malicious context cases.",
            "Report deterministic boundary results separately from live-model quality."
          ],
          "implementationNotes": [
            "Do not claim reduced incident duration from this local prototype."
          ],
          "verification": [
            "Detect an invented root cause.",
            "Accept a concise unresolved summary with valid diagnostic next steps."
          ],
          "deliverables": [
            "Evaluation protocol and failure report."
          ],
          "rollout": "Expand incident coverage only after reviewing unsupported-claim failures.",
          "skills": [
            "AI evaluation",
            "Incident response"
          ],
          "fieldMix": [
            {
              "field": "Applied AI",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ca9dd116-7a68-4a74-92d8-3755c87b856d",
          "key": "BTRIAGE-110",
          "title": "Write an operator handoff for stale or unavailable assistance",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "assess",
          "dependsOn": [
            "BTRIAGE-109"
          ],
          "scenario": "Operators must continue handling incidents when the assistant is down.",
          "acceptanceCriteria": [
            "Show draft age and source window.",
            "Link the original authorized records.",
            "Document the manual timeline workflow."
          ],
          "implementationNotes": [
            "The assistant is never a dependency for incident response."
          ],
          "verification": [
            "Continue from source records during provider failure.",
            "Verify stale drafts cannot appear current."
          ],
          "deliverables": [
            "Operator fallback guide."
          ],
          "rollout": "Ship the fallback with the prototype and rehearse it locally.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Applied AI",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "2f93285f-6c1b-42ea-893f-ed7e6afc7778",
      "key": "BBILL",
      "title": "Payment-provider reconciliation adapter",
      "field": "Integrations",
      "summary": "Reconcile local order state with a simulated provider under duplicate and delayed delivery.",
      "context": "A fictional software vendor changes payment providers. Its application must tolerate unknown outcomes, signed callbacks, refunds, and inconsistent settlement reports.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create a local payment-provider double and synthetic orders; use test-only signatures and execute no financial transactions."
      ],
      "developerValue": "Practice idempotent integrations, state reconciliation, and provider migration.",
      "companyValue": "Provide a reviewable adapter design that protects order consistency and recovery.",
      "delivery": "Deliver local provider contracts and reconciliation rehearsals; no live money or provider accounts.",
      "phases": [
        {
          "id": "contract",
          "title": "Define provider semantics",
          "goal": "Model identities and state transitions."
        },
        {
          "id": "connect",
          "title": "Handle asynchronous results",
          "goal": "Process callbacks and unknown outcomes safely."
        },
        {
          "id": "reconcile",
          "title": "Recover discrepancies",
          "goal": "Reconcile records and rehearse migration."
        }
      ],
      "tickets": [
        {
          "id": "91bd95c9-0297-4942-9673-fcbeae63477c",
          "key": "BBILL-101",
          "title": "Map provider payment states to explicit order transitions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Two provider status names are currently treated as equivalent even though only one confirms collection.",
          "acceptanceCriteria": [
            "List provider states and allowed transitions.",
            "Represent pending and unknown separately.",
            "Reject impossible terminal reversals."
          ],
          "implementationNotes": [
            "Keep provider status distinct from local order status."
          ],
          "verification": [
            "Map successful and pending examples.",
            "Reject an unsupported state without marking an order paid."
          ],
          "deliverables": [
            "State mapping contract."
          ],
          "rollout": "Review mapping before accepting callbacks.",
          "skills": [
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1270b2a7-898f-49ea-9704-338710dde496",
          "key": "BBILL-102",
          "title": "Bind payment creation retries to one local operation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "contract",
          "dependsOn": [
            "BBILL-101"
          ],
          "scenario": "A timeout prompts the application to create a second payment.",
          "acceptanceCriteria": [
            "Persist operation identity before dispatch.",
            "Reuse identity for identical retries.",
            "Reject conflicting payload reuse."
          ],
          "implementationNotes": [
            "Synthetic amounts use integer minor units."
          ],
          "verification": [
            "Retry a timed-out accepted request.",
            "Reuse a key with another amount and verify rejection."
          ],
          "deliverables": [
            "Idempotent payment command."
          ],
          "rollout": "Keep uncertain operations pending for reconciliation.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8bd5242d-5c0f-459d-a014-5ce8dac7b167",
          "key": "BBILL-103",
          "title": "Verify callback signatures before trusting event fields",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "connect",
          "dependsOn": [
            "BBILL-101"
          ],
          "scenario": "The adapter currently reads order IDs before validating callbacks.",
          "acceptanceCriteria": [
            "Verify raw bytes with the configured test key.",
            "Enforce timestamp tolerance and key identity.",
            "Reject malformed or unsigned bodies before processing."
          ],
          "implementationNotes": [
            "Never log signing secrets or full callback bodies."
          ],
          "verification": [
            "Accept a valid signed fixture.",
            "Reject modified bytes and an expired timestamp."
          ],
          "deliverables": [
            "Callback verification boundary."
          ],
          "rollout": "Reject unverifiable callbacks; retain safe failure counts.",
          "skills": [
            "Webhook security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Integrations",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9e44b045-4470-4f50-82a3-66aa3d7dd3f1",
          "key": "BBILL-104",
          "title": "Apply duplicate and out-of-order payment callbacks idempotently",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "connect",
          "dependsOn": [
            "BBILL-102",
            "BBILL-103"
          ],
          "scenario": "A delayed pending callback overwrites an already-confirmed payment.",
          "acceptanceCriteria": [
            "Deduplicate provider event identity.",
            "Apply only allowed state transitions.",
            "Record ignored stale events for diagnosis."
          ],
          "implementationNotes": [
            "Commit state and processed-event record atomically."
          ],
          "verification": [
            "Replay a successful callback twice.",
            "Deliver pending after confirmed and preserve confirmation."
          ],
          "deliverables": [
            "Callback transition handler."
          ],
          "rollout": "Adopt per synthetic merchant; pause on unresolved transition conflicts.",
          "skills": [
            "Transactions",
            "Event ordering"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f7d999cd-38e7-4637-a565-cec7346a2d67",
          "key": "BBILL-105",
          "title": "Reconcile unknown creation outcomes by operation identity",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "connect",
          "dependsOn": [
            "BBILL-102",
            "BBILL-104"
          ],
          "scenario": "The provider accepted creation but the application lost the response.",
          "acceptanceCriteria": [
            "Query the provider using the original operation identity.",
            "Adopt the matching remote payment once.",
            "Keep missing or mismatched results unresolved."
          ],
          "implementationNotes": [
            "Bound query retries and elapsed reconciliation time."
          ],
          "verification": [
            "Recover a matching accepted payment.",
            "Reject a remote result with different amount or currency."
          ],
          "deliverables": [
            "Unknown-outcome reconciler."
          ],
          "rollout": "Stop new attempts for unresolved operations; retry reconciliation explicitly.",
          "skills": [
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "7bcc58ca-b5bd-4a04-9952-22bd15accf25",
          "key": "BBILL-106",
          "title": "Represent partial refunds without rewriting original payment facts",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "connect",
          "dependsOn": [
            "BBILL-104"
          ],
          "scenario": "A partial refund currently changes the original collected amount.",
          "acceptanceCriteria": [
            "Append refund operations separately.",
            "Limit cumulative confirmed refunds to the collected amount.",
            "Distinguish requested, pending, and confirmed refund totals."
          ],
          "implementationNotes": [
            "Run against the local double only."
          ],
          "verification": [
            "Confirm two valid partial refunds.",
            "Race excess refunds and verify the invariant holds."
          ],
          "deliverables": [
            "Refund state model."
          ],
          "rollout": "Enable after payment reconciliation; retain failed requests for investigation.",
          "skills": [
            "Ledger modeling",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "af1713a9-0d11-4ff5-8bf4-95379c5fb315",
          "key": "BBILL-107",
          "title": "Import settlement rows with source-file provenance",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "reconcile",
          "dependsOn": [
            "BBILL-105",
            "BBILL-106"
          ],
          "scenario": "Repeated report uploads create duplicate reconciliation entries.",
          "acceptanceCriteria": [
            "Bind imports to file digest and provider report identity.",
            "Deduplicate exact rows without losing source references.",
            "Reject conflicting duplicate settlement identities."
          ],
          "implementationNotes": [
            "Use synthetic CSV and sanitize spreadsheet formula prefixes in exports."
          ],
          "verification": [
            "Import the same report twice.",
            "Detect a changed amount under an existing settlement identity."
          ],
          "deliverables": [
            "Settlement import pipeline."
          ],
          "rollout": "Stage reports before matching; preserve original synthetic report digests.",
          "skills": [
            "Data ingestion",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3bdcf04e-19e3-4dc6-883c-dabbbdf4e22a",
          "key": "BBILL-108",
          "title": "Explain settlement discrepancies without automatic repair",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "reconcile",
          "dependsOn": [
            "BBILL-107"
          ],
          "scenario": "Finance staff see only a mismatch count and cannot identify its cause.",
          "acceptanceCriteria": [
            "Classify missing, amount, currency, and timing mismatches.",
            "Link each discrepancy to local and provider identities.",
            "Keep disputed records unchanged."
          ],
          "implementationNotes": [
            "Do not infer fraud or automatically move funds."
          ],
          "verification": [
            "Explain a timing difference and an amount mismatch.",
            "Verify unknown discrepancies remain unresolved."
          ],
          "deliverables": [
            "Discrepancy report."
          ],
          "rollout": "Use reports for reviewed repair; keep reconciliation read-only by default.",
          "skills": [
            "Diagnostics",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "786f6a47-ed53-49ba-9084-48c574c69592",
          "key": "BBILL-109",
          "title": "Design a provider cutover with in-flight payment ownership",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "reconcile",
          "dependsOn": [
            "BBILL-105",
            "BBILL-108"
          ],
          "scenario": "Switching all traffic at once would send old payment lookups to the new provider.",
          "acceptanceCriteria": [
            "Pin each operation to its original provider.",
            "Define new-operation routing and rollback conditions.",
            "Rehearse callbacks and refunds crossing the cutover boundary."
          ],
          "implementationNotes": [
            "Compare adapter complexity and reconciliation burden explicitly."
          ],
          "verification": [
            "Complete an old-provider payment after cutover.",
            "Roll back new routing without reassigning existing operations."
          ],
          "deliverables": [
            "Cutover decision record and rehearsal."
          ],
          "rollout": "Change only new-operation routing; retain both adapters until old obligations finish.",
          "skills": [
            "Migration design",
            "Distributed consistency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "048d8f1b-3f1c-411d-890c-5a7241bfc64a",
          "key": "BBILL-110",
          "title": "Document a safe manual replay of a rejected callback",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "reconcile",
          "dependsOn": [
            "BBILL-109"
          ],
          "scenario": "Support needs to retry a corrected callback without bypassing verification.",
          "acceptanceCriteria": [
            "Require original event identity and verified source.",
            "Use the normal validation and idempotency path.",
            "Record replay operator and reason."
          ],
          "implementationNotes": [
            "No direct database status edits."
          ],
          "verification": [
            "Replay a previously failed valid event.",
            "Reject a replay with altered signed content."
          ],
          "deliverables": [
            "Callback replay runbook."
          ],
          "rollout": "Keep replay scoped and audited; stop on conflicting operation facts.",
          "skills": [
            "Runbooks",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "fe12ff15-5218-4692-b487-7326309121cc",
      "key": "BCRM",
      "title": "CRM contact synchronization repair",
      "field": "Integrations",
      "summary": "Keep customer records consistent across a local application and a simulated CRM.",
      "context": "A fictional account team sees overwritten edits, duplicate contacts, and stale opt-out preferences after synchronization retries.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "HTTP"
      ],
      "prerequisites": [
        "Create a local CRM double and synthetic contact records for two organizations; no real personal data or CRM credentials."
      ],
      "developerValue": "Practice sync cursors, conflict policies, privacy boundaries, and replay.",
      "companyValue": "Provide predictable customer-data synchronization with inspectable conflicts.",
      "delivery": "Deliver a local bidirectional adapter and reconciliation report.",
      "phases": [
        {
          "id": "map",
          "title": "Map authority",
          "goal": "Define identities and field ownership."
        },
        {
          "id": "sync",
          "title": "Synchronize changes",
          "goal": "Handle pagination, retries, conflicts, and deletion."
        },
        {
          "id": "operate",
          "title": "Operate safely",
          "goal": "Reconcile drift and recover interrupted imports."
        }
      ],
      "tickets": [
        {
          "id": "2df0ac0d-8624-4029-8200-a133636749c0",
          "key": "BCRM-101",
          "title": "Define contact field ownership between the app and CRM",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "map",
          "dependsOn": [],
          "scenario": "Both systems overwrite account names and communication preferences.",
          "acceptanceCriteria": [
            "Assign an authority rule per synchronized field.",
            "Separate display fields from consent fields.",
            "Define unresolved conflicts explicitly."
          ],
          "implementationNotes": [
            "Never infer marketing consent from unrelated activity."
          ],
          "verification": [
            "Resolve an app-owned field change.",
            "Keep conflicting consent records unresolved."
          ],
          "deliverables": [
            "Field ownership matrix."
          ],
          "rollout": "Review the matrix before enabling writes.",
          "skills": [
            "Data ownership"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "30d0d38d-4f5d-4ca2-96ff-ceaf0c7ecb98",
          "key": "BCRM-102",
          "title": "Separate external contact identity from email addresses",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "map",
          "dependsOn": [
            "BCRM-101"
          ],
          "scenario": "An email change creates a second contact instead of updating the original.",
          "acceptanceCriteria": [
            "Use provider and organization-scoped external identities.",
            "Allow email changes without identity replacement.",
            "Detect conflicting identity mappings."
          ],
          "implementationNotes": [
            "Email is mutable data, not a stable key."
          ],
          "verification": [
            "Update an existing contact's email.",
            "Reject an external identity mapped across organizations."
          ],
          "deliverables": [
            "Identity mapping model."
          ],
          "rollout": "Backfill synthetic mappings before synchronization.",
          "skills": [
            "Identity modeling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ef10713b-2428-4a43-b570-128fa7c0a900",
          "key": "BCRM-103",
          "title": "Checkpoint CRM pagination only after local batch commit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "BCRM-102"
          ],
          "scenario": "The cursor advances even when a page fails to persist.",
          "acceptanceCriteria": [
            "Commit page changes and cursor together.",
            "Resume from the last committed cursor.",
            "Bound page size and total import work."
          ],
          "implementationNotes": [
            "Do not use timestamps alone as a pagination tie-breaker."
          ],
          "verification": [
            "Interrupt after a committed page and resume.",
            "Fail persistence and verify the cursor remains unchanged."
          ],
          "deliverables": [
            "Transactional page importer."
          ],
          "rollout": "Start with small batches; retain checkpoints during recovery.",
          "skills": [
            "Transactions",
            "Pagination"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bf12e9ad-3239-4f74-b3c9-754703db9a52",
          "key": "BCRM-104",
          "title": "Apply contact updates with explicit conflict detection",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "sync",
          "dependsOn": [
            "BCRM-101",
            "BCRM-103"
          ],
          "scenario": "A delayed CRM event overwrites a newer local edit.",
          "acceptanceCriteria": [
            "Compare the declared version or revision.",
            "Apply field ownership rules on conflicts.",
            "Preserve unresolved values and provenance."
          ],
          "implementationNotes": [
            "Do not use arrival time as proof of freshness."
          ],
          "verification": [
            "Merge independent field edits.",
            "Detect conflicting edits to the same owned field."
          ],
          "deliverables": [
            "Conflict-aware update handler."
          ],
          "rollout": "Enable writes only after the conflict report is reviewable.",
          "skills": [
            "Concurrency",
            "Data synchronization"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "537a0fc4-8f29-43b6-9ad5-d6d9adf98bd3",
          "key": "BCRM-105",
          "title": "Propagate communication opt-outs ahead of ordinary profile updates",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "BCRM-104"
          ],
          "scenario": "An opt-out remains queued behind thousands of cosmetic profile changes.",
          "acceptanceCriteria": [
            "Prioritize restrictive preference updates.",
            "Prevent older permissive values from restoring permission.",
            "Record propagation state without exposing contact details in logs."
          ],
          "implementationNotes": [
            "Use synthetic preferences; no messages are sent."
          ],
          "verification": [
            "Propagate a new opt-out.",
            "Replay an older opt-in and preserve the restrictive state."
          ],
          "deliverables": [
            "Preference propagation checks."
          ],
          "rollout": "Pause outbound communication integration when preference state is uncertain.",
          "skills": [
            "Privacy engineering",
            "Event ordering"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b893312e-905c-4229-88c2-b56bbc475dd7",
          "key": "BCRM-106",
          "title": "Handle provider rate limits without skipping contacts",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "sync",
          "dependsOn": [
            "BCRM-103"
          ],
          "scenario": "The importer treats a rate-limited page as empty and advances.",
          "acceptanceCriteria": [
            "Respect bounded retry delays.",
            "Keep the current cursor until a successful page.",
            "Distinguish terminal authentication failure from throttling."
          ],
          "implementationNotes": [
            "Use a mock clock and fixed retry ceiling."
          ],
          "verification": [
            "Recover from one rate-limited response.",
            "Exhaust retries without advancing the cursor."
          ],
          "deliverables": [
            "Rate-limit handling."
          ],
          "rollout": "Pause the organization sync after exhaustion; resume from its saved cursor.",
          "skills": [
            "Retries",
            "HTTP"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "fac441b1-6085-4319-b69b-2f8c19ed1439",
          "key": "BCRM-107",
          "title": "Represent deleted CRM records with tombstone semantics",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "BCRM-104",
            "BCRM-105"
          ],
          "scenario": "A deleted record reappears when an old update is replayed.",
          "acceptanceCriteria": [
            "Retain deletion identity and source revision.",
            "Prevent older updates from resurrecting the record.",
            "Apply the documented retention rule to local fields."
          ],
          "implementationNotes": [
            "Deletion policy must distinguish identity metadata from contact contents."
          ],
          "verification": [
            "Apply a deletion then replay an older update.",
            "Verify an authorized new identity follows an explicit recreation path."
          ],
          "deliverables": [
            "Deletion and replay rules."
          ],
          "rollout": "Introduce tombstones before importing deletion events.",
          "skills": [
            "Data lifecycle",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3759404a-694e-4e94-8e2d-04d6e296fc5e",
          "key": "BCRM-108",
          "title": "Reconcile contact drift using bounded hashes and counts",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BCRM-106",
            "BCRM-107"
          ],
          "scenario": "Support needs to find mismatches without exporting every contact's personal data.",
          "acceptanceCriteria": [
            "Compare scoped canonical synchronized-field digests.",
            "Report missing and changed identities separately.",
            "Limit detailed inspection to authorized records."
          ],
          "implementationNotes": [
            "Do not publish raw contact values in aggregate reports."
          ],
          "verification": [
            "Identify one missing and one changed contact.",
            "Deny reconciliation across organization boundaries."
          ],
          "deliverables": [
            "Drift report."
          ],
          "rollout": "Run read-only reconciliation before repair.",
          "skills": [
            "Reconciliation",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e5af60b7-68bf-42f1-ad86-aa92debe1c13",
          "key": "BCRM-109",
          "title": "Plan a full CRM resynchronization without erasing local edits",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BCRM-104",
            "BCRM-108"
          ],
          "scenario": "A corrupted cursor requires a new import while staff continue editing customer records.",
          "acceptanceCriteria": [
            "Freeze an import boundary and preserve concurrent local revisions.",
            "Compare merge strategies and conflict workload.",
            "Rehearse resumption and cancellation without bulk replacement."
          ],
          "implementationNotes": [
            "Keep the exercise bounded to the synthetic dataset."
          ],
          "verification": [
            "Resume an interrupted full import.",
            "Edit a contact mid-import and verify conflict preservation."
          ],
          "deliverables": [
            "Resynchronization decision record."
          ],
          "rollout": "Run read-only comparison first; apply reviewed differences in bounded batches.",
          "skills": [
            "Migration design",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2853cc6a-076a-4900-a651-e6056a1e445c",
          "key": "BCRM-110",
          "title": "Create a sync support view with safe failure categories",
          "type": "STORY",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "operate",
          "dependsOn": [
            "BCRM-109"
          ],
          "scenario": "Support sees only 'sync failed' and repeatedly restarts imports.",
          "acceptanceCriteria": [
            "Show last committed cursor age and operation status.",
            "Distinguish throttling, authorization, conflict, and malformed data.",
            "Provide a scoped resume action using existing identity."
          ],
          "implementationNotes": [
            "Exclude tokens and contact contents from status output."
          ],
          "verification": [
            "Display a successful completed import.",
            "Show authorization failure without retrying indefinitely."
          ],
          "deliverables": [
            "Support status projection."
          ],
          "rollout": "Expose read-only status first; keep repairs separately authorized.",
          "skills": [
            "Operational UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ad1d2a4c-4a0a-4163-b967-e66fda0e3ab0",
      "key": "BCALENDAR",
      "title": "Calendar availability synchronization",
      "field": "Integrations",
      "summary": "Reconcile availability and event changes across a scheduling app and a local calendar provider.",
      "context": "A fictional booking service supports consultants in multiple time zones. Recurring events, revoked access, and delayed callbacks cause missed conflicts.",
      "stack": [
        "TypeScript",
        "iCalendar",
        "HTTP"
      ],
      "prerequisites": [
        "Author synthetic calendars and a local provider double with recurrence, timezone, and access-revocation cases."
      ],
      "developerValue": "Practice temporal modeling, synchronization lifecycles, and privacy-preserving projections.",
      "companyValue": "Reduce scheduling ambiguity through explicit availability contracts and recoverable synchronization.",
      "delivery": "Deliver local availability calculations and sync behavior; send no invitations or calendar writes externally.",
      "phases": [
        {
          "id": "time",
          "title": "Define temporal semantics",
          "goal": "Model instants, zones, and recurrence."
        },
        {
          "id": "sync",
          "title": "Synchronize availability",
          "goal": "Handle event updates and provider failures."
        },
        {
          "id": "release",
          "title": "Rehearse edge cases",
          "goal": "Verify privacy, cutover, and recovery."
        }
      ],
      "tickets": [
        {
          "id": "62dacf22-0cf9-45d2-9a55-afa5c7c606aa",
          "key": "BCALENDAR-101",
          "title": "Distinguish all-day events from timed calendar intervals",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "time",
          "dependsOn": [],
          "scenario": "An all-day absence becomes a twenty-four-hour UTC interval and shifts across local dates.",
          "acceptanceCriteria": [
            "Represent all-day dates separately from instants.",
            "Declare exclusive end semantics.",
            "Preserve the event's timezone context."
          ],
          "implementationNotes": [
            "Do not infer an event zone from the server timezone."
          ],
          "verification": [
            "Render a timed event and all-day absence correctly.",
            "Reject missing timezone context for ambiguous local times."
          ],
          "deliverables": [
            "Temporal data contract."
          ],
          "rollout": "Version the contract before importing calendar records.",
          "skills": [
            "Time modeling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9cb30c75-0c33-4e96-9c10-35f15f6e15f9",
          "key": "BCALENDAR-102",
          "title": "Resolve daylight-saving gaps and repeated local times",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "time",
          "dependsOn": [
            "BCALENDAR-101"
          ],
          "scenario": "A recurring appointment lands in a nonexistent local hour during a timezone transition.",
          "acceptanceCriteria": [
            "Define explicit gap and overlap policies.",
            "Keep original local time and selected offset.",
            "Return ambiguity when policy cannot resolve the occurrence."
          ],
          "implementationNotes": [
            "Use a maintained timezone database available locally."
          ],
          "verification": [
            "Exercise a spring gap and autumn repeated hour.",
            "Reject a silently guessed offset."
          ],
          "deliverables": [
            "Timezone resolution tests."
          ],
          "rollout": "Keep affected appointments unresolved until policy is applied.",
          "skills": [
            "Time zones"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5e1871f5-fbed-4eee-b3d6-e74066dfeebd",
          "key": "BCALENDAR-103",
          "title": "Expand recurrence within a bounded availability window",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "time",
          "dependsOn": [
            "BCALENDAR-102"
          ],
          "scenario": "An unbounded recurrence rule exhausts the availability request.",
          "acceptanceCriteria": [
            "Require finite query start and end.",
            "Limit emitted occurrences and processing work.",
            "Honor exclusions and changed single occurrences."
          ],
          "implementationNotes": [
            "Reject unsupported recurrence forms explicitly."
          ],
          "verification": [
            "Expand a weekly rule with an exception.",
            "Bound an excessive recurrence and reject unsupported syntax."
          ],
          "deliverables": [
            "Bounded recurrence engine."
          ],
          "rollout": "Start with declared supported rules; preserve unsupported events as unavailable context.",
          "skills": [
            "Recurrence",
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "78089c42-aaa5-4b14-8cd2-8b6714f691fe",
          "key": "BCALENDAR-104",
          "title": "Apply event revisions without reviving cancelled occurrences",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "BCALENDAR-103"
          ],
          "scenario": "An old series update recreates a cancelled individual appointment.",
          "acceptanceCriteria": [
            "Track series and occurrence revisions separately.",
            "Preserve cancellation tombstones.",
            "Ignore stale updates with an observable reason."
          ],
          "implementationNotes": [
            "Arrival order is not event version authority."
          ],
          "verification": [
            "Update one occurrence in a series.",
            "Replay an older series update after cancellation."
          ],
          "deliverables": [
            "Revision-aware event importer."
          ],
          "rollout": "Adopt on synthetic calendars first; reconcile before enabling booking decisions.",
          "skills": [
            "Event ordering"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "867f52a6-2787-491a-87c8-ad055a0d5980",
          "key": "BCALENDAR-105",
          "title": "Use incremental sync tokens without losing full-resync coverage",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "sync",
          "dependsOn": [
            "BCALENDAR-104"
          ],
          "scenario": "The provider invalidates a sync token, and the app interprets it as an empty calendar.",
          "acceptanceCriteria": [
            "Distinguish token invalidation from no changes.",
            "Start a bounded full sync on invalidation.",
            "Keep existing availability marked stale until replacement completes."
          ],
          "implementationNotes": [
            "Never clear events because a provider request failed."
          ],
          "verification": [
            "Apply a normal incremental page.",
            "Invalidate the token and preserve stale records during recovery."
          ],
          "deliverables": [
            "Sync-token recovery."
          ],
          "rollout": "Pause definitive availability claims while full sync is incomplete.",
          "skills": [
            "Synchronization"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9a37b006-7826-4fd0-bf6e-ee6b851125e8",
          "key": "BCALENDAR-106",
          "title": "Project busy intervals without exposing event descriptions",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "sync",
          "dependsOn": [
            "BCALENDAR-104"
          ],
          "scenario": "Availability responses leak private appointment titles to bookers.",
          "acceptanceCriteria": [
            "Expose only necessary busy intervals.",
            "Scope calendars by current access grants.",
            "Exclude titles, attendees, and notes from public projections."
          ],
          "implementationNotes": [
            "Private provider fields remain outside scheduling responses."
          ],
          "verification": [
            "Compute availability from authorized events.",
            "Seed sensitive markers and verify they never appear in outputs."
          ],
          "deliverables": [
            "Privacy-preserving availability projection."
          ],
          "rollout": "Replace detailed projections before public availability is enabled.",
          "skills": [
            "Privacy",
            "API projections"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "47fe39d9-47d3-465e-9042-cb7dadb918a1",
          "key": "BCALENDAR-107",
          "title": "Stop provider calls immediately after access revocation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sync",
          "dependsOn": [
            "BCALENDAR-105",
            "BCALENDAR-106"
          ],
          "scenario": "Revoked calendars remain cached and continue receiving background refreshes.",
          "acceptanceCriteria": [
            "Invalidate active grants and queued refresh authority.",
            "Suppress cached private availability after revocation.",
            "Make reconnect an explicit new authorization flow."
          ],
          "implementationNotes": [
            "Do not retry authorization failures as transient errors."
          ],
          "verification": [
            "Refresh an authorized calendar.",
            "Revoke access mid-queue and verify no further authorized reads occur."
          ],
          "deliverables": [
            "Revocation handling."
          ],
          "rollout": "Fail closed on uncertain grants; retain only allowed operational metadata.",
          "skills": [
            "Authorization",
            "Lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "cbef8f7e-533d-4d35-af78-6248144aa474",
          "key": "BCALENDAR-108",
          "title": "Detect overlapping booking attempts against one availability revision",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "release",
          "dependsOn": [
            "BCALENDAR-106",
            "BCALENDAR-107"
          ],
          "scenario": "Two bookers see the same open slot before either reservation is committed.",
          "acceptanceCriteria": [
            "Bind booking checks to a declared availability revision.",
            "Serialize or atomically reject overlapping local reservations.",
            "Represent external confirmation as pending when unknown."
          ],
          "implementationNotes": [
            "Use a local provider double; create no real events."
          ],
          "verification": [
            "Race two bookings for one slot.",
            "Change provider availability during booking and expose the conflict."
          ],
          "deliverables": [
            "Booking consistency checks."
          ],
          "rollout": "Keep short local reservations; reconcile unknown external outcomes before releasing them.",
          "skills": [
            "Concurrency",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8a13fb19-bb75-438d-9f93-6805759ac562",
          "key": "BCALENDAR-109",
          "title": "Assess polling versus callbacks for calendar freshness",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "release",
          "dependsOn": [
            "BCALENDAR-105",
            "BCALENDAR-108"
          ],
          "scenario": "The provider's callbacks are delayed, but frequent polling consumes the request budget.",
          "acceptanceCriteria": [
            "Compare bounded polling and callback-assisted approaches.",
            "Declare acceptable staleness and request-budget assumptions.",
            "Rehearse dropped callbacks, duplicates, and provider outages."
          ],
          "implementationNotes": [
            "Local measurements do not establish a live provider's delivery guarantees."
          ],
          "verification": [
            "Recover a missed callback through polling.",
            "Exhaust the budget and show stale availability explicitly."
          ],
          "deliverables": [
            "Freshness tradeoff assessment."
          ],
          "rollout": "Adopt a conservative refresh policy with visible age and a manual recovery path.",
          "skills": [
            "System tradeoffs",
            "Integration reliability"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "193ed6f0-b1ad-454d-8e0c-934918b78f7c",
          "key": "BCALENDAR-110",
          "title": "Write the calendar recovery checklist for invalid sync state",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "release",
          "dependsOn": [
            "BCALENDAR-109"
          ],
          "scenario": "Support needs to recover a calendar without deleting local reservations.",
          "acceptanceCriteria": [
            "Identify the calendar, grant, and sync revision.",
            "Show safe resync and status commands.",
            "Preserve local reservations while replacing imported events."
          ],
          "implementationNotes": [
            "No direct lifecycle-state edits."
          ],
          "verification": [
            "Recover an invalid token using the guide.",
            "Reject recovery for a revoked grant."
          ],
          "deliverables": [
            "Calendar support runbook."
          ],
          "rollout": "Rehearse against synthetic calendars before enabling a support action.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "e19da797-4e34-424a-8bea-e1bd111f2f21",
      "key": "BSLO",
      "title": "Checkout service-level objectives",
      "field": "Site reliability",
      "summary": "Define customer-facing reliability indicators and actionable budget policies.",
      "context": "A fictional checkout service reports process uptime while customers experience failed orders and slow confirmations.",
      "stack": [
        "TypeScript",
        "Prometheus",
        "HTTP"
      ],
      "prerequisites": [
        "Create synthetic request and order-event traces plus a local query or metrics fixture; no production telemetry required."
      ],
      "developerValue": "Practice SLI semantics, alert evaluation, and reliability tradeoffs.",
      "companyValue": "Align reliability discussions with customer outcomes and explicit measurement limits.",
      "delivery": "Deliver executable indicator queries, alert fixtures, and an SLO decision record.",
      "phases": [
        {
          "id": "define",
          "title": "Define indicators",
          "goal": "Specify measurable user outcomes and valid denominators."
        },
        {
          "id": "measure",
          "title": "Compute and alert",
          "goal": "Handle missing data and evaluate budget burn."
        },
        {
          "id": "operate",
          "title": "Use the objective",
          "goal": "Connect reliability policy to reviewable operational decisions."
        }
      ],
      "tickets": [
        {
          "id": "82ab987d-c26d-404b-b5f2-9b94ef2e1ddc",
          "key": "BSLO-101",
          "title": "Define eligible checkout attempts and successful completion",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "define",
          "dependsOn": [],
          "scenario": "Availability reports count health checks as customer success.",
          "acceptanceCriteria": [
            "Define eligible attempts and completion deadlines.",
            "Exclude synthetic probes from customer denominators.",
            "Document validation failures and abandoned checkouts separately."
          ],
          "implementationNotes": [
            "Do not exclude service failures to improve the ratio."
          ],
          "verification": [
            "Classify representative success and failure traces.",
            "Reject a denominator that includes only completed orders."
          ],
          "deliverables": [
            "SLI event contract."
          ],
          "rollout": "Review event semantics before publishing an objective.",
          "skills": [
            "SLI design"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1dee3a71-bf26-4dfd-b903-57721a6a48e7",
          "key": "BSLO-102",
          "title": "Deduplicate retried checkout attempts in indicator calculations",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "define",
          "dependsOn": [
            "BSLO-101"
          ],
          "scenario": "Client retries inflate both request volume and apparent success.",
          "acceptanceCriteria": [
            "Count one logical attempt under the declared identity.",
            "Preserve retry observations separately.",
            "Flag missing identities without guessing deduplication."
          ],
          "implementationNotes": [
            "Avoid user-identifying metric labels."
          ],
          "verification": [
            "Count a retried successful attempt once.",
            "Expose ambiguous records with missing attempt IDs."
          ],
          "deliverables": [
            "Deduplicated indicator query."
          ],
          "rollout": "Compare old and new counts before switching dashboards.",
          "skills": [
            "Metrics",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ca7a1b21-ade8-49fd-b32f-7cc555e18db0",
          "key": "BSLO-103",
          "title": "Compute completion latency from consistent event pairs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "measure",
          "dependsOn": [
            "BSLO-102"
          ],
          "scenario": "Latency is measured from different start events across client versions.",
          "acceptanceCriteria": [
            "Specify start and completion event semantics.",
            "Reject negative or unmatched durations.",
            "Track excluded samples and instrumentation version."
          ],
          "implementationNotes": [
            "State clock assumptions explicitly."
          ],
          "verification": [
            "Compute known synthetic durations.",
            "Detect clock skew and unmatched completion events."
          ],
          "deliverables": [
            "Latency indicator implementation."
          ],
          "rollout": "Run both definitions during comparison; retain the prior dashboard for diagnosis.",
          "skills": [
            "Observability",
            "Time handling"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "69dbe211-67a5-4f1e-92e7-166559ead4bc",
          "key": "BSLO-104",
          "title": "Keep missing telemetry distinct from successful service",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "measure",
          "dependsOn": [
            "BSLO-103"
          ],
          "scenario": "A metrics outage produces an empty query that the dashboard renders as healthy.",
          "acceptanceCriteria": [
            "Represent no data separately from zero failures.",
            "Display data freshness and coverage.",
            "Alert on measurement failure independently."
          ],
          "implementationNotes": [
            "Unknown reliability cannot consume zero budget by default."
          ],
          "verification": [
            "Show healthy complete telemetry.",
            "Drop a source stream and display unknown coverage."
          ],
          "deliverables": [
            "Missing-data handling."
          ],
          "rollout": "Enable measurement alerts before relying on budget policy.",
          "skills": [
            "Monitoring"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 80
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8337d4a2-93ee-44fb-94f9-8d4bee7fe1ab",
          "key": "BSLO-105",
          "title": "Implement multi-window error-budget burn calculations",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "measure",
          "dependsOn": [
            "BSLO-102",
            "BSLO-104"
          ],
          "scenario": "A brief spike pages the team while a slower sustained incident passes unnoticed.",
          "acceptanceCriteria": [
            "Calculate burn against the declared objective.",
            "Require aligned short and long windows for the chosen alert.",
            "Handle window edges and low sample counts explicitly."
          ],
          "implementationNotes": [
            "Thresholds are scenario assumptions, not universal defaults."
          ],
          "verification": [
            "Trigger on sustained synthetic burn.",
            "Avoid paging for an isolated low-volume failure under the documented policy."
          ],
          "deliverables": [
            "Burn-rate queries and fixtures."
          ],
          "rollout": "Run alerts without notifications locally before operational adoption.",
          "skills": [
            "Alerting",
            "Time-series analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "dddd7323-f403-4b5c-bd9b-f847880985f6",
          "key": "BSLO-106",
          "title": "Separate dependency failure from the customer-facing objective",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "measure",
          "dependsOn": [
            "BSLO-105"
          ],
          "scenario": "The team wants to exclude payment-provider outages from checkout reliability.",
          "acceptanceCriteria": [
            "Keep customer outcome accounting intact.",
            "Add dependency attribution as a separate diagnostic dimension.",
            "Expose uncertain attribution without changing the denominator."
          ],
          "implementationNotes": [
            "Do not transfer responsibility by redefining failed outcomes away."
          ],
          "verification": [
            "Count a dependency-caused customer failure.",
            "Show attribution missing while retaining the failure."
          ],
          "deliverables": [
            "Attribution dashboard contract."
          ],
          "rollout": "Add diagnostics alongside the objective; preserve historical customer outcomes.",
          "skills": [
            "Reliability analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 80
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d52c9403-e3c7-49e8-b57a-eff445ab21a6",
          "key": "BSLO-107",
          "title": "Define release actions for exhausted error budget",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BSLO-105",
            "BSLO-106"
          ],
          "scenario": "An exhausted budget triggers a blanket release freeze, including urgent reliability fixes.",
          "acceptanceCriteria": [
            "Distinguish feature, risk-reduction, and emergency changes.",
            "Define reviewed exception authority and expiry.",
            "Compare business urgency against measured reliability risk."
          ],
          "implementationNotes": [
            "Policy provides decision support, not automatic business authority."
          ],
          "verification": [
            "Apply policy to a normal feature release.",
            "Document an emergency exception with unresolved risks."
          ],
          "deliverables": [
            "Error-budget policy decision record."
          ],
          "rollout": "Trial the policy in a tabletop; preserve human release accountability.",
          "skills": [
            "Operational policy",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 80
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "78da471b-f9d4-4c81-8565-9502f011614a",
          "key": "BSLO-108",
          "title": "Build an SLO dashboard with bounded diagnostic dimensions",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BSLO-106"
          ],
          "scenario": "Engineers cannot relate budget burn to endpoint versions without exposing user data.",
          "acceptanceCriteria": [
            "Show objective, burn, eligible volume, and coverage.",
            "Allow only bounded endpoint/version dimensions.",
            "Keep customer identifiers out of labels and URLs."
          ],
          "implementationNotes": [
            "Dashboard totals must reconcile with source fixtures."
          ],
          "verification": [
            "Reconcile known synthetic totals.",
            "Reject an unbounded user-ID dimension."
          ],
          "deliverables": [
            "SLO dashboard definition."
          ],
          "rollout": "Publish read-only views first; restore prior queries if totals diverge.",
          "skills": [
            "Observability",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6cfabedd-ea85-49d0-9696-9b9648f35c62",
          "key": "BSLO-109",
          "title": "Rehearse an objective change without rewriting historical results",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operate",
          "dependsOn": [
            "BSLO-107",
            "BSLO-108"
          ],
          "scenario": "A new completion deadline would make last month's results look better if applied retrospectively.",
          "acceptanceCriteria": [
            "Version objective and indicator definitions.",
            "Compute new results from an explicit effective time.",
            "Preserve historical values under their original definition."
          ],
          "implementationNotes": [
            "Show comparison overlap without relabeling old performance."
          ],
          "verification": [
            "Run old and new definitions on the same fixture.",
            "Verify historical records remain bound to the old version."
          ],
          "deliverables": [
            "SLO revision rehearsal."
          ],
          "rollout": "Run overlapping views before changing the active objective.",
          "skills": [
            "Versioning",
            "Operational integrity"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6de914b1-bdbb-48e9-854c-67d5b7451e36",
          "key": "BSLO-110",
          "title": "Write an SLO interpretation guide for low-traffic periods",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "operate",
          "dependsOn": [
            "BSLO-109"
          ],
          "scenario": "A single failure overnight produces a dramatic percentage without explaining the sample size.",
          "acceptanceCriteria": [
            "Display eligible event count with the ratio.",
            "Explain low-volume uncertainty.",
            "Document when to inspect individual synthetic traces."
          ],
          "implementationNotes": [
            "Avoid promises of perfect reliability."
          ],
          "verification": [
            "Interpret one failure in a small sample.",
            "Distinguish zero traffic from a healthy measured window."
          ],
          "deliverables": [
            "SLO interpretation guide."
          ],
          "rollout": "Link guidance from dashboards and alert descriptions.",
          "skills": [
            "Technical writing",
            "Reliability"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "f1a43d6a-7c9b-4238-9fdd-c8584780644a",
      "key": "BINCIDENT",
      "title": "Queue backlog incident response",
      "field": "Site reliability",
      "summary": "Diagnose and recover delayed background work without duplicating effects.",
      "context": "A fictional document service has a rising processing backlog. Operators cannot tell whether arrivals, worker failures, or a slow dependency is responsible.",
      "stack": [
        "TypeScript",
        "BullMQ",
        "Redis"
      ],
      "prerequisites": [
        "Create a bounded local queue simulation with synthetic jobs and controllable worker/dependency failures."
      ],
      "developerValue": "Practice incident timelines, queue diagnosis, and measured recovery.",
      "companyValue": "Produce a repeatable response that preserves work integrity and exposes customer delay.",
      "delivery": "Deliver local incident instrumentation, recovery controls, and a tabletop report.",
      "phases": [
        {
          "id": "observe",
          "title": "Observe backlog",
          "goal": "Separate queue age, throughput, and failure symptoms."
        },
        {
          "id": "contain",
          "title": "Contain safely",
          "goal": "Control arrivals and retries while preserving job identity."
        },
        {
          "id": "recover",
          "title": "Recover and learn",
          "goal": "Drain work and validate recovery decisions."
        }
      ],
      "tickets": [
        {
          "id": "132f5f91-367b-419e-9187-8c0346612078",
          "key": "BINCIDENT-101",
          "title": "Report oldest eligible job age alongside queue depth",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "observe",
          "dependsOn": [],
          "scenario": "A shallow queue can still contain a single customer job stuck for hours.",
          "acceptanceCriteria": [
            "Measure oldest eligible age separately from count.",
            "Exclude scheduled future work from overdue age.",
            "Show missing timestamp records explicitly."
          ],
          "implementationNotes": [
            "Use bounded job-type labels only."
          ],
          "verification": [
            "Measure a known delayed fixture.",
            "Keep future-scheduled jobs out of overdue calculations."
          ],
          "deliverables": [
            "Backlog age metric."
          ],
          "rollout": "Add read-only metrics before changing worker behavior.",
          "skills": [
            "Queue observability"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 80
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3e4b7de0-a6a4-4786-9248-2a5a42215167",
          "key": "BINCIDENT-102",
          "title": "Separate arrival rate from successful service rate",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "observe",
          "dependsOn": [
            "BINCIDENT-101"
          ],
          "scenario": "The dashboard counts retries as new incoming customer work.",
          "acceptanceCriteria": [
            "Track logical arrivals, attempts, and completions separately.",
            "Use consistent measurement windows.",
            "Expose worker concurrency with throughput."
          ],
          "implementationNotes": [
            "Do not infer capacity from a single peak sample."
          ],
          "verification": [
            "Reconcile a fixture with repeated attempts.",
            "Detect growing backlog despite high attempt throughput."
          ],
          "deliverables": [
            "Queue flow dashboard."
          ],
          "rollout": "Compare against synthetic queue inventory before relying on alerts.",
          "skills": [
            "Metrics",
            "Capacity analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "94197340-77d5-486a-a40c-0ef9de7bcfcf",
          "key": "BINCIDENT-103",
          "title": "Identify poison jobs without starving unrelated work",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "contain",
          "dependsOn": [
            "BINCIDENT-102"
          ],
          "scenario": "One malformed document repeatedly consumes the first worker slot.",
          "acceptanceCriteria": [
            "Bound attempts by failure category.",
            "Move exhausted jobs to an inspectable terminal holding state.",
            "Allow unrelated valid jobs to continue."
          ],
          "implementationNotes": [
            "Keep payload contents out of generic incident logs."
          ],
          "verification": [
            "Quarantine a deterministic poison job.",
            "Process a valid neighboring job and preserve its identity."
          ],
          "deliverables": [
            "Poison-job containment."
          ],
          "rollout": "Enable per job type; retain held work for reviewed correction.",
          "skills": [
            "Retries",
            "Queue design"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "bed818de-b4ef-4677-8183-ff690a51ba12",
          "key": "BINCIDENT-104",
          "title": "Pause selected producers while preserving accepted work",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "contain",
          "dependsOn": [
            "BINCIDENT-102"
          ],
          "scenario": "Operators stop every producer even though only one import path overloads the queue.",
          "acceptanceCriteria": [
            "Scope pause controls to declared producer classes.",
            "Reject new work with explicit retry guidance.",
            "Preserve previously accepted job records."
          ],
          "implementationNotes": [
            "Privileged pause changes require an audit entry."
          ],
          "verification": [
            "Pause the synthetic import producer.",
            "Verify another producer works and unauthorized pause is denied."
          ],
          "deliverables": [
            "Scoped admission control."
          ],
          "rollout": "Start with one producer switch; restore intake gradually after backlog age recovers.",
          "skills": [
            "Admission control",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3f380235-9c75-4802-8726-3a31c66fe0fa",
          "key": "BINCIDENT-105",
          "title": "Recover expired worker leases without concurrent duplicate effects",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "contain",
          "dependsOn": [
            "BINCIDENT-103"
          ],
          "scenario": "A worker crashes after producing output but before acknowledging completion.",
          "acceptanceCriteria": [
            "Use stable job operation identity.",
            "Reclaim only expired ownership.",
            "Adopt existing completed output before repeating effects."
          ],
          "implementationNotes": [
            "Mock effects must be idempotent and locally scoped."
          ],
          "verification": [
            "Crash after effect acceptance and reclaim.",
            "Race two reclaimers and observe one terminal outcome."
          ],
          "deliverables": [
            "Lease recovery behavior."
          ],
          "rollout": "Reclaim in bounded batches; stop on conflicting output identities.",
          "skills": [
            "Leases",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e9de9fc1-cff1-433c-8989-3db9130ff37f",
          "key": "BINCIDENT-106",
          "title": "Tune retry delay for a throttled dependency",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "contain",
          "dependsOn": [
            "BINCIDENT-103",
            "BINCIDENT-104"
          ],
          "scenario": "Immediate retries amplify the dependency's temporary throttling.",
          "acceptanceCriteria": [
            "Respect bounded retry-after guidance.",
            "Apply jitter with reproducible test control.",
            "Cap total attempts and elapsed time."
          ],
          "implementationNotes": [
            "Never retry permanent validation or authorization failures."
          ],
          "verification": [
            "Recover after a temporary throttle.",
            "Exhaust a persistent outage without a retry storm."
          ],
          "deliverables": [
            "Dependency retry policy."
          ],
          "rollout": "Trial on one job class; pause dispatch if throttling remains sustained.",
          "skills": [
            "Backoff",
            "Resilience"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5e3e5a35-2214-4c97-b5f2-a20ff4972b7f",
          "key": "BINCIDENT-107",
          "title": "Estimate backlog drain time under explicit capacity assumptions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "BINCIDENT-102",
            "BINCIDENT-106"
          ],
          "scenario": "Support promises a completion time using queue depth divided by the busiest worker's speed.",
          "acceptanceCriteria": [
            "Use measured successful service and arrival rates.",
            "Report assumptions and uncertainty bounds.",
            "Return no finite estimate when arrivals meet or exceed service."
          ],
          "implementationNotes": [
            "Use synthetic measurements and avoid general capacity claims."
          ],
          "verification": [
            "Estimate a controlled draining workload.",
            "Show an unstable workload as non-draining."
          ],
          "deliverables": [
            "Drain-time estimator."
          ],
          "rollout": "Publish estimates with their observation window; retract stale estimates.",
          "skills": [
            "Queueing",
            "Capacity planning"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "bf808a7a-5d59-4411-968a-e212a1d66b4c",
          "key": "BINCIDENT-108",
          "title": "Rehearse backlog recovery with a constrained worker budget",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "BINCIDENT-104",
            "BINCIDENT-105",
            "BINCIDENT-107"
          ],
          "scenario": "Adding workers may increase database contention and make recovery slower.",
          "acceptanceCriteria": [
            "Compare two bounded concurrency settings under identical arrivals.",
            "Measure completion age, dependency pressure, and duplicate-effect checks.",
            "Choose a recovery setting with stated tradeoffs."
          ],
          "implementationNotes": [
            "Record machine limits; do not extrapolate local capacity to production."
          ],
          "verification": [
            "Drain the synthetic incident workload.",
            "Demonstrate a setting that worsens contention or violates limits."
          ],
          "deliverables": [
            "Recovery experiment report."
          ],
          "rollout": "Raise concurrency in measured steps; revert when dependency or integrity thresholds fail.",
          "skills": [
            "Performance experiments",
            "Incident response"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ba55f9ec-cb8f-48ef-abad-0c468c0fc0c5",
          "key": "BINCIDENT-109",
          "title": "Create an incident timeline from control and queue events",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recover",
          "dependsOn": [
            "BINCIDENT-108"
          ],
          "scenario": "The post-incident discussion relies on memory of when pauses and retries changed.",
          "acceptanceCriteria": [
            "Record control actions with actor and UTC time.",
            "Link changes to observed backlog metrics.",
            "Separate observations from causal hypotheses."
          ],
          "implementationNotes": [
            "Exclude customer payloads and personal operator commentary."
          ],
          "verification": [
            "Reconstruct the synthetic incident.",
            "Show a missing observation as a gap rather than inventing timing."
          ],
          "deliverables": [
            "Incident timeline exporter."
          ],
          "rollout": "Preserve original event records; append corrections to the timeline.",
          "skills": [
            "Auditability",
            "Incident analysis"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "95ee50ea-fc4b-4fbe-bc39-42b52dcfad77",
          "key": "BINCIDENT-110",
          "title": "Write a queue handoff with explicit resume conditions",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "recover",
          "dependsOn": [
            "BINCIDENT-109"
          ],
          "scenario": "The next on-call engineer inherits paused intake without knowing when to reopen it.",
          "acceptanceCriteria": [
            "List active controls and held job counts.",
            "Specify measurable intake-resume conditions.",
            "Document safe rollback of each temporary control."
          ],
          "implementationNotes": [
            "Commands target the local incident fixture only."
          ],
          "verification": [
            "Resume intake using the handoff.",
            "Keep intake paused when dependency health remains unknown."
          ],
          "deliverables": [
            "On-call handoff runbook."
          ],
          "rollout": "Require a handoff whenever containment outlives the current operator.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "5951c8eb-f3ff-4d2e-a159-df7597aa8a15",
      "key": "BRESTORE",
      "title": "Backup restoration rehearsal",
      "field": "Site reliability",
      "summary": "Verify that database and object-store backups can reconstruct a coherent service.",
      "context": "A fictional reporting service has successful backup jobs but no recent restore rehearsal. Database rows reference objects with different retention schedules.",
      "stack": [
        "PostgreSQL",
        "S3-compatible storage",
        "TypeScript"
      ],
      "prerequisites": [
        "Create disposable local database and object-store fixtures with synthetic reports; author backup and corruption examples."
      ],
      "developerValue": "Practice recovery consistency, integrity validation, and honest recovery objectives.",
      "companyValue": "Replace backup-job optimism with a repeatable restoration assessment.",
      "delivery": "Deliver a local restore harness and recovery report; change no production backup policy.",
      "phases": [
        {
          "id": "inventory",
          "title": "Inventory recovery dependencies",
          "goal": "Define backup scope and consistency requirements."
        },
        {
          "id": "restore",
          "title": "Restore isolated data",
          "goal": "Reconstruct and validate a coherent snapshot."
        },
        {
          "id": "prove",
          "title": "Rehearse disruption",
          "goal": "Measure recovery and document unrecoverable gaps."
        }
      ],
      "tickets": [
        {
          "id": "0ee5a2c7-d2e6-44cb-9924-b80e3247c9f3",
          "key": "BRESTORE-101",
          "title": "Inventory the data required to restore one report",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "inventory",
          "dependsOn": [],
          "scenario": "A database backup omits the object containing the actual report.",
          "acceptanceCriteria": [
            "List database rows, objects, and configuration references.",
            "Identify authoritative and rebuildable data.",
            "Document retention mismatches."
          ],
          "implementationNotes": [
            "Use synthetic records and secret placeholders."
          ],
          "verification": [
            "Trace one report end to end.",
            "Identify a missing object as an incomplete recovery dependency."
          ],
          "deliverables": [
            "Recovery inventory."
          ],
          "rollout": "Review inventory before altering backup jobs.",
          "skills": [
            "Recovery planning"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "cb85c00a-328e-43ab-b224-3cca5203b5a0",
          "key": "BRESTORE-102",
          "title": "Define a consistent backup manifest across stores",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "inventory",
          "dependsOn": [
            "BRESTORE-101"
          ],
          "scenario": "Database and object backups represent different points in time.",
          "acceptanceCriteria": [
            "Record snapshot boundary and object version digests.",
            "Include schema and manifest versions.",
            "Reject incomplete manifests."
          ],
          "implementationNotes": [
            "Do not equate wall-clock proximity with transactional consistency."
          ],
          "verification": [
            "Build a coherent synthetic manifest.",
            "Reject a manifest referencing an unavailable object version."
          ],
          "deliverables": [
            "Backup manifest contract."
          ],
          "rollout": "Version manifests and retain the prior complete backup set.",
          "skills": [
            "Consistency",
            "Provenance"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b9650b0e-1c8b-4292-92c3-0d7923300b8a",
          "key": "BRESTORE-103",
          "title": "Guard restore commands against non-scratch targets",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "restore",
          "dependsOn": [
            "BRESTORE-102"
          ],
          "scenario": "A restore command can overwrite an existing developer database by mistake.",
          "acceptanceCriteria": [
            "Require an explicit scratch target.",
            "Reject nonempty or unapproved destinations.",
            "Display sanitized target identity."
          ],
          "implementationNotes": [
            "No remote or production endpoints in this exercise."
          ],
          "verification": [
            "Restore into an empty named scratch database.",
            "Reject an occupied or remote destination."
          ],
          "deliverables": [
            "Restore target guard."
          ],
          "rollout": "Default to inspection-only until target validation passes.",
          "skills": [
            "Operational safety"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "47c47925-5172-422a-afdf-19c488a9d82f",
          "key": "BRESTORE-104",
          "title": "Verify backup bytes before applying restored data",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "restore",
          "dependsOn": [
            "BRESTORE-102",
            "BRESTORE-103"
          ],
          "scenario": "A truncated object archive is discovered only after the application starts.",
          "acceptanceCriteria": [
            "Validate declared sizes and content digests.",
            "Reject missing or extra required archive members.",
            "Stop before promotion on any mismatch."
          ],
          "implementationNotes": [
            "Bound archive expansion and reject traversal paths."
          ],
          "verification": [
            "Verify a complete backup set.",
            "Reject corruption and an escaping archive entry."
          ],
          "deliverables": [
            "Backup integrity verifier."
          ],
          "rollout": "Keep failed restores isolated and retain diagnostic metadata.",
          "skills": [
            "Integrity",
            "Archive handling"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4ba8ef07-7084-4fff-89e3-a8bb0c104332",
          "key": "BRESTORE-105",
          "title": "Restore database references before enabling object reads",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "restore",
          "dependsOn": [
            "BRESTORE-104"
          ],
          "scenario": "The application exposes restored metadata while referenced objects are still missing.",
          "acceptanceCriteria": [
            "Keep restored service unavailable until coherence checks pass.",
            "Reconcile every required object reference.",
            "Report dangling references without inventing replacements."
          ],
          "implementationNotes": [
            "Public readiness must not imply partial data is complete."
          ],
          "verification": [
            "Restore a coherent report set.",
            "Remove one object and keep readiness blocked."
          ],
          "deliverables": [
            "Restore readiness checks."
          ],
          "rollout": "Promote only a validated restore; preserve the original scratch failure state.",
          "skills": [
            "Readiness",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b233188d-9f99-42ab-9828-9bc7a9d0ebc4",
          "key": "BRESTORE-106",
          "title": "Rebuild derived indexes from restored authoritative records",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "restore",
          "dependsOn": [
            "BRESTORE-105"
          ],
          "scenario": "The backup contains stale search indexes that disagree with restored reports.",
          "acceptanceCriteria": [
            "Rebuild indexes from the restored authority.",
            "Make rebuild restartable and bounded.",
            "Verify index counts and sampled content bindings."
          ],
          "implementationNotes": [
            "Never treat an index as the source of truth."
          ],
          "verification": [
            "Rebuild after a complete restore.",
            "Interrupt rebuilding and resume without duplicate entries."
          ],
          "deliverables": [
            "Derived-data rebuild command."
          ],
          "rollout": "Keep search unavailable until its version matches restored data.",
          "skills": [
            "Data recovery",
            "Indexing"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "92514dc4-34d8-4207-9576-2abbc636060d",
          "key": "BRESTORE-107",
          "title": "Check application compatibility against restored schema versions",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "prove",
          "dependsOn": [
            "BRESTORE-105",
            "BRESTORE-106"
          ],
          "scenario": "The latest application cannot read a backup taken before a schema contraction.",
          "acceptanceCriteria": [
            "Declare compatible application/schema pairs.",
            "Run representative reads and writes after restore.",
            "Identify migration requirements before promotion."
          ],
          "implementationNotes": [
            "Do not silently upgrade restored data without a reviewed path."
          ],
          "verification": [
            "Start a compatible build against the restore.",
            "Reject an incompatible schema with clear guidance."
          ],
          "deliverables": [
            "Restore compatibility matrix."
          ],
          "rollout": "Retain a compatible application artifact with each backup generation.",
          "skills": [
            "Schema evolution"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "80bb26c3-b7cc-4990-8344-6c5cae8578a9",
          "key": "BRESTORE-108",
          "title": "Measure recovery time and recoverable data loss separately",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "prove",
          "dependsOn": [
            "BRESTORE-107"
          ],
          "scenario": "Management asks for recovery objectives, but a single successful local restore is being treated as a guarantee.",
          "acceptanceCriteria": [
            "Measure each restore phase under stated dataset and machine limits.",
            "Compute the gap between backup boundary and failure time.",
            "Report untested scale and dependency assumptions."
          ],
          "implementationNotes": [
            "Local rehearsal establishes observations, not production RTO or RPO guarantees."
          ],
          "verification": [
            "Measure a complete synthetic recovery.",
            "Expose an unrecoverable post-backup write explicitly."
          ],
          "deliverables": [
            "Recovery assessment."
          ],
          "rollout": "Use results to propose objectives; repeat in the target environment before committing to them.",
          "skills": [
            "Reliability planning",
            "Experimental design"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e254c6b8-e2ca-47d8-98d7-c7556dde8bbd",
          "key": "BRESTORE-109",
          "title": "Rehearse recovery when the newest backup is unusable",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "prove",
          "dependsOn": [
            "BRESTORE-104",
            "BRESTORE-108"
          ],
          "scenario": "The latest backup manifest is valid but one required object version is unavailable.",
          "acceptanceCriteria": [
            "Select an older complete recovery set explicitly.",
            "Report the increased data-loss window.",
            "Preserve evidence of why the newest set was rejected."
          ],
          "implementationNotes": [
            "Never merge unrelated backup generations without a defined consistency rule."
          ],
          "verification": [
            "Recover from the previous complete set.",
            "Reject an inconsistent mix of database and object generations."
          ],
          "deliverables": [
            "Backup fallback rehearsal."
          ],
          "rollout": "Keep multiple complete generations until retention review permits removal.",
          "skills": [
            "Disaster recovery"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bc1bb4d9-e9be-4a38-8437-2428fe1928b8",
          "key": "BRESTORE-110",
          "title": "Write a restore handoff with promotion and abandonment criteria",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "prove",
          "dependsOn": [
            "BRESTORE-109"
          ],
          "scenario": "An operator needs to decide whether a long-running restore is safe to promote.",
          "acceptanceCriteria": [
            "List required integrity and compatibility checks.",
            "Document promotion authority and target identity.",
            "Explain how to abandon the scratch restore safely."
          ],
          "implementationNotes": [
            "Avoid destructive cleanup commands outside the named scratch directory."
          ],
          "verification": [
            "Follow the handoff to promote a valid fixture.",
            "Keep a restore with missing objects unpromoted."
          ],
          "deliverables": [
            "Restore runbook."
          ],
          "rollout": "Store the runbook with backup manifests and compatible build references.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "4eedb0cf-a8b2-46b9-ba4d-b3b11d9c61f1",
      "key": "BLOADSHED",
      "title": "Overload admission and graceful degradation",
      "field": "Site reliability",
      "summary": "Protect essential reads when optional workloads saturate a service.",
      "context": "A fictional ticketing service becomes unresponsive during event releases because optional recommendation calls consume the same resources as reservation checks.",
      "stack": [
        "TypeScript",
        "HTTP",
        "Redis"
      ],
      "prerequisites": [
        "Build a bounded local service and synthetic open-loop workload generator with controllable dependency delays."
      ],
      "developerValue": "Practice overload behavior, admission control, and fair performance experiments.",
      "companyValue": "Create predictable failure and degradation behavior under declared capacity constraints.",
      "delivery": "Deliver local controls and measurements; no live load generation.",
      "phases": [
        {
          "id": "baseline",
          "title": "Characterize overload",
          "goal": "Define essential outcomes and bounded workload assumptions."
        },
        {
          "id": "protect",
          "title": "Protect service capacity",
          "goal": "Limit queues and isolate optional work."
        },
        {
          "id": "validate",
          "title": "Validate recovery",
          "goal": "Compare policies and verify return to normal operation."
        }
      ],
      "tickets": [
        {
          "id": "700db22b-abb4-48dc-872e-e99f913bdcaa",
          "key": "BLOADSHED-101",
          "title": "Classify essential and optional ticketing requests",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Recommendation requests compete with reservation checks without any priority policy.",
          "acceptanceCriteria": [
            "List request classes and user impact.",
            "Define allowed degradation per class.",
            "Keep reservation correctness invariant."
          ],
          "implementationNotes": [
            "Do not prioritize users by inferred personal traits."
          ],
          "verification": [
            "Classify a reservation and recommendation request.",
            "Identify a request that must fail explicitly rather than degrade silently."
          ],
          "deliverables": [
            "Request-class policy."
          ],
          "rollout": "Review classification before applying limits.",
          "skills": [
            "Reliability design"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "096593a7-fc9b-4341-8216-f31544e26f7e",
          "key": "BLOADSHED-102",
          "title": "Build a workload that preserves offered arrival rate",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "baseline",
          "dependsOn": [
            "BLOADSHED-101"
          ],
          "scenario": "A closed-loop load script hides overload by sending fewer requests as responses slow.",
          "acceptanceCriteria": [
            "Record offered, admitted, completed, and rejected rates.",
            "Use bounded open-loop scheduling.",
            "Report dropped generator work and resource limits."
          ],
          "implementationNotes": [
            "Run only against the local fixture."
          ],
          "verification": [
            "Generate the declared steady arrival rate.",
            "Overload the generator and report its invalid measurement window."
          ],
          "deliverables": [
            "Load harness."
          ],
          "rollout": "Cap duration and concurrency; discard runs with unreported generator saturation.",
          "skills": [
            "Load testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e6ccbf58-4c81-4766-8c2d-1e9ecb5403b4",
          "key": "BLOADSHED-103",
          "title": "Bound the waiting queue before worker slots are exhausted",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "protect",
          "dependsOn": [
            "BLOADSHED-102"
          ],
          "scenario": "Requests accumulate indefinitely while waiting for a shared dependency.",
          "acceptanceCriteria": [
            "Enforce a finite waiting capacity.",
            "Return a documented overload response when full.",
            "Remove cancelled requests from the queue."
          ],
          "implementationNotes": [
            "Never report rejected requests as successful degradation."
          ],
          "verification": [
            "Admit work below the limit.",
            "Overflow and cancel queued requests without leaked slots."
          ],
          "deliverables": [
            "Bounded admission queue."
          ],
          "rollout": "Start with conservative limits; restore the previous policy if essential outcomes regress.",
          "skills": [
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "47461420-3a09-4f0a-9499-677fe40ba9f8",
          "key": "BLOADSHED-104",
          "title": "Isolate optional recommendation concurrency",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "protect",
          "dependsOn": [
            "BLOADSHED-101",
            "BLOADSHED-103"
          ],
          "scenario": "Slow recommendations consume every outbound connection.",
          "acceptanceCriteria": [
            "Use a separate optional-work concurrency budget.",
            "Reserve declared capacity for essential requests.",
            "Skip optional work when its budget is unavailable."
          ],
          "implementationNotes": [
            "Use a real bounded pool, not an unbounded background task list."
          ],
          "verification": [
            "Serve reservations while recommendations stall.",
            "Exhaust optional slots and verify graceful omission."
          ],
          "deliverables": [
            "Optional-work bulkhead."
          ],
          "rollout": "Enable the bulkhead before increasing overall concurrency.",
          "skills": [
            "Bulkheads",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "bulkhead",
              "activity": "APPLY",
              "focus": "Bound optional recommendation concurrency separately from essential requests and show that exhausted optional capacity cannot consume the essential reserve."
            }
          ]
        },
        {
          "id": "eb421617-924e-4f34-9ef4-43ab5abd9b87",
          "key": "BLOADSHED-105",
          "title": "Propagate request deadlines to downstream work",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "protect",
          "dependsOn": [
            "BLOADSHED-103",
            "BLOADSHED-104"
          ],
          "scenario": "The client has timed out while its dependency request continues holding a slot.",
          "acceptanceCriteria": [
            "Derive child deadlines from remaining request time.",
            "Abort owned work on cancellation.",
            "Release capacity even when a double ignores cancellation."
          ],
          "implementationNotes": [
            "Bound cleanup time and track late completions safely."
          ],
          "verification": [
            "Complete within a shared deadline.",
            "Timeout an uncooperative dependency and reclaim the slot."
          ],
          "deliverables": [
            "Deadline propagation."
          ],
          "rollout": "Default to shorter optional deadlines; retain explicit timeout responses.",
          "skills": [
            "Cancellation",
            "Resource lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "852edd48-4bd6-45b1-b9da-9b979bcdf246",
          "key": "BLOADSHED-106",
          "title": "Provide retry guidance that does not synchronize every client",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "protect",
          "dependsOn": [
            "BLOADSHED-103"
          ],
          "scenario": "All rejected clients retry exactly one second later and recreate the spike.",
          "acceptanceCriteria": [
            "Return bounded retry guidance.",
            "Document jitter and attempt ceilings for clients.",
            "Avoid automatic retry of unsafe writes."
          ],
          "implementationNotes": [
            "Use deterministic random input in tests."
          ],
          "verification": [
            "Spread synthetic client retries across the window.",
            "Verify non-idempotent requests are not blindly retried."
          ],
          "deliverables": [
            "Overload response contract."
          ],
          "rollout": "Publish guidance with admission changes; monitor repeated rejection bursts.",
          "skills": [
            "Retry design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "be97e858-aed6-4d05-b610-799daaa0cdeb",
          "key": "BLOADSHED-107",
          "title": "Preserve fair access across tenant request queues",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "protect",
          "dependsOn": [
            "BLOADSHED-103",
            "BLOADSHED-104"
          ],
          "scenario": "One large tenant fills every waiting slot and blocks smaller tenants.",
          "acceptanceCriteria": [
            "Bound per-tenant queued work.",
            "Define a transparent scheduling policy.",
            "Prevent idle tenant allocation from wasting all spare capacity."
          ],
          "implementationNotes": [
            "Use synthetic tenant classes and document fairness assumptions."
          ],
          "verification": [
            "Serve concurrent tenants under sustained load.",
            "Flood one tenant and verify others retain declared progress."
          ],
          "deliverables": [
            "Tenant scheduling policy."
          ],
          "rollout": "Trial with fixed limits; disable new policy if starvation appears.",
          "skills": [
            "Fair scheduling"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "76ed83f9-7374-42b7-a7af-3a20f2d974af",
          "key": "BLOADSHED-108",
          "title": "Compare rejection policies under the same offered workload",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "validate",
          "dependsOn": [
            "BLOADSHED-102",
            "BLOADSHED-105",
            "BLOADSHED-106",
            "BLOADSHED-107"
          ],
          "scenario": "The team must choose between a larger queue and earlier rejection.",
          "acceptanceCriteria": [
            "Compare identical arrival traces and resource budgets.",
            "Measure essential latency, rejection, completion, and recovery separately.",
            "Explain tradeoffs and remaining uncertainty."
          ],
          "implementationNotes": [
            "Do not compare only successful-response latency or hide rejected work."
          ],
          "verification": [
            "Run both policies on the same synthetic burst.",
            "Expose a policy that improves accepted latency by rejecting more work."
          ],
          "deliverables": [
            "Admission policy assessment."
          ],
          "rollout": "Choose a bounded default and retain a tested configuration rollback.",
          "skills": [
            "Performance analysis",
            "Reliability tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c4a36bc6-fc26-422a-9956-d47831944dd9",
          "key": "BLOADSHED-109",
          "title": "Prevent capacity oscillation when the burst ends",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "validate",
          "dependsOn": [
            "BLOADSHED-108"
          ],
          "scenario": "Degradation switches on and off rapidly near the threshold.",
          "acceptanceCriteria": [
            "Add declared hysteresis or cooldown semantics.",
            "Return to normal after sustained recovery.",
            "Keep manual emergency controls auditable."
          ],
          "implementationNotes": [
            "Avoid permanent degradation after transient overload."
          ],
          "verification": [
            "Recover after a controlled burst.",
            "Oscillate near thresholds and verify bounded mode changes."
          ],
          "deliverables": [
            "Recovery controller tests."
          ],
          "rollout": "Run in observation mode first; allow a safe fixed-policy fallback.",
          "skills": [
            "Control systems"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1000c007-b937-4b0b-8386-552d023d17d5",
          "key": "BLOADSHED-110",
          "title": "Document the customer-visible degraded service contract",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "validate",
          "dependsOn": [
            "BLOADSHED-109"
          ],
          "scenario": "Product support cannot explain which features disappear during overload.",
          "acceptanceCriteria": [
            "List omitted features and explicit failures.",
            "Describe recovery indicators without promising exact times.",
            "Include support diagnosis from safe metrics."
          ],
          "implementationNotes": [
            "No false success when essential work was rejected."
          ],
          "verification": [
            "Review a degraded response against the guide.",
            "Verify a failed reservation is never described as completed."
          ],
          "deliverables": [
            "Degradation guide."
          ],
          "rollout": "Ship alongside controls and update it when request classes change.",
          "skills": [
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "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": []
        }
      ]
    },
    {
      "id": "2f2e66a5-cabc-4b08-b389-3e4ca4825dab",
      "key": "BCOST",
      "title": "Object-storage cost controls",
      "field": "Cloud infrastructure",
      "summary": "Make storage growth and transfer costs inspectable without compromising retained records.",
      "context": "A fictional analytics service stores exports and intermediate artifacts indefinitely. Finance sees a rising bill but engineers cannot explain which lifecycle policy is responsible.",
      "stack": [
        "TypeScript",
        "S3-compatible storage",
        "CSV"
      ],
      "prerequisites": [
        "Create synthetic object inventories and a local object-store double; author fictional unit prices as explicit assumptions."
      ],
      "developerValue": "Practice cost attribution, lifecycle modeling, and safe retention controls.",
      "companyValue": "Produce reviewable storage-cost options with recovery and data-retention consequences.",
      "delivery": "Deliver an offline cost model and local policy rehearsal; delete no real cloud objects.",
      "phases": [
        {
          "id": "inventory",
          "title": "Attribute storage",
          "goal": "Describe objects, ownership, and cost assumptions."
        },
        {
          "id": "control",
          "title": "Model lifecycle changes",
          "goal": "Evaluate retention and transfer controls safely."
        },
        {
          "id": "review",
          "title": "Review savings proposals",
          "goal": "Compare options and expose uncertainty."
        }
      ],
      "tickets": [
        {
          "id": "8ffb3566-63c9-4e68-a67f-cfb1406692bb",
          "key": "BCOST-101",
          "title": "Normalize object inventory units and ownership labels",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "inventory",
          "dependsOn": [],
          "scenario": "Inventory exports mix byte counts, rounded sizes, and missing owners.",
          "acceptanceCriteria": [
            "Use bytes as the canonical size unit.",
            "Separate unknown owners from shared infrastructure.",
            "Preserve inventory time and source identity."
          ],
          "implementationNotes": [
            "Use synthetic names without customer identifiers."
          ],
          "verification": [
            "Normalize mixed display units accurately.",
            "Reject negative sizes and report missing ownership."
          ],
          "deliverables": [
            "Inventory parser."
          ],
          "rollout": "Run read-only attribution before proposing lifecycle changes.",
          "skills": [
            "Data normalization"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ed66d2df-c232-4173-ac0c-e1a69d36e525",
          "key": "BCOST-102",
          "title": "Model storage, requests, and transfer costs separately",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "inventory",
          "dependsOn": [
            "BCOST-101"
          ],
          "scenario": "A storage-only estimate ignores the cost of regenerating and downloading exports.",
          "acceptanceCriteria": [
            "Version explicit fictional unit-price assumptions.",
            "Calculate each cost component separately.",
            "Show unknown request or transfer volume."
          ],
          "implementationNotes": [
            "Do not present modeled savings as observed billing results."
          ],
          "verification": [
            "Reconcile a hand-calculated synthetic example.",
            "Refuse a total when a required unit conversion is ambiguous."
          ],
          "deliverables": [
            "Offline cost calculator."
          ],
          "rollout": "Keep original assumptions with every report.",
          "skills": [
            "Cost modeling"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "fe92ac53-95bb-4418-b74a-0e8676787b54",
          "key": "BCOST-103",
          "title": "Classify objects by recovery and retention requirements",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "control",
          "dependsOn": [
            "BCOST-101"
          ],
          "scenario": "A broad expiry rule would remove the only copy of finalized reports.",
          "acceptanceCriteria": [
            "Distinguish authoritative, reproducible, and temporary objects.",
            "Attach minimum retention and recovery requirements.",
            "Block lifecycle proposals for unclassified objects."
          ],
          "implementationNotes": [
            "Retention requirements are scenario inputs, not legal advice."
          ],
          "verification": [
            "Allow expiry of a declared temporary object.",
            "Block deletion of an authoritative unclassified report."
          ],
          "deliverables": [
            "Object lifecycle classification."
          ],
          "rollout": "Start with temporary classes only; preserve unknown objects.",
          "skills": [
            "Data lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "74f448e4-1a40-4ef2-a781-5df103e310a8",
          "key": "BCOST-104",
          "title": "Simulate lifecycle transitions before object deletion",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "BCOST-103"
          ],
          "scenario": "Operators cannot see which objects a new rule would affect.",
          "acceptanceCriteria": [
            "Produce a dry-run object set and byte total.",
            "Bind the plan to inventory and policy digests.",
            "Reject execution if the reviewed plan is stale."
          ],
          "implementationNotes": [
            "The exercise uses only a disposable local object store."
          ],
          "verification": [
            "Preview an eligible temporary set.",
            "Change policy inputs and reject the stale plan."
          ],
          "deliverables": [
            "Lifecycle dry-run planner."
          ],
          "rollout": "Require review of the exact plan; keep deletion disabled by default.",
          "skills": [
            "Change safety",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7ccebcaf-4884-48ce-b6c8-9c5a8c2e592c",
          "key": "BCOST-105",
          "title": "Account for retrieval delay in colder storage proposals",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "control",
          "dependsOn": [
            "BCOST-102",
            "BCOST-103"
          ],
          "scenario": "A cheaper storage tier may violate the reporting team's recovery expectations.",
          "acceptanceCriteria": [
            "Model retrieval time and per-request charges explicitly.",
            "Compare ordinary access and restore scenarios.",
            "Exclude objects whose declared recovery target is incompatible."
          ],
          "implementationNotes": [
            "Use simulated tier behavior and labeled assumptions."
          ],
          "verification": [
            "Compare two fictional tier policies.",
            "Reject a cheap option that misses the recovery requirement."
          ],
          "deliverables": [
            "Tier tradeoff report."
          ],
          "rollout": "Pilot only reproducible artifacts with a tested restore path.",
          "skills": [
            "Cloud economics",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "21766ec3-6407-476b-b32b-2ede6c058380",
          "key": "BCOST-106",
          "title": "Bound export retention per tenant without crossing ownership",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "control",
          "dependsOn": [
            "BCOST-104"
          ],
          "scenario": "One tenant's cleanup job selects similarly named exports belonging to another.",
          "acceptanceCriteria": [
            "Scope inventory and policy evaluation by tenant identity.",
            "Use opaque object references rather than name prefixes alone.",
            "Audit planned and completed cleanup identities."
          ],
          "implementationNotes": [
            "Repository boundaries must enforce scope."
          ],
          "verification": [
            "Expire eligible exports for one tenant.",
            "Attempt cross-tenant cleanup and verify denial."
          ],
          "deliverables": [
            "Scoped retention evaluator."
          ],
          "rollout": "Trial on one synthetic tenant; stop on inventory discrepancies.",
          "skills": [
            "Authorization",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3230ee07-e9a3-4309-a026-54745bf9b181",
          "key": "BCOST-107",
          "title": "Reduce repeated downloads with integrity-aware caching",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "BCOST-102"
          ],
          "scenario": "Unchanged exports are repeatedly transferred because clients cannot validate their cache.",
          "acceptanceCriteria": [
            "Expose stable content validators for immutable exports.",
            "Honor conditional reads correctly.",
            "Invalidate cached authority when access is revoked."
          ],
          "implementationNotes": [
            "A content digest is not an access credential."
          ],
          "verification": [
            "Return unchanged status for an authorized matching validator.",
            "Deny a revoked client despite its cached validator."
          ],
          "deliverables": [
            "Conditional-download contract."
          ],
          "rollout": "Enable for immutable exports first; retain full-download fallback.",
          "skills": [
            "HTTP caching",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4cd1c3f0-0d09-4564-abdc-422e7832c9bc",
          "key": "BCOST-108",
          "title": "Compare retention changes against rebuild workload and budget",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "review",
          "dependsOn": [
            "BCOST-105",
            "BCOST-106",
            "BCOST-107"
          ],
          "scenario": "Deleting intermediate files saves storage but may shift cost into repeated computation.",
          "acceptanceCriteria": [
            "Model storage, rebuild, transfer, and operational effort together.",
            "Run bounded local rebuild measurements with declared inputs.",
            "Show uncertainty ranges and excluded costs."
          ],
          "implementationNotes": [
            "No claim of real bill reduction from synthetic data."
          ],
          "verification": [
            "Compare a retained and regenerated artifact policy.",
            "Expose the case where regeneration costs more."
          ],
          "deliverables": [
            "Cost-control decision record."
          ],
          "rollout": "Choose a reversible policy for reproducible data; preserve authoritative copies.",
          "skills": [
            "Tradeoff analysis",
            "FinOps"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "00feb5e4-5a7e-4003-87d2-0391784933e4",
          "key": "BCOST-109",
          "title": "Add budget alerts that distinguish actual and forecast usage",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "review",
          "dependsOn": [
            "BCOST-108"
          ],
          "scenario": "A forecast estimate appears in the same chart as already-incurred usage.",
          "acceptanceCriteria": [
            "Label measured inventory cost and forecast separately.",
            "Define alert thresholds and data freshness.",
            "Avoid duplicate alerts for one reporting window."
          ],
          "implementationNotes": [
            "Alerts remain local outputs; send no external notifications."
          ],
          "verification": [
            "Trigger a synthetic budget threshold.",
            "Show stale inventory as uncertain instead of a current total."
          ],
          "deliverables": [
            "Budget alert fixtures."
          ],
          "rollout": "Run advisory reports before operational notification wiring.",
          "skills": [
            "Observability",
            "Cost controls"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4ad505bc-1447-4556-a6f5-a7f2cf9a645b",
          "key": "BCOST-110",
          "title": "Document restoration before approving local expiry rules",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "review",
          "dependsOn": [
            "BCOST-109"
          ],
          "scenario": "Cleanup reviewers need to understand which deleted artifacts can be recreated.",
          "acceptanceCriteria": [
            "Identify rebuild inputs and commands.",
            "State unrecoverable classes explicitly.",
            "Include the latest dry-run plan identity."
          ],
          "implementationNotes": [
            "Do not promise recovery without retained inputs."
          ],
          "verification": [
            "Rebuild an expired synthetic intermediate artifact.",
            "Reject expiry when required rebuild inputs are absent."
          ],
          "deliverables": [
            "Retention review checklist."
          ],
          "rollout": "Attach to policy proposals and re-review after input changes.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "6fc97ff2-68bb-400a-a79a-fac5daeb1bd8",
      "key": "BIAC",
      "title": "Reviewable infrastructure plan pipeline",
      "field": "Cloud infrastructure",
      "summary": "Validate infrastructure changes as bounded plans with drift and recovery context.",
      "context": "A fictional application team manages a small database, cache, and object store. Reviewers struggle to distinguish harmless configuration changes from destructive replacements.",
      "stack": [
        "TypeScript",
        "Terraform plan JSON",
        "Policy fixtures"
      ],
      "prerequisites": [
        "Author synthetic infrastructure plans and state snapshots; use local files only and no cloud credentials."
      ],
      "developerValue": "Practice infrastructure risk analysis, plan integrity, and least-privilege change workflows.",
      "companyValue": "Give infrastructure reviewers concrete change scope and recovery consequences.",
      "delivery": "Deliver an offline plan-review tool and synthetic workflow; provision nothing externally.",
      "phases": [
        {
          "id": "parse",
          "title": "Parse plan authority",
          "goal": "Normalize resource actions and unknown values."
        },
        {
          "id": "review",
          "title": "Review risk",
          "goal": "Surface destructive changes and policy failures."
        },
        {
          "id": "apply",
          "title": "Bind execution intent",
          "goal": "Verify freshness, ownership, and recovery information."
        }
      ],
      "tickets": [
        {
          "id": "f9be7500-9325-4b6e-82c8-9697acd44d67",
          "key": "BIAC-101",
          "title": "Normalize infrastructure resource actions for review",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "parse",
          "dependsOn": [],
          "scenario": "Review summaries collapse updates and replacements into one change count.",
          "acceptanceCriteria": [
            "Separate create, update, replace, and delete actions.",
            "Preserve resource addresses and dependencies.",
            "Represent unknown values explicitly."
          ],
          "implementationNotes": [
            "Treat plan JSON as untrusted data."
          ],
          "verification": [
            "Parse a valid mixed-action plan.",
            "Reject malformed action combinations."
          ],
          "deliverables": [
            "Plan action model."
          ],
          "rollout": "Adopt read-only summaries before any execution integration.",
          "skills": [
            "Infrastructure analysis"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "779ee956-1f16-4366-bca3-08797bff0f55",
          "key": "BIAC-102",
          "title": "Redact sensitive plan values while preserving review context",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "parse",
          "dependsOn": [
            "BIAC-101"
          ],
          "scenario": "A database password appears in a generated review report.",
          "acceptanceCriteria": [
            "Honor sensitive markers recursively.",
            "Remove seeded secret values from report and errors.",
            "Keep resource identity and action visible."
          ],
          "implementationNotes": [
            "Unknown nested formats must fail safely."
          ],
          "verification": [
            "Review a non-sensitive change.",
            "Seed secrets in nested arrays and verify redaction."
          ],
          "deliverables": [
            "Plan redaction boundary."
          ],
          "rollout": "Block report publication if redaction validation fails.",
          "skills": [
            "Data protection"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "94bd55f6-2cef-4ff7-b1a9-6f8730e71143",
          "key": "BIAC-103",
          "title": "Flag replacements of persistent resources with recovery requirements",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "review",
          "dependsOn": [
            "BIAC-101",
            "BIAC-102"
          ],
          "scenario": "A small naming change replaces the database resource.",
          "acceptanceCriteria": [
            "Identify persistent resource replacements.",
            "Require declared backup and restore context.",
            "Show dependent application impact."
          ],
          "implementationNotes": [
            "Do not infer that a snapshot policy proves restorability."
          ],
          "verification": [
            "Flag a synthetic database replacement.",
            "Allow a stateless replacement with its distinct risk classification."
          ],
          "deliverables": [
            "Replacement risk rule."
          ],
          "rollout": "Require review before any persistent-resource execution path.",
          "skills": [
            "Change risk"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "b80bdc5a-27a9-4668-81af-fd820d07cd8b",
          "key": "BIAC-104",
          "title": "Reject public exposure introduced by default configuration",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "review",
          "dependsOn": [
            "BIAC-102"
          ],
          "scenario": "An omitted access setting turns a private storage resource public.",
          "acceptanceCriteria": [
            "Evaluate effective exposure including defaults.",
            "Identify the exact field causing exposure.",
            "Keep unknown defaults unresolved."
          ],
          "implementationNotes": [
            "Use explicit provider-schema fixtures rather than live provider assumptions."
          ],
          "verification": [
            "Detect a public-access transition.",
            "Keep unknown provider behavior blocked for review."
          ],
          "deliverables": [
            "Exposure policy check."
          ],
          "rollout": "Start with the modeled resource types; reject unsupported exposure analysis.",
          "skills": [
            "Cloud security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0d746fc5-48d7-433a-94cc-561872e7ea3b",
          "key": "BIAC-105",
          "title": "Validate backup retention changes against declared recovery policy",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "review",
          "dependsOn": [
            "BIAC-103"
          ],
          "scenario": "A retention reduction removes the recovery window the application team relies on.",
          "acceptanceCriteria": [
            "Compare proposed retention with the scenario requirement.",
            "Account for deletion of old backup generations.",
            "Require an explanation for incompatible changes."
          ],
          "implementationNotes": [
            "Policy requirements are explicit inputs."
          ],
          "verification": [
            "Accept a compatible retention update.",
            "Flag a shorter recovery window and missing policy."
          ],
          "deliverables": [
            "Retention plan rule."
          ],
          "rollout": "Review changes alongside the restore rehearsal record.",
          "skills": [
            "Recovery policy"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "238c088a-de04-4857-b972-0742a0e88733",
          "key": "BIAC-106",
          "title": "Detect plan drift between review and execution",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "apply",
          "dependsOn": [
            "BIAC-104",
            "BIAC-105"
          ],
          "scenario": "A plan is reviewed, then regenerated with additional deletions before execution.",
          "acceptanceCriteria": [
            "Bind approval intent to plan digest and target identity.",
            "Check state serial and configuration revision.",
            "Reject modified or stale plans."
          ],
          "implementationNotes": [
            "No actual cloud apply is performed in this exercise."
          ],
          "verification": [
            "Accept an unchanged synthetic reviewed plan.",
            "Change one action and reject the execution intent."
          ],
          "deliverables": [
            "Plan binding verifier."
          ],
          "rollout": "Require regeneration and review on drift; preserve prior plan artifacts.",
          "skills": [
            "Integrity",
            "Change control"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7eea29b1-f2ae-419b-910e-5a21db689301",
          "key": "BIAC-107",
          "title": "Keep infrastructure workspace identities from crossing environments",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "apply",
          "dependsOn": [
            "BIAC-106"
          ],
          "scenario": "A staging plan is accidentally paired with production target metadata.",
          "acceptanceCriteria": [
            "Bind workspace, account class, and resource namespace.",
            "Reject mixed-environment inputs.",
            "Show sanitized target context in the review summary."
          ],
          "implementationNotes": [
            "Use fictional account identities and no credentials."
          ],
          "verification": [
            "Verify a matching staging plan.",
            "Reject a production identity substituted after review."
          ],
          "deliverables": [
            "Environment binding guard."
          ],
          "rollout": "Fail closed on ambiguous identity.",
          "skills": [
            "Configuration",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e6c0a5bb-8028-47ba-8083-65d44e360210",
          "key": "BIAC-108",
          "title": "Model partial apply recovery without assuming atomic infrastructure changes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "apply",
          "dependsOn": [
            "BIAC-103",
            "BIAC-106",
            "BIAC-107"
          ],
          "scenario": "A plan contains several resource updates, and the third may fail after earlier changes succeed.",
          "acceptanceCriteria": [
            "Identify dependency-ordered partial states.",
            "Compare forward repair and rollback per resource.",
            "Preserve completed changes in the recovery record."
          ],
          "implementationNotes": [
            "Do not present infrastructure apply as one database transaction."
          ],
          "verification": [
            "Simulate failure after two accepted changes.",
            "Reject a rollback that would delete newly authoritative data."
          ],
          "deliverables": [
            "Partial-apply recovery decision record."
          ],
          "rollout": "Keep execution hypothetical until target-specific recovery is verified.",
          "skills": [
            "Infrastructure design",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a941bf32-2501-4121-8322-10d60662a653",
          "key": "BIAC-109",
          "title": "Generate an infrastructure change summary for application owners",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "apply",
          "dependsOn": [
            "BIAC-108"
          ],
          "scenario": "Application owners cannot determine whether a plan changes endpoints or causes downtime.",
          "acceptanceCriteria": [
            "Summarize connectivity, storage, and availability impacts.",
            "Link impacts to exact resource actions.",
            "List unresolved values and required follow-up."
          ],
          "implementationNotes": [
            "Do not hide unresolved risks behind an overall green status."
          ],
          "verification": [
            "Explain a cache replacement and endpoint change.",
            "Show unknown replacement timing explicitly."
          ],
          "deliverables": [
            "Owner review report."
          ],
          "rollout": "Attach reports to the exact plan digest.",
          "skills": [
            "Technical communication"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2cd68dc6-d2a7-413c-abae-fedfc6319856",
          "key": "BIAC-110",
          "title": "Document how to retire a policy exception",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "apply",
          "dependsOn": [
            "BIAC-109"
          ],
          "scenario": "A temporary public-access exception remains active after the migration finishes.",
          "acceptanceCriteria": [
            "Require owner, scope, reason, and expiry.",
            "Reject expired or wildcard exceptions.",
            "Preserve exception history after retirement."
          ],
          "implementationNotes": [
            "Exceptions cannot bypass plan identity checks."
          ],
          "verification": [
            "Retire a scoped synthetic exception.",
            "Verify an expired exception blocks the next plan."
          ],
          "deliverables": [
            "Exception lifecycle guide."
          ],
          "rollout": "Inventory exceptions before enabling enforcement.",
          "skills": [
            "Policy governance"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "50db3076-1599-4748-a194-24385125bd18",
      "key": "BIDENT",
      "title": "Workload identity credential rotation",
      "field": "Cloud infrastructure",
      "summary": "Replace static service credentials with bounded workload identity and tested rotation.",
      "context": "A fictional export worker shares a long-lived object-store credential across environments. The team needs a provider-neutral identity boundary with safe expiry and revocation.",
      "stack": [
        "TypeScript",
        "JWT",
        "HTTP"
      ],
      "prerequisites": [
        "Create a local identity issuer and object-store double using generated test-only keys; no cloud account or production secret."
      ],
      "developerValue": "Practice workload identity, audience restrictions, and credential lifecycle failures.",
      "companyValue": "Produce a migration path that narrows credential scope and makes revocation observable.",
      "delivery": "Deliver local identity contracts and rotation rehearsals; deploy no live trust policy.",
      "phases": [
        {
          "id": "trust",
          "title": "Define trust scope",
          "goal": "Bind identities to workloads and resources."
        },
        {
          "id": "issue",
          "title": "Issue bounded credentials",
          "goal": "Validate tokens, caching, and provider failures."
        },
        {
          "id": "rotate",
          "title": "Rehearse lifecycle changes",
          "goal": "Test rotation, revocation, and migration recovery."
        }
      ],
      "tickets": [
        {
          "id": "c7f2bad1-0743-456d-a2c5-4e82aaac6cb5",
          "key": "BIDENT-101",
          "title": "Inventory the export worker's required storage operations",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "trust",
          "dependsOn": [],
          "scenario": "The worker credential permits listing and deleting unrelated storage objects.",
          "acceptanceCriteria": [
            "List operations required for one export lifecycle.",
            "Separate read, write, and cleanup authority.",
            "Identify unnecessary permissions."
          ],
          "implementationNotes": [
            "Use synthetic object namespaces."
          ],
          "verification": [
            "Complete an export with the proposed operation list.",
            "Deny an unrelated bucket-list request."
          ],
          "deliverables": [
            "Least-privilege operation matrix."
          ],
          "rollout": "Review scope before issuing replacement credentials.",
          "skills": [
            "Least privilege"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "af570982-1105-44dd-a380-218d881572fc",
          "key": "BIDENT-102",
          "title": "Bind workload assertions to issuer, audience, and environment",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "trust",
          "dependsOn": [
            "BIDENT-101"
          ],
          "scenario": "A staging assertion is accepted by the production-class storage adapter.",
          "acceptanceCriteria": [
            "Validate issuer and exact audience.",
            "Bind workload and environment identity.",
            "Reject unknown signing keys and algorithms."
          ],
          "implementationNotes": [
            "Use generated local test keys only."
          ],
          "verification": [
            "Accept a matching assertion.",
            "Reject wrong audience, environment, and algorithm fixtures."
          ],
          "deliverables": [
            "Assertion verifier."
          ],
          "rollout": "Fail closed on unresolved trust configuration.",
          "skills": [
            "Identity",
            "JWT validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4f8c4481-3463-4cfe-acd5-2f46b99b7b8e",
          "key": "BIDENT-103",
          "title": "Issue short-lived storage grants with exact resource scope",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "issue",
          "dependsOn": [
            "BIDENT-102"
          ],
          "scenario": "A workload token grants access to every export instead of one operation.",
          "acceptanceCriteria": [
            "Bind grant to resource and allowed operation.",
            "Enforce expiry and unique grant identity.",
            "Prevent the caller from widening scope."
          ],
          "implementationNotes": [
            "Grant fields derive from authorized server state."
          ],
          "verification": [
            "Write the intended synthetic export.",
            "Reject a different resource or operation under the same grant."
          ],
          "deliverables": [
            "Scoped grant issuer."
          ],
          "rollout": "Start with one export path; retain no broad fallback credential.",
          "skills": [
            "Capability security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "71a2e5c5-3277-4e99-8d55-70bb8745db26",
          "key": "BIDENT-104",
          "title": "Refresh credentials before expiry without creating a refresh storm",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "issue",
          "dependsOn": [
            "BIDENT-103"
          ],
          "scenario": "Every concurrent request refreshes the same expiring credential.",
          "acceptanceCriteria": [
            "Coalesce equivalent in-flight refreshes.",
            "Refresh within a declared bounded window.",
            "Avoid caching failed or mismatched grants."
          ],
          "implementationNotes": [
            "Cache keys include workload, resource scope, and audience."
          ],
          "verification": [
            "Share one refresh across concurrent requests.",
            "Reject cross-scope cache reuse and retry a failed refresh safely."
          ],
          "deliverables": [
            "Credential cache."
          ],
          "rollout": "Use short cache lifetimes; clear affected entries on validation failure.",
          "skills": [
            "Caching",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b6c477ce-4f97-4b08-8632-c8db10b3a388",
          "key": "BIDENT-105",
          "title": "Keep clock skew from extending grant lifetime indefinitely",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "issue",
          "dependsOn": [
            "BIDENT-102",
            "BIDENT-104"
          ],
          "scenario": "A large token leeway makes expired credentials valid far longer than intended.",
          "acceptanceCriteria": [
            "Bound allowed skew explicitly.",
            "Reject impossible issue and expiry ordering.",
            "Report clock-related failures without token contents."
          ],
          "implementationNotes": [
            "Use an injected clock for deterministic checks."
          ],
          "verification": [
            "Accept a token inside the declared skew window.",
            "Reject expired and future-issued tokens beyond the bound."
          ],
          "deliverables": [
            "Expiry boundary tests."
          ],
          "rollout": "Deploy with monitored clock assumptions; stop issuance if time authority is unavailable.",
          "skills": [
            "Time validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "dae1fb6d-0ebc-42c8-a091-8036f26cd552",
          "key": "BIDENT-106",
          "title": "Prevent identity-provider outages from selecting static credentials",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "issue",
          "dependsOn": [
            "BIDENT-104",
            "BIDENT-105"
          ],
          "scenario": "The adapter silently falls back to an old environment secret when token refresh fails.",
          "acceptanceCriteria": [
            "Remove implicit static fallback.",
            "Return a bounded unavailable state.",
            "Allow only already-valid scoped grants until expiry."
          ],
          "implementationNotes": [
            "Never log credentials in failure diagnostics."
          ],
          "verification": [
            "Continue with a valid unexpired grant.",
            "Fail closed after expiry during issuer outage."
          ],
          "deliverables": [
            "Provider failure behavior."
          ],
          "rollout": "Disable issuance cleanly on outage; restore only after trust validation succeeds.",
          "skills": [
            "Fail-closed design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5a0aa8bc-d126-4688-b148-cc9e8fb8cdd9",
          "key": "BIDENT-107",
          "title": "Rotate signing keys with a bounded overlap window",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rotate",
          "dependsOn": [
            "BIDENT-105",
            "BIDENT-106"
          ],
          "scenario": "Immediate key replacement breaks in-flight exports while indefinite overlap preserves old authority.",
          "acceptanceCriteria": [
            "Publish new verification key before issuance switches.",
            "Bound old-key acceptance by policy and token expiry.",
            "Reject retired keys after the overlap."
          ],
          "implementationNotes": [
            "Private keys remain test-only runtime inputs."
          ],
          "verification": [
            "Complete an in-flight old-key export during overlap.",
            "Reject an old-key token after retirement."
          ],
          "deliverables": [
            "Key rotation rehearsal."
          ],
          "rollout": "Retain the previous public verifier only for the declared overlap.",
          "skills": [
            "Key lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "88af240a-4f1c-4a52-a7f6-9965d2c1e668",
          "key": "BIDENT-108",
          "title": "Revoke one workload without disrupting unrelated exporters",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "rotate",
          "dependsOn": [
            "BIDENT-107"
          ],
          "scenario": "A broad emergency revocation stops every export worker.",
          "acceptanceCriteria": [
            "Scope revocation to workload identity and grant class.",
            "Check revocation before accepting cached authority.",
            "Preserve unrelated authorized workloads."
          ],
          "implementationNotes": [
            "Privileged revocations require append-only audit metadata."
          ],
          "verification": [
            "Revoke one synthetic worker.",
            "Verify its cached grant fails while another worker succeeds."
          ],
          "deliverables": [
            "Scoped revocation behavior."
          ],
          "rollout": "Test revocation before replacing the static credential path.",
          "skills": [
            "Revocation",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c7952c01-6962-42cc-b58f-4aa985ed344e",
          "key": "BIDENT-109",
          "title": "Design the static-to-workload identity cutover",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "rotate",
          "dependsOn": [
            "BIDENT-106",
            "BIDENT-108"
          ],
          "scenario": "The team must migrate without leaving a forgotten permanent credential active.",
          "acceptanceCriteria": [
            "Inventory callers and staged cutover order.",
            "Define proof that no caller requires the old credential.",
            "Compare rollback availability against retained-secret risk."
          ],
          "implementationNotes": [
            "Do not restore broad credentials automatically on failure."
          ],
          "verification": [
            "Migrate two synthetic callers and revoke the old key.",
            "Detect a forgotten caller before declaring the migration complete."
          ],
          "deliverables": [
            "Identity migration decision record."
          ],
          "rollout": "Use a reviewed emergency path; retire the static key after verified caller migration.",
          "skills": [
            "Migration design",
            "Security tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "221f8b0f-4f32-44a2-a702-bf8cfb374847",
          "key": "BIDENT-110",
          "title": "Write credential-failure diagnostics without secret exposure",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "rotate",
          "dependsOn": [
            "BIDENT-109"
          ],
          "scenario": "Operators need to distinguish expiry, audience mismatch, and issuer failure.",
          "acceptanceCriteria": [
            "Define safe failure categories and request IDs.",
            "Document scoped recovery actions.",
            "Exclude tokens, private keys, and authorization headers."
          ],
          "implementationNotes": [
            "Use synthetic secret markers in verification."
          ],
          "verification": [
            "Diagnose an expired grant from safe metadata.",
            "Verify no seeded secret appears in logs or reports."
          ],
          "deliverables": [
            "Identity support runbook."
          ],
          "rollout": "Publish with the adapter and recheck after logging changes.",
          "skills": [
            "Operational security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "00bdbc24-f9ef-4819-b10c-5161124ff0a8",
      "key": "BARTIF",
      "title": "Artifact registry promotion controls",
      "field": "Cloud infrastructure",
      "summary": "Promote immutable application artifacts through environments with inspectable provenance.",
      "context": "A fictional application team deploys mutable image tags and cannot reliably identify the artifact running during an incident.",
      "stack": [
        "TypeScript",
        "OCI metadata",
        "JSON"
      ],
      "prerequisites": [
        "Author synthetic artifact manifests and a local registry double; do not pull or execute untrusted images."
      ],
      "developerValue": "Practice artifact identity, promotion policies, and release provenance.",
      "companyValue": "Provide reproducible deployments and a clear path to withdraw defective artifacts.",
      "delivery": "Deliver offline promotion checks and local registry-state rehearsals; perform no real deployment.",
      "phases": [
        {
          "id": "identify",
          "title": "Identify immutable artifacts",
          "goal": "Capture build identity and provenance."
        },
        {
          "id": "promote",
          "title": "Control promotion",
          "goal": "Validate artifact readiness and environment bindings."
        },
        {
          "id": "recover",
          "title": "Recover releases",
          "goal": "Handle withdrawal, retention, and rollback."
        }
      ],
      "tickets": [
        {
          "id": "afc5fb7f-1c66-49c4-8dcf-24065dace5a5",
          "key": "BARTIF-101",
          "title": "Resolve deployment references to immutable artifact digests",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "identify",
          "dependsOn": [],
          "scenario": "The same release tag points to different bytes across environments.",
          "acceptanceCriteria": [
            "Store the resolved digest with each deployment intent.",
            "Preserve the human-readable tag as metadata.",
            "Reject missing or ambiguous digest resolution."
          ],
          "implementationNotes": [
            "Synthetic registry manifests are sufficient."
          ],
          "verification": [
            "Resolve a stable release reference.",
            "Move its tag and detect changed identity."
          ],
          "deliverables": [
            "Artifact identity model."
          ],
          "rollout": "Introduce digest recording before enforcing immutable references.",
          "skills": [
            "Artifact integrity"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fb479c12-9758-4023-a872-41832a45c1ab",
          "key": "BARTIF-102",
          "title": "Record build inputs without exposing build secrets",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "identify",
          "dependsOn": [
            "BARTIF-101"
          ],
          "scenario": "Provenance output includes all build environment variables.",
          "acceptanceCriteria": [
            "Record source revision, builder version, and declared inputs.",
            "Exclude secrets and workstation paths.",
            "Bind provenance to the exact artifact digest."
          ],
          "implementationNotes": [
            "Use allowlisted metadata rather than environment dumps."
          ],
          "verification": [
            "Verify a complete synthetic provenance record.",
            "Reject mismatched digest and detect seeded secret leakage."
          ],
          "deliverables": [
            "Provenance manifest."
          ],
          "rollout": "Block promotion when required provenance is missing.",
          "skills": [
            "Supply-chain integrity"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6c73e81d-5b12-4648-bac1-fb23d9d85d85",
          "key": "BARTIF-103",
          "title": "Reject promotion of artifacts with unresolved policy findings",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "promote",
          "dependsOn": [
            "BARTIF-102"
          ],
          "scenario": "A failed scan is treated like a scan with no findings.",
          "acceptanceCriteria": [
            "Distinguish passed, failed, missing, and stale checks.",
            "Bind check results to artifact and policy versions.",
            "Keep unresolved required checks blocking."
          ],
          "implementationNotes": [
            "Fixture scan results are not real vulnerability evidence."
          ],
          "verification": [
            "Promote a fixture with complete checks.",
            "Reject unavailable or stale check results."
          ],
          "deliverables": [
            "Promotion policy evaluator."
          ],
          "rollout": "Run advisory comparisons before enforcement.",
          "skills": [
            "Policy design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9fd22540-dd63-4243-b1bf-bdfb6e58cdbe",
          "key": "BARTIF-104",
          "title": "Keep environment-specific settings outside immutable application bytes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "promote",
          "dependsOn": [
            "BARTIF-101",
            "BARTIF-102"
          ],
          "scenario": "The team rebuilds the same release for staging and production, making tested bytes differ from deployed bytes.",
          "acceptanceCriteria": [
            "Use one application digest across modeled environments.",
            "Bind runtime configuration separately.",
            "Validate required configuration without embedding secrets."
          ],
          "implementationNotes": [
            "No actual cloud deployment is required."
          ],
          "verification": [
            "Promote the same digest through two synthetic environments.",
            "Reject a configuration missing a required setting."
          ],
          "deliverables": [
            "Artifact/configuration boundary."
          ],
          "rollout": "Adopt on one service; retain previous configuration versions for recovery.",
          "skills": [
            "Deployment design"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e377cc12-827d-49ad-ad20-c53b94ab69a0",
          "key": "BARTIF-105",
          "title": "Bind a promotion decision to current environment state",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "promote",
          "dependsOn": [
            "BARTIF-103",
            "BARTIF-104"
          ],
          "scenario": "Two simultaneous promotion requests overwrite each other's intended release.",
          "acceptanceCriteria": [
            "Require expected environment revision.",
            "Record one accepted transition atomically.",
            "Reject stale decisions without changing active identity."
          ],
          "implementationNotes": [
            "Use a local state store and explicit transition methods."
          ],
          "verification": [
            "Promote against the current revision.",
            "Race two decisions and verify one conflict."
          ],
          "deliverables": [
            "Optimistic promotion workflow."
          ],
          "rollout": "Start with serialized local promotion; preserve every prior revision.",
          "skills": [
            "Concurrency",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0b36aede-a446-4955-b80f-e28a82bc3ea4",
          "key": "BARTIF-106",
          "title": "Handle registry unavailability without changing artifact identity",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "promote",
          "dependsOn": [
            "BARTIF-105"
          ],
          "scenario": "A failed digest lookup falls back to the latest cached tag.",
          "acceptanceCriteria": [
            "Use cached data only for the exact verified digest.",
            "Return unavailable for unresolved references.",
            "Bound fetch retries and response size."
          ],
          "implementationNotes": [
            "Do not substitute another release during failure."
          ],
          "verification": [
            "Reuse a verified digest manifest.",
            "Fail tag resolution during outage without selecting latest."
          ],
          "deliverables": [
            "Registry failure handling."
          ],
          "rollout": "Keep current release running in the scenario; retry promotion explicitly.",
          "skills": [
            "Resilience",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4bca9e85-acd1-44bb-917b-fbb915e61bb0",
          "key": "BARTIF-107",
          "title": "Withdraw a defective artifact without deleting incident history",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "BARTIF-105"
          ],
          "scenario": "Deleting a bad image makes historical deployment records impossible to inspect.",
          "acceptanceCriteria": [
            "Mark the digest withdrawn with reason and actor.",
            "Block new promotion of withdrawn artifacts.",
            "Preserve manifests and prior deployment references."
          ],
          "implementationNotes": [
            "Withdrawal is append-only state, not evidence deletion."
          ],
          "verification": [
            "Withdraw a synthetic defective artifact.",
            "Reject new promotion while retaining historical reads."
          ],
          "deliverables": [
            "Artifact withdrawal workflow."
          ],
          "rollout": "Withdraw before cleanup; use a separate approved retention policy.",
          "skills": [
            "Lifecycle management"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "61ac0d80-9acb-46f3-9f5b-bad1a0e3cdd7",
          "key": "BARTIF-108",
          "title": "Protect rollback artifacts from registry retention cleanup",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "recover",
          "dependsOn": [
            "BARTIF-107"
          ],
          "scenario": "A cleanup job deletes the last known usable release.",
          "acceptanceCriteria": [
            "Retain artifacts referenced by active and rollback revisions.",
            "Evaluate cleanup from current authoritative references.",
            "Produce a dry-run deletion set."
          ],
          "implementationNotes": [
            "Use only local synthetic artifacts."
          ],
          "verification": [
            "Identify unreferenced eligible artifacts.",
            "Keep an older digest referenced by a rollback plan."
          ],
          "deliverables": [
            "Reference-aware retention policy."
          ],
          "rollout": "Run dry-run review before local deletion.",
          "skills": [
            "Retention",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7fb9c773-690c-497b-aefa-9d0be1446f71",
          "key": "BARTIF-109",
          "title": "Assess rollback compatibility beyond selecting an older digest",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "BARTIF-104",
            "BARTIF-108"
          ],
          "scenario": "An older image starts successfully but cannot read data written by the new release.",
          "acceptanceCriteria": [
            "Bind rollback candidates to schema and configuration compatibility.",
            "Rehearse representative read/write behavior locally.",
            "Compare rollback with forward repair when compatibility fails."
          ],
          "implementationNotes": [
            "Artifact availability alone does not prove recoverability."
          ],
          "verification": [
            "Restore a compatible synthetic release.",
            "Reject an incompatible candidate despite its valid digest."
          ],
          "deliverables": [
            "Rollback compatibility assessment."
          ],
          "rollout": "Keep compatible artifacts and configuration together; choose forward repair when required.",
          "skills": [
            "Release recovery",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9122ab79-876a-4f54-b86f-115a1623ad88",
          "key": "BARTIF-110",
          "title": "Write an artifact incident lookup guide",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "recover",
          "dependsOn": [
            "BARTIF-109"
          ],
          "scenario": "On-call staff need to identify source, checks, and prior release from one deployed digest.",
          "acceptanceCriteria": [
            "Show lookup from environment revision to artifact.",
            "Link provenance and policy results by identity.",
            "Document withdrawn and missing-artifact behavior."
          ],
          "implementationNotes": [
            "Do not include registry credentials in examples."
          ],
          "verification": [
            "Trace one synthetic deployment to source inputs.",
            "Handle a withdrawn artifact without losing history."
          ],
          "deliverables": [
            "Artifact investigation guide."
          ],
          "rollout": "Store with promotion tooling and update when manifest schema changes.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "a344edd4-0f2f-4cdb-af59-b7bd3bbc5c06",
      "key": "BENV",
      "title": "Ephemeral review-environment lifecycle",
      "field": "Cloud infrastructure",
      "summary": "Manage short-lived review environments with bounded resources and safe cleanup.",
      "context": "A fictional product team creates preview environments for pull requests. Forgotten environments accumulate cost, and shared test data leaks between reviews.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Infrastructure plan fixtures"
      ],
      "prerequisites": [
        "Author a local environment-provider double and synthetic pull-request events; provision no external resources."
      ],
      "developerValue": "Practice resource lifecycle state machines, isolation, and reconciliation.",
      "companyValue": "Make review environments predictable, isolated, and accountable to a budget.",
      "delivery": "Deliver a local lifecycle controller and cleanup rehearsal using simulated resource records.",
      "phases": [
        {
          "id": "model",
          "title": "Model environment ownership",
          "goal": "Define identity, scope, and resource limits."
        },
        {
          "id": "manage",
          "title": "Manage lifecycle",
          "goal": "Create, update, expire, and reconcile environments."
        },
        {
          "id": "operate",
          "title": "Operate within bounds",
          "goal": "Verify cleanup safety and cost controls."
        }
      ],
      "tickets": [
        {
          "id": "8f4a4b8a-7701-4a3c-a570-e20723f5b5c7",
          "key": "BENV-101",
          "title": "Define review-environment identity independently of branch names",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Renamed branches orphan their original preview resources.",
          "acceptanceCriteria": [
            "Use stable repository and change identities.",
            "Keep branch names as mutable labels.",
            "Record owner and expiry explicitly."
          ],
          "implementationNotes": [
            "Use fictional repositories and no real webhook subscription."
          ],
          "verification": [
            "Rename a synthetic branch without creating another environment.",
            "Reject conflicting repository identity reuse."
          ],
          "deliverables": [
            "Environment identity model."
          ],
          "rollout": "Adopt identity recording before resource creation.",
          "skills": [
            "Lifecycle modeling"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "05af66d5-b1f7-4b0d-a54b-5ad2e8bb5360",
          "key": "BENV-102",
          "title": "Set per-environment and per-team resource ceilings",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "model",
          "dependsOn": [
            "BENV-101"
          ],
          "scenario": "One team opens enough previews to exhaust the shared database quota.",
          "acceptanceCriteria": [
            "Declare resource units and budget limits.",
            "Reserve capacity before creation.",
            "Reject requests exceeding either ceiling."
          ],
          "implementationNotes": [
            "Provider resources are simulated records."
          ],
          "verification": [
            "Reserve an allowed preview.",
            "Race requests at the limit and prevent over-allocation."
          ],
          "deliverables": [
            "Quota reservation logic."
          ],
          "rollout": "Start with low fixture quotas; release reservations only through terminal lifecycle actions.",
          "skills": [
            "Quota management"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9ef38c04-c504-49da-8fb2-6d3697fd9c89",
          "key": "BENV-103",
          "title": "Create environments through idempotent provider operations",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "manage",
          "dependsOn": [
            "BENV-102"
          ],
          "scenario": "A create timeout produces two environments for the same review.",
          "acceptanceCriteria": [
            "Persist a stable operation identity before dispatch.",
            "Adopt matching provider resources after retry.",
            "Reject conflicting provider ownership metadata."
          ],
          "implementationNotes": [
            "Use explicit provider interfaces and local doubles."
          ],
          "verification": [
            "Recover after an accepted create loses its response.",
            "Detect an existing resource owned by another review."
          ],
          "deliverables": [
            "Idempotent provision coordinator."
          ],
          "rollout": "Keep uncertain creates pending until reconciliation.",
          "skills": [
            "Provider design",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "f3d0b347-fc66-43fc-8fac-c9c79615a4c9",
          "key": "BENV-104",
          "title": "Seed synthetic review data in isolated namespaces",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "manage",
          "dependsOn": [
            "BENV-103"
          ],
          "scenario": "Two previews share account records and interfere with each other's review.",
          "acceptanceCriteria": [
            "Assign a unique data namespace per environment.",
            "Seed only synthetic records.",
            "Deny reads across environment namespaces."
          ],
          "implementationNotes": [
            "Never copy production user data into previews."
          ],
          "verification": [
            "Run two previews with identical synthetic usernames.",
            "Verify cross-environment reads and cleanup are denied."
          ],
          "deliverables": [
            "Isolated seed workflow."
          ],
          "rollout": "Validate isolation before marking environments ready.",
          "skills": [
            "Data isolation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8c93b4a3-553b-4f62-bbd5-e9db303976f6",
          "key": "BENV-105",
          "title": "Bind preview URLs and callbacks to the environment origin",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "manage",
          "dependsOn": [
            "BENV-104"
          ],
          "scenario": "A preview callback redirects to an unrelated origin supplied in change metadata.",
          "acceptanceCriteria": [
            "Derive allowed origins from trusted environment state.",
            "Reject arbitrary redirect and callback destinations.",
            "Expire origin authority when the environment closes."
          ],
          "implementationNotes": [
            "Use local URLs and do not contact external hosts."
          ],
          "verification": [
            "Accept the environment's declared local callback.",
            "Reject a substituted external origin and stale environment."
          ],
          "deliverables": [
            "Origin binding guard."
          ],
          "rollout": "Expose preview links only after origin validation.",
          "skills": [
            "Origin security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "df0fb766-4b33-4217-923a-3bba77eb0adc",
          "key": "BENV-106",
          "title": "Expire environments using leases rather than event delivery alone",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "manage",
          "dependsOn": [
            "BENV-103",
            "BENV-105"
          ],
          "scenario": "A missed close event leaves a preview running indefinitely.",
          "acceptanceCriteria": [
            "Persist expiry and extension revisions.",
            "Reclaim expired environments through a periodic scan.",
            "Reject stale extensions after cleanup starts."
          ],
          "implementationNotes": [
            "Lifecycle state changes use explicit transitions."
          ],
          "verification": [
            "Expire an environment with no close event.",
            "Race extension and cleanup without resurrecting deleted state."
          ],
          "deliverables": [
            "Lease-based expiry."
          ],
          "rollout": "Start with dry-run expiry reports; enable cleanup after ownership checks.",
          "skills": [
            "Leases",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ed58fe64-6b0b-46c8-8743-c89b46d984fe",
          "key": "BENV-107",
          "title": "Reconcile partially created environments after provider failure",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "manage",
          "dependsOn": [
            "BENV-103",
            "BENV-106"
          ],
          "scenario": "The database resource exists but the web resource failed, leaving an unusable partial preview.",
          "acceptanceCriteria": [
            "Record each provider resource identity.",
            "Resume or compensate according to lifecycle policy.",
            "Release quota only after owned resources are accounted for."
          ],
          "implementationNotes": [
            "Never delete resources without matching ownership metadata."
          ],
          "verification": [
            "Recover a partially created preview.",
            "Encounter a foreign resource and stop compensation safely."
          ],
          "deliverables": [
            "Partial-creation reconciler."
          ],
          "rollout": "Keep the environment unavailable until complete; retain reconciliation history.",
          "skills": [
            "Reconciliation",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f59f1c83-434d-4969-8aa3-02964b604ad1",
          "key": "BENV-108",
          "title": "Produce a cleanup plan that proves exact resource ownership",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BENV-107"
          ],
          "scenario": "A broad name-prefix cleanup could delete another team's preview.",
          "acceptanceCriteria": [
            "List exact resource IDs and ownership bindings.",
            "Bind deletion intent to lifecycle revision.",
            "Reject changed ownership or active lease."
          ],
          "implementationNotes": [
            "Cleanup applies only to the local provider double."
          ],
          "verification": [
            "Delete an expired owned environment.",
            "Reject a foreign or newly extended resource."
          ],
          "deliverables": [
            "Reviewed cleanup plan."
          ],
          "rollout": "Use dry-run output first; stop on any ownership mismatch.",
          "skills": [
            "Resource safety"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "858dae45-ee39-471e-bc3f-36446294374e",
          "key": "BENV-109",
          "title": "Compare pooled and dedicated preview dependencies",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BENV-104",
            "BENV-108"
          ],
          "scenario": "Dedicated databases simplify isolation but cost more than a shared instance with namespaces.",
          "acceptanceCriteria": [
            "Compare isolation, startup time, cleanup, and quota assumptions.",
            "Rehearse cross-environment denial for the pooled option.",
            "Document failure domains and untested provider behavior."
          ],
          "implementationNotes": [
            "No speculative infrastructure is required beyond the local model."
          ],
          "verification": [
            "Evaluate both options against the same synthetic review workload.",
            "Reject a cheaper option that fails isolation requirements."
          ],
          "deliverables": [
            "Preview architecture decision record."
          ],
          "rollout": "Choose the smallest option satisfying isolation; keep migration and cleanup steps explicit.",
          "skills": [
            "Cloud architecture",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "309e2052-80cb-4951-babd-6ae160a1eccd",
          "key": "BENV-110",
          "title": "Write a stale-preview support checklist",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "operate",
          "dependsOn": [
            "BENV-109"
          ],
          "scenario": "Reviewers need to know whether a broken preview is creating, expired, or awaiting cleanup.",
          "acceptanceCriteria": [
            "Expose lifecycle state and last safe failure category.",
            "Show owner, expiry, and review identity.",
            "Document scoped retry and extension behavior."
          ],
          "implementationNotes": [
            "Status contains no credentials or seed data."
          ],
          "verification": [
            "Diagnose an expired synthetic preview.",
            "Reject extension after irreversible cleanup begins."
          ],
          "deliverables": [
            "Preview support guide."
          ],
          "rollout": "Ship with lifecycle controls and update after state changes.",
          "skills": [
            "Operational UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 40
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "aeceae5d-eb1e-42b5-a19f-ba251320a8ba",
      "key": "BDNS",
      "title": "Service DNS migration lab",
      "field": "Networking",
      "summary": "Move a service endpoint while accounting for caches, negative answers, and resolver behavior.",
      "context": "A fictional internal API is moving to a new endpoint. The team assumes DNS changes are immediate and has no rehearsal for stale clients.",
      "stack": [
        "TypeScript",
        "DNS fixtures",
        "HTTP"
      ],
      "prerequisites": [
        "Create a local resolver simulator and two loopback service endpoints with synthetic DNS records; query no external infrastructure."
      ],
      "developerValue": "Practice DNS semantics, migration timing, and network diagnosis.",
      "companyValue": "Produce a migration plan that makes cache delay and endpoint compatibility explicit.",
      "delivery": "Deliver local DNS simulations and a cutover report; modify no real DNS records.",
      "phases": [
        {
          "id": "records",
          "title": "Model DNS responses",
          "goal": "Define record and cache semantics."
        },
        {
          "id": "migrate",
          "title": "Rehearse endpoint changes",
          "goal": "Handle stale clients and lookup failures."
        },
        {
          "id": "assess",
          "title": "Review cutover",
          "goal": "Choose timing and recovery controls."
        }
      ],
      "tickets": [
        {
          "id": "249e22a3-59c1-4588-a50e-8f5e583464b8",
          "key": "BDNS-101",
          "title": "Inventory service records and their consumers",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "records",
          "dependsOn": [],
          "scenario": "The team knows the main hostname but not aliases used by background jobs.",
          "acceptanceCriteria": [
            "List record types, aliases, and modeled consumers.",
            "Identify ownership and current TTL.",
            "Mark unknown client caching behavior."
          ],
          "implementationNotes": [
            "Use reserved local test names only."
          ],
          "verification": [
            "Resolve the declared alias chain.",
            "Report an unknown consumer cache policy explicitly."
          ],
          "deliverables": [
            "DNS dependency inventory."
          ],
          "rollout": "Review inventory before scheduling a cutover.",
          "skills": [
            "DNS fundamentals"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "bf6086e3-8102-4a40-bffe-a1e7b83b1e80",
          "key": "BDNS-102",
          "title": "Implement TTL-aware positive caching in the resolver fixture",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "records",
          "dependsOn": [
            "BDNS-101"
          ],
          "scenario": "The simulator caches every answer forever and cannot represent migration delays.",
          "acceptanceCriteria": [
            "Expire answers using an injected clock.",
            "Honor the declared TTL without extending it on reads.",
            "Key cache entries by name and record type."
          ],
          "implementationNotes": [
            "Do not use wall-clock sleeps in tests."
          ],
          "verification": [
            "Serve a cached answer before expiry.",
            "Advance time and retrieve the changed authoritative answer."
          ],
          "deliverables": [
            "Positive-cache simulator."
          ],
          "rollout": "Validate the simulator against its documented semantics before using results.",
          "skills": [
            "Caching",
            "DNS"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "cf50600f-9307-4e82-885d-1bd7185bdc21",
          "key": "BDNS-103",
          "title": "Model negative caching separately from empty address records",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "records",
          "dependsOn": [
            "BDNS-102"
          ],
          "scenario": "A temporary missing hostname remains unavailable after its record is created.",
          "acceptanceCriteria": [
            "Distinguish nonexistent name from no record of requested type.",
            "Apply declared negative-cache lifetime.",
            "Preserve the reason for cached negative answers."
          ],
          "implementationNotes": [
            "Use explicit fixture policy rather than claiming universal resolver behavior."
          ],
          "verification": [
            "Create a record after a negative lookup.",
            "Show recovery only after the modeled negative cache expires."
          ],
          "deliverables": [
            "Negative-cache scenarios."
          ],
          "rollout": "Avoid deleting names during cutover unless negative-cache effects are accepted.",
          "skills": [
            "DNS",
            "Failure analysis"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "39da833a-46b5-45ef-a09f-5f7627bd6a4c",
          "key": "BDNS-104",
          "title": "Reject alias loops and excessively deep resolution chains",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "migrate",
          "dependsOn": [
            "BDNS-102"
          ],
          "scenario": "A mistaken alias points back to the original hostname and exhausts lookup work.",
          "acceptanceCriteria": [
            "Track visited aliases.",
            "Bound chain depth and response size.",
            "Return a clear resolution failure without partial success."
          ],
          "implementationNotes": [
            "The resolver fixture remains local and read-only."
          ],
          "verification": [
            "Resolve a valid multi-hop chain.",
            "Reject a loop and an over-depth chain."
          ],
          "deliverables": [
            "Alias validation."
          ],
          "rollout": "Validate proposed record sets before applying the synthetic change.",
          "skills": [
            "Graph traversal",
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7c85c9cf-6719-4a49-af03-da492dd31022",
          "key": "BDNS-105",
          "title": "Rehearse lowering TTL before endpoint cutover",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "migrate",
          "dependsOn": [
            "BDNS-102",
            "BDNS-103"
          ],
          "scenario": "Lowering TTL at the same moment as the address change does not shorten existing cached lifetimes.",
          "acceptanceCriteria": [
            "Model caches populated before and after TTL reduction.",
            "Calculate the required wait under declared assumptions.",
            "Track old and new endpoint usage during overlap."
          ],
          "implementationNotes": [
            "Do not promise that every real client respects TTL."
          ],
          "verification": [
            "Simulate an appropriately staged cutover.",
            "Show a stale pre-change cache after an immediate cutover."
          ],
          "deliverables": [
            "TTL staging rehearsal."
          ],
          "rollout": "Keep the old endpoint available through the documented overlap.",
          "skills": [
            "Migration planning"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1208381a-6a1e-48d8-8aba-6d74458d6151",
          "key": "BDNS-106",
          "title": "Preserve application compatibility across old and new addresses",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "migrate",
          "dependsOn": [
            "BDNS-105"
          ],
          "scenario": "DNS propagation sends different clients to different service versions.",
          "acceptanceCriteria": [
            "Exercise the same public contract on both endpoints.",
            "Preserve shared operation identity across retries.",
            "Reject incompatible old/new behavior before cutover."
          ],
          "implementationNotes": [
            "Use synthetic requests and loopback endpoints."
          ],
          "verification": [
            "Complete retries across both endpoints.",
            "Detect a response-contract mismatch during overlap."
          ],
          "deliverables": [
            "Endpoint overlap checks."
          ],
          "rollout": "Deploy compatible service behavior before changing DNS.",
          "skills": [
            "Compatibility",
            "Networking"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "adbe8e8c-7b08-44dc-9a68-ff7614f15e89",
          "key": "BDNS-107",
          "title": "Distinguish resolver failure from application connection failure",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "migrate",
          "dependsOn": [
            "BDNS-104",
            "BDNS-106"
          ],
          "scenario": "Operators see one generic network error for lookup failures and refused connections.",
          "acceptanceCriteria": [
            "Classify lookup, address selection, connection, and HTTP failures.",
            "Record bounded timing per stage.",
            "Keep hostnames and request data within the declared safe diagnostic policy."
          ],
          "implementationNotes": [
            "No packet payloads or credentials in generic logs."
          ],
          "verification": [
            "Diagnose a local nonexistent name.",
            "Resolve an address then distinguish refused connection."
          ],
          "deliverables": [
            "Network-stage diagnostics."
          ],
          "rollout": "Add classification before changing retry behavior.",
          "skills": [
            "Network diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5cdf40a3-177e-417d-acf2-102fd280ff4f",
          "key": "BDNS-108",
          "title": "Evaluate rollback when both old and new answers remain cached",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "assess",
          "dependsOn": [
            "BDNS-105",
            "BDNS-106",
            "BDNS-107"
          ],
          "scenario": "Reverting the DNS record does not immediately send every client back to the old endpoint.",
          "acceptanceCriteria": [
            "Model multiple cache ages during rollback.",
            "Define service compatibility and overlap requirements.",
            "Compare DNS rollback with routing-level containment under declared constraints."
          ],
          "implementationNotes": [
            "Keep conclusions scoped to the simulated client population."
          ],
          "verification": [
            "Roll back with mixed cached answers.",
            "Expose clients that continue using the new endpoint until expiry."
          ],
          "deliverables": [
            "DNS recovery decision record."
          ],
          "rollout": "Retain both compatible endpoints until the modeled overlap and operational checks complete.",
          "skills": [
            "Distributed systems",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "24913884-11e1-4b8c-83f1-44fb1e8843a5",
          "key": "BDNS-109",
          "title": "Check IPv4 and IPv6 record migration independently",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "assess",
          "dependsOn": [
            "BDNS-108"
          ],
          "scenario": "Only the IPv4 record is updated while dual-stack clients continue using the old IPv6 endpoint.",
          "acceptanceCriteria": [
            "Track A and AAAA records separately.",
            "Rehearse differing cache ages by family.",
            "Verify contract compatibility on both local address families."
          ],
          "implementationNotes": [
            "If IPv6 is unavailable locally, label that execution unverified and use deterministic fixtures."
          ],
          "verification": [
            "Simulate synchronized family updates.",
            "Detect a stale AAAA record after A changes."
          ],
          "deliverables": [
            "Dual-stack DNS cutover checks."
          ],
          "rollout": "Require family-specific review before final endpoint retirement.",
          "skills": [
            "IPv6",
            "DNS"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 80
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "21b490b7-5c22-4a1b-82d5-5cc59efb1674",
          "key": "BDNS-110",
          "title": "Write a DNS change record with cache assumptions",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "assess",
          "dependsOn": [
            "BDNS-109"
          ],
          "scenario": "The handoff omits when TTL was lowered and when old endpoints can be removed.",
          "acceptanceCriteria": [
            "Record old/new values and effective times.",
            "List modeled cache and compatibility assumptions.",
            "Define endpoint retirement criteria."
          ],
          "implementationNotes": [
            "Use UTC timestamps and synthetic record identities."
          ],
          "verification": [
            "Follow the staged change from the record.",
            "Keep retirement blocked when a required client assumption is unknown."
          ],
          "deliverables": [
            "DNS cutover runbook."
          ],
          "rollout": "Preserve the change record after rollback or completion.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "0b34c443-3e67-4369-8c00-5773c489b84f",
      "key": "BPROXY",
      "title": "Reverse-proxy connection reliability",
      "field": "Networking",
      "summary": "Correct proxy behavior for trusted forwarding, connection reuse, and streaming cancellation.",
      "context": "A fictional reporting API sits behind a reverse proxy. Clients see intermittent disconnects and incorrect origins after changes to keep-alive and forwarding headers.",
      "stack": [
        "TypeScript",
        "HTTP",
        "Local reverse proxy"
      ],
      "prerequisites": [
        "Create two loopback HTTP services and a local proxy with synthetic requests; no public scanning or external traffic."
      ],
      "developerValue": "Practice HTTP intermediaries, connection lifetimes, and network failure isolation.",
      "companyValue": "Provide a proxy contract that preserves request identity and releases resources predictably.",
      "delivery": "Deliver a local proxy configuration or adapter plus reproducible failure checks.",
      "phases": [
        {
          "id": "boundary",
          "title": "Define proxy trust",
          "goal": "Constrain forwarding and request interpretation."
        },
        {
          "id": "connections",
          "title": "Manage connections",
          "goal": "Handle reuse, timeouts, and cancellation."
        },
        {
          "id": "rollout",
          "title": "Verify proxy changes",
          "goal": "Measure behavior and rehearse configuration recovery."
        }
      ],
      "tickets": [
        {
          "id": "6a4b0d4c-7843-46b3-94d4-c765394a6fe7",
          "key": "BPROXY-101",
          "title": "Document the trusted proxy chain and public origin",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "boundary",
          "dependsOn": [],
          "scenario": "The application trusts forwarding headers from any caller.",
          "acceptanceCriteria": [
            "List trusted proxy hops and expected public origin.",
            "Define which hop sets each forwarding field.",
            "Reject ambiguous trust configuration."
          ],
          "implementationNotes": [
            "All modeled hops are local fixtures."
          ],
          "verification": [
            "Resolve origin through the trusted chain.",
            "Reject direct-client spoofed forwarding metadata."
          ],
          "deliverables": [
            "Proxy trust contract."
          ],
          "rollout": "Review the trust chain before changing application origin handling.",
          "skills": [
            "HTTP",
            "Trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f6ccd885-21d0-4f80-aba6-9a92e126231c",
          "key": "BPROXY-102",
          "title": "Normalize forwarded headers without accepting client spoofing",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "boundary",
          "dependsOn": [
            "BPROXY-101"
          ],
          "scenario": "A client-provided forwarded host changes generated callback URLs.",
          "acceptanceCriteria": [
            "Discard untrusted incoming forwarding fields.",
            "Set canonical forwarding metadata at the trusted boundary.",
            "Reject malformed or conflicting host values."
          ],
          "implementationNotes": [
            "Use an explicit allowed-origin list."
          ],
          "verification": [
            "Generate a callback for the allowed origin.",
            "Inject a spoofed forwarded host and verify rejection."
          ],
          "deliverables": [
            "Forwarding-header guard."
          ],
          "rollout": "Enable alongside the reviewed proxy chain; retain safe fixed-origin fallback.",
          "skills": [
            "Header security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9889cdbd-dca2-4db6-a82d-56bdf2e1c8a8",
          "key": "BPROXY-103",
          "title": "Strip hop-by-hop headers before forwarding requests",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "boundary",
          "dependsOn": [
            "BPROXY-102"
          ],
          "scenario": "Connection-specific headers are forwarded as if they were end-to-end metadata.",
          "acceptanceCriteria": [
            "Remove declared hop-by-hop fields.",
            "Honor fields named by the Connection header.",
            "Preserve required end-to-end headers."
          ],
          "implementationNotes": [
            "Parse header names case-insensitively and bound header size."
          ],
          "verification": [
            "Forward a valid request unchanged semantically.",
            "Verify Connection-nominated fields do not reach upstream."
          ],
          "deliverables": [
            "Header forwarding tests."
          ],
          "rollout": "Deploy to the local proxy fixture first and inspect resulting headers.",
          "skills": [
            "HTTP semantics"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "95089183-5f4f-47be-a0ca-4a0510371d47",
          "key": "BPROXY-104",
          "title": "Align keep-alive lifetimes between proxy and upstream",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "connections",
          "dependsOn": [
            "BPROXY-103"
          ],
          "scenario": "The proxy reuses sockets just after the upstream has closed them.",
          "acceptanceCriteria": [
            "Document idle-timeout relationships.",
            "Retire idle connections before unsafe reuse under the chosen policy.",
            "Classify stale-connection failures separately."
          ],
          "implementationNotes": [
            "Use controlled local timeout fixtures."
          ],
          "verification": [
            "Reuse a valid connection.",
            "Expire upstream idle state and verify bounded recovery."
          ],
          "deliverables": [
            "Connection lifetime configuration."
          ],
          "rollout": "Change one timeout at a time; retain previous values for comparison.",
          "skills": [
            "Connection pooling"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5543888b-e2e2-414b-b20d-7affc60c0a96",
          "key": "BPROXY-105",
          "title": "Limit upstream connections per service without unbounded waiting",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "connections",
          "dependsOn": [
            "BPROXY-104"
          ],
          "scenario": "A slow upstream creates an unlimited queue behind a finite connection pool.",
          "acceptanceCriteria": [
            "Set finite active and waiting limits.",
            "Return explicit overload responses when waiting is full.",
            "Remove cancelled waiters."
          ],
          "implementationNotes": [
            "Keep limits service-scoped and observable."
          ],
          "verification": [
            "Serve within the configured pool.",
            "Overflow the wait queue and verify no resource leak."
          ],
          "deliverables": [
            "Bounded upstream pool."
          ],
          "rollout": "Start conservatively; tune only from recorded workload behavior.",
          "skills": [
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7431849c-0083-4838-a9c3-3222ff2b748c",
          "key": "BPROXY-106",
          "title": "Propagate downstream disconnects through streamed responses",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "connections",
          "dependsOn": [
            "BPROXY-105"
          ],
          "scenario": "A cancelled report download continues consuming upstream bandwidth.",
          "acceptanceCriteria": [
            "Abort the owned upstream request on disconnect.",
            "Stop buffering and release stream resources.",
            "Preserve completion metrics distinct from cancellation."
          ],
          "implementationNotes": [
            "Use bounded synthetic report streams."
          ],
          "verification": [
            "Finish a small streamed response.",
            "Disconnect mid-stream and verify upstream cancellation."
          ],
          "deliverables": [
            "Streaming cancellation fix."
          ],
          "rollout": "Adopt on one streaming route; retain traces of safe lifecycle events.",
          "skills": [
            "Streams",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c61bf0c8-7cf5-46ef-94b8-af7993f836ed",
          "key": "BPROXY-107",
          "title": "Avoid unsafe automatic replay after partial request transmission",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "connections",
          "dependsOn": [
            "BPROXY-104",
            "BPROXY-106"
          ],
          "scenario": "The proxy retries a POST after its connection breaks, potentially duplicating a write.",
          "acceptanceCriteria": [
            "Distinguish retryable methods and declared idempotent operations.",
            "Track whether request transmission may have occurred.",
            "Return unknown outcome when safe replay cannot be established."
          ],
          "implementationNotes": [
            "Do not infer idempotency from an empty response."
          ],
          "verification": [
            "Retry a safe read after a stale connection.",
            "Break a write after transmission and prevent blind replay."
          ],
          "deliverables": [
            "Proxy retry policy."
          ],
          "rollout": "Disable automatic write retries until application identity semantics are explicit.",
          "skills": [
            "HTTP retries",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3c504c51-bdb4-41fa-a7fb-405c9880582b",
          "key": "BPROXY-108",
          "title": "Compare buffering and streaming under bounded memory",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "rollout",
          "dependsOn": [
            "BPROXY-105",
            "BPROXY-106",
            "BPROXY-107"
          ],
          "scenario": "Buffering simplifies upstream retries but large reports exhaust proxy memory.",
          "acceptanceCriteria": [
            "Compare identical synthetic response sizes and client rates.",
            "Measure memory, time-to-first-byte, completion, and cancellation.",
            "Explain retry and partial-response tradeoffs."
          ],
          "implementationNotes": [
            "Record machine limits and do not generalize local throughput."
          ],
          "verification": [
            "Run fast and slow clients under both policies.",
            "Expose the memory or partial-response failure boundary."
          ],
          "deliverables": [
            "Proxy buffering decision record."
          ],
          "rollout": "Select route-specific policy with explicit byte limits and rollback configuration.",
          "skills": [
            "Performance analysis",
            "Network design"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9ace06f2-5dec-46bf-9f91-aadf73c690ed",
          "key": "BPROXY-109",
          "title": "Reload proxy configuration without dropping healthy in-flight requests",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rollout",
          "dependsOn": [
            "BPROXY-108"
          ],
          "scenario": "Configuration reloads close active report streams immediately.",
          "acceptanceCriteria": [
            "Validate new configuration before activation.",
            "Drain existing connections within a bounded deadline.",
            "Reject invalid reloads while retaining the prior configuration."
          ],
          "implementationNotes": [
            "Use only locally owned processes."
          ],
          "verification": [
            "Reload during an active stream.",
            "Submit invalid configuration and verify the old proxy remains usable."
          ],
          "deliverables": [
            "Graceful reload behavior."
          ],
          "rollout": "Keep a tested prior configuration and an explicit drain timeout.",
          "skills": [
            "Operational networking"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8ac5eb33-3fab-47a8-bf68-9743bacd25f4",
          "key": "BPROXY-110",
          "title": "Write a proxy incident checklist by connection stage",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "rollout",
          "dependsOn": [
            "BPROXY-109"
          ],
          "scenario": "Operators need to distinguish header rejection, pool waiting, and upstream disconnects.",
          "acceptanceCriteria": [
            "Map safe failure categories to checks.",
            "Include current timeout and pool settings.",
            "Document bounded rollback and drain commands."
          ],
          "implementationNotes": [
            "Do not capture request bodies or credentials."
          ],
          "verification": [
            "Diagnose a synthetic stale connection.",
            "Distinguish pool overload from upstream application failure."
          ],
          "deliverables": [
            "Proxy support runbook."
          ],
          "rollout": "Ship with configuration changes and verify it during local rehearsal.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "27823903-8b56-4675-865e-2f00111503b6",
      "key": "BMTLS",
      "title": "Mutual TLS certificate lifecycle",
      "field": "Networking",
      "summary": "Operate authenticated service connections through expiry, rotation, and trust changes.",
      "context": "A fictional internal report exporter uses mutual TLS. Certificates are renewed manually, and operators cannot distinguish peer identity failures from network outages.",
      "stack": [
        "TypeScript",
        "TLS",
        "Local certificate fixtures"
      ],
      "prerequisites": [
        "Generate disposable test-only certificate authorities and leaf certificates for loopback services; use no production keys."
      ],
      "developerValue": "Practice transport identity, trust-store changes, and certificate failure diagnosis.",
      "companyValue": "Provide repeatable rotation and recovery behavior for authenticated service communication.",
      "delivery": "Deliver local TLS checks and lifecycle rehearsals; modify no real trust stores.",
      "phases": [
        {
          "id": "identity",
          "title": "Define peer identity",
          "goal": "Specify certificate and name constraints."
        },
        {
          "id": "connect",
          "title": "Enforce transport trust",
          "goal": "Validate peers and handle connection lifecycle."
        },
        {
          "id": "rotate",
          "title": "Rehearse certificate changes",
          "goal": "Test overlap, expiry, revocation, and recovery."
        }
      ],
      "tickets": [
        {
          "id": "f4d534fd-159e-4013-8e49-287c7ba5fc54",
          "key": "BMTLS-101",
          "title": "Define expected service names and certificate usage",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "identity",
          "dependsOn": [],
          "scenario": "A certificate signed by the internal CA is accepted for any service name.",
          "acceptanceCriteria": [
            "List expected subject alternative names per peer.",
            "Declare client and server usage requirements.",
            "Separate trust-chain validity from service identity."
          ],
          "implementationNotes": [
            "Use reserved local names and test certificates."
          ],
          "verification": [
            "Match the intended service identity.",
            "Reject a valid-chain certificate for another service."
          ],
          "deliverables": [
            "TLS identity contract."
          ],
          "rollout": "Review identities before enabling peer authentication.",
          "skills": [
            "TLS fundamentals"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "60a5f622-c9ae-4259-854a-0417f18562e2",
          "key": "BMTLS-102",
          "title": "Validate certificate chains without disabling hostname checks",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "identity",
          "dependsOn": [
            "BMTLS-101"
          ],
          "scenario": "A workaround accepts self-signed certificates by disabling all verification.",
          "acceptanceCriteria": [
            "Trust only the configured test CA set.",
            "Verify peer names and intended usage.",
            "Reject expired, incomplete, and unknown chains."
          ],
          "implementationNotes": [
            "No permissive verification bypass is allowed."
          ],
          "verification": [
            "Connect with the authorized test chain.",
            "Reject wrong-name and untrusted certificates."
          ],
          "deliverables": [
            "Strict TLS configuration."
          ],
          "rollout": "Fail closed and expose safe diagnostic categories.",
          "skills": [
            "Certificate validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b3bd1e34-3e4c-466b-a723-2d0fae968bb9",
          "key": "BMTLS-103",
          "title": "Separate certificate expiry alerts from connection failure rates",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "connect",
          "dependsOn": [
            "BMTLS-102"
          ],
          "scenario": "Renewal is noticed only when connections begin failing.",
          "acceptanceCriteria": [
            "Report remaining certificate lifetime.",
            "Distinguish leaf and trust-anchor expiry.",
            "Keep expiry observations separate from availability outcomes."
          ],
          "implementationNotes": [
            "Avoid private-key or full certificate dumps in generic logs."
          ],
          "verification": [
            "Observe a near-expiry leaf certificate.",
            "Show an expired CA distinctly from an unreachable peer."
          ],
          "deliverables": [
            "Certificate health metrics."
          ],
          "rollout": "Run read-only checks before wiring operational alerts.",
          "skills": [
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 20
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "95618661-2048-4357-aaae-9eccb5884382",
          "key": "BMTLS-104",
          "title": "Refresh connection pools after client-certificate rotation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "connect",
          "dependsOn": [
            "BMTLS-102",
            "BMTLS-103"
          ],
          "scenario": "Long-lived connections keep using the old client identity after new credentials are loaded.",
          "acceptanceCriteria": [
            "Bind pools to certificate generation.",
            "Stop assigning new requests to retired pools.",
            "Drain existing connections within a declared deadline."
          ],
          "implementationNotes": [
            "Do not terminate healthy requests without the documented drain policy."
          ],
          "verification": [
            "Rotate while a request is active.",
            "Verify new connections use the new certificate generation."
          ],
          "deliverables": [
            "Certificate-aware pool lifecycle."
          ],
          "rollout": "Roll out with a bounded overlap; preserve prior public trust during drain.",
          "skills": [
            "Connection lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9abacd1d-6b31-4252-b00b-9836c93b100d",
          "key": "BMTLS-105",
          "title": "Keep TLS errors from exposing peer secrets or request payloads",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "connect",
          "dependsOn": [
            "BMTLS-103"
          ],
          "scenario": "Handshake errors include large diagnostic objects containing sensitive material.",
          "acceptanceCriteria": [
            "Map failures to bounded safe categories.",
            "Include correlation and expected peer class.",
            "Exclude private keys, tokens, and request bodies."
          ],
          "implementationNotes": [
            "Use seeded synthetic secret markers."
          ],
          "verification": [
            "Diagnose hostname and expiry failures.",
            "Verify secret markers never appear in logs."
          ],
          "deliverables": [
            "Safe TLS error mapping."
          ],
          "rollout": "Replace broad error serialization before expanding diagnostics.",
          "skills": [
            "Operational security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "843931c0-7a2e-4fa5-a70e-383fffd6b110",
          "key": "BMTLS-106",
          "title": "Rehearse leaf renewal under an unchanged trust anchor",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "rotate",
          "dependsOn": [
            "BMTLS-104",
            "BMTLS-105"
          ],
          "scenario": "Routine renewal should not require every client to restart simultaneously.",
          "acceptanceCriteria": [
            "Issue a new leaf with the same declared identity.",
            "Overlap old and new leaves within policy.",
            "Verify old-leaf retirement after draining."
          ],
          "implementationNotes": [
            "Generated keys remain local temporary test assets."
          ],
          "verification": [
            "Renew without interrupting the declared local request flow.",
            "Reject the expired prior leaf after overlap."
          ],
          "deliverables": [
            "Leaf renewal rehearsal."
          ],
          "rollout": "Renew before expiry and retain a bounded rollback window.",
          "skills": [
            "Certificate operations"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a2972e5f-f7a5-481a-a5b6-8263b3ac51d5",
          "key": "BMTLS-107",
          "title": "Rotate trust anchors without accepting unrelated authorities",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rotate",
          "dependsOn": [
            "BMTLS-106"
          ],
          "scenario": "Adding a new CA to the trust store accidentally imports every certificate from a shared bundle.",
          "acceptanceCriteria": [
            "Allowlist exact old and new test anchors.",
            "Stage verifier trust before switching issuers.",
            "Remove the old anchor after the declared overlap."
          ],
          "implementationNotes": [
            "Never trust an arbitrary system bundle for this private service boundary."
          ],
          "verification": [
            "Complete a staged CA rotation.",
            "Reject a third unrelated CA throughout the overlap."
          ],
          "deliverables": [
            "Trust-anchor rotation procedure."
          ],
          "rollout": "Keep overlap short and reviewed; fail closed on unexpected trust material.",
          "skills": [
            "Trust management"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ccbd4534-8033-4264-bcc1-0c68fe098ecf",
          "key": "BMTLS-108",
          "title": "Enforce peer revocation on reused connections",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "rotate",
          "dependsOn": [
            "BMTLS-104",
            "BMTLS-107"
          ],
          "scenario": "A revoked peer retains a long-lived authenticated connection.",
          "acceptanceCriteria": [
            "Define revocation checks and maximum connection lifetime.",
            "Stop new requests for revoked peer identity.",
            "Close or drain existing connections according to the incident policy."
          ],
          "implementationNotes": [
            "Revocation policy must state its bounded enforcement delay."
          ],
          "verification": [
            "Revoke an idle authenticated peer.",
            "Attempt reuse and verify denial within the declared bound."
          ],
          "deliverables": [
            "Revocation enforcement tests."
          ],
          "rollout": "Rehearse revocation before relying on certificate identity for sensitive operations.",
          "skills": [
            "Revocation",
            "Networking"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3768e95b-a596-477c-b424-c678934f469b",
          "key": "BMTLS-109",
          "title": "Compare certificate overlap availability against retained trust risk",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "rotate",
          "dependsOn": [
            "BMTLS-107",
            "BMTLS-108"
          ],
          "scenario": "A long overlap helps slow clients but extends acceptance of old credentials.",
          "acceptanceCriteria": [
            "Model client refresh distribution and enforcement delay.",
            "Compare bounded overlap options.",
            "Document unknown client behavior and recovery implications."
          ],
          "implementationNotes": [
            "The local rehearsal cannot prove organization-wide certificate rollout coverage."
          ],
          "verification": [
            "Evaluate fast and delayed synthetic clients.",
            "Reject an overlap proposal without an explicit old-trust retirement point."
          ],
          "deliverables": [
            "TLS lifecycle decision record."
          ],
          "rollout": "Choose a measurable overlap and track lagging clients before retirement.",
          "skills": [
            "Security tradeoffs",
            "Reliability"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2ec6280e-6ad2-4a31-993d-3d184c37947a",
          "key": "BMTLS-110",
          "title": "Write a certificate-expiry incident handoff",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "rotate",
          "dependsOn": [
            "BMTLS-109"
          ],
          "scenario": "On-call staff need a safe response when one peer fails certificate validation.",
          "acceptanceCriteria": [
            "Identify failing peer class and certificate generation.",
            "Show approved renewal and trust-check steps.",
            "Explain when to stop retries and escalate ownership."
          ],
          "implementationNotes": [
            "Never recommend disabling certificate verification."
          ],
          "verification": [
            "Resolve a synthetic expired leaf using the guide.",
            "Keep an unknown-CA failure closed."
          ],
          "deliverables": [
            "TLS support runbook."
          ],
          "rollout": "Store with the service identity inventory and rotation schedule.",
          "skills": [
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "88f4d00d-8c24-464f-b798-acd1dc739870",
      "key": "BEGRESS",
      "title": "Restricted outbound fetch gateway",
      "field": "Networking",
      "summary": "Fetch approved external resources through a bounded provider-neutral network boundary.",
      "context": "A fictional content-import service accepts document URLs. The team needs explicit destination approval, redirect handling, and response limits before enabling imports.",
      "stack": [
        "TypeScript",
        "HTTP",
        "DNS fixtures"
      ],
      "prerequisites": [
        "Create a local HTTP destination simulator and DNS double with authorized address cases; contact no real external hosts."
      ],
      "developerValue": "Practice URL interpretation, network policy enforcement, and resource controls.",
      "companyValue": "Provide a reusable fetch boundary that makes destination authority and failure behavior inspectable.",
      "delivery": "Deliver a local gateway contract and authorized lab tests; no unrestricted internet proxy.",
      "phases": [
        {
          "id": "policy",
          "title": "Define destination policy",
          "goal": "Normalize URLs and bind approved destinations."
        },
        {
          "id": "fetch",
          "title": "Enforce bounded fetching",
          "goal": "Check resolution, redirects, and response limits."
        },
        {
          "id": "operate",
          "title": "Review policy lifecycle",
          "goal": "Handle policy changes, exceptions, and operational diagnostics."
        }
      ],
      "tickets": [
        {
          "id": "21671c49-1621-4fa1-a77f-3d94701896ea",
          "key": "BEGRESS-101",
          "title": "Define the approved destination contract for imports",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "policy",
          "dependsOn": [],
          "scenario": "The importer accepts any URL beginning with a trusted-looking string.",
          "acceptanceCriteria": [
            "Specify allowed scheme, hostname, port, and path scope.",
            "Represent exact hosts separately from subdomain rules.",
            "Reject unknown policy entries."
          ],
          "implementationNotes": [
            "Use fictional destinations mapped only inside the local simulator."
          ],
          "verification": [
            "Accept an exact approved destination.",
            "Reject a lookalike hostname and unapproved port."
          ],
          "deliverables": [
            "Destination policy schema."
          ],
          "rollout": "Default to deny until a reviewed policy exists.",
          "skills": [
            "Network policy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c60c5ccb-7e30-4c95-935e-b66ecbb838e5",
          "key": "BEGRESS-102",
          "title": "Normalize import URLs without changing their authority",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "policy",
          "dependsOn": [
            "BEGRESS-101"
          ],
          "scenario": "User-info syntax and encoded separators confuse destination checks.",
          "acceptanceCriteria": [
            "Parse URLs with a single canonical parser.",
            "Reject credentials, ambiguous encodings, and unsupported schemes.",
            "Compare normalized authority against policy."
          ],
          "implementationNotes": [
            "Do not perform a request during validation."
          ],
          "verification": [
            "Normalize an approved URL deterministically.",
            "Reject user-info and authority-confusion fixtures."
          ],
          "deliverables": [
            "URL validation boundary."
          ],
          "rollout": "Run validation before queueing any fetch.",
          "skills": [
            "URL security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e0ed4d00-674c-4aba-ba8a-ab54af466810",
          "key": "BEGRESS-103",
          "title": "Bind resolved addresses to the approved hostname policy",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "fetch",
          "dependsOn": [
            "BEGRESS-102"
          ],
          "scenario": "An approved hostname resolves to an address outside the permitted destination range.",
          "acceptanceCriteria": [
            "Validate every candidate address against policy.",
            "Reject private or special ranges unless explicitly authorized in the lab policy.",
            "Pin the validated resolution for the connection."
          ],
          "implementationNotes": [
            "The local test harness explicitly maps approved loopback fixtures; production defaults remain deny."
          ],
          "verification": [
            "Connect using an approved simulated resolution.",
            "Change resolution to an unapproved range and deny the request."
          ],
          "deliverables": [
            "Resolution-aware fetch policy."
          ],
          "rollout": "Fail closed on resolution ambiguity or unavailable policy.",
          "skills": [
            "DNS",
            "Egress control"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "2010a492-1443-4578-b04d-9eb02d59e0b4",
          "key": "BEGRESS-104",
          "title": "Revalidate every redirect before following it",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "fetch",
          "dependsOn": [
            "BEGRESS-103"
          ],
          "scenario": "An approved endpoint redirects the importer to an unapproved destination.",
          "acceptanceCriteria": [
            "Validate each redirect target independently.",
            "Bound redirect count.",
            "Prevent credentials or sensitive headers crossing origins."
          ],
          "implementationNotes": [
            "Do not inherit destination approval from the first URL."
          ],
          "verification": [
            "Follow an approved same-policy redirect.",
            "Reject an unapproved target and a redirect loop."
          ],
          "deliverables": [
            "Redirect policy checks."
          ],
          "rollout": "Disable redirects by default until the policy is configured.",
          "skills": [
            "HTTP",
            "Trust boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7b1bc163-40a9-423c-9a5b-e997f81d6b5d",
          "key": "BEGRESS-105",
          "title": "Enforce response byte limits during streaming",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "fetch",
          "dependsOn": [
            "BEGRESS-104"
          ],
          "scenario": "A response exceeds memory limits before its declared size can be checked.",
          "acceptanceCriteria": [
            "Enforce streamed compressed and expanded byte limits.",
            "Abort when the configured bound is exceeded.",
            "Reject inconsistent length metadata safely."
          ],
          "implementationNotes": [
            "Never buffer an unbounded response."
          ],
          "verification": [
            "Fetch a small valid synthetic document.",
            "Abort an oversized or expanding response and release resources."
          ],
          "deliverables": [
            "Bounded response reader."
          ],
          "rollout": "Start with conservative document limits and explicit too-large errors.",
          "skills": [
            "Streaming",
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "36933a4f-3293-4b58-ac4d-daa93e1d9481",
          "key": "BEGRESS-106",
          "title": "Constrain total fetch time across DNS and redirects",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "fetch",
          "dependsOn": [
            "BEGRESS-103",
            "BEGRESS-104",
            "BEGRESS-105"
          ],
          "scenario": "Each redirect gets a fresh timeout, extending one import indefinitely.",
          "acceptanceCriteria": [
            "Use one total deadline for all stages.",
            "Propagate cancellation to owned operations.",
            "Settle even when a destination double ignores cancellation."
          ],
          "implementationNotes": [
            "No automatic retry after the total budget expires."
          ],
          "verification": [
            "Complete a multi-stage fetch within budget.",
            "Exhaust the deadline during redirects and verify cleanup."
          ],
          "deliverables": [
            "End-to-end fetch deadline."
          ],
          "rollout": "Return a retryable unavailable result only under the documented import policy.",
          "skills": [
            "Cancellation",
            "Timeout design"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a0f985ec-6af8-47f4-a770-311c0b07f1e8",
          "key": "BEGRESS-107",
          "title": "Separate content-type validation from document parser selection",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "fetch",
          "dependsOn": [
            "BEGRESS-105"
          ],
          "scenario": "The importer trusts a response header and sends arbitrary bytes to the wrong parser.",
          "acceptanceCriteria": [
            "Allowlist supported content types.",
            "Check bounded content signatures where applicable.",
            "Reject disagreement instead of guessing a parser."
          ],
          "implementationNotes": [
            "Parsing runs only through the authorized document-processing boundary."
          ],
          "verification": [
            "Accept a matching synthetic text document.",
            "Reject mislabeled binary content and unsupported types."
          ],
          "deliverables": [
            "Content validation contract."
          ],
          "rollout": "Keep unsupported imports rejected with clear user guidance.",
          "skills": [
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c9e280b5-1b65-40c0-b948-1f446770b0b4",
          "key": "BEGRESS-108",
          "title": "Revoke destination approval for queued and cached imports",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operate",
          "dependsOn": [
            "BEGRESS-106",
            "BEGRESS-107"
          ],
          "scenario": "An endpoint is removed from policy but previously queued work still fetches it.",
          "acceptanceCriteria": [
            "Recheck current policy before dispatch.",
            "Bind cached fetch authority to policy revision.",
            "Invalidate revoked destinations without serving stale private content."
          ],
          "implementationNotes": [
            "Cached bytes cannot authorize a new network operation."
          ],
          "verification": [
            "Dispatch an unchanged approved import.",
            "Revoke the host and deny queued work before connection."
          ],
          "deliverables": [
            "Policy revocation handling."
          ],
          "rollout": "Pause affected work and preserve safe operation metadata.",
          "skills": [
            "Authorization",
            "Lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a13dfcf0-a578-4e24-abb5-8dcdf5682757",
          "key": "BEGRESS-109",
          "title": "Assess proxy deployment versus embedded fetch enforcement",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BEGRESS-103",
            "BEGRESS-108"
          ],
          "scenario": "The team must decide whether every service implements egress checks or shares a constrained gateway.",
          "acceptanceCriteria": [
            "Compare enforcement consistency, latency, failure domain, and operations burden.",
            "Model bypass risks and explicit provider boundaries.",
            "Choose the smallest design satisfying the scenario."
          ],
          "implementationNotes": [
            "Do not add microservices without a demonstrated need; a local module may be sufficient."
          ],
          "verification": [
            "Trace an authorized import through the chosen boundary.",
            "Show how direct unapproved network access is prevented in the model."
          ],
          "deliverables": [
            "Egress architecture decision record."
          ],
          "rollout": "Keep the gateway unavailable until enforcement and bypass assumptions are verified.",
          "skills": [
            "Network architecture",
            "Tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "32fe8fc8-36da-4b08-b6c6-9c58ba6104c4",
          "key": "BEGRESS-110",
          "title": "Write a destination-exception review with expiry",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "operate",
          "dependsOn": [
            "BEGRESS-109"
          ],
          "scenario": "A temporary import source should not become a permanent wildcard allowlist entry.",
          "acceptanceCriteria": [
            "Require exact destination, owner, reason, and expiry.",
            "Document required negative checks.",
            "Preserve exception history after removal."
          ],
          "implementationNotes": [
            "Exceptions cannot disable response or time bounds."
          ],
          "verification": [
            "Approve a narrow synthetic exception.",
            "Reject expired and wildcard-wide exceptions."
          ],
          "deliverables": [
            "Egress exception guide."
          ],
          "rollout": "Review exceptions before policy publication and remove expired authority.",
          "skills": [
            "Policy governance"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "934d7d97-1f21-4cf3-9d79-c8cc30d66837",
      "key": "BNETDIAG",
      "title": "Dual-stack network troubleshooting kit",
      "field": "Networking",
      "summary": "Diagnose address-family, packet-size, and routing failures in an authorized local lab.",
      "context": "A fictional desktop sync client works on one office network but intermittently fails on another. Application retries hide whether DNS, IPv6, or transport limits are responsible.",
      "stack": [
        "TypeScript",
        "Packet trace fixtures",
        "HTTP"
      ],
      "prerequisites": [
        "Author synthetic packet traces and local IPv4/IPv6 endpoint doubles; use no third-party scanning or captured personal traffic."
      ],
      "developerValue": "Practice layered network diagnosis and reproducible troubleshooting.",
      "companyValue": "Produce precise support diagnostics that distinguish application defects from connectivity conditions.",
      "delivery": "Deliver an offline trace analyzer and local diagnostic workflow with explicit platform limits.",
      "phases": [
        {
          "id": "observe",
          "title": "Observe network stages",
          "goal": "Normalize safe diagnostics and establish controlled cases."
        },
        {
          "id": "diagnose",
          "title": "Diagnose failure families",
          "goal": "Separate resolution, address selection, and transport behavior."
        },
        {
          "id": "handoff",
          "title": "Make diagnosis repeatable",
          "goal": "Evaluate fallback and produce safe support artifacts."
        }
      ],
      "tickets": [
        {
          "id": "f116d752-b86a-4dfd-9750-2d5f65068f7c",
          "key": "BNETDIAG-101",
          "title": "Define a sanitized connection-attempt diagnostic record",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "observe",
          "dependsOn": [],
          "scenario": "Support receives raw traces containing request payloads and personal hostnames.",
          "acceptanceCriteria": [
            "Record stage, address family, duration, and safe error category.",
            "Exclude payloads, credentials, and user identifiers.",
            "Mark unavailable measurements explicitly."
          ],
          "implementationNotes": [
            "Use synthetic traces only."
          ],
          "verification": [
            "Represent a successful local connection.",
            "Scan a seeded sensitive trace and verify excluded fields."
          ],
          "deliverables": [
            "Diagnostic schema."
          ],
          "rollout": "Adopt minimal records before collecting more detail.",
          "skills": [
            "Network diagnostics",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "0a477436-0b32-47f9-8f99-a8850bd691b0",
          "key": "BNETDIAG-102",
          "title": "Correlate DNS answers with selected connection addresses",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "observe",
          "dependsOn": [
            "BNETDIAG-101"
          ],
          "scenario": "The client log shows resolved addresses but not which one it attempted.",
          "acceptanceCriteria": [
            "Bind attempts to their resolution result identity.",
            "Record selected family and address classification.",
            "Detect attempts outside the recorded answer set."
          ],
          "implementationNotes": [
            "Store only approved synthetic addresses."
          ],
          "verification": [
            "Trace selection from a dual-stack answer.",
            "Flag a connection address absent from the result."
          ],
          "deliverables": [
            "Resolution-to-connection correlation."
          ],
          "rollout": "Enable in local diagnostic mode first.",
          "skills": [
            "DNS",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "cfcab83a-679b-4567-9ed2-0d29bef8fdb3",
          "key": "BNETDIAG-103",
          "title": "Implement bounded address-family fallback in the client fixture",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "diagnose",
          "dependsOn": [
            "BNETDIAG-102"
          ],
          "scenario": "An unreachable IPv6 address delays a working IPv4 connection until a long timeout.",
          "acceptanceCriteria": [
            "Race or sequence families under a declared bounded policy.",
            "Cancel losing attempts and release sockets.",
            "Preserve meaningful final errors when both fail."
          ],
          "implementationNotes": [
            "Use deterministic timers and loopback doubles."
          ],
          "verification": [
            "Reach IPv4 when the IPv6 fixture stalls.",
            "Fail both families without leaked attempts."
          ],
          "deliverables": [
            "Address-family fallback policy."
          ],
          "rollout": "Compare with the previous policy under identical traces before adoption.",
          "skills": [
            "IPv6",
            "Connection management"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8d9d381a-306b-4ca9-b9a7-1abca267870a",
          "key": "BNETDIAG-104",
          "title": "Detect a packet-size black-hole pattern in synthetic traces",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "diagnose",
          "dependsOn": [
            "BNETDIAG-101"
          ],
          "scenario": "Small requests succeed while larger uploads stall without an application response.",
          "acceptanceCriteria": [
            "Identify the declared retransmission and size pattern.",
            "Distinguish a hypothesis from confirmed cause.",
            "Suggest one bounded local verification step."
          ],
          "implementationNotes": [
            "Do not infer path MTU from an arbitrary single failed request."
          ],
          "verification": [
            "Analyze a synthetic size-dependent failure.",
            "Keep a generic timeout trace inconclusive."
          ],
          "deliverables": [
            "Packet-size diagnostic rule."
          ],
          "rollout": "Use advisory findings only; require the verification step before configuration changes.",
          "skills": [
            "Transport analysis"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b332474a-7990-42ee-b315-d03f9e9d09e2",
          "key": "BNETDIAG-105",
          "title": "Separate proxy interception from origin TLS failure",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "diagnose",
          "dependsOn": [
            "BNETDIAG-101",
            "BNETDIAG-102"
          ],
          "scenario": "Certificate failures on one network are blamed on the origin service.",
          "acceptanceCriteria": [
            "Compare expected peer identity with observed chain metadata.",
            "Record proxy configuration source safely.",
            "Keep unknown interception explicitly unresolved."
          ],
          "implementationNotes": [
            "Never recommend disabling TLS verification."
          ],
          "verification": [
            "Identify the modeled local proxy certificate.",
            "Distinguish a wrong-origin certificate from an unreachable origin."
          ],
          "deliverables": [
            "TLS path diagnostic."
          ],
          "rollout": "Keep failed connections closed while investigating trust configuration.",
          "skills": [
            "TLS",
            "Network troubleshooting"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8f7fc050-b648-4bc7-b2fa-d64d9f11d26d",
          "key": "BNETDIAG-106",
          "title": "Detect split-horizon DNS differences without leaking private zones",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "diagnose",
          "dependsOn": [
            "BNETDIAG-102"
          ],
          "scenario": "The same service name maps differently in two authorized network contexts.",
          "acceptanceCriteria": [
            "Compare labeled resolver-context results.",
            "Report family, record class, and policy differences.",
            "Redact private names from shareable output."
          ],
          "implementationNotes": [
            "Use synthetic zone data and no external DNS queries."
          ],
          "verification": [
            "Compare two intentional split-horizon fixtures.",
            "Detect an unexpected public-context answer."
          ],
          "deliverables": [
            "Resolver comparison report."
          ],
          "rollout": "Review private results locally; share only the sanitized projection.",
          "skills": [
            "DNS",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "325c5d20-c3f3-43be-a8d6-1bef19019cc4",
          "key": "BNETDIAG-107",
          "title": "Bound diagnostic retries independently of application retries",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "diagnose",
          "dependsOn": [
            "BNETDIAG-103"
          ],
          "scenario": "Running the diagnostic tool triggers the client's normal retry loop and floods the local test endpoint.",
          "acceptanceCriteria": [
            "Use a separate fixed diagnostic attempt budget.",
            "Disable application retry chaining.",
            "Stop immediately on explicit cancellation."
          ],
          "implementationNotes": [
            "Targets must match the authorized local allowlist."
          ],
          "verification": [
            "Run the declared number of attempts.",
            "Cancel or supply an unapproved target and verify no further connections."
          ],
          "deliverables": [
            "Diagnostic execution guard."
          ],
          "rollout": "Default to offline analysis; require explicit local target configuration.",
          "skills": [
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e2e21850-c6c4-48b1-ac6a-bbd71a5a07e3",
          "key": "BNETDIAG-108",
          "title": "Compare fallback latency without hiding failed attempts",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "handoff",
          "dependsOn": [
            "BNETDIAG-103",
            "BNETDIAG-104",
            "BNETDIAG-105",
            "BNETDIAG-107"
          ],
          "scenario": "A new connection policy appears faster because the report excludes failed IPv6 attempts.",
          "acceptanceCriteria": [
            "Use identical network-condition traces for both policies.",
            "Report end-to-end success, failure, latency, and extra connection work.",
            "Document simulated conditions and unverified real-network behavior."
          ],
          "implementationNotes": [
            "Do not rank policies solely by successful median latency."
          ],
          "verification": [
            "Compare healthy and one-family-failing cases.",
            "Expose additional connection cost and dual-family failure behavior."
          ],
          "deliverables": [
            "Fallback policy assessment."
          ],
          "rollout": "Adopt only for the modeled conditions and retain a configuration rollback.",
          "skills": [
            "Performance methodology",
            "Networking"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7409d699-460e-4f98-8aee-8f8b99a1f8fc",
          "key": "BNETDIAG-109",
          "title": "Generate a shareable network diagnosis bundle",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "BNETDIAG-106",
            "BNETDIAG-108"
          ],
          "scenario": "Support needs a useful report without raw packet payloads.",
          "acceptanceCriteria": [
            "Include tool version, scenario, and safe stage observations.",
            "Link findings to sanitized trace identities.",
            "Bound bundle size and reject forbidden fields."
          ],
          "implementationNotes": [
            "Keep original synthetic trace data separate."
          ],
          "verification": [
            "Build a bundle for a known local failure.",
            "Seed credentials and verify they cannot enter the bundle."
          ],
          "deliverables": [
            "Sanitized diagnosis bundle."
          ],
          "rollout": "Review the bundle schema before any real support collection.",
          "skills": [
            "Diagnostics",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "395985ea-05a3-48f1-bf79-d99a766adcf9",
          "key": "BNETDIAG-110",
          "title": "Write a troubleshooting decision tree with inconclusive exits",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "handoff",
          "dependsOn": [
            "BNETDIAG-109"
          ],
          "scenario": "Support scripts force every connection failure into a known cause.",
          "acceptanceCriteria": [
            "Separate DNS, connect, TLS, and HTTP branches.",
            "Include evidence needed for each next step.",
            "Provide an inconclusive result when observations are insufficient."
          ],
          "implementationNotes": [
            "Every active check stays inside the authorized local lab."
          ],
          "verification": [
            "Follow the tree for a modeled family failure.",
            "Stop inconclusively for missing telemetry."
          ],
          "deliverables": [
            "Network troubleshooting guide."
          ],
          "rollout": "Keep the guide tied to implemented diagnostics and declared limits.",
          "skills": [
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "Networking",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "7dedf604-7124-4e19-9376-9b04b468e3ad",
      "key": "BAPIVER",
      "title": "Public API version transition",
      "field": "API design",
      "summary": "Evolve a partner API with explicit compatibility, deprecation, and client migration contracts.",
      "context": "A fictional inventory platform must replace a legacy availability response. Existing partners upgrade on different schedules, and the team needs a versioned transition.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "HTTP"
      ],
      "prerequisites": [
        "Create two local API versions and synthetic partner clients with different upgrade schedules; no real partner traffic."
      ],
      "developerValue": "Practice public-contract design, compatible evolution, and client lifecycle management.",
      "companyValue": "Provide a predictable migration that keeps supported integrations inspectable and recoverable.",
      "delivery": "Deliver local versioned contracts, compatibility checks, and a deprecation packet.",
      "phases": [
        {
          "id": "design",
          "title": "Design version semantics",
          "goal": "Identify changes and supported compatibility."
        },
        {
          "id": "implement",
          "title": "Implement coexistence",
          "goal": "Serve explicit contracts and safe migration behavior."
        },
        {
          "id": "retire",
          "title": "Manage deprecation",
          "goal": "Verify client migration and retirement conditions."
        }
      ],
      "tickets": [
        {
          "id": "3aac7642-5850-464f-9bcd-ffecd89b2df8",
          "key": "BAPIVER-101",
          "title": "Inventory breaking and additive availability-contract changes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "design",
          "dependsOn": [],
          "scenario": "The proposed response renames fields and changes unknown stock from null to zero.",
          "acceptanceCriteria": [
            "Classify each request and response change.",
            "Preserve unknown versus zero semantics.",
            "Identify supported legacy behavior explicitly."
          ],
          "implementationNotes": [
            "Use actual local contract examples rather than general compatibility slogans."
          ],
          "verification": [
            "Classify an optional additive field.",
            "Flag a meaning-changing null-to-zero conversion."
          ],
          "deliverables": [
            "Contract change inventory."
          ],
          "rollout": "Review the inventory before choosing a versioning approach.",
          "skills": [
            "API compatibility"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "67ed328e-e997-4276-bec3-a7b036f2fcac",
          "key": "BAPIVER-102",
          "title": "Define version selection and unsupported-version errors",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "design",
          "dependsOn": [
            "BAPIVER-101"
          ],
          "scenario": "Clients cannot tell which contract a request will receive.",
          "acceptanceCriteria": [
            "Choose one explicit version selection rule.",
            "Document a deterministic default only if retained intentionally.",
            "Return structured errors for unsupported versions."
          ],
          "implementationNotes": [
            "Keep routes under /api/v1 and /api/v2 in the scenario."
          ],
          "verification": [
            "Request each supported version.",
            "Request an unknown version and inspect its documented problem response."
          ],
          "deliverables": [
            "Version selection contract."
          ],
          "rollout": "Introduce explicit selection before changing existing defaults.",
          "skills": [
            "REST design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "bd1370bd-be60-4017-9812-eb8426573d40",
          "key": "BAPIVER-103",
          "title": "Keep legacy and new projections over one domain authority",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "implement",
          "dependsOn": [
            "BAPIVER-102"
          ],
          "scenario": "Separate version handlers duplicate inventory rules and begin disagreeing.",
          "acceptanceCriteria": [
            "Share domain availability calculation.",
            "Map into distinct immutable transport schemas.",
            "Preserve version-specific unknown-state semantics."
          ],
          "implementationNotes": [
            "Controllers cannot bypass tenant-scoped service reads."
          ],
          "verification": [
            "Project one domain result into both versions.",
            "Deny cross-tenant reads through either route."
          ],
          "deliverables": [
            "Versioned projection boundary."
          ],
          "rollout": "Ship the new projection alongside the old; retain identical domain invariants.",
          "skills": [
            "Architecture",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d68e7df7-a9c4-455a-a0a5-640ea6289750",
          "key": "BAPIVER-104",
          "title": "Use Problem Details for versioned validation failures",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "implement",
          "dependsOn": [
            "BAPIVER-103"
          ],
          "scenario": "Partners parse changing human messages to detect invalid warehouse filters.",
          "acceptanceCriteria": [
            "Publish stable problem types and field paths.",
            "Keep instance and request identifiers safe.",
            "Version any materially changed error semantics."
          ],
          "implementationNotes": [
            "Exclude stack traces and internal database details."
          ],
          "verification": [
            "Validate a malformed filter in both versions.",
            "Verify cross-tenant denial reveals no private identifiers."
          ],
          "deliverables": [
            "Error contract examples."
          ],
          "rollout": "Add structured fields compatibly and document client handling.",
          "skills": [
            "Error design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6c06777e-2b8a-4462-8e8b-0f4833141baf",
          "key": "BAPIVER-105",
          "title": "Preserve idempotency semantics across client version upgrades",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "implement",
          "dependsOn": [
            "BAPIVER-103",
            "BAPIVER-104"
          ],
          "scenario": "A client retries an inventory reservation with the same key after upgrading its API version.",
          "acceptanceCriteria": [
            "Define whether keys bind to normalized domain intent or transport version.",
            "Reject conflicting reuse consistently.",
            "Prevent duplicate domain effects across supported routes."
          ],
          "implementationNotes": [
            "Document the chosen scope rather than silently translating incompatible requests."
          ],
          "verification": [
            "Replay equivalent supported requests under the chosen policy.",
            "Reject a changed reservation under the same key."
          ],
          "deliverables": [
            "Cross-version idempotency contract."
          ],
          "rollout": "Retain original operation facts during migration.",
          "skills": [
            "Idempotency",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bd22832d-4482-41ea-868c-73c4a7d5db6a",
          "key": "BAPIVER-106",
          "title": "Generate SDK migration examples from packaged client versions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "implement",
          "dependsOn": [
            "BAPIVER-104",
            "BAPIVER-105"
          ],
          "scenario": "Migration documentation uses methods not present in the released client archive.",
          "acceptanceCriteria": [
            "Compile old and new examples against local packaged clients.",
            "Show equivalent availability and error handling.",
            "Document changed optional and nullable fields."
          ],
          "implementationNotes": [
            "Use local archives and mock servers only."
          ],
          "verification": [
            "Run both documented examples.",
            "Detect a snippet importing a removed method."
          ],
          "deliverables": [
            "Executable SDK migration examples."
          ],
          "rollout": "Publish examples with the matching contract revision.",
          "skills": [
            "SDK lifecycle",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9b9473c4-4dc7-4c27-9c67-994466dca3d8",
          "key": "BAPIVER-107",
          "title": "Expose deprecation signals without breaking successful responses",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "retire",
          "dependsOn": [
            "BAPIVER-106"
          ],
          "scenario": "Partners need machine-readable notice that the old version has a planned sunset.",
          "acceptanceCriteria": [
            "Document deprecation metadata and dates.",
            "Keep response behavior compatible during support.",
            "Link a versioned migration guide."
          ],
          "implementationNotes": [
            "Dates are fictional scenario inputs and must be labeled in fixtures."
          ],
          "verification": [
            "Read a legacy response with deprecation metadata.",
            "Verify the new version does not carry an incorrect retirement notice."
          ],
          "deliverables": [
            "Deprecation response contract."
          ],
          "rollout": "Enable notice before any retirement gate.",
          "skills": [
            "API lifecycle"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "14dd8cba-1d1a-45dd-851e-d365f318015b",
          "key": "BAPIVER-108",
          "title": "Measure version adoption using bounded non-sensitive metadata",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "retire",
          "dependsOn": [
            "BAPIVER-107"
          ],
          "scenario": "The team wants to know whether supported clients still use the old version without collecting request bodies.",
          "acceptanceCriteria": [
            "Count requests by declared client class and API version.",
            "Track unknown client versions separately.",
            "Exclude tokens, payloads, and personal identifiers."
          ],
          "implementationNotes": [
            "Do not equate no observed traffic with confirmed migration."
          ],
          "verification": [
            "Report synthetic mixed-version traffic.",
            "Show an inactive client as unknown rather than migrated."
          ],
          "deliverables": [
            "Adoption report."
          ],
          "rollout": "Use counts as one input to retirement review; preserve explicit client support records.",
          "skills": [
            "Observability",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "70a1e47b-b7fc-4969-966f-e9e9785b45e5",
          "key": "BAPIVER-109",
          "title": "Decide retirement with client obligations and rollback constraints",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "retire",
          "dependsOn": [
            "BAPIVER-105",
            "BAPIVER-108"
          ],
          "scenario": "The old API has little traffic but one supported partner still relies on its unknown-stock behavior.",
          "acceptanceCriteria": [
            "Define retirement criteria beyond traffic volume.",
            "Compare support cost, partner migration risk, and data compatibility.",
            "Rehearse restoring legacy routing after a failed retirement."
          ],
          "implementationNotes": [
            "Keep unsupported assumptions visible; no actual partner notifications are sent."
          ],
          "verification": [
            "Retire a fully migrated synthetic client set.",
            "Block retirement when a supported dependency remains unresolved."
          ],
          "deliverables": [
            "API retirement decision record."
          ],
          "rollout": "Use a staged local retirement and retain tested legacy artifacts through the rollback window.",
          "skills": [
            "API strategy",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 20
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "16bca313-38b5-4c15-b9b1-399deaedc2c1",
          "key": "BAPIVER-110",
          "title": "Write the partner migration checklist with observable completion",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "retire",
          "dependsOn": [
            "BAPIVER-109"
          ],
          "scenario": "A checklist saying 'upgrade the SDK' misses changed error and unknown-state handling.",
          "acceptanceCriteria": [
            "List client-code, error, and data-semantic changes.",
            "Include local verification commands.",
            "Define completion through exercised operations."
          ],
          "implementationNotes": [
            "Do not claim a partner migrated without recorded confirmation."
          ],
          "verification": [
            "Migrate the synthetic client using the checklist.",
            "Catch a client still treating unknown stock as zero."
          ],
          "deliverables": [
            "Partner migration guide."
          ],
          "rollout": "Version the guide and retain legacy instructions for supported clients.",
          "skills": [
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "8e2589ff-c0f5-4704-8288-1dff41c049c8",
      "key": "BAPIBULK",
      "title": "Asynchronous bulk API contract",
      "field": "API design",
      "summary": "Design bulk record imports with explicit operation state, item errors, and recovery semantics.",
      "context": "A fictional catalog API needs to accept imports too large for one synchronous request. Partners need to distinguish accepted work, completed items, and recoverable failures.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local API and worker double with synthetic catalog records and controlled interruption points."
      ],
      "developerValue": "Practice asynchronous resource contracts, partial outcomes, and idempotent operations.",
      "companyValue": "Provide predictable bulk integration behavior without ambiguous success or repeated effects.",
      "delivery": "Deliver local bulk endpoints, operation transitions, and public client examples.",
      "phases": [
        {
          "id": "contract",
          "title": "Define operation resources",
          "goal": "Specify admission, identities, and lifecycle semantics."
        },
        {
          "id": "process",
          "title": "Process bounded work",
          "goal": "Handle item outcomes, cancellation, and recovery."
        },
        {
          "id": "client",
          "title": "Support clients",
          "goal": "Expose safe progress and lifecycle guidance."
        }
      ],
      "tickets": [
        {
          "id": "fba83ad4-ac1d-490a-8e98-44314d90eb67",
          "key": "BAPIBULK-101",
          "title": "Define the difference between accepted and completed bulk work",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "The current endpoint returns success before any imported row has been validated.",
          "acceptanceCriteria": [
            "Publish accepted, running, completed, and failed meanings.",
            "Define terminal partial-success representation.",
            "Keep transport acceptance separate from item validity."
          ],
          "implementationNotes": [
            "Use explicit operation transition methods."
          ],
          "verification": [
            "Represent an accepted unprocessed import.",
            "Show completed-with-errors without claiming every item succeeded."
          ],
          "deliverables": [
            "Bulk operation schema."
          ],
          "rollout": "Review lifecycle vocabulary before adding endpoints.",
          "skills": [
            "API modeling"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6df20f71-1f85-475e-9961-91b826121fe2",
          "key": "BAPIBULK-102",
          "title": "Bound bulk request size and record counts before admission",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [
            "BAPIBULK-101"
          ],
          "scenario": "A single import can exhaust parser memory before validation runs.",
          "acceptanceCriteria": [
            "Enforce byte and item-count ceilings.",
            "Validate envelope schema before queueing work.",
            "Return structured errors without echoing the payload."
          ],
          "implementationNotes": [
            "Use streamed or bounded parsing appropriate to the fixture."
          ],
          "verification": [
            "Accept an import at the declared limit.",
            "Reject oversized and malformed requests before creating work."
          ],
          "deliverables": [
            "Admission validator."
          ],
          "rollout": "Start with conservative limits and explicit client guidance.",
          "skills": [
            "Resource bounds",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4c15e2d4-cf5e-421a-938d-a59ab8326202",
          "key": "BAPIBULK-103",
          "title": "Create bulk operations with tenant-scoped idempotency",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "contract",
          "dependsOn": [
            "BAPIBULK-102"
          ],
          "scenario": "A timeout after admission causes the partner to submit the same catalog import again.",
          "acceptanceCriteria": [
            "Bind key to tenant and canonical request digest.",
            "Return the existing operation on exact replay.",
            "Reject changed input under the same key."
          ],
          "implementationNotes": [
            "Commit operation and dispatch intent atomically."
          ],
          "verification": [
            "Replay a lost admission response.",
            "Race conflicting requests and preserve one operation identity."
          ],
          "deliverables": [
            "Bulk admission command."
          ],
          "rollout": "Keep operation identity stable through retries.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0223718a-bcd7-4976-9cc1-12de5720b3d1",
          "key": "BAPIBULK-104",
          "title": "Return per-item problems without exposing other tenant records",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "process",
          "dependsOn": [
            "BAPIBULK-103"
          ],
          "scenario": "An item conflict response includes details about a catalog record owned by another tenant.",
          "acceptanceCriteria": [
            "Authorize each item at the service boundary.",
            "Use stable item references and safe problem types.",
            "Avoid disclosing foreign record existence."
          ],
          "implementationNotes": [
            "Item IDs supplied by clients are untrusted labels."
          ],
          "verification": [
            "Import authorized updates and invalid items together.",
            "Attempt a cross-tenant item and verify safe denial."
          ],
          "deliverables": [
            "Per-item outcome contract."
          ],
          "rollout": "Block imports with tenant-boundary regressions before expanding item types.",
          "skills": [
            "Authorization",
            "Error design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "df3d070b-2848-4a7d-9a05-3233a7c8e34e",
          "key": "BAPIBULK-105",
          "title": "Checkpoint item progress without changing retry outcomes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "process",
          "dependsOn": [
            "BAPIBULK-104"
          ],
          "scenario": "A worker restart reapplies successful items and duplicates side effects.",
          "acceptanceCriteria": [
            "Persist committed item outcomes with operation identity.",
            "Resume only incomplete items.",
            "Return the original result for exact processed-item replay."
          ],
          "implementationNotes": [
            "Bound item batches and transaction duration."
          ],
          "verification": [
            "Interrupt after a committed batch and resume.",
            "Retry a successful item and verify unchanged effects."
          ],
          "deliverables": [
            "Resumable bulk processor."
          ],
          "rollout": "Retain checkpoints and immutable terminal item outcomes.",
          "skills": [
            "Batch processing",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c587f1ed-4e7c-40fb-b375-1ca36a9cc536",
          "key": "BAPIBULK-106",
          "title": "Define cancellation after some items have committed",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "process",
          "dependsOn": [
            "BAPIBULK-105"
          ],
          "scenario": "Clients assume cancelling an import undoes all previous item updates.",
          "acceptanceCriteria": [
            "Document cancellation as stopping future work unless compensation exists.",
            "Preserve committed outcomes.",
            "Resolve cancellation-versus-completion races explicitly."
          ],
          "implementationNotes": [
            "Do not silently roll back unrelated later changes."
          ],
          "verification": [
            "Cancel after two items commit.",
            "Race cancellation with final completion and produce one terminal state."
          ],
          "deliverables": [
            "Cancellation contract."
          ],
          "rollout": "Expose committed counts before accepting cancellation.",
          "skills": [
            "State transitions",
            "API semantics"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "74c6ed43-3c83-4aea-8e98-39087d4550b0",
          "key": "BAPIBULK-107",
          "title": "Paginate bulk item outcomes with stable ordering",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "process",
          "dependsOn": [
            "BAPIBULK-104",
            "BAPIBULK-105"
          ],
          "scenario": "Large result lists exceed response limits and change order while the client reads them.",
          "acceptanceCriteria": [
            "Use stable operation-scoped ordering.",
            "Bound page sizes and cursor lifetime.",
            "Bind cursors to tenant, operation, and filter."
          ],
          "implementationNotes": [
            "Do not place raw item payloads in cursors."
          ],
          "verification": [
            "Read all outcomes without duplicates.",
            "Reject a cursor reused for another operation or tenant."
          ],
          "deliverables": [
            "Outcome pagination endpoint."
          ],
          "rollout": "Keep terminal result pages immutable within retention.",
          "skills": [
            "Pagination",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "664e163e-e1f0-4c93-97eb-2ef910a8b2bb",
          "key": "BAPIBULK-108",
          "title": "Expose progress that does not imply unobserved completion",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "client",
          "dependsOn": [
            "BAPIBULK-106",
            "BAPIBULK-107"
          ],
          "scenario": "The UI computes ninety-nine percent from queued jobs even when several items are unresolved.",
          "acceptanceCriteria": [
            "Report accepted, committed, failed, and pending counts.",
            "Reconcile totals under declared semantics.",
            "Show unknown progress when observations are incomplete."
          ],
          "implementationNotes": [
            "Avoid a fabricated precise completion estimate."
          ],
          "verification": [
            "Display partial progress from known outcomes.",
            "Detect inconsistent counters and return an unavailable projection."
          ],
          "deliverables": [
            "Safe progress projection."
          ],
          "rollout": "Use authoritative counters and stop polling on terminal states.",
          "skills": [
            "API projections"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b261a0b0-97d5-498c-942a-1c99b06ba0a2",
          "key": "BAPIBULK-109",
          "title": "Choose atomic or partial bulk semantics for dependent items",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "client",
          "dependsOn": [
            "BAPIBULK-104",
            "BAPIBULK-106",
            "BAPIBULK-108"
          ],
          "scenario": "Some imports contain parent and child catalog records, making arbitrary independent item processing unsafe.",
          "acceptanceCriteria": [
            "Define the supported dependency boundary.",
            "Compare whole-request atomicity, ordered groups, and independent items.",
            "Document transaction, recovery, and client complexity tradeoffs."
          ],
          "implementationNotes": [
            "Bound the decision to the synthetic catalog use case."
          ],
          "verification": [
            "Import a valid parent-child group.",
            "Reject or explicitly report a missing-parent group under the chosen semantics."
          ],
          "deliverables": [
            "Bulk semantics decision record."
          ],
          "rollout": "Start with the smallest supported grouping and reject unsupported dependency patterns.",
          "skills": [
            "API architecture",
            "Tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0156b062-92c8-455f-aed0-ca3299954881",
          "key": "BAPIBULK-110",
          "title": "Publish a bulk client example covering timeout and partial failure",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "client",
          "dependsOn": [
            "BAPIBULK-109"
          ],
          "scenario": "Partners have only a happy-path example that treats HTTP acceptance as completion.",
          "acceptanceCriteria": [
            "Show admission retry with one idempotency key.",
            "Poll to a terminal operation state.",
            "Inspect item errors and retained committed results."
          ],
          "implementationNotes": [
            "Use local mock data and no credentials."
          ],
          "verification": [
            "Run a successful example.",
            "Run timeout, partial failure, and cancellation examples without duplicate submissions."
          ],
          "deliverables": [
            "Executable bulk client guide."
          ],
          "rollout": "Version the example with the operation contract.",
          "skills": [
            "SDK design",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "29a64a20-2cb2-41f8-afc9-8685fde8b8b0",
      "key": "BAPIPAGE",
      "title": "Consistent query and pagination API",
      "field": "API design",
      "summary": "Expose a changing catalog through bounded filters, stable cursors, and explicit consistency.",
      "context": "A fictional logistics platform lists shipments for partner dashboards. Offset pagination duplicates records during updates, while unrestricted filters create expensive database queries.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local shipment dataset with synthetic tenants, equal timestamps, and concurrent update fixtures."
      ],
      "developerValue": "Practice cursor design, query contracts, and consistency/performance tradeoffs.",
      "companyValue": "Provide predictable list APIs that remain bounded and preserve tenant scope.",
      "delivery": "Deliver a local versioned listing endpoint and documented client iteration behavior.",
      "phases": [
        {
          "id": "query",
          "title": "Define query semantics",
          "goal": "Specify supported filters, sorting, and authorization."
        },
        {
          "id": "cursor",
          "title": "Implement stable traversal",
          "goal": "Bind cursors and handle concurrent data changes."
        },
        {
          "id": "review",
          "title": "Review contract limits",
          "goal": "Measure query plans and document consistency."
        }
      ],
      "tickets": [
        {
          "id": "8e05903c-9a17-41d1-be86-e6d7d3d9eaed",
          "key": "BAPIPAGE-101",
          "title": "Define supported shipment filters and their exact semantics",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "query",
          "dependsOn": [],
          "scenario": "Different clients interpret date ranges and empty status lists differently.",
          "acceptanceCriteria": [
            "Specify inclusive and exclusive boundaries.",
            "Distinguish absent from empty filters.",
            "Reject unsupported filter properties."
          ],
          "implementationNotes": [
            "Use UTC instants for timestamp filters."
          ],
          "verification": [
            "Exercise a boundary timestamp.",
            "Reject an empty status list if the contract declares it invalid."
          ],
          "deliverables": [
            "Filter contract."
          ],
          "rollout": "Publish explicit examples before replacing legacy behavior.",
          "skills": [
            "API design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b8e92724-56d7-4d2e-85ef-c7768dd0c094",
          "key": "BAPIPAGE-102",
          "title": "Validate bounded sort options instead of accepting SQL fragments",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "query",
          "dependsOn": [
            "BAPIPAGE-101"
          ],
          "scenario": "Clients can pass arbitrary sort expressions into query construction.",
          "acceptanceCriteria": [
            "Allowlist sort fields and directions.",
            "Use parameterized query construction.",
            "Append a stable unique tie-breaker."
          ],
          "implementationNotes": [
            "Never concatenate untrusted SQL."
          ],
          "verification": [
            "Sort equal timestamps deterministically.",
            "Reject an expression-shaped sort value."
          ],
          "deliverables": [
            "Safe sort parser."
          ],
          "rollout": "Adopt on the new endpoint first; keep unknown sorts rejected.",
          "skills": [
            "Input validation",
            "SQL"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "969006e0-82f1-47b6-863c-c7a6bacc4c99",
          "key": "BAPIPAGE-103",
          "title": "Enforce tenant scope before applying user filters",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "query",
          "dependsOn": [
            "BAPIPAGE-102"
          ],
          "scenario": "An optional organization filter can replace the caller's tenant predicate.",
          "acceptanceCriteria": [
            "Derive tenant from authenticated context.",
            "Apply scope in repository queries.",
            "Keep client filters unable to widen authority."
          ],
          "implementationNotes": [
            "Unauthorized records must not influence totals."
          ],
          "verification": [
            "List owned shipments with several filters.",
            "Attempt foreign-tenant filtering and verify non-disclosure."
          ],
          "deliverables": [
            "Scoped query repository."
          ],
          "rollout": "Gate all listing variants on cross-tenant denial checks.",
          "skills": [
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "10c1fef9-3575-4332-9126-c8cacfa0d8f0",
          "key": "BAPIPAGE-104",
          "title": "Encode opaque cursors bound to the normalized query",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "cursor",
          "dependsOn": [
            "BAPIPAGE-101",
            "BAPIPAGE-102",
            "BAPIPAGE-103"
          ],
          "scenario": "A cursor from one status filter is reused with another and skips records.",
          "acceptanceCriteria": [
            "Bind cursor to tenant, sort, filter digest, and position.",
            "Validate schema, size, integrity, and expiry.",
            "Return a stable invalid-cursor problem."
          ],
          "implementationNotes": [
            "Opaque encoding alone is not integrity protection."
          ],
          "verification": [
            "Continue a matching query.",
            "Reject tampered, expired, and cross-query cursors."
          ],
          "deliverables": [
            "Cursor contract."
          ],
          "rollout": "Version cursors and retain support only for declared compatible versions.",
          "skills": [
            "Cursor design",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f21744ab-3606-40e0-998f-d2dadd762010",
          "key": "BAPIPAGE-105",
          "title": "Use keyset traversal for shipments sharing timestamps",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "cursor",
          "dependsOn": [
            "BAPIPAGE-104"
          ],
          "scenario": "Pagination drops shipments when several rows have the same update timestamp.",
          "acceptanceCriteria": [
            "Compare the complete sort tuple.",
            "Use the unique tie-breaker consistently in both directions.",
            "Avoid duplicate boundary rows."
          ],
          "implementationNotes": [
            "Indexes must match the declared ordering."
          ],
          "verification": [
            "Traverse a fixture with many equal timestamps.",
            "Verify no omission or duplication at page boundaries."
          ],
          "deliverables": [
            "Keyset query implementation."
          ],
          "rollout": "Compare full traversal against a fixed fixture before replacing offsets.",
          "skills": [
            "Database queries"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f6304386-0c3e-4f2e-a8c6-8f4705f20045",
          "key": "BAPIPAGE-106",
          "title": "Define how mutable shipment updates affect an active traversal",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "cursor",
          "dependsOn": [
            "BAPIPAGE-105"
          ],
          "scenario": "A shipment changes status between pages, and partners expect a snapshot the endpoint never promised.",
          "acceptanceCriteria": [
            "Compare live traversal, snapshot boundary, and export-resource options.",
            "Choose explicit consistency semantics for this endpoint.",
            "Document duplicate or omission risks that remain."
          ],
          "implementationNotes": [
            "Do not claim snapshot consistency without implementing its data boundary."
          ],
          "verification": [
            "Update a shipment between pages under the chosen model.",
            "Verify observed behavior matches the documented guarantee."
          ],
          "deliverables": [
            "Pagination consistency decision record."
          ],
          "rollout": "Introduce the consistency contract before clients depend on stable exports.",
          "skills": [
            "Consistency",
            "API architecture"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c7d39be5-e77a-4148-888f-82efe5e0018a",
          "key": "BAPIPAGE-107",
          "title": "Bound total-count work independently of result pagination",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "cursor",
          "dependsOn": [
            "BAPIPAGE-103",
            "BAPIPAGE-105"
          ],
          "scenario": "A fast first page still waits for an expensive exact count.",
          "acceptanceCriteria": [
            "Make count behavior explicit and optional if appropriate.",
            "Bound count execution time.",
            "Distinguish unavailable or estimated totals from exact totals."
          ],
          "implementationNotes": [
            "Never label an estimate as an exact count."
          ],
          "verification": [
            "Return a page without optional count work.",
            "Timeout count calculation without misreporting zero results."
          ],
          "deliverables": [
            "Count contract."
          ],
          "rollout": "Default to the least expensive contract satisfying the use case.",
          "skills": [
            "Query performance"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a0857ffa-6b96-4052-b918-837c0d51d625",
          "key": "BAPIPAGE-108",
          "title": "Review query plans for supported high-cardinality filters",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "review",
          "dependsOn": [
            "BAPIPAGE-105",
            "BAPIPAGE-107"
          ],
          "scenario": "A permitted filter scans every shipment despite bounded page size.",
          "acceptanceCriteria": [
            "Capture plans against a declared synthetic dataset.",
            "Check indexes for supported filter/sort combinations.",
            "Report dataset size, cache state, and machine limits."
          ],
          "implementationNotes": [
            "Local query plans are evidence for the fixture, not production latency guarantees."
          ],
          "verification": [
            "Measure a selective and broad query.",
            "Identify a missing-index case and compare the corrected plan."
          ],
          "deliverables": [
            "Query-plan review."
          ],
          "rollout": "Add indexes through migrations; retain a rollback plan for index changes.",
          "skills": [
            "PostgreSQL",
            "Performance"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3fc7f3ef-5274-463c-b930-955e06e39eed",
          "key": "BAPIPAGE-109",
          "title": "Provide a resumable iterator that stops on cursor expiry",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "review",
          "dependsOn": [
            "BAPIPAGE-104",
            "BAPIPAGE-106",
            "BAPIPAGE-108"
          ],
          "scenario": "The client SDK retries invalid cursors forever instead of telling callers to restart.",
          "acceptanceCriteria": [
            "Expose bounded async iteration with cancellation.",
            "Stop on terminal and invalid-cursor responses.",
            "Document restart behavior under the consistency contract."
          ],
          "implementationNotes": [
            "Do not silently restart and merge potentially duplicated records."
          ],
          "verification": [
            "Iterate a complete synthetic result set.",
            "Expire a cursor mid-run and surface the documented error."
          ],
          "deliverables": [
            "Client iterator example."
          ],
          "rollout": "Release with explicit cursor-lifecycle documentation.",
          "skills": [
            "SDK design"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "17b76fdd-5a75-4be1-a6d5-3aab9bc64212",
          "key": "BAPIPAGE-110",
          "title": "Document list versus export guarantees for partner dashboards",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "review",
          "dependsOn": [
            "BAPIPAGE-109"
          ],
          "scenario": "Partners use an interactive list endpoint as if it were a financial or audit export.",
          "acceptanceCriteria": [
            "State ordering, freshness, and traversal guarantees.",
            "List unsupported snapshot assumptions.",
            "Show the appropriate restart and bounded export approach."
          ],
          "implementationNotes": [
            "No legal or financial completeness claims."
          ],
          "verification": [
            "Follow the guide for a changing dashboard list.",
            "Identify a use case requiring a separate snapshot export."
          ],
          "deliverables": [
            "Query API usage guide."
          ],
          "rollout": "Keep examples aligned with implemented consistency behavior.",
          "skills": [
            "Technical writing"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 100
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "57c9682e-7fce-4003-8c0b-0e09f8ee3bb3",
      "key": "BAPIAUTH",
      "title": "Delegated partner API access",
      "field": "API design",
      "summary": "Design scoped partner credentials with revocation, safe errors, and client lifecycle controls.",
      "context": "A fictional operations platform lets customers connect automation clients. Broad API keys and inconsistent tenant checks make delegated access difficult to review.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local authorization service and synthetic partner clients for two organizations; generate disposable test credentials only."
      ],
      "developerValue": "Practice delegated authorization, resource scoping, and secure public API ergonomics.",
      "companyValue": "Provide usable partner access that remains least-privilege and revocable.",
      "delivery": "Deliver local credential and access contracts; connect no real partner account.",
      "phases": [
        {
          "id": "scope",
          "title": "Define delegated authority",
          "goal": "Separate actor, organization, client, and permission scope."
        },
        {
          "id": "access",
          "title": "Enforce access",
          "goal": "Validate resource authority and token lifecycle."
        },
        {
          "id": "operate",
          "title": "Support client operations",
          "goal": "Handle rotation, auditing, and migration."
        }
      ],
      "tickets": [
        {
          "id": "ce6b449b-4a6b-4470-b1c0-ec6e086d1290",
          "key": "BAPIAUTH-101",
          "title": "Define partner scopes from concrete API operations",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "scope",
          "dependsOn": [],
          "scenario": "A single automation scope permits every operation in the organization.",
          "acceptanceCriteria": [
            "Map scopes to specific operation classes.",
            "Separate read, write, and administrative authority.",
            "Document unsupported scope combinations."
          ],
          "implementationNotes": [
            "Do not derive permissions from client-provided role names."
          ],
          "verification": [
            "Authorize a read-only synthetic client.",
            "Deny a write under the read-only scope."
          ],
          "deliverables": [
            "Partner scope matrix."
          ],
          "rollout": "Review least-privilege defaults before issuing credentials.",
          "skills": [
            "Authorization design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ccd9c24e-4f1e-424f-a050-2cf39315c248",
          "key": "BAPIAUTH-102",
          "title": "Bind delegated credentials to organization and client identity",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "scope",
          "dependsOn": [
            "BAPIAUTH-101"
          ],
          "scenario": "A valid credential can be paired with another organization ID in the URL.",
          "acceptanceCriteria": [
            "Store organization and client authority server-side.",
            "Require exact binding on each service call.",
            "Reject caller attempts to substitute actor identity."
          ],
          "implementationNotes": [
            "Opaque credentials are never interpreted as authorization claims without lookup or verification."
          ],
          "verification": [
            "Call an owned resource.",
            "Reuse the credential against another organization and deny safely."
          ],
          "deliverables": [
            "Credential authority model."
          ],
          "rollout": "Fail closed on missing client or membership authority.",
          "skills": [
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f58521d3-f1aa-4fc0-91b9-0c91aacd3724",
          "key": "BAPIAUTH-103",
          "title": "Return non-enumerating errors for unauthorized partner resources",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "access",
          "dependsOn": [
            "BAPIAUTH-102"
          ],
          "scenario": "Partners can distinguish nonexistent records from records belonging to another organization.",
          "acceptanceCriteria": [
            "Define stable safe denial semantics.",
            "Keep error bodies free of foreign identifiers.",
            "Preserve internal diagnostic categories separately."
          ],
          "implementationNotes": [
            "Use Problem Details-style public errors."
          ],
          "verification": [
            "Read an authorized record.",
            "Compare missing and foreign-record public responses."
          ],
          "deliverables": [
            "Partner error contract."
          ],
          "rollout": "Use the same safe projection across all resource endpoints.",
          "skills": [
            "Error design",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "27057922-a6df-4324-9c92-328e2882be5e",
          "key": "BAPIAUTH-104",
          "title": "Enforce authorization in nested and batch partner operations",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "access",
          "dependsOn": [
            "BAPIAUTH-102",
            "BAPIAUTH-103"
          ],
          "scenario": "The parent resource is authorized, but nested record IDs bypass tenant checks.",
          "acceptanceCriteria": [
            "Reauthorize every nested resource at the service boundary.",
            "Define atomic or per-item denial behavior.",
            "Prevent unauthorized items from influencing result totals."
          ],
          "implementationNotes": [
            "Client-supplied parent-child relationships are untrusted."
          ],
          "verification": [
            "Process a valid nested update.",
            "Insert a foreign child ID and verify the declared denial behavior."
          ],
          "deliverables": [
            "Nested authorization regression."
          ],
          "rollout": "Gate batch rollout on cross-tenant and relationship checks.",
          "skills": [
            "Authorization",
            "API consistency"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8f0920d4-7b6c-4da8-96f8-dc8b27d7fb00",
          "key": "BAPIAUTH-105",
          "title": "Rotate partner credentials without indefinite dual-key access",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "access",
          "dependsOn": [
            "BAPIAUTH-102",
            "BAPIAUTH-104"
          ],
          "scenario": "Customers need rotation overlap, but old keys remain valid forever.",
          "acceptanceCriteria": [
            "Issue a distinct new credential generation.",
            "Set an explicit overlap expiry for the old generation.",
            "Show generation status without exposing credential values."
          ],
          "implementationNotes": [
            "Reveal a generated test credential only through the intended creation response."
          ],
          "verification": [
            "Use both generations during overlap.",
            "Reject the old generation after expiry."
          ],
          "deliverables": [
            "Credential rotation workflow."
          ],
          "rollout": "Keep overlap bounded and auditable; never restore retired credentials silently.",
          "skills": [
            "Credential lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "489ea678-167f-4289-8fa5-a27bdff07fd7",
          "key": "BAPIAUTH-106",
          "title": "Revoke partner access across cached authorization decisions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "access",
          "dependsOn": [
            "BAPIAUTH-105"
          ],
          "scenario": "Revoked clients retain access until a long cache TTL expires.",
          "acceptanceCriteria": [
            "Bind caches to current authorization revision.",
            "Recheck or invalidate revoked authority within the declared bound.",
            "Deny new operations after revocation."
          ],
          "implementationNotes": [
            "Cached membership is not permanent authority."
          ],
          "verification": [
            "Serve a current authorized cache entry.",
            "Revoke the client and verify cached access stops within policy."
          ],
          "deliverables": [
            "Revocation-aware authorization cache."
          ],
          "rollout": "Prioritize denial when revision freshness is unavailable.",
          "skills": [
            "Caching",
            "Revocation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "aa46adbb-a2af-4650-94d8-2db69aa9ba38",
          "key": "BAPIAUTH-107",
          "title": "Rate-limit by delegated client without losing tenant-wide protection",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BAPIAUTH-104",
            "BAPIAUTH-106"
          ],
          "scenario": "Creating many client keys bypasses a per-key request limit.",
          "acceptanceCriteria": [
            "Apply both client and organization budgets.",
            "Return documented retry guidance.",
            "Keep denied requests from consuming unrelated client authority."
          ],
          "implementationNotes": [
            "Use deterministic local counters and no customer profiling."
          ],
          "verification": [
            "Exercise separate clients within the organization ceiling.",
            "Create multiple clients and verify the shared cap holds."
          ],
          "deliverables": [
            "Delegated rate-limit contract."
          ],
          "rollout": "Start with published conservative limits and inspect false rejection cases.",
          "skills": [
            "API limits"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "37721d78-a253-469f-b2db-dda6b3ec8cec",
          "key": "BAPIAUTH-108",
          "title": "Expose an audit trail of privileged partner-client changes",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "BAPIAUTH-105",
            "BAPIAUTH-106"
          ],
          "scenario": "Organization owners cannot see who expanded a client scope.",
          "acceptanceCriteria": [
            "Append actor, client, changed scope, and UTC time.",
            "Exclude tokens and request payloads.",
            "Scope audit reads to current authorized organization members."
          ],
          "implementationNotes": [
            "Do not overwrite previous audit facts."
          ],
          "verification": [
            "Inspect a credential rotation and scope change.",
            "Deny a cross-organization audit read."
          ],
          "deliverables": [
            "Partner access audit projection."
          ],
          "rollout": "Enable audit recording before scope mutation endpoints.",
          "skills": [
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ad7b4211-2bf6-453b-9d9b-db612015168f",
          "key": "BAPIAUTH-109",
          "title": "Design migration from broad keys to scoped delegated clients",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "BAPIAUTH-107",
            "BAPIAUTH-108"
          ],
          "scenario": "Existing integrations depend on broad keys and cannot all migrate at once.",
          "acceptanceCriteria": [
            "Inventory actual required operations through safe synthetic usage records.",
            "Define staged scope reduction and client cutover.",
            "Compare compatibility burden with the risk of retained broad authority."
          ],
          "implementationNotes": [
            "No real partner usage is inferred from absence of traffic."
          ],
          "verification": [
            "Migrate two synthetic clients with different needs.",
            "Keep an unknown integration unresolved instead of silently revoking or broadening it."
          ],
          "deliverables": [
            "Delegated-access migration plan."
          ],
          "rollout": "Use explicit reviewed deadlines and retain a bounded recovery process.",
          "skills": [
            "API strategy",
            "Security tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b0425786-d306-4067-906d-f3899996da55",
          "key": "BAPIAUTH-110",
          "title": "Write a partner credential handling example for rotation and denial",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "operate",
          "dependsOn": [
            "BAPIAUTH-109"
          ],
          "scenario": "Documentation encourages hardcoding keys and retrying every unauthorized response.",
          "acceptanceCriteria": [
            "Read credentials from the intended runtime boundary.",
            "Handle expiry and revocation without infinite retries.",
            "Show safe rotation using local test credentials."
          ],
          "implementationNotes": [
            "Examples must not log authorization headers."
          ],
          "verification": [
            "Run the example through a valid rotation.",
            "Revoke access and verify a terminal actionable error."
          ],
          "deliverables": [
            "Executable partner access guide."
          ],
          "rollout": "Version examples with the credential contract and remove obsolete broad-key guidance.",
          "skills": [
            "SDK ergonomics",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "12ba592f-1c32-4fe8-bb2b-0c964762cf36",
      "key": "BAPIHOOK",
      "title": "Public webhook delivery contract",
      "field": "API design",
      "summary": "Expose event subscriptions with immutable envelopes, bounded delivery, and safe replay.",
      "context": "A fictional logistics platform sends shipment events to partner endpoints. Partners need stable schemas and recovery semantics despite duplicate delivery, failures, and subscription changes.",
      "stack": [
        "TypeScript",
        "OpenAPI",
        "HTTP",
        "PostgreSQL"
      ],
      "prerequisites": [
        "Create a local webhook sender and receiver doubles with synthetic shipment events and disposable signing keys."
      ],
      "developerValue": "Practice public event contracts, delivery guarantees, and partner recovery workflows.",
      "companyValue": "Provide inspectable asynchronous integration behavior with controlled retries and clear compatibility.",
      "delivery": "Deliver local subscription and delivery contracts; send no external webhook traffic.",
      "phases": [
        {
          "id": "events",
          "title": "Define public events",
          "goal": "Specify immutable identities, schemas, and subscription authority."
        },
        {
          "id": "deliver",
          "title": "Deliver predictably",
          "goal": "Handle signatures, retries, ordering, and endpoint boundaries."
        },
        {
          "id": "support",
          "title": "Support evolution and replay",
          "goal": "Make recovery and schema migration explicit."
        }
      ],
      "tickets": [
        {
          "id": "20fe4bcb-9fe6-4c23-8665-61c27643a24f",
          "key": "BAPIHOOK-101",
          "title": "Define immutable webhook envelopes independently of database rows",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "events",
          "dependsOn": [],
          "scenario": "Event payloads mirror internal shipment rows and change whenever the schema changes.",
          "acceptanceCriteria": [
            "Publish event ID, type, version, and occurrence time.",
            "Use a deliberate public payload projection.",
            "Preserve emitted event bytes or canonical content identity."
          ],
          "implementationNotes": [
            "Exclude internal fields and hidden operational metadata."
          ],
          "verification": [
            "Create a documented shipment event.",
            "Change an internal-only field without altering the public contract."
          ],
          "deliverables": [
            "Webhook envelope schema."
          ],
          "rollout": "Version public payloads before accepting subscriptions.",
          "skills": [
            "Event API design"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3498cf27-3472-4dae-9044-1f1c9b51984f",
          "key": "BAPIHOOK-102",
          "title": "Authorize subscription creation and event scope per organization",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "events",
          "dependsOn": [
            "BAPIHOOK-101"
          ],
          "scenario": "A caller can subscribe its endpoint to another organization's shipment events.",
          "acceptanceCriteria": [
            "Derive organization scope from authenticated authority.",
            "Validate permitted event types.",
            "Recheck subscription authority before delivery."
          ],
          "implementationNotes": [
            "Endpoint ownership does not grant access to event data."
          ],
          "verification": [
            "Create a scoped synthetic subscription.",
            "Reject foreign-organization event scope and unauthorized event types."
          ],
          "deliverables": [
            "Subscription authorization boundary."
          ],
          "rollout": "Enable subscriptions only after cross-tenant denial checks pass.",
          "skills": [
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b492201d-4dae-42e4-8dff-b3265e8ede2d",
          "key": "BAPIHOOK-103",
          "title": "Validate webhook destinations through the restricted network boundary",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "events",
          "dependsOn": [
            "BAPIHOOK-102"
          ],
          "scenario": "An arbitrary callback URL could direct the sender toward unapproved network resources.",
          "acceptanceCriteria": [
            "Enforce approved schemes, origins, and ports.",
            "Validate resolution and redirects for every delivery.",
            "Bind destinations to reviewed subscription revisions."
          ],
          "implementationNotes": [
            "Use local receiver doubles and an explicit lab allowlist."
          ],
          "verification": [
            "Deliver to an approved local receiver.",
            "Reject an unapproved redirect or changed destination authority."
          ],
          "deliverables": [
            "Webhook destination policy."
          ],
          "rollout": "Default to no external destinations until the policy is configured.",
          "skills": [
            "Egress control"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "495208db-6ee4-4ab1-bed9-2c4674555480",
          "key": "BAPIHOOK-104",
          "title": "Sign exact webhook bytes with versioned verification metadata",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "deliver",
          "dependsOn": [
            "BAPIHOOK-101",
            "BAPIHOOK-103"
          ],
          "scenario": "Partners cannot verify signatures after the sender serializes the same event differently on retry.",
          "acceptanceCriteria": [
            "Sign the exact delivered bytes.",
            "Include key identity and bounded timestamp semantics.",
            "Document receiver verification before payload trust."
          ],
          "implementationNotes": [
            "Use generated test keys and never log signing material."
          ],
          "verification": [
            "Verify a valid local delivery.",
            "Change one byte or timestamp and reject verification."
          ],
          "deliverables": [
            "Signing contract and receiver example."
          ],
          "rollout": "Introduce a versioned signature format with a bounded rotation overlap.",
          "skills": [
            "Webhook security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5f29b50b-ca3a-42f8-ad42-13b6a4f27e21",
          "key": "BAPIHOOK-105",
          "title": "Document at-least-once delivery with stable event identities",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "deliver",
          "dependsOn": [
            "BAPIHOOK-104"
          ],
          "scenario": "The platform advertises one delivery even though connection loss can cause duplicates.",
          "acceptanceCriteria": [
            "Keep event identity stable across attempts.",
            "Record delivery attempts separately from event facts.",
            "Provide a receiver deduplication example."
          ],
          "implementationNotes": [
            "Do not claim exactly-once delivery across HTTP."
          ],
          "verification": [
            "Lose a receiver acknowledgement and retry.",
            "Verify the receiver applies the event once using its deduplication record."
          ],
          "deliverables": [
            "Delivery semantics and replay checks."
          ],
          "rollout": "Preserve event identity through all retries and support actions.",
          "skills": [
            "Distributed systems",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2fdf96a5-bf08-4ffa-b951-76ac55377094",
          "key": "BAPIHOOK-106",
          "title": "Bound retry scheduling and distinguish terminal receiver responses",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "deliver",
          "dependsOn": [
            "BAPIHOOK-105"
          ],
          "scenario": "The sender retries every response indefinitely, including malformed-endpoint failures.",
          "acceptanceCriteria": [
            "Define retryable status classes and total delivery age.",
            "Respect bounded retry-after guidance.",
            "Move exhausted deliveries to an inspectable terminal state."
          ],
          "implementationNotes": [
            "Use an injected clock and fixed maximum attempts."
          ],
          "verification": [
            "Recover from a temporary receiver failure.",
            "Exhaust a persistent failure without unbounded work."
          ],
          "deliverables": [
            "Retry contract."
          ],
          "rollout": "Start with conservative limits; expose terminal state to authorized subscription owners.",
          "skills": [
            "Retry policy"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "564011eb-ab74-4ab5-9158-29ea7794028e",
          "key": "BAPIHOOK-107",
          "title": "Expose event ordering limits without requiring global sequencing",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "deliver",
          "dependsOn": [
            "BAPIHOOK-105",
            "BAPIHOOK-106"
          ],
          "scenario": "Partners assume events arrive in the order they happened, but parallel delivery reorders them.",
          "acceptanceCriteria": [
            "Declare the actual ordering scope.",
            "Include resource revision where needed for stale-event handling.",
            "Document how receivers handle gaps and older revisions."
          ],
          "implementationNotes": [
            "Avoid promising global ordering without implementing it."
          ],
          "verification": [
            "Deliver two resource revisions out of order.",
            "Verify a receiver preserves its declared monotonic state."
          ],
          "deliverables": [
            "Ordering contract and receiver tests."
          ],
          "rollout": "Publish ordering guidance before increasing delivery parallelism.",
          "skills": [
            "Event ordering"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0c8052d6-7329-40c0-9022-5ed24d6d9900",
          "key": "BAPIHOOK-108",
          "title": "Replay terminal deliveries without mutating original event content",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "support",
          "dependsOn": [
            "BAPIHOOK-106",
            "BAPIHOOK-107"
          ],
          "scenario": "Support repairs a payload during replay and leaves the same event ID representing different facts.",
          "acceptanceCriteria": [
            "Replay the original immutable event under a new attempt identity.",
            "Require authorized subscription scope and reason.",
            "Reject replay when current destination or data authority is revoked."
          ],
          "implementationNotes": [
            "Corrections require a new event identity and explicit relation."
          ],
          "verification": [
            "Replay a failed synthetic delivery.",
            "Reject changed payload bytes and revoked subscription authority."
          ],
          "deliverables": [
            "Audited replay endpoint."
          ],
          "rollout": "Keep replay bounded and visible to subscription owners.",
          "skills": [
            "Auditability",
            "Immutability"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "36d11b9f-244f-47ec-9e56-12816d9fb58f",
          "key": "BAPIHOOK-109",
          "title": "Design webhook schema migration for independently deployed receivers",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "support",
          "dependsOn": [
            "BAPIHOOK-104",
            "BAPIHOOK-107",
            "BAPIHOOK-108"
          ],
          "scenario": "A required payload change cannot be safely deployed to all partner receivers at once.",
          "acceptanceCriteria": [
            "Compare versioned subscriptions and additive-compatible evolution.",
            "Define supported version overlap and retirement evidence.",
            "Rehearse receiver upgrade, rollback, and replay of historical events."
          ],
          "implementationNotes": [
            "Historical events retain their original schema identity."
          ],
          "verification": [
            "Upgrade one synthetic receiver while another stays legacy.",
            "Replay an old event after upgrade and verify documented handling."
          ],
          "deliverables": [
            "Webhook evolution decision record."
          ],
          "rollout": "Keep supported schema serializers and examples through the retention window.",
          "skills": [
            "API lifecycle",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "62fabe0d-08af-453d-9dc5-dff2b45599c2",
          "key": "BAPIHOOK-110",
          "title": "Publish a webhook receiver checklist with failure recovery",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "support",
          "dependsOn": [
            "BAPIHOOK-109"
          ],
          "scenario": "Partners acknowledge before persisting event identity and lose events after a crash.",
          "acceptanceCriteria": [
            "Show signature verification before parsing trusted fields.",
            "Persist deduplication and accepted work before acknowledgement.",
            "Document retry, replay, and unknown-version behavior."
          ],
          "implementationNotes": [
            "Use the local receiver double and synthetic events."
          ],
          "verification": [
            "Recover after a receiver crash before acknowledgement.",
            "Reject an unsupported event version without discarding its identity."
          ],
          "deliverables": [
            "Executable receiver guide."
          ],
          "rollout": "Version the guide with event and signature contracts.",
          "skills": [
            "Documentation",
            "Integration design"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "2b33069c-9cb1-47c9-a1a7-8d54f07ffdb9",
      "key": "CGRID",
      "title": "An inventory grid with trustworthy edits",
      "field": "Frontend",
      "summary": "Make spreadsheet-like stock editing predictable across validation and concurrent updates.",
      "context": "Fictional supplier Reedworks uses a browser inventory table. Quantities are planning records, not live warehouse instructions.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Playwright"
      ],
      "prerequisites": [
        "Create synthetic SKUs with revisions and nullable quantities.",
        "Implement a local paginated adapter with conditional updates."
      ],
      "developerValue": "Practice grid interaction and concurrent edit recovery.",
      "companyValue": "Inspect how changes protect operator intent during partial failures.",
      "delivery": "Deliver separate pull requests using synthetic stock.",
      "phases": [
        {
          "id": "cells",
          "title": "Understand cells",
          "goal": "Define value and edit contracts."
        },
        {
          "id": "edits",
          "title": "Protect edits",
          "goal": "Preserve selection and drafts."
        },
        {
          "id": "release",
          "title": "Handle interruption",
          "goal": "Recover from partial writes."
        }
      ],
      "tickets": [
        {
          "id": "1b80a753-efea-4ad3-8157-028a1a57f570",
          "key": "CGRID-101",
          "title": "Render unknown stock separately from zero",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "cells",
          "dependsOn": [],
          "scenario": "Buyers mistake missing quantities for zero because the grid coerces null. Preserve the API distinction.",
          "acceptanceCriteria": [
            "Null displays Unknown",
            "Zero displays 0",
            "Unknown values sort last"
          ],
          "implementationNotes": [
            "Do not mutate stored quantities."
          ],
          "verification": [
            "Render null beside zero",
            "Reject nonnumeric values without showing NaN"
          ],
          "deliverables": [
            "Quantity renderer and cases"
          ],
          "rollout": "Revert the renderer without migration.",
          "skills": [
            "Rendering",
            "Data contracts"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a9da8cd1-8adb-49b3-a688-2d55a5ee929b",
          "key": "CGRID-102",
          "title": "Keep inventory column widths after reload",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "cells",
          "dependsOn": [],
          "scenario": "Operators resize the SKU column every morning. Save bounded widths per grid version.",
          "acceptanceCriteria": [
            "Widths restore after reload",
            "Limits prevent hidden controls",
            "Reset removes overrides"
          ],
          "implementationNotes": [
            "Persist layout only."
          ],
          "verification": [
            "Restore two widths",
            "Corrupt saved JSON and verify defaults"
          ],
          "deliverables": [
            "Width persistence and reset control"
          ],
          "rollout": "Disable persistence if controls disappear.",
          "skills": [
            "Browser storage",
            "Layout"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "0aed0914-bb05-43fd-82b2-db6e3d96a6e7",
          "key": "CGRID-103",
          "title": "Validate stock edits before saving",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "cells",
          "dependsOn": [
            "CGRID-101"
          ],
          "scenario": "Pasting a decimal quantity sends an invalid stock update. Add recoverable field validation.",
          "acceptanceCriteria": [
            "Nonnegative integers save",
            "Decimals and negatives remain editable",
            "Errors identify the cell"
          ],
          "implementationNotes": [
            "Follow the local adapter contract."
          ],
          "verification": [
            "Save quantity 12",
            "Paste -1 and verify no request"
          ],
          "deliverables": [
            "Cell validator and interaction cases"
          ],
          "rollout": "Restore read-only quantities if valid saves fail.",
          "skills": [
            "Forms",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b917a431-552a-4556-90bb-99334d37a519",
          "key": "CGRID-104",
          "title": "Maintain inventory selection while sorted rows update",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "edits",
          "dependsOn": [
            "CGRID-101"
          ],
          "scenario": "A background refresh reorders rows and moves the editing highlight to another SKU. Anchor selection to identity.",
          "acceptanceCriteria": [
            "Selected SKU remains selected",
            "Deleted selection clears explicitly",
            "Sorting cannot change edit target"
          ],
          "implementationNotes": [
            "Array indices cannot identify rows."
          ],
          "verification": [
            "Refresh reordered rows",
            "Delete the selected SKU mid-edit"
          ],
          "deliverables": [
            "Identity-based selection coordinator"
          ],
          "rollout": "Disable background refresh if selection diverges.",
          "skills": [
            "State management",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c00e399a-d101-4b7b-a6dd-5d181365f97a",
          "key": "CGRID-105",
          "title": "Reject stale stock updates without losing drafts",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "edits",
          "dependsOn": [
            "CGRID-103"
          ],
          "scenario": "Two buyers edit the same row and the second overwrites the first. Handle revision conflicts.",
          "acceptanceCriteria": [
            "Saves include expected revision",
            "Conflict preserves draft and current value",
            "Resubmission requires reconciliation"
          ],
          "implementationNotes": [
            "Never blindly retry conflicts."
          ],
          "verification": [
            "Accept matching revision",
            "Reject stale revision and inspect draft"
          ],
          "deliverables": [
            "Conflict panel and adapter cases"
          ],
          "rollout": "Gate editing while conflict handling is repaired.",
          "skills": [
            "Concurrency",
            "HTTP"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6f578554-b6ce-41f0-b541-86e96775b83d",
          "key": "CGRID-106",
          "title": "Define keyboard entry and escape for inventory cells",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "edits",
          "dependsOn": [
            "CGRID-103",
            "CGRID-104"
          ],
          "scenario": "Arrow keys sometimes move cells while users edit text. Introduce explicit navigation and editing states.",
          "acceptanceCriteria": [
            "Enter starts editing",
            "Escape restores committed value",
            "Editor arrows retain native behavior"
          ],
          "implementationNotes": [
            "Provide semantic controls and visible focus."
          ],
          "verification": [
            "Edit without a pointer",
            "Escape an invalid draft"
          ],
          "deliverables": [
            "Keyboard contract and checks"
          ],
          "rollout": "Fall back to ordinary row forms.",
          "skills": [
            "Accessibility",
            "Keyboard"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9a577bc6-cdd0-4f0c-a8bf-5a4f88eee321",
          "key": "CGRID-107",
          "title": "Undo only an uncontested stock change",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "edits",
          "dependsOn": [
            "CGRID-105"
          ],
          "scenario": "A blind Undo would erase a colleague's newer stock value. Add one guarded inverse update.",
          "acceptanceCriteria": [
            "Undo uses resulting revision",
            "Newer revisions reject undo",
            "Failure preserves current row"
          ],
          "implementationNotes": [
            "Undo must be a conditional write."
          ],
          "verification": [
            "Undo an uncontested save",
            "Advance revision before undo"
          ],
          "deliverables": [
            "Guarded undo and race case"
          ],
          "rollout": "Hide Undo while retaining ordinary edits.",
          "skills": [
            "Concurrency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "ffbe691a-b90f-4685-8ed9-7a215f8d059d",
          "key": "CGRID-108",
          "title": "Preview pasted stock ranges before applying them",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "release",
          "dependsOn": [
            "CGRID-103",
            "CGRID-106"
          ],
          "scenario": "A spreadsheet paste includes headers and an extra column. Show its target mapping before writing.",
          "acceptanceCriteria": [
            "Preview names target SKUs",
            "Malformed rows show errors",
            "Confirm sends selected valid rows only"
          ],
          "implementationNotes": [
            "Bound paste size and treat text as untrusted."
          ],
          "verification": [
            "Preview three rows",
            "Reject oversized formula-like input safely"
          ],
          "deliverables": [
            "Paste parser and confirmation preview"
          ],
          "rollout": "Disable paste while preserving manual edits.",
          "skills": [
            "Parsing",
            "Input security"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "88cca219-2074-4d93-8470-c3f057073a41",
          "key": "CGRID-109",
          "title": "Report individual results for a partial stock save",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "release",
          "dependsOn": [
            "CGRID-105",
            "CGRID-108"
          ],
          "scenario": "Bulk edit says Saved when one row failed. Return stable per-row outcomes.",
          "acceptanceCriteria": [
            "Success shows committed revision",
            "Failure retains draft",
            "Retry selects failed rows only"
          ],
          "implementationNotes": [
            "Timeouts remain unresolved until reconciled."
          ],
          "verification": [
            "Save mixed valid and invalid rows",
            "Timeout one row and inspect uncertainty"
          ],
          "deliverables": [
            "Result summary and retry controls"
          ],
          "rollout": "Disable bulk save if result mapping fails.",
          "skills": [
            "Partial failure",
            "UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7346772b-385e-435c-9e56-b5433646a66c",
          "key": "CGRID-110",
          "title": "Export inventory-grid diagnostics without stock data",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "release",
          "dependsOn": [
            "CGRID-104",
            "CGRID-109"
          ],
          "scenario": "Support needs grid state but copying rows exposes inventory. Add an opt-in diagnostic download.",
          "acceptanceCriteria": [
            "Includes grid version and flags",
            "Omits quantities and SKU labels",
            "User previews the report"
          ],
          "implementationNotes": [
            "Allowlist diagnostic fields."
          ],
          "verification": [
            "Export populated grid",
            "Verify secret-like fixture values are absent"
          ],
          "deliverables": [
            "Exporter and exclusion checks"
          ],
          "rollout": "Remove export if unexpected fields appear.",
          "skills": [
            "Observability",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "a8eb9cae-2929-4c42-90e3-0e6be4af2782",
      "key": "CSEARCH",
      "title": "A catalog search that survives interruption",
      "field": "Frontend",
      "summary": "Build navigable search and result recovery for a public directory.",
      "context": "Fictional workshop directory Cedar lists tools and spare parts using a local search adapter.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Testing Library"
      ],
      "prerequisites": [
        "Create synthetic items with stable identifiers.",
        "Stub cursor pages, facets, delayed responses and missing items."
      ],
      "developerValue": "Practice URL contracts and request ownership.",
      "companyValue": "Inspect whether discovery intent survives changing results.",
      "delivery": "Use local fixtures; external search services are excluded.",
      "phases": [
        {
          "id": "query",
          "title": "Specify search state",
          "goal": "Make queries shareable."
        },
        {
          "id": "results",
          "title": "Handle changing results",
          "goal": "Keep feedback attached to active queries."
        },
        {
          "id": "shipping",
          "title": "Prepare recovery",
          "goal": "Bound caching and support diagnosis."
        }
      ],
      "tickets": [
        {
          "id": "bee813b1-be0d-4057-9a08-38377e4c3309",
          "key": "CSEARCH-101",
          "title": "Normalize directory whitespace without changing part codes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "query",
          "dependsOn": [],
          "scenario": "Repeated spaces create separate search requests. Define normalization without altering case-sensitive part codes.",
          "acceptanceCriteria": [
            "Outer spaces trim",
            "Internal-space policy is documented",
            "Input preserves edits until submit"
          ],
          "implementationNotes": [
            "Do not silently lowercase identifiers."
          ],
          "verification": [
            "Submit padded code",
            "Submit whitespace only"
          ],
          "deliverables": [
            "Query parser and examples"
          ],
          "rollout": "Revert normalization while accepting old links.",
          "skills": [
            "URL state",
            "Parsing"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "4f3e73e8-da44-4de7-84c9-ee7f84b07306",
          "key": "CSEARCH-102",
          "title": "Expose selected directory facets in shared links",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "query",
          "dependsOn": [
            "CSEARCH-101"
          ],
          "scenario": "Shared search links conceal which filters excluded parts. Render removable facets from validated URL values.",
          "acceptanceCriteria": [
            "Active facets have labels",
            "Unknown facets use visible fallback",
            "Removal resets pagination"
          ],
          "implementationNotes": [
            "Resolve labels from trusted metadata."
          ],
          "verification": [
            "Open two selected facets",
            "Use unknown facet ID"
          ],
          "deliverables": [
            "Facet controls and URL cases"
          ],
          "rollout": "Disable facet writes while retaining parsing.",
          "skills": [
            "Navigation",
            "Filtering"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "40dbb1f2-a650-4d74-a1bb-29ffbe8040e7",
          "key": "CSEARCH-103",
          "title": "Announce completed directory searches once",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "query",
          "dependsOn": [
            "CSEARCH-101"
          ],
          "scenario": "A live region reads counts after every keystroke. Announce committed search outcomes without moving focus.",
          "acceptanceCriteria": [
            "Count announces on completion",
            "Loading has one status",
            "Errors explain retry"
          ],
          "implementationNotes": [
            "Do not focus status updates."
          ],
          "verification": [
            "Submit and inspect announcement",
            "Reject search and inspect error"
          ],
          "deliverables": [
            "Status component and manual protocol"
          ],
          "rollout": "Use submit-only announcements if updates repeat.",
          "skills": [
            "Accessibility",
            "Live regions"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c90114cd-15ae-4e8d-ad99-e38cb94e616a",
          "key": "CSEARCH-104",
          "title": "Bind directory page cursors to their originating query",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "results",
          "dependsOn": [
            "CSEARCH-102"
          ],
          "scenario": "More results races with facet changes and appends unrelated products. Scope pages to query identity.",
          "acceptanceCriteria": [
            "Matching pages alone append",
            "Facet changes invalidate cursors",
            "IDs deduplicate repeated results"
          ],
          "implementationNotes": [
            "Cancellation alone is insufficient."
          ],
          "verification": [
            "Append matching page",
            "Resolve old page after new query"
          ],
          "deliverables": [
            "Query-scoped pager and race test"
          ],
          "rollout": "Disable incremental paging on ownership failure.",
          "skills": [
            "Race conditions",
            "Pagination"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "aa435d3b-18cf-4189-aac9-98dc4d554a5d",
          "key": "CSEARCH-105",
          "title": "Restore a directory result anchor after detail navigation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "results",
          "dependsOn": [
            "CSEARCH-104"
          ],
          "scenario": "Returning from a part detail resets a long search to the top. Restore the visited item.",
          "acceptanceCriteria": [
            "Back restores query and anchor",
            "Missing item has fallback",
            "Focus returns to originating link"
          ],
          "implementationNotes": [
            "Do not identify anchors only by pixels."
          ],
          "verification": [
            "Visit later result and return",
            "Remove it before Back"
          ],
          "deliverables": [
            "History restoration and browser case"
          ],
          "rollout": "Disable anchoring while retaining query history.",
          "skills": [
            "Navigation",
            "Focus"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Accessibility",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "18c1e082-9a83-44f9-87e1-5a78c525f9d1",
          "key": "CSEARCH-106",
          "title": "Explain unavailable parts in bookmarked directory links",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "results",
          "dependsOn": [
            "CSEARCH-101"
          ],
          "scenario": "An old part bookmark renders a blank page. Distinguish removal from failed loading.",
          "acceptanceCriteria": [
            "Missing and failed reads differ",
            "Return preserves valid search",
            "External return targets are rejected"
          ],
          "implementationNotes": [
            "Allowlist internal return routes."
          ],
          "verification": [
            "Open removed part",
            "Inject external return URL"
          ],
          "deliverables": [
            "Unavailable state and route tests"
          ],
          "rollout": "Restore static unavailable page if navigation breaks.",
          "skills": [
            "Error handling",
            "URL safety"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "992eb921-cc0a-4182-8124-4f9fe8f11100",
          "key": "CSEARCH-107",
          "title": "Keep zero-count directory facets removable",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "results",
          "dependsOn": [
            "CSEARCH-102",
            "CSEARCH-104"
          ],
          "scenario": "Selected filters disappear when counts reach zero, trapping the query. Separate selection from availability.",
          "acceptanceCriteria": [
            "Selected zero-count facets remain",
            "Stale counts are labeled",
            "Count failure preserves selection"
          ],
          "implementationNotes": [
            "Count refresh cannot rewrite selections."
          ],
          "verification": [
            "Select zero-result facet",
            "Reject facet-count refresh"
          ],
          "deliverables": [
            "Facet reconciliation and cases"
          ],
          "rollout": "Freeze counts while preserving removal.",
          "skills": [
            "State management",
            "Resilience"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "5341c4c6-5d0f-4906-8cef-a4f2ecbe0576",
          "key": "CSEARCH-108",
          "title": "Bound the directory query cache",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "shipping",
          "dependsOn": [
            "CSEARCH-104",
            "CSEARCH-107"
          ],
          "scenario": "Browsing many searches grows memory indefinitely. Introduce capacity and expiry with deterministic eviction.",
          "acceptanceCriteria": [
            "Capacity is configurable",
            "Keys contain all query dimensions",
            "Expired entries refresh visibly"
          ],
          "implementationNotes": [
            "Cache public directory records only."
          ],
          "verification": [
            "Revisit retained query",
            "Exceed capacity and inspect eviction"
          ],
          "deliverables": [
            "Cache policy and clock tests"
          ],
          "rollout": "Disable cache and fetch committed queries.",
          "skills": [
            "Caching",
            "Memory"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7a19a7e9-4633-45b2-9083-2dd7c22bd52a",
          "key": "CSEARCH-109",
          "title": "Print a directory shortlist from current item identities",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "shipping",
          "dependsOn": [
            "CSEARCH-105",
            "CSEARCH-106"
          ],
          "scenario": "Printed shortlists include removed entries. Use a dedicated projection resolved by current item IDs.",
          "acceptanceCriteria": [
            "Missing items are identified",
            "Removal updates print",
            "Controls are hidden in print"
          ],
          "implementationNotes": [
            "Use the local directory adapter."
          ],
          "verification": [
            "Print two entries",
            "Remove one before printing"
          ],
          "deliverables": [
            "Print view and media checks"
          ],
          "rollout": "Hide printing if projections diverge.",
          "skills": [
            "CSS",
            "Projection"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c3910c4e-87a5-4314-a44e-9db99939cb90",
          "key": "CSEARCH-110",
          "title": "Instrument directory search without capturing query text",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "ADVANCED",
          "estimateMinutes": 120,
          "phaseId": "shipping",
          "dependsOn": [
            "CSEARCH-103",
            "CSEARCH-108"
          ],
          "scenario": "Search failure metrics currently include potentially sensitive part queries. Add bounded operational events.",
          "acceptanceCriteria": [
            "Includes outcome and duration bucket",
            "Omits queries and item names",
            "Retries retain correlation token"
          ],
          "implementationNotes": [
            "Verify through a local event collector."
          ],
          "verification": [
            "Complete search and inspect event",
            "Fail secret-like query and check exclusion"
          ],
          "deliverables": [
            "Event allowlist and samples"
          ],
          "rollout": "Disable event sink if unexpected fields appear.",
          "skills": [
            "Instrumentation",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "3a4ae0f1-d121-40a3-a798-b0494e8508ed",
      "key": "CFORM",
      "title": "A procurement form that protects drafts",
      "field": "Frontend",
      "summary": "Repair conditional fields, draft recovery, and deliberate submission.",
      "context": "Fictional procurement team Northroom collects purchase requests in a browser form. Work uses local stubs and cannot place purchases.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Playwright"
      ],
      "prerequisites": [
        "Create synthetic categories and conditional request fields.",
        "Stub draft revisions and submission outcomes."
      ],
      "developerValue": "Practice state boundaries and form schema transitions.",
      "companyValue": "Inspect how hidden obsolete data and duplicate requests are prevented.",
      "delivery": "Submit each form behavior as a separate change.",
      "phases": [
        {
          "id": "fields",
          "title": "Clarify fields",
          "goal": "Specify amounts and conditional values."
        },
        {
          "id": "drafts",
          "title": "Protect progress",
          "goal": "Recover drafts and schema changes."
        },
        {
          "id": "submission",
          "title": "Submit deliberately",
          "goal": "Bind review to confirmed writes."
        }
      ],
      "tickets": [
        {
          "id": "21cb669c-863e-404c-8b10-ba9a698299fe",
          "key": "CFORM-101",
          "title": "Preserve procurement amount precision during editing",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "fields",
          "dependsOn": [],
          "scenario": "Entered 19.90 becomes 19.9 and later rounds. Separate edit text from validated minor units.",
          "acceptanceCriteria": [
            "Review uses currency precision",
            "Incomplete text stays editable",
            "Excess precision blocks submit"
          ],
          "implementationNotes": [
            "Parse decimals without binary float arithmetic."
          ],
          "verification": [
            "Review 19.90",
            "Enter excess decimal places"
          ],
          "deliverables": [
            "Amount parser and field cases"
          ],
          "rollout": "Revert formatting while retaining minor-unit storage.",
          "skills": [
            "Forms",
            "Decimal arithmetic"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c0b75bf4-accf-4c60-a05e-cdb56435ca24",
          "key": "CFORM-102",
          "title": "Link procurement error summaries to affected fields",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "fields",
          "dependsOn": [],
          "scenario": "Required fields missing gives no location. Add field errors and a navigable summary.",
          "acceptanceCriteria": [
            "Summary links focus fields",
            "Labels expose required state",
            "Corrections clear only relevant errors"
          ],
          "implementationNotes": [
            "Use stable description IDs."
          ],
          "verification": [
            "Follow summary link",
            "Submit several missing values"
          ],
          "deliverables": [
            "Summary and keyboard checks"
          ],
          "rollout": "Retain field errors if summary navigation fails.",
          "skills": [
            "Accessibility",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "77f35919-ae38-4f56-a86f-eaff1a3e1794",
          "key": "CFORM-103",
          "title": "Remove obsolete shipping fields on procurement category changes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "fields",
          "dependsOn": [
            "CFORM-101"
          ],
          "scenario": "Switching hardware to services retains a hidden shipping address in the payload. Make conditional removal explicit.",
          "acceptanceCriteria": [
            "Payload excludes inactive fields",
            "Discard prompts identify entered data",
            "Cancel preserves category"
          ],
          "implementationNotes": [
            "Hidden inputs are not a serialization policy."
          ],
          "verification": [
            "Switch empty category",
            "Cancel populated category switch"
          ],
          "deliverables": [
            "Conditional payload projection"
          ],
          "rollout": "Disable category changes until removal is corrected.",
          "skills": [
            "Data modeling",
            "Forms"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ab21e7f9-4989-41be-82dd-7117e3bec02e",
          "key": "CFORM-104",
          "title": "Allow earlier procurement corrections after final-step errors",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "drafts",
          "dependsOn": [
            "CFORM-102",
            "CFORM-103"
          ],
          "scenario": "A final-step error blocks users from returning to fix amounts. Separate navigation from submission validity.",
          "acceptanceCriteria": [
            "Back stays available",
            "Forward validates applicable step",
            "Submit validates full active payload"
          ],
          "implementationNotes": [
            "Share one validation contract."
          ],
          "verification": [
            "Correct earlier amount",
            "Fail final validation and go Back"
          ],
          "deliverables": [
            "Step validation coordinator"
          ],
          "rollout": "Fall back to a single-page form.",
          "skills": [
            "State machines",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b2c9bc24-61f3-4b47-be5c-23b700ab6e6e",
          "key": "CFORM-105",
          "title": "Show acknowledged and unsaved procurement draft states",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "drafts",
          "dependsOn": [
            "CFORM-104"
          ],
          "scenario": "Failed autosaves look saved. Track acknowledgements without interrupting editing.",
          "acceptanceCriteria": [
            "Saved means acknowledged revision",
            "Failure retains edits",
            "Late acknowledgement cannot mark newer edits saved"
          ],
          "implementationNotes": [
            "Debouncing cannot establish revision ownership."
          ],
          "verification": [
            "Save then edit",
            "Resolve saves out of order"
          ],
          "deliverables": [
            "Draft states and race tests"
          ],
          "rollout": "Disable autosave and expose explicit save.",
          "skills": [
            "Async state",
            "Persistence"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a087b3c1-9b95-4714-8e03-3f905d880627",
          "key": "CFORM-106",
          "title": "Stop conflicting procurement saves from another tab",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "drafts",
          "dependsOn": [
            "CFORM-105"
          ],
          "scenario": "Two tabs silently overwrite a draft. Require expected revisions and preserve conflicting local work.",
          "acceptanceCriteria": [
            "Stale writes fail visibly",
            "Local edits remain recoverable",
            "Reconciliation is explicit"
          ],
          "implementationNotes": [
            "Browser warnings cannot replace revision checks."
          ],
          "verification": [
            "Save one tab",
            "Submit stale save in second"
          ],
          "deliverables": [
            "Multi-tab conflict flow"
          ],
          "rollout": "Pause writes on unresolved conflict.",
          "skills": [
            "Concurrency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "47a850ad-3b09-4b46-97cd-9d55d41ca2de",
          "key": "CFORM-107",
          "title": "Migrate one procurement draft schema transition",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "drafts",
          "dependsOn": [
            "CFORM-103",
            "CFORM-105"
          ],
          "scenario": "A category field changes shape while drafts remain open. Add one deterministic version migration.",
          "acceptanceCriteria": [
            "Old version migrates predictably",
            "Future versions stay read-only",
            "Dropped fields appear in review"
          ],
          "implementationNotes": [
            "Preserve original draft until acknowledgement."
          ],
          "verification": [
            "Migrate old fixture",
            "Open unsupported future version"
          ],
          "deliverables": [
            "Migration and preserved-original cases"
          ],
          "rollout": "Restore old reader using preserved drafts.",
          "skills": [
            "Schema evolution",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "f57ad6ba-0a05-4ac5-a3d1-db332cade92c",
          "key": "CFORM-108",
          "title": "Bind procurement review to the exact submission snapshot",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "submission",
          "dependsOn": [
            "CFORM-104",
            "CFORM-107"
          ],
          "scenario": "Review recomputes defaults differently from submit. Create one validated snapshot for both.",
          "acceptanceCriteria": [
            "Review matches sent values",
            "Editing invalidates review",
            "Inactive fields are excluded"
          ],
          "implementationNotes": [
            "Confirmation identifies snapshot revision."
          ],
          "verification": [
            "Review and submit unchanged",
            "Edit amount after review"
          ],
          "deliverables": [
            "Snapshot projection and checks"
          ],
          "rollout": "Disable submit if snapshot matching fails.",
          "skills": [
            "State ownership",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0be4da5b-1289-4646-88fc-1b4dacaf0094",
          "key": "CFORM-109",
          "title": "Reconcile uncertain procurement submissions before retrying",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "submission",
          "dependsOn": [
            "CFORM-108"
          ],
          "scenario": "A timeout followed by retry creates duplicate requests. Retain one submission key until resolved.",
          "acceptanceCriteria": [
            "Retry reuses key",
            "Success locks snapshot",
            "Unknown outcomes expose status lookup"
          ],
          "implementationNotes": [
            "Timeout alone cannot prove failure."
          ],
          "verification": [
            "Submit then retry",
            "Timeout after adapter acceptance"
          ],
          "deliverables": [
            "Submission coordinator and timeout case"
          ],
          "rollout": "Pause retries while allowing lookup.",
          "skills": [
            "Idempotency",
            "Failure handling"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "c09bdcb6-f980-4b07-9e18-80c8b29f710e",
          "key": "CFORM-110",
          "title": "Export one recoverable procurement draft without session data",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "submission",
          "dependsOn": [
            "CFORM-106",
            "CFORM-109"
          ],
          "scenario": "Support requests whole browser storage to recover drafts. Offer scoped, previewed export instead.",
          "acceptanceCriteria": [
            "Preview lists included fields",
            "Session tokens are omitted",
            "Invalid drafts export as drafts"
          ],
          "implementationNotes": [
            "Never trust exported content as HTML."
          ],
          "verification": [
            "Export current draft",
            "Check other drafts and tokens are absent"
          ],
          "deliverables": [
            "Draft export and scope checks"
          ],
          "rollout": "Remove export if isolation fails.",
          "skills": [
            "Data minimization",
            "Serialization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "6a2ae98c-4938-46b5-bcd2-64cd6cbad7c4",
      "key": "CROUTE",
      "title": "An offline field-service route notebook",
      "field": "Mobile",
      "summary": "Keep synthetic visit notes reliable through offline use and process restarts.",
      "context": "Fictional maintenance coordinator Elm dispatches non-safety-critical inspection visits. Implement a mobile application in an emulator with local API stubs; physical devices and credentials are unnecessary.",
      "stack": [
        "React Native",
        "TypeScript",
        "SQLite",
        "Emulator"
      ],
      "prerequisites": [
        "Create synthetic visits and a local sync adapter.",
        "Provide controllable connectivity and process-restart simulation."
      ],
      "developerValue": "Practice durable mobile state and explicit sync conflicts.",
      "companyValue": "Inspect how an engineer protects field work during disconnection.",
      "delivery": "Use synthetic notes and emulator runs; no location tracking or real dispatch.",
      "phases": [
        {
          "id": "visits",
          "title": "Make visits readable",
          "goal": "Define local visit state."
        },
        {
          "id": "offline",
          "title": "Protect offline work",
          "goal": "Persist notes and resolve conflicts."
        },
        {
          "id": "recovery",
          "title": "Recover interruptions",
          "goal": "Bound retries and explain sync outcomes."
        }
      ],
      "tickets": [
        {
          "id": "362ea8e1-b6bd-406e-8c94-6d653f86f996",
          "key": "CROUTE-101",
          "title": "Label route-note timestamps with their actual zone",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "visits",
          "dependsOn": [],
          "scenario": "Visit notes appear an hour early after an emulator zone change. Distinguish stored instants from displayed local times.",
          "acceptanceCriteria": [
            "Instants remain UTC",
            "Display identifies zone",
            "Invalid timestamps show unavailable"
          ],
          "implementationNotes": [
            "Inject time and zone in tests."
          ],
          "verification": [
            "Change emulator zone",
            "Render malformed timestamp"
          ],
          "deliverables": [
            "Timestamp formatter and cases"
          ],
          "rollout": "Restore UTC display if local conversion fails.",
          "skills": [
            "Time",
            "Mobile UI"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "6ea7dc96-6ad7-4249-9e04-1c22f67242e8",
          "key": "CROUTE-102",
          "title": "Show downloaded visits when route refresh fails",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "visits",
          "dependsOn": [],
          "scenario": "An offline refresh replaces the route with an empty screen. Retain downloaded visits and identify staleness.",
          "acceptanceCriteria": [
            "Cached visits remain visible",
            "Last sync time appears",
            "Retry does not delete cache"
          ],
          "implementationNotes": [
            "Distinguish empty success from network failure."
          ],
          "verification": [
            "Load cached route offline",
            "Return successful empty route"
          ],
          "deliverables": [
            "Route loading states"
          ],
          "rollout": "Disable refresh clearing if cache disappears.",
          "skills": [
            "Offline UX",
            "Caching"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "fe684644-f94a-4467-9103-b7e1221604af",
          "key": "CROUTE-103",
          "title": "Persist field-note edits before leaving a visit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "visits",
          "dependsOn": [
            "CROUTE-101",
            "CROUTE-102"
          ],
          "scenario": "Back navigation occasionally loses the last sentence. Commit local edits before acknowledging navigation.",
          "acceptanceCriteria": [
            "Confirmed save survives restart",
            "Failed writes retain editor",
            "Navigation explains unresolved persistence"
          ],
          "implementationNotes": [
            "Use a local transaction, not delayed component state."
          ],
          "verification": [
            "Save then restart",
            "Inject storage failure on Back"
          ],
          "deliverables": [
            "Durable draft write and restart cases"
          ],
          "rollout": "Prevent exit with unsaved changes until repaired.",
          "skills": [
            "SQLite",
            "Durability"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "bf08e31f-69e3-4c34-8968-520e3665bbc9",
          "key": "CROUTE-104",
          "title": "Queue field-note synchronization by immutable operation ID",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "offline",
          "dependsOn": [
            "CROUTE-103"
          ],
          "scenario": "The same offline note uploads twice after a timeout. Persist an operation ID alongside each queued change.",
          "acceptanceCriteria": [
            "Retries reuse ID",
            "Accepted changes leave queue atomically",
            "New edits create new operations"
          ],
          "implementationNotes": [
            "Server stub must deduplicate operations."
          ],
          "verification": [
            "Replay accepted upload",
            "Crash after acceptance before dequeue"
          ],
          "deliverables": [
            "Sync queue and replay tests"
          ],
          "rollout": "Pause uploading without deleting queued work.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "57ccf3cb-881a-413d-9f51-90ef48281d37",
          "key": "CROUTE-105",
          "title": "Preserve conflicting offline visit notes for explicit resolution",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "offline",
          "dependsOn": [
            "CROUTE-104"
          ],
          "scenario": "Two emulators edit one visit offline and last-write-wins removes a paragraph. Surface both revisions.",
          "acceptanceCriteria": [
            "Conflict preserves both texts",
            "No silent merge occurs",
            "Resolution creates a new revision"
          ],
          "implementationNotes": [
            "Synthetic notes only; omit content from logs."
          ],
          "verification": [
            "Resolve two independent drafts",
            "Reject a stale resolution revision"
          ],
          "deliverables": [
            "Conflict screen and revision cases"
          ],
          "rollout": "Keep conflicts read-only while resolver is repaired.",
          "skills": [
            "Conflict resolution",
            "Revision control"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "759e2468-713a-424e-af11-728ed87f1f65",
          "key": "CROUTE-106",
          "title": "Resume route-note upload after application termination",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "offline",
          "dependsOn": [
            "CROUTE-104"
          ],
          "scenario": "Killing the process mid-sync leaves operations marked Sending forever. Add a recoverable lease state.",
          "acceptanceCriteria": [
            "Expired sends return to retryable",
            "Active leases avoid duplicate work",
            "Attempt count is bounded"
          ],
          "implementationNotes": [
            "Use an injected monotonic lease clock."
          ],
          "verification": [
            "Restart after expired lease",
            "Restart before lease expiry"
          ],
          "deliverables": [
            "Lease recovery and crash schedule"
          ],
          "rollout": "Pause runner and retain durable queue.",
          "skills": [
            "Recovery",
            "Leases"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f553e98e-0a04-4cc5-b9be-a7ccff4cfa20",
          "key": "CROUTE-107",
          "title": "Remove downloaded visit attachments without deleting notes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "offline",
          "dependsOn": [
            "CROUTE-102",
            "CROUTE-103"
          ],
          "scenario": "Attachment cache consumes emulator storage. Add per-visit cleanup that preserves authored drafts.",
          "acceptanceCriteria": [
            "Cleanup targets downloaded blobs",
            "Notes and queue remain intact",
            "Failed deletion reports reclaim uncertainty"
          ],
          "implementationNotes": [
            "Separate cache paths from draft storage."
          ],
          "verification": [
            "Clean one visit",
            "Fail blob removal and inspect notes"
          ],
          "deliverables": [
            "Cache cleanup and isolation cases"
          ],
          "rollout": "Disable cleanup if protected paths overlap.",
          "skills": [
            "Storage",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3df04cfc-c032-498e-bccd-8e1145439ac2",
          "key": "CROUTE-108",
          "title": "Bound offline route-note retry backoff",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "recovery",
          "dependsOn": [
            "CROUTE-106"
          ],
          "scenario": "A disconnected emulator retries uploads continuously and drains resources. Add capped backoff with manual retry semantics.",
          "acceptanceCriteria": [
            "Delays grow to cap",
            "Connectivity recovery can wake once",
            "Manual retry cannot create parallel senders"
          ],
          "implementationNotes": [
            "Inject timers; avoid wall-clock sleeps in tests."
          ],
          "verification": [
            "Observe scheduled delays",
            "Toggle connectivity repeatedly"
          ],
          "deliverables": [
            "Retry scheduler and fake-clock tests"
          ],
          "rollout": "Stop automatic retries and expose manual sync.",
          "skills": [
            "Scheduling",
            "Backoff"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d690c6fd-e6f2-471e-8925-3ea1ca90aee2",
          "key": "CROUTE-109",
          "title": "Explain partial route synchronization per visit",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recovery",
          "dependsOn": [
            "CROUTE-105",
            "CROUTE-108"
          ],
          "scenario": "A global Sync complete banner hides a failed visit. Show per-visit pending, conflicted, and acknowledged states.",
          "acceptanceCriteria": [
            "Global summary counts unresolved visits",
            "Each failure has action",
            "Success follows acknowledgement"
          ],
          "implementationNotes": [
            "Do not infer sync from an empty in-memory queue."
          ],
          "verification": [
            "Sync mixed outcomes",
            "Restart with persisted pending work"
          ],
          "deliverables": [
            "Sync summary and recovery checks"
          ],
          "rollout": "Hide global success if summaries disagree.",
          "skills": [
            "State projection",
            "UX"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b3243c62-4d30-496c-8e9c-2c22084aad36",
          "key": "CROUTE-110",
          "title": "Export a synthetic field-note recovery bundle deliberately",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "recovery",
          "dependsOn": [
            "CROUTE-106",
            "CROUTE-109"
          ],
          "scenario": "Debugging a stuck route requires durable state without sharing account tokens. Provide a previewed local recovery bundle.",
          "acceptanceCriteria": [
            "Includes operation metadata",
            "Excludes tokens and attachment bytes",
            "User explicitly includes note text"
          ],
          "implementationNotes": [
            "Default export omits note bodies."
          ],
          "verification": [
            "Export default bundle",
            "Verify secret-like fixture text is absent"
          ],
          "deliverables": [
            "Bundle schema and redaction cases"
          ],
          "rollout": "Remove export if exclusions fail.",
          "skills": [
            "Diagnostics",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "c9f3c302-8964-4275-ba34-361bc13c1d07",
      "key": "CDOWN",
      "title": "A dependable mobile course-download shelf",
      "field": "Mobile",
      "summary": "Manage resumable public-content downloads and safe local playback state.",
      "context": "Fictional learning app Birch offers synthetic text and small local media fixtures through a loopback adapter. No copyrighted course assets or network accounts are needed.",
      "stack": [
        "React Native",
        "TypeScript",
        "SQLite",
        "Emulator"
      ],
      "prerequisites": [
        "Create small local byte fixtures and a range-response stub.",
        "Simulate low storage, interruptions and stale manifests."
      ],
      "developerValue": "Practice mobile file lifecycles and background state recovery.",
      "companyValue": "Inspect predictable resource usage and truthful download status.",
      "delivery": "Use generated local fixtures; app-store publishing is outside scope.",
      "phases": [
        {
          "id": "shelf",
          "title": "Describe downloads",
          "goal": "Model local content and sizes."
        },
        {
          "id": "transfer",
          "title": "Handle transfer boundaries",
          "goal": "Verify and recover bytes."
        },
        {
          "id": "lifecycle",
          "title": "Maintain the shelf",
          "goal": "Clean up and explain resource failures."
        }
      ],
      "tickets": [
        {
          "id": "a5a79885-e03a-44a5-b0eb-3c45ce51e13d",
          "key": "CDOWN-101",
          "title": "Distinguish unknown course-download sizes from zero bytes",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "shelf",
          "dependsOn": [],
          "scenario": "Unmeasured courses show 0 MB and users assume downloads are free of storage cost. Display size uncertainty.",
          "acceptanceCriteria": [
            "Unknown size is labeled",
            "Zero-byte fixtures remain valid",
            "Unit formatting has boundary tests"
          ],
          "implementationNotes": [
            "Do not invent estimates without metadata."
          ],
          "verification": [
            "Render zero and unknown",
            "Render malformed size"
          ],
          "deliverables": [
            "Size formatter and shelf states"
          ],
          "rollout": "Fall back to byte counts for known values.",
          "skills": [
            "Formatting",
            "UX"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "63240b04-034f-470e-8fec-b277528a15c3",
          "key": "CDOWN-102",
          "title": "Keep mobile download buttons consistent with durable state",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "shelf",
          "dependsOn": [],
          "scenario": "Returning to the shelf shows Download while a transfer is active. Render controls from one persisted lifecycle.",
          "acceptanceCriteria": [
            "Active transfer shows pause",
            "Completed content shows open",
            "Invalid states do not expose start"
          ],
          "implementationNotes": [
            "Define explicit lifecycle transitions."
          ],
          "verification": [
            "Navigate away and return",
            "Load corrupt lifecycle value"
          ],
          "deliverables": [
            "Download-state projection"
          ],
          "rollout": "Disable new downloads if state cannot be read.",
          "skills": [
            "State machines",
            "Persistence"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 80
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "69e55e83-3c66-4aa6-bf4a-e1a0c3399a46",
          "key": "CDOWN-103",
          "title": "Validate course manifest paths before creating files",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "shelf",
          "dependsOn": [
            "CDOWN-101"
          ],
          "scenario": "A malformed manifest filename can escape its course directory. Restrict all destinations to a scoped cache root.",
          "acceptanceCriteria": [
            "Traversal is rejected",
            "Absolute paths are rejected",
            "Valid nested relative paths stay scoped"
          ],
          "implementationNotes": [
            "Resolve paths before opening files."
          ],
          "verification": [
            "Write a valid nested fixture",
            "Reject parent-directory and drive paths"
          ],
          "deliverables": [
            "Manifest path validator"
          ],
          "rollout": "Reject new manifests until path validation is restored.",
          "skills": [
            "Filesystem",
            "Input security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 20
            },
            {
              "field": "Mobile",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "a37b82a5-3097-47a8-b6f3-9fc4251423e1",
          "key": "CDOWN-104",
          "title": "Resume a mobile course transfer only with matching content identity",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "transfer",
          "dependsOn": [
            "CDOWN-102",
            "CDOWN-103"
          ],
          "scenario": "A paused transfer resumes after content changed and produces mixed bytes. Bind ranges to a manifest version.",
          "acceptanceCriteria": [
            "Resume checks content identity",
            "Mismatch discards incompatible partial bytes",
            "Restart remains explicit in UI"
          ],
          "implementationNotes": [
            "Treat ETags as opaque validators."
          ],
          "verification": [
            "Resume unchanged fixture",
            "Change validator during pause"
          ],
          "deliverables": [
            "Range-resume coordinator"
          ],
          "rollout": "Disable resume and restart from zero safely.",
          "skills": [
            "HTTP",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Mobile",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2cba4bfc-9ce8-4f34-8471-f5265a4e39c7",
          "key": "CDOWN-105",
          "title": "Verify downloaded course bytes before exposing Open",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "transfer",
          "dependsOn": [
            "CDOWN-104"
          ],
          "scenario": "A truncated transfer is marked complete because the connection closed normally. Verify length and declared digest.",
          "acceptanceCriteria": [
            "Completed means both checks pass",
            "Mismatch stays unavailable",
            "Bad partial bytes can be removed"
          ],
          "implementationNotes": [
            "Digest metadata comes from the local trusted manifest."
          ],
          "verification": [
            "Download valid fixture",
            "Truncate or flip one byte"
          ],
          "deliverables": [
            "Completion verifier and corruption cases"
          ],
          "rollout": "Disable Open for unverified content.",
          "skills": [
            "Hashing",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9da19238-5006-42ef-b966-b70da5aee1a7",
          "key": "CDOWN-106",
          "title": "Pause mobile transfers when storage reservation fails",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "transfer",
          "dependsOn": [
            "CDOWN-102",
            "CDOWN-103"
          ],
          "scenario": "A nearly full emulator accepts several downloads and fails unpredictably. Reserve a bounded budget before writing.",
          "acceptanceCriteria": [
            "Admission accounts for active transfers",
            "Failure preserves existing content",
            "User sees required space"
          ],
          "implementationNotes": [
            "Reservation estimates must state uncertainty."
          ],
          "verification": [
            "Admit fitting transfer",
            "Start competing transfers exceeding budget"
          ],
          "deliverables": [
            "Storage admission policy"
          ],
          "rollout": "Stop new transfers while preserving installed courses.",
          "skills": [
            "Resource management",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Mobile",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "776a4e76-9081-4c57-b692-b4995ccff979",
          "key": "CDOWN-107",
          "title": "Recover a course-download rename interrupted by process death",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "transfer",
          "dependsOn": [
            "CDOWN-105",
            "CDOWN-106"
          ],
          "scenario": "A crash between verification and final rename leaves duplicate shelf entries. Introduce a recoverable promotion record.",
          "acceptanceCriteria": [
            "Recovery identifies one installed version",
            "Unverified partials stay hidden",
            "Repeated recovery is idempotent"
          ],
          "implementationNotes": [
            "Keep metadata and file promotion reconciliation explicit."
          ],
          "verification": [
            "Kill at each promotion boundary",
            "Repeat recovery after missing temp file"
          ],
          "deliverables": [
            "Promotion journal and crash cases"
          ],
          "rollout": "Disable promotion and retain recoverable temporary files.",
          "skills": [
            "Crash consistency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Mobile",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "9449c0b3-357d-4c5e-96a8-5cdaccbf927c",
          "key": "CDOWN-108",
          "title": "Remove one downloaded course without breaking shared assets",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CDOWN-107"
          ],
          "scenario": "Deleting a course removes an image another course references. Track local references before reclaiming shared blobs.",
          "acceptanceCriteria": [
            "Unreferenced blobs are reclaimed",
            "Referenced blobs remain",
            "Failed cleanup is retryable"
          ],
          "implementationNotes": [
            "Keep references scoped to verified manifests."
          ],
          "verification": [
            "Delete unique course",
            "Delete course with shared asset"
          ],
          "deliverables": [
            "Reference-aware cleanup"
          ],
          "rollout": "Disable physical reclamation while fixing reference accounting.",
          "skills": [
            "Reference counting",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Mobile",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "fc923325-e7c1-4576-b712-9a5456e6b24a",
          "key": "CDOWN-109",
          "title": "Show course-download progress without rendering every chunk",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CDOWN-104"
          ],
          "scenario": "Small network chunks trigger excessive mobile renders. Coalesce progress updates while keeping completion immediate.",
          "acceptanceCriteria": [
            "Updates have bounded frequency",
            "Completion bypasses throttle",
            "Paused bytes remain accurate"
          ],
          "implementationNotes": [
            "Use an injected scheduler."
          ],
          "verification": [
            "Stream many chunks",
            "Pause between scheduled updates"
          ],
          "deliverables": [
            "Progress coalescer and render-count check"
          ],
          "rollout": "Reduce to coarse milestones if scheduling regresses.",
          "skills": [
            "Rendering",
            "Performance"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "df1317f2-dad1-4fd2-856b-69c2e4f0ceab",
          "key": "CDOWN-110",
          "title": "Provide a local download repair action with explicit scope",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "lifecycle",
          "dependsOn": [
            "CDOWN-108",
            "CDOWN-109"
          ],
          "scenario": "Users cannot recover one corrupt course without clearing the entire app. Add repair for the selected course only.",
          "acceptanceCriteria": [
            "Repair revalidates selected files",
            "Other courses remain intact",
            "Offline repair explains deferred bytes"
          ],
          "implementationNotes": [
            "Never clear account or unrelated application storage."
          ],
          "verification": [
            "Repair corrupted fixture",
            "Run repair offline"
          ],
          "deliverables": [
            "Scoped repair flow and isolation checks"
          ],
          "rollout": "Hide repair if deletion scope cannot be established.",
          "skills": [
            "Recovery",
            "Isolation"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "5e342e68-06ac-450f-97dc-2882570fedea",
      "key": "CLINK",
      "title": "Mobile invitation and session navigation",
      "field": "Mobile",
      "summary": "Handle deep links, expired sessions, and interrupted navigation using local identity stubs.",
      "context": "Fictional team-planning app Finch opens invitations and shared work items. All users and sessions are synthetic; implement the app in an emulator without external identity credentials.",
      "stack": [
        "React Native",
        "TypeScript",
        "Emulator",
        "Testing Library"
      ],
      "prerequisites": [
        "Create a local session adapter with expiry and revocation.",
        "Define synthetic invitation and work-item links."
      ],
      "developerValue": "Practice navigation state, capability checks and session boundaries.",
      "companyValue": "Inspect whether links remain useful without bypassing authorization.",
      "delivery": "Deliver local navigation behaviors; real identity integrations remain separate.",
      "phases": [
        {
          "id": "links",
          "title": "Parse entry points",
          "goal": "Establish safe route contracts."
        },
        {
          "id": "sessions",
          "title": "Handle identity changes",
          "goal": "Preserve only authorized navigation intent."
        },
        {
          "id": "recovery",
          "title": "Test interruption",
          "goal": "Recover process and session transitions."
        }
      ],
      "tickets": [
        {
          "id": "94ab1322-3e8e-4767-8a36-0fa4f6ce1394",
          "key": "CLINK-101",
          "title": "Reject malformed mobile invitation routes before navigation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "links",
          "dependsOn": [],
          "scenario": "Pasted links with missing invitation IDs crash route construction. Add strict parsing before mounting screens.",
          "acceptanceCriteria": [
            "Valid IDs produce typed routes",
            "Malformed links show a recoverable state",
            "Unsupported schemes are rejected"
          ],
          "implementationNotes": [
            "Do not render arbitrary link text as markup."
          ],
          "verification": [
            "Open valid fixture link",
            "Open empty and oversized IDs"
          ],
          "deliverables": [
            "Link parser and invalid-input cases"
          ],
          "rollout": "Disable invitation entry while keeping home navigation.",
          "skills": [
            "Parsing",
            "Navigation"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bd963918-9199-4570-a221-49277c472b71",
          "key": "CLINK-102",
          "title": "Explain expired mobile invitations without automatic retries",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "links",
          "dependsOn": [
            "CLINK-101"
          ],
          "scenario": "Expired invitations spin indefinitely because the client treats every response as transient. Render terminal expiry distinctly.",
          "acceptanceCriteria": [
            "Expiry stops retry",
            "User can return home",
            "Temporary failures retain manual retry"
          ],
          "implementationNotes": [
            "Follow typed adapter error codes."
          ],
          "verification": [
            "Open expired fixture",
            "Simulate temporary outage"
          ],
          "deliverables": [
            "Invitation error states"
          ],
          "rollout": "Restore static invitation failure page if classification breaks.",
          "skills": [
            "Error handling",
            "Mobile UI"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "723af4e7-3069-4d2c-9157-829e93dbec20",
          "key": "CLINK-103",
          "title": "Retain a mobile link destination through local sign-in",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "links",
          "dependsOn": [
            "CLINK-101",
            "CLINK-102"
          ],
          "scenario": "Signing in from an invitation lands on the dashboard. Preserve a validated destination until identity is available.",
          "acceptanceCriteria": [
            "Valid destination resumes once",
            "External destinations are rejected",
            "Cancel sign-in clears pending intent"
          ],
          "implementationNotes": [
            "Store route identity, not raw credentials or URL tokens."
          ],
          "verification": [
            "Sign in and resume",
            "Cancel then sign in normally"
          ],
          "deliverables": [
            "Pending-route coordinator"
          ],
          "rollout": "Disable continuation if validation fails.",
          "skills": [
            "Navigation",
            "State management"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 80
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b1bcdf64-7b6a-45d1-9913-1485c742edce",
          "key": "CLINK-104",
          "title": "Recheck mobile work-item access after account switching",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sessions",
          "dependsOn": [
            "CLINK-103"
          ],
          "scenario": "Switching accounts leaves the previous account's work screen visible. Clear account-scoped cache before refetching.",
          "acceptanceCriteria": [
            "Old content clears on switch",
            "New identity requires authorized read",
            "Denied reads show no prior item data"
          ],
          "implementationNotes": [
            "Account identity belongs in cache boundaries."
          ],
          "verification": [
            "Switch to authorized account",
            "Switch to denied account"
          ],
          "deliverables": [
            "Account-switch isolation and checks"
          ],
          "rollout": "Force full local session reset while repaired.",
          "skills": [
            "Authorization",
            "Caching"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Mobile",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "930c4ab4-8742-4877-8b91-f73b40bb2af9",
          "key": "CLINK-105",
          "title": "Serialize mobile session refresh for simultaneous requests",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "sessions",
          "dependsOn": [
            "CLINK-103"
          ],
          "scenario": "Opening a linked screen triggers three refresh calls and conflicting session updates. Share one in-flight refresh.",
          "acceptanceCriteria": [
            "Concurrent reads share refresh",
            "Failure releases waiting requests consistently",
            "Later retry can start anew"
          ],
          "implementationNotes": [
            "Session tokens stay outside generic logs."
          ],
          "verification": [
            "Trigger three expired reads",
            "Reject refresh then retry"
          ],
          "deliverables": [
            "Refresh coordinator and concurrency tests"
          ],
          "rollout": "Stop automatic refresh and require explicit sign-in.",
          "skills": [
            "Concurrency",
            "Authentication"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ee8175ab-7137-4d1c-8a5c-e99dd084592e",
          "key": "CLINK-106",
          "title": "Cancel pending mobile navigation when invitation ownership changes",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "sessions",
          "dependsOn": [
            "CLINK-104",
            "CLINK-105"
          ],
          "scenario": "An invitation opened before account switching completes under the wrong identity. Bind continuation to the initiating session generation.",
          "acceptanceCriteria": [
            "Stale continuation is discarded",
            "Current session can reopen link",
            "No prior invitation details remain visible"
          ],
          "implementationNotes": [
            "Cancellation must survive late adapter responses."
          ],
          "verification": [
            "Resolve current invitation",
            "Resolve old invitation after switch"
          ],
          "deliverables": [
            "Session-scoped continuation guard"
          ],
          "rollout": "Clear all pending routes on account change.",
          "skills": [
            "Race conditions",
            "Isolation"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "fa337840-8ea6-48d4-b6d1-ddf4e6bb13dc",
          "key": "CLINK-107",
          "title": "Recover mobile sign-in continuation after process restart",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "sessions",
          "dependsOn": [
            "CLINK-103",
            "CLINK-105"
          ],
          "scenario": "An emulator restart during local sign-in loses the requested destination. Persist minimal, expiring continuation state.",
          "acceptanceCriteria": [
            "Valid continuation resumes once",
            "Expired continuation is discarded",
            "Unknown schema versions fail closed"
          ],
          "implementationNotes": [
            "Persist no session secrets in navigation storage."
          ],
          "verification": [
            "Restart before continuation",
            "Tamper with saved destination"
          ],
          "deliverables": [
            "Versioned continuation store and restart checks"
          ],
          "rollout": "Delete continuation metadata and return home.",
          "skills": [
            "Persistence",
            "Security"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "04218435-cda2-4bb2-a14d-88dd3c397f9b",
          "key": "CLINK-108",
          "title": "Keep the mobile Back stack free of completed sign-in screens",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "recovery",
          "dependsOn": [
            "CLINK-106",
            "CLINK-107"
          ],
          "scenario": "After joining a team, Back returns to a completed sign-in screen that resubmits. Replace transient routes on success.",
          "acceptanceCriteria": [
            "Back reaches prior meaningful screen",
            "Completed forms cannot resubmit",
            "Failed sign-in remains editable"
          ],
          "implementationNotes": [
            "Specify stack behavior for cold and warm launches."
          ],
          "verification": [
            "Complete cold-launch sign-in",
            "Fail then retry warm launch"
          ],
          "deliverables": [
            "Stack transition and navigation tests"
          ],
          "rollout": "Reset to home after sign-in if replacement fails.",
          "skills": [
            "Navigation",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Mobile",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "cadaefab-0a72-4a87-94bf-49411f775609",
          "key": "CLINK-109",
          "title": "Expose revoked mobile sessions before showing cached team content",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recovery",
          "dependsOn": [
            "CLINK-104",
            "CLINK-108"
          ],
          "scenario": "A resumed app flashes old team details before learning the session was revoked. Gate sensitive cached rendering.",
          "acceptanceCriteria": [
            "Resume enters verification state",
            "Revocation clears scoped cache",
            "Offline uncertainty has an explicit locked view"
          ],
          "implementationNotes": [
            "Public shell may render without private records."
          ],
          "verification": [
            "Resume valid session",
            "Revoke during background pause"
          ],
          "deliverables": [
            "Resume gate and revocation checks"
          ],
          "rollout": "Clear private cache on every resume until fixed.",
          "skills": [
            "Authorization",
            "Lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Mobile",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "35869e79-68b9-444b-be15-3300a46da8e6",
          "key": "CLINK-110",
          "title": "Record mobile deep-link failure categories without invitation tokens",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "recovery",
          "dependsOn": [
            "CLINK-109"
          ],
          "scenario": "Support logs raw invitation URLs while diagnosing failures. Emit categories and route types only.",
          "acceptanceCriteria": [
            "Logs exclude IDs and tokens",
            "Known failures have stable categories",
            "Unexpected errors use bounded safe summaries"
          ],
          "implementationNotes": [
            "Verify with synthetic secret-like links."
          ],
          "verification": [
            "Log valid route outcome",
            "Reject token-bearing malformed URL"
          ],
          "deliverables": [
            "Diagnostic event contract"
          ],
          "rollout": "Disable link diagnostics on redaction failure.",
          "skills": [
            "Logging",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Mobile",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "628e43ab-fe14-4972-af76-e17a61493695",
      "key": "CCAL",
      "title": "An accessible staffing calendar",
      "field": "Accessibility",
      "summary": "Make scheduling interactions operable with keyboard, magnification and assistive technology.",
      "context": "Fictional studio Loom assigns editorial shifts. Build synthetic shifts and a local scheduling adapter; no real staff records are used.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Playwright"
      ],
      "prerequisites": [
        "Create synthetic shifts including overlaps and daylight-saving boundaries.",
        "Implement a local schedule revision adapter."
      ],
      "developerValue": "Practice focus models and accessible alternatives for spatial interfaces.",
      "companyValue": "Inspect whether scheduling remains usable across input methods and failure states.",
      "delivery": "Record automated checks and a manual protocol; do not claim accessibility certification.",
      "phases": [
        {
          "id": "reading",
          "title": "Read the schedule",
          "goal": "Provide meaningful structure and labels."
        },
        {
          "id": "editing",
          "title": "Operate shifts",
          "goal": "Support alternatives and stable focus."
        },
        {
          "id": "review",
          "title": "Verify adaptive use",
          "goal": "Handle zoom, motion and assistive feedback."
        }
      ],
      "tickets": [
        {
          "id": "b4ac3526-4e47-4fdb-a7e4-51710ec81c1e",
          "key": "CCAL-101",
          "title": "Name staffing shifts independently of calendar color",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "reading",
          "dependsOn": [],
          "scenario": "Shift type is conveyed only by blue or green blocks. Add visible labels and complete accessible names.",
          "acceptanceCriteria": [
            "Type appears as text",
            "Names include date and duration",
            "Color remains optional reinforcement"
          ],
          "implementationNotes": [
            "Do not concatenate decorative icon names."
          ],
          "verification": [
            "Inspect two shift types",
            "Disable color and distinguish them"
          ],
          "deliverables": [
            "Shift label component and checks"
          ],
          "rollout": "Restore text-only blocks if labels become ambiguous.",
          "skills": [
            "Semantics",
            "Accessible names"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 80
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ad818a2e-4906-4a2e-a1aa-df37445a6808",
          "key": "CCAL-102",
          "title": "Provide a chronological agenda beside the staffing grid",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "reading",
          "dependsOn": [
            "CCAL-101"
          ],
          "scenario": "Screen-reader users must traverse many empty calendar cells to find shifts. Offer an equivalent agenda view.",
          "acceptanceCriteria": [
            "Agenda lists all visible shifts",
            "Dates are headings",
            "View switch retains selected date"
          ],
          "implementationNotes": [
            "Both views use one data projection."
          ],
          "verification": [
            "Compare grid and agenda identities",
            "Render an empty week"
          ],
          "deliverables": [
            "Agenda view and equivalence checks"
          ],
          "rollout": "Keep agenda available if grid navigation is withdrawn.",
          "skills": [
            "Information architecture",
            "Accessibility"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0f8e3896-3137-436f-947f-7dcb03af8f98",
          "key": "CCAL-103",
          "title": "Describe staffing time-zone changes explicitly",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "reading",
          "dependsOn": [
            "CCAL-101"
          ],
          "scenario": "The calendar silently changes times when the display zone changes. Show zone context without announcing every cell.",
          "acceptanceCriteria": [
            "Header identifies display zone",
            "Shift detail exposes full date/time",
            "Zone change has one status announcement"
          ],
          "implementationNotes": [
            "Store instants independently from labels."
          ],
          "verification": [
            "Change zone and inspect detail",
            "Use ambiguous clock time fixture"
          ],
          "deliverables": [
            "Zone labels and manual reading protocol"
          ],
          "rollout": "Fix display to documented UTC if conversion fails.",
          "skills": [
            "Time",
            "Live regions"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6b6aa958-5a50-439e-8524-2655136de1e0",
          "key": "CCAL-104",
          "title": "Move staffing shifts through a keyboard form",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "editing",
          "dependsOn": [
            "CCAL-102",
            "CCAL-103"
          ],
          "scenario": "Dragging is the only way to move a shift. Add date/time controls with equivalent validation.",
          "acceptanceCriteria": [
            "Every draggable shift has Move action",
            "Form and drag share validation",
            "Cancel preserves the shift"
          ],
          "implementationNotes": [
            "The form must not require pointer gestures."
          ],
          "verification": [
            "Move using keyboard",
            "Submit overlapping invalid shift"
          ],
          "deliverables": [
            "Move form and equivalence cases"
          ],
          "rollout": "Disable dragging if it diverges from the form contract.",
          "skills": [
            "Keyboard",
            "Forms"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "43ef9cfd-783b-4937-8469-9aaab5dc73c9",
          "key": "CCAL-105",
          "title": "Restore staffing focus after a shift is deleted",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "editing",
          "dependsOn": [
            "CCAL-104"
          ],
          "scenario": "Deleting a selected block sends focus to the document body. Choose a predictable surviving target.",
          "acceptanceCriteria": [
            "Next chronological shift receives focus",
            "Empty day focuses its heading control",
            "Failed deletion retains original focus"
          ],
          "implementationNotes": [
            "Resolve targets after committed DOM updates."
          ],
          "verification": [
            "Delete middle shift",
            "Reject deletion and inspect focus"
          ],
          "deliverables": [
            "Focus resolver and deletion checks"
          ],
          "rollout": "Keep deleted-row placeholder temporarily if focus restoration fails.",
          "skills": [
            "Focus management",
            "Async UI"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d77ad343-de27-4799-bd8d-f441ce4c84aa",
          "key": "CCAL-106",
          "title": "Announce staffing conflicts without repeating the entire calendar",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "editing",
          "dependsOn": [
            "CCAL-104"
          ],
          "scenario": "A revision conflict rerenders the grid and reads dozens of cells. Isolate a concise conflict message and resolution controls.",
          "acceptanceCriteria": [
            "Conflict identifies affected shift",
            "Draft remains available",
            "Calendar content is not a live region"
          ],
          "implementationNotes": [
            "Announcements must not reveal unrelated staff data."
          ],
          "verification": [
            "Trigger one conflict",
            "Retry failure and check announcement count"
          ],
          "deliverables": [
            "Conflict status region"
          ],
          "rollout": "Disable auto-refresh announcements if they repeat.",
          "skills": [
            "Live regions",
            "Error handling"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "61498424-8b97-4400-b6da-2b4f4017da3a",
          "key": "CCAL-107",
          "title": "Support calendar navigation across removed and disabled shifts",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "editing",
          "dependsOn": [
            "CCAL-105",
            "CCAL-106"
          ],
          "scenario": "Roving focus points at a disabled shift after refresh. Define deterministic navigation across changing eligible targets.",
          "acceptanceCriteria": [
            "Only one navigation tab stop exists",
            "Disabled targets are skipped",
            "Removed focus resolves predictably"
          ],
          "implementationNotes": [
            "Document arrow-key behavior without overriding text inputs."
          ],
          "verification": [
            "Navigate mixed availability",
            "Remove current target during refresh"
          ],
          "deliverables": [
            "Navigation model and transition cases"
          ],
          "rollout": "Switch to ordinary tab stops while repairing the model.",
          "skills": [
            "Keyboard",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "49af2492-d237-49ea-96c6-89321122a5d4",
          "key": "CCAL-108",
          "title": "Reflow staffing controls at high text zoom",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "review",
          "dependsOn": [
            "CCAL-102",
            "CCAL-107"
          ],
          "scenario": "At 200 percent text size the week selector hides Add shift. Reflow controls while keeping date context.",
          "acceptanceCriteria": [
            "Controls wrap without clipping",
            "Agenda avoids horizontal document overflow",
            "Focus remains visible"
          ],
          "implementationNotes": [
            "Horizontal grid scrolling may remain within a labeled region."
          ],
          "verification": [
            "Check enlarged text in agenda",
            "Check long synthetic shift labels"
          ],
          "deliverables": [
            "CSS changes and viewport evidence"
          ],
          "rollout": "Prefer agenda on constrained layouts if grid controls fail.",
          "skills": [
            "Responsive design",
            "CSS"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d8b5212f-a49a-4886-aeb9-5c9b6a522778",
          "key": "CCAL-109",
          "title": "Remove nonessential motion from staffing date transitions",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "review",
          "dependsOn": [
            "CCAL-103"
          ],
          "scenario": "Animated week slides make date navigation uncomfortable for some users. Respect reduced motion while preserving orientation.",
          "acceptanceCriteria": [
            "Reduced motion skips sliding",
            "Date heading still updates",
            "Focus and selection remain stable"
          ],
          "implementationNotes": [
            "Do not use animation completion as business logic."
          ],
          "verification": [
            "Toggle reduced-motion preference",
            "Navigate rapidly during transition"
          ],
          "deliverables": [
            "Motion styles and interaction case"
          ],
          "rollout": "Disable transitions globally if state depends on them.",
          "skills": [
            "Reduced motion",
            "CSS"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "447e7e78-9f3d-4bcb-ae97-030dfe52c4b0",
          "key": "CCAL-110",
          "title": "Audit staffing calendar semantics in a reproducible manual walkthrough",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "review",
          "dependsOn": [
            "CCAL-107",
            "CCAL-108",
            "CCAL-109"
          ],
          "scenario": "Automated checks pass but the team lacks a repeatable reading and editing protocol. Write and execute a bounded walkthrough.",
          "acceptanceCriteria": [
            "Protocol covers agenda and grid",
            "Keyboard outcomes are recorded",
            "Failures include concrete reproduction steps"
          ],
          "implementationNotes": [
            "Report tested browser and assistive tool versions, not certification."
          ],
          "verification": [
            "Complete one shift move",
            "Exercise conflict and empty-week paths"
          ],
          "deliverables": [
            "Manual audit record with unresolved findings"
          ],
          "rollout": "Reopen failed behaviors before widening the calendar pilot.",
          "skills": [
            "Accessibility testing",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "b36fc115-2462-454c-a65f-b038da1ea5a6",
      "key": "CTABLE",
      "title": "An accessible reporting workbench",
      "field": "Accessibility",
      "summary": "Give charts, sortable tables and exports equivalent understandable information.",
      "context": "Fictional cooperative Quarry reviews synthetic service-volume reports. Build local report fixtures with empty, missing and delayed values.",
      "stack": [
        "React",
        "TypeScript",
        "CSS Modules",
        "Playwright"
      ],
      "prerequisites": [
        "Create synthetic report series with explicit missing values.",
        "Stub report loading, sorting and export responses."
      ],
      "developerValue": "Practice semantic data presentation and robust interaction.",
      "companyValue": "Inspect whether reporting decisions remain possible without color or pointer use.",
      "delivery": "Submit focused report changes with manual checks; no compliance certification is implied.",
      "phases": [
        {
          "id": "meaning",
          "title": "Expose report meaning",
          "goal": "Define labels and missing values."
        },
        {
          "id": "interaction",
          "title": "Operate report controls",
          "goal": "Keep sorting, disclosure and export accessible."
        },
        {
          "id": "validation",
          "title": "Verify equivalent access",
          "goal": "Test constrained display and failure feedback."
        }
      ],
      "tickets": [
        {
          "id": "72dd31e1-90fa-440a-9a0c-dbbe8ae37892",
          "key": "CTABLE-101",
          "title": "Give report charts a textual trend summary",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "meaning",
          "dependsOn": [],
          "scenario": "A line chart has only an image label reading Chart. Add a concise summary sourced from the displayed series.",
          "acceptanceCriteria": [
            "Summary names metric and period",
            "Missing samples are disclosed",
            "Summary does not invent causation"
          ],
          "implementationNotes": [
            "Compute facts from fixture data only."
          ],
          "verification": [
            "Summarize rising series",
            "Summarize incomplete series"
          ],
          "deliverables": [
            "Trend summary projection"
          ],
          "rollout": "Hide summary if it disagrees with displayed data.",
          "skills": [
            "Data visualization",
            "Semantics"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d79e6c2c-dc9d-42d5-8550-fcb648a1935c",
          "key": "CTABLE-102",
          "title": "Preserve table header associations in the reporting workbench",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "meaning",
          "dependsOn": [],
          "scenario": "Sticky styling replaced table headers with generic containers. Restore native table relationships.",
          "acceptanceCriteria": [
            "Column headers use correct semantics",
            "Row labels identify rows",
            "Sticky behavior preserves reading order"
          ],
          "implementationNotes": [
            "Avoid ARIA overrides of native table roles."
          ],
          "verification": [
            "Inspect header relationships",
            "Render grouped and empty rows"
          ],
          "deliverables": [
            "Semantic table markup"
          ],
          "rollout": "Remove sticky styling if it breaks semantics.",
          "skills": [
            "HTML",
            "Tables"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "49633b20-7d34-4613-9a7f-9d886177bac2",
          "key": "CTABLE-103",
          "title": "Represent missing report observations distinctly from zero",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "meaning",
          "dependsOn": [
            "CTABLE-101",
            "CTABLE-102"
          ],
          "scenario": "Missing intervals are graphed at zero and alter the apparent trend. Define equivalent chart and table representations.",
          "acceptanceCriteria": [
            "Zero remains numeric",
            "Missing values have explicit text",
            "Chart gaps match table omissions"
          ],
          "implementationNotes": [
            "Do not impute values within this ticket."
          ],
          "verification": [
            "Compare zero and missing rows",
            "Use all-missing series"
          ],
          "deliverables": [
            "Missing-value contract and cases"
          ],
          "rollout": "Disable chart interpolation if gaps are misrepresented.",
          "skills": [
            "Data integrity",
            "Visualization"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 20
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2afec68f-511f-46eb-9d08-cf536d92f036",
          "key": "CTABLE-104",
          "title": "Expose report sorting through semantic header buttons",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "interaction",
          "dependsOn": [
            "CTABLE-102",
            "CTABLE-103"
          ],
          "scenario": "Column sorting works only by clicking an unlabeled header. Add named buttons and current sort direction.",
          "acceptanceCriteria": [
            "Buttons identify sortable field",
            "Current direction is exposed",
            "Unsortable headers remain plain text"
          ],
          "implementationNotes": [
            "Preserve native table navigation."
          ],
          "verification": [
            "Sort ascending then descending",
            "Activate with keyboard"
          ],
          "deliverables": [
            "Sort controls and keyboard cases"
          ],
          "rollout": "Restore fixed documented ordering if controls fail.",
          "skills": [
            "Accessibility",
            "Sorting"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "095d55d5-a733-4445-8bbe-8962e3f5db31",
          "key": "CTABLE-105",
          "title": "Keep report filter errors near their controls",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "interaction",
          "dependsOn": [
            "CTABLE-104"
          ],
          "scenario": "Invalid date ranges produce a toast that disappears before users reach the fields. Add persistent linked errors.",
          "acceptanceCriteria": [
            "Error names affected range",
            "Correction clears the message",
            "Submitted values remain editable"
          ],
          "implementationNotes": [
            "Do not automatically reset user dates."
          ],
          "verification": [
            "Submit reversed range",
            "Correct only end date"
          ],
          "deliverables": [
            "Date-filter errors and focus checks"
          ],
          "rollout": "Fall back to explicit apply with inline errors.",
          "skills": [
            "Forms",
            "Error recovery"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4c51e0cd-d6b5-4a5c-baeb-a9973efd15df",
          "key": "CTABLE-106",
          "title": "Provide a keyboard alternative to chart range brushing",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "interaction",
          "dependsOn": [
            "CTABLE-101",
            "CTABLE-105"
          ],
          "scenario": "Selecting a chart interval requires dragging across the plot. Add equivalent start/end interval controls.",
          "acceptanceCriteria": [
            "Controls select the same range",
            "Selection is visible in table",
            "Out-of-range values explain limits"
          ],
          "implementationNotes": [
            "Keep brushing optional."
          ],
          "verification": [
            "Select identical range both ways",
            "Enter range outside data"
          ],
          "deliverables": [
            "Range selector and equivalence tests"
          ],
          "rollout": "Disable brushing if it diverges from controls.",
          "skills": [
            "Keyboard",
            "Data visualization"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "09761a98-c142-499b-9059-8e2a7f1a4cf2",
          "key": "CTABLE-107",
          "title": "Keep report details discoverable after virtualized rows leave view",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "interaction",
          "dependsOn": [
            "CTABLE-104",
            "CTABLE-106"
          ],
          "scenario": "Expanded row details unmount during scrolling and leave focus nowhere. Bound virtualization around active interaction.",
          "acceptanceCriteria": [
            "Focused details remain mounted",
            "Collapsed rows release retained nodes",
            "Large fixtures stay within documented DOM budget"
          ],
          "implementationNotes": [
            "Do not pin every previously opened row forever."
          ],
          "verification": [
            "Scroll focused detail out of view",
            "Collapse and verify reclamation"
          ],
          "deliverables": [
            "Focus-aware virtualization policy"
          ],
          "rollout": "Disable virtualization for interactive details if focus is lost.",
          "skills": [
            "Virtualization",
            "Focus management"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2eeee55f-abac-4af4-80c7-91ccd10b6404",
          "key": "CTABLE-108",
          "title": "Announce reporting export readiness without stealing focus",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "validation",
          "dependsOn": [
            "CTABLE-105"
          ],
          "scenario": "A completed export opens a modal and interrupts filter editing. Expose a stable download action with a status message.",
          "acceptanceCriteria": [
            "Readiness announces once",
            "Focus stays in active control",
            "Failure exposes retry"
          ],
          "implementationNotes": [
            "Keep file status outside the table live region."
          ],
          "verification": [
            "Complete export while editing",
            "Fail export before completion"
          ],
          "deliverables": [
            "Export status component"
          ],
          "rollout": "Use explicit status refresh if announcements repeat.",
          "skills": [
            "Async UI",
            "Live regions"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d3e5b338-8cff-48ae-a275-80cfe7f81771",
          "key": "CTABLE-109",
          "title": "Keep report distinctions visible in forced-color mode",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "validation",
          "dependsOn": [
            "CTABLE-103",
            "CTABLE-107"
          ],
          "scenario": "Report lines and selected rows vanish under forced colors. Add structural distinctions using patterns and borders.",
          "acceptanceCriteria": [
            "Series have non-color identifiers",
            "Selected rows retain visible state",
            "Focus outline remains discernible"
          ],
          "implementationNotes": [
            "Honor system colors instead of forcing brand fills."
          ],
          "verification": [
            "Inspect forced-color rendering",
            "Check selected row on empty refresh"
          ],
          "deliverables": [
            "Styles and captured verification notes"
          ],
          "rollout": "Use the data table as the default constrained view.",
          "skills": [
            "Forced colors",
            "CSS"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "135c5ace-7524-4fa8-8b3a-4b35ae3ea645",
          "key": "CTABLE-110",
          "title": "Document report equivalence through a narrow assistive audit",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "validation",
          "dependsOn": [
            "CTABLE-107",
            "CTABLE-108",
            "CTABLE-109"
          ],
          "scenario": "The team cannot verify that the chart alternative carries the same decisions. Execute a defined fixture-based comparison.",
          "acceptanceCriteria": [
            "Audit compares values and gaps",
            "Keyboard sort and export are covered",
            "Unresolved limitations remain explicit"
          ],
          "implementationNotes": [
            "Record environment and actual observations."
          ],
          "verification": [
            "Find highest known interval both ways",
            "Inspect missing data and failed export"
          ],
          "deliverables": [
            "Audit protocol and findings"
          ],
          "rollout": "Block wider report rollout for reproducible information loss.",
          "skills": [
            "Accessibility testing",
            "Data quality"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "9e8f3851-5a67-45b4-b7ea-05be8f9a803f",
      "key": "CMODAL",
      "title": "Accessible overlays and notifications in a team portal",
      "field": "Accessibility",
      "summary": "Make dialogs, menus, toasts and nested workflows predictable across input methods.",
      "context": "Fictional membership portal Juniper manages synthetic team settings. Use locally owned components and a local settings adapter.",
      "stack": [
        "React",
        "TypeScript",
        "Base UI",
        "CSS Modules"
      ],
      "prerequisites": [
        "Create synthetic settings forms and destructive-action stubs.",
        "Provide delayed success, rejection and removed-trigger cases."
      ],
      "developerValue": "Practice focus containment, dismissal and asynchronous feedback.",
      "companyValue": "Inspect whether shared UI primitives protect users across many product flows.",
      "delivery": "Change one owned primitive at a time and record affected portal consumers.",
      "phases": [
        {
          "id": "contracts",
          "title": "Specify overlay contracts",
          "goal": "Name dialogs and define dismissal."
        },
        {
          "id": "composition",
          "title": "Handle nested interactions",
          "goal": "Preserve focus and pending user work."
        },
        {
          "id": "feedback",
          "title": "Make feedback durable",
          "goal": "Support zoom and verify reusable behavior."
        }
      ],
      "tickets": [
        {
          "id": "5c8d129a-8969-4b50-a9a0-3355f2710707",
          "key": "CMODAL-101",
          "title": "Name team-setting dialogs from visible headings",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contracts",
          "dependsOn": [],
          "scenario": "Screen readers announce Dialog without a purpose. Connect each settings dialog to its visible heading.",
          "acceptanceCriteria": [
            "Dialog has a meaningful name",
            "Description excludes the entire form",
            "Heading IDs remain unique"
          ],
          "implementationNotes": [
            "Use the owned primitive's naming API."
          ],
          "verification": [
            "Open two dialog types",
            "Mount repeated instances"
          ],
          "deliverables": [
            "Dialog naming fix and checks"
          ],
          "rollout": "Revert consumer composition if names collide.",
          "skills": [
            "Accessible names",
            "Composition"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 80
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3319f07e-2e79-4a61-a3e8-41826272824b",
          "key": "CMODAL-102",
          "title": "Make portal notification dismissal keyboard operable",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "contracts",
          "dependsOn": [],
          "scenario": "Toast close icons have no accessible name and cannot receive focus. Add an explicit dismissal control.",
          "acceptanceCriteria": [
            "Close has an action name",
            "Keyboard activation dismisses",
            "Dismissal preserves sensible focus"
          ],
          "implementationNotes": [
            "Notifications cannot trap focus."
          ],
          "verification": [
            "Dismiss via keyboard",
            "Dismiss notification whose trigger disappeared"
          ],
          "deliverables": [
            "Dismiss control and focus cases"
          ],
          "rollout": "Keep notifications persistent if dismissal becomes unreachable.",
          "skills": [
            "Keyboard",
            "Focus"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0129c725-af78-460b-a1d2-846202ff3a0a",
          "key": "CMODAL-103",
          "title": "Define when unsaved settings dialogs may close",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contracts",
          "dependsOn": [
            "CMODAL-101"
          ],
          "scenario": "Escape silently discards edited settings. Add a dirty-state close contract shared by close button and outside interaction.",
          "acceptanceCriteria": [
            "Clean dialogs close normally",
            "Dirty close requests confirmation",
            "Cancel keeps draft and focus"
          ],
          "implementationNotes": [
            "Avoid browser-wide beforeunload for local overlay changes."
          ],
          "verification": [
            "Close clean dialog",
            "Cancel dirty dismissal"
          ],
          "deliverables": [
            "Close policy and interaction cases"
          ],
          "rollout": "Disable outside dismissal while correcting the policy.",
          "skills": [
            "Forms",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Accessibility",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e94885c4-025e-47b9-98f4-cc0ae22fe105",
          "key": "CMODAL-104",
          "title": "Return focus when a portal dialog trigger disappears",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "composition",
          "dependsOn": [
            "CMODAL-103"
          ],
          "scenario": "After deleting a row through its dialog, the original trigger no longer exists. Provide a surviving fallback target.",
          "acceptanceCriteria": [
            "Existing trigger regains focus",
            "Deleted trigger uses nearest contextual control",
            "Failure keeps focus inside dialog"
          ],
          "implementationNotes": [
            "Resolve fallback after committed row removal."
          ],
          "verification": [
            "Save without deleting trigger",
            "Delete the trigger's row"
          ],
          "deliverables": [
            "Focus-return resolver and cases"
          ],
          "rollout": "Keep an action-result placeholder if no valid target exists.",
          "skills": [
            "Focus management",
            "DOM"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "dd12ae09-2103-4fe2-bf3d-4f20da4ffe89",
          "key": "CMODAL-105",
          "title": "Keep parent settings inert while a nested confirmation is open",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "composition",
          "dependsOn": [
            "CMODAL-103",
            "CMODAL-104"
          ],
          "scenario": "Tab reaches the parent form behind a confirmation dialog. Compose modal ownership across one nested level.",
          "acceptanceCriteria": [
            "Tab stays in active confirmation",
            "Escape closes only top layer",
            "Parent state survives confirmation cancellation"
          ],
          "implementationNotes": [
            "Use the accessible primitive rather than manual document-wide traps."
          ],
          "verification": [
            "Cycle Tab through nested dialog",
            "Cancel then resume parent form"
          ],
          "deliverables": [
            "Nested-dialog composition tests"
          ],
          "rollout": "Replace nested confirmation with an inline confirmation step.",
          "skills": [
            "Accessibility",
            "Modal composition"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "87e54181-f529-4674-8a58-c23c0c12a028",
          "key": "CMODAL-106",
          "title": "Prevent menu dismissal from swallowing a settings action",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "composition",
          "dependsOn": [
            "CMODAL-104"
          ],
          "scenario": "Choosing Rename closes the menu before its dialog receives the intended row. Make the action payload stable through dismissal.",
          "acceptanceCriteria": [
            "Rename targets selected row",
            "Keyboard and pointer match",
            "Removed rows show unavailable state"
          ],
          "implementationNotes": [
            "Capture immutable row identity at activation."
          ],
          "verification": [
            "Rename from keyboard menu",
            "Remove row before dialog load"
          ],
          "deliverables": [
            "Menu-to-dialog handoff"
          ],
          "rollout": "Disable the menu action if identity is unresolved.",
          "skills": [
            "Event ordering",
            "State ownership"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "73b2eeaa-62b5-499c-acb3-e9abe5b9e9d5",
          "key": "CMODAL-107",
          "title": "Keep pending portal dialog saves cancellable without duplicate writes",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "composition",
          "dependsOn": [
            "CMODAL-105",
            "CMODAL-106"
          ],
          "scenario": "A slow save invites repeated clicks and users cannot tell whether closing cancels the write. Specify operation and view lifecycles separately.",
          "acceptanceCriteria": [
            "One pending write per revision",
            "Closing does not claim server cancellation",
            "Reopen reconciles operation status"
          ],
          "implementationNotes": [
            "Adapter cancellation may be advisory only."
          ],
          "verification": [
            "Close after accepted save",
            "Timeout then reopen same operation"
          ],
          "deliverables": [
            "Pending-operation model and races"
          ],
          "rollout": "Disable closing during unresolved operations with an explicit explanation.",
          "skills": [
            "Concurrency",
            "Failure semantics"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5929d491-ce01-4b5c-bce0-756131ccf00d",
          "key": "CMODAL-108",
          "title": "Reflow portal dialogs without hiding their confirmation actions",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "feedback",
          "dependsOn": [
            "CMODAL-105"
          ],
          "scenario": "Magnified text pushes Save below a fixed-height dialog with no reachable scroll path. Reflow the dialog shell.",
          "acceptanceCriteria": [
            "Content scrolls inside labeled region",
            "Actions stay reachable",
            "Document background remains inert"
          ],
          "implementationNotes": [
            "Avoid fixed pixel heights for text containers."
          ],
          "verification": [
            "Check 200 percent text sizing",
            "Use long error descriptions"
          ],
          "deliverables": [
            "Responsive dialog styles"
          ],
          "rollout": "Use full-page forms if actions cannot remain reachable.",
          "skills": [
            "CSS",
            "Responsive design"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a8c3ef95-2d38-451e-acc6-666eb0e90a4d",
          "key": "CMODAL-109",
          "title": "Make critical portal notifications persistent until acknowledged",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "feedback",
          "dependsOn": [
            "CMODAL-102",
            "CMODAL-107"
          ],
          "scenario": "A failed permission change disappears after four seconds. Separate persistent actionable failures from transient informational status.",
          "acceptanceCriteria": [
            "Failed changes remain visible",
            "Acknowledgement is explicit",
            "Repeated same failure coalesces without losing action"
          ],
          "implementationNotes": [
            "Do not use urgency announcements for every toast."
          ],
          "verification": [
            "Reject permission change",
            "Repeat rejection and inspect coalescing"
          ],
          "deliverables": [
            "Notification priority contract"
          ],
          "rollout": "Disable auto-dismiss for all actionable messages if classification fails.",
          "skills": [
            "Live regions",
            "Error handling"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1935ea54-b140-4201-836c-d17096293a6d",
          "key": "CMODAL-110",
          "title": "Audit shared portal overlays across input and theme settings",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "feedback",
          "dependsOn": [
            "CMODAL-108",
            "CMODAL-109"
          ],
          "scenario": "Primitive fixes may regress different consumers. Run a bounded matrix on settings, rename and deletion flows.",
          "acceptanceCriteria": [
            "Matrix covers keyboard and pointer",
            "Light dark and forced colors are recorded",
            "Failures include minimal reproduction"
          ],
          "implementationNotes": [
            "Report actual local observations and remaining gaps."
          ],
          "verification": [
            "Complete rename flow",
            "Exercise rejected delete in constrained display"
          ],
          "deliverables": [
            "Overlay audit record"
          ],
          "rollout": "Keep affected consumer disabled until its blocking regression is fixed.",
          "skills": [
            "Accessibility testing",
            "Regression analysis"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "c3d7d229-4f2e-4563-8d9c-867a2ec3412a",
      "key": "CPRES",
      "title": "Presence that remains honest during disconnection",
      "field": "Real-time systems",
      "summary": "Model ephemeral team presence with expiry, reconnects and scoped fan-out.",
      "context": "Fictional document team Pine shows collaboration presence for synthetic accounts. Build a loopback WebSocket server and injected clocks; no message content or activity surveillance is required.",
      "stack": [
        "TypeScript",
        "WebSocket",
        "Redis adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create synthetic memberships and session identifiers.",
        "Implement controllable sockets and an in-memory TTL adapter."
      ],
      "developerValue": "Practice ephemeral state, ordering and reconnect semantics.",
      "companyValue": "Inspect whether online indicators avoid stale or unauthorized claims.",
      "delivery": "Presence means an active connection lease only; it does not infer attention or productivity.",
      "phases": [
        {
          "id": "leases",
          "title": "Define presence meaning",
          "goal": "Specify scopes and expiry."
        },
        {
          "id": "fanout",
          "title": "Distribute state safely",
          "goal": "Handle identity and reconnect races."
        },
        {
          "id": "operations",
          "title": "Bound operating behavior",
          "goal": "Limit work and diagnose stale indicators."
        }
      ],
      "tickets": [
        {
          "id": "0e5e9b70-dd06-4b27-ac48-b35f427c20eb",
          "key": "CPRES-101",
          "title": "Define online presence as an unexpired connection lease",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "leases",
          "dependsOn": [],
          "scenario": "A green dot remains after the browser closes. Replace the permanent flag with explicitly expiring presence.",
          "acceptanceCriteria": [
            "Active lease shows connected",
            "Expiry removes connected state",
            "UI explains connection meaning"
          ],
          "implementationNotes": [
            "Do not infer human attention from a socket."
          ],
          "verification": [
            "Advance clock before expiry",
            "Advance beyond expiry without disconnect"
          ],
          "deliverables": [
            "Lease contract and clock cases"
          ],
          "rollout": "Hide presence if lease freshness cannot be established.",
          "skills": [
            "TTL",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c61f0c42-ba2a-4cb8-bc3d-e40757c6bac8",
          "key": "CPRES-102",
          "title": "Validate presence room identifiers before subscribing",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "leases",
          "dependsOn": [],
          "scenario": "Malformed room names reach the broker and create unbounded keys. Parse a bounded typed room identifier.",
          "acceptanceCriteria": [
            "Valid room IDs subscribe",
            "Malformed IDs fail before broker access",
            "Error omits raw oversized input"
          ],
          "implementationNotes": [
            "Room parsing does not replace membership checks."
          ],
          "verification": [
            "Subscribe valid fixture room",
            "Send oversized room identifier"
          ],
          "deliverables": [
            "Room parser and rejection tests"
          ],
          "rollout": "Reject new subscriptions if parsing fails.",
          "skills": [
            "Input validation",
            "Pub-sub"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "3615cb97-e65d-49b0-8f84-a63f91672070",
          "key": "CPRES-103",
          "title": "Scope presence membership checks to each room subscription",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "leases",
          "dependsOn": [
            "CPRES-101",
            "CPRES-102"
          ],
          "scenario": "Authentication alone currently permits joining any document room. Require current membership in the room boundary.",
          "acceptanceCriteria": [
            "Member can join",
            "Foreign member is denied",
            "Revoked membership cannot renew lease"
          ],
          "implementationNotes": [
            "Recheck authority at renewal using local stub."
          ],
          "verification": [
            "Join authorized room",
            "Revoke membership before renewal"
          ],
          "deliverables": [
            "Subscription authorization and denial cases"
          ],
          "rollout": "Stop renewals while membership adapter is unavailable.",
          "skills": [
            "Authorization",
            "Tenancy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "aae20ce3-3f0b-475f-aff3-bf73ab346b38",
          "key": "CPRES-104",
          "title": "Count multiple presence connections without duplicating people",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "fanout",
          "dependsOn": [
            "CPRES-103"
          ],
          "scenario": "Two tabs display the same teammate twice. Aggregate active connection leases under a scoped synthetic account.",
          "acceptanceCriteria": [
            "One person entry per room",
            "Closing one tab preserves other lease",
            "Last expiry removes person"
          ],
          "implementationNotes": [
            "Do not merge identities across organizations."
          ],
          "verification": [
            "Open two tabs",
            "Expire last connection"
          ],
          "deliverables": [
            "Presence aggregation and cases"
          ],
          "rollout": "Display connection counts only if person aggregation is incorrect.",
          "skills": [
            "Aggregation",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "12b600c2-1d58-4ba9-a9bb-ce9a97266c1e",
          "key": "CPRES-105",
          "title": "Reject stale presence heartbeats after reconnect",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "fanout",
          "dependsOn": [
            "CPRES-103",
            "CPRES-104"
          ],
          "scenario": "Delayed heartbeat from a replaced socket prolongs a dead session. Bind renewal to session generation.",
          "acceptanceCriteria": [
            "New generation supersedes old",
            "Old heartbeat cannot renew",
            "Current heartbeat extends its own lease"
          ],
          "implementationNotes": [
            "Generation changes must be atomic in the adapter."
          ],
          "verification": [
            "Renew current session",
            "Deliver old heartbeat after reconnect"
          ],
          "deliverables": [
            "Generation guard and race tests"
          ],
          "rollout": "Close superseded sessions and require fresh joins.",
          "skills": [
            "Concurrency",
            "Fencing"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1493c756-a2ef-4649-adc5-d4a98f2700c7",
          "key": "CPRES-106",
          "title": "Send a presence snapshot before incremental updates",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "fanout",
          "dependsOn": [
            "CPRES-104",
            "CPRES-105"
          ],
          "scenario": "A new client applies deltas to an empty list and misses existing teammates. Add snapshot sequencing at subscription.",
          "acceptanceCriteria": [
            "Snapshot establishes sequence",
            "Later deltas follow its watermark",
            "Detected gaps trigger resnapshot"
          ],
          "implementationNotes": [
            "Buffer during snapshot only within a documented limit."
          ],
          "verification": [
            "Join populated room",
            "Drop one delta and detect gap"
          ],
          "deliverables": [
            "Snapshot handshake and gap cases"
          ],
          "rollout": "Resend full snapshots while delta path is repaired.",
          "skills": [
            "Ordering",
            "State synchronization"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e2bf9730-d315-444e-afac-538f8929b1f1",
          "key": "CPRES-107",
          "title": "Expire presence independently of disconnect delivery",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "fanout",
          "dependsOn": [
            "CPRES-101",
            "CPRES-105",
            "CPRES-106"
          ],
          "scenario": "A server restart loses disconnect events and rooms retain ghosts. Make lease expiry authoritative across process recovery.",
          "acceptanceCriteria": [
            "Restart cannot preserve expired entries",
            "Cleanup repeats safely",
            "Concurrent renewal cannot delete fresh lease"
          ],
          "implementationNotes": [
            "Compare stored lease identity before removal."
          ],
          "verification": [
            "Restart with expired leases",
            "Renew during cleanup"
          ],
          "deliverables": [
            "Expiry reconciliation and interleaving cases"
          ],
          "rollout": "Disable cleanup writes if lease identity cannot be checked.",
          "skills": [
            "Recovery",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "74712b3c-239c-4c07-a17e-fb5266b0641a",
          "key": "CPRES-108",
          "title": "Cap presence fan-out per room without silently losing state",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operations",
          "dependsOn": [
            "CPRES-106"
          ],
          "scenario": "A synthetic busy room causes unbounded socket buffers. Introduce a per-client queue cap and resync fallback.",
          "acceptanceCriteria": [
            "Buffer count is bounded",
            "Overflow requests resnapshot",
            "Healthy peers continue receiving"
          ],
          "implementationNotes": [
            "Do not drop arbitrary deltas and claim synchronization."
          ],
          "verification": [
            "Exercise normal fan-out",
            "Stall one client to capacity"
          ],
          "deliverables": [
            "Bounded broadcaster and overflow cases"
          ],
          "rollout": "Disconnect slow clients with a clear resync reason.",
          "skills": [
            "Backpressure",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "96146c8d-8185-444a-8fdf-b49e87410f84",
          "key": "CPRES-109",
          "title": "Distinguish disconnected and stale presence in the client",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "operations",
          "dependsOn": [
            "CPRES-107",
            "CPRES-108"
          ],
          "scenario": "Network loss freezes green dots and suggests teammates remain connected. Mark stale state during transport uncertainty.",
          "acceptanceCriteria": [
            "Local disconnect marks snapshot stale",
            "Reconnect waits for fresh snapshot",
            "Stale entries are not labeled online"
          ],
          "implementationNotes": [
            "Preserve names only while room access remains valid."
          ],
          "verification": [
            "Disconnect then reconnect",
            "Lose authorization during reconnect"
          ],
          "deliverables": [
            "Presence freshness UI"
          ],
          "rollout": "Hide entries during uncertainty if freshness labeling fails.",
          "skills": [
            "UX",
            "State projection"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e4a92b23-ca34-4c54-b330-b63cf085f028",
          "key": "CPRES-110",
          "title": "Expose presence lease diagnostics without activity histories",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "operations",
          "dependsOn": [
            "CPRES-109"
          ],
          "scenario": "Operators need to locate ghost indicators without collecting behavioral timelines. Add current aggregate lease counters.",
          "acceptanceCriteria": [
            "Counters include active and expired totals",
            "No per-person activity history is stored",
            "Room labels use bounded safe identifiers"
          ],
          "implementationNotes": [
            "Use synthetic rooms in samples."
          ],
          "verification": [
            "Inspect healthy counters",
            "Create expired lease and verify aggregation"
          ],
          "deliverables": [
            "Diagnostic contract and samples"
          ],
          "rollout": "Disable diagnostics if person-level histories appear.",
          "skills": [
            "Observability",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Real-time systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "ad213ad0-6963-4653-8f19-f91db05f6240",
      "key": "CLIVE",
      "title": "A live incident board with recoverable updates",
      "field": "Real-time systems",
      "summary": "Keep a synthetic service-status board ordered and replayable over server-sent events.",
      "context": "Fictional internal status team Harbor updates operational incident cards. Build a local event log and SSE adapter; incidents and service names are invented.",
      "stack": [
        "TypeScript",
        "Server-sent events",
        "PostgreSQL adapter",
        "React"
      ],
      "prerequisites": [
        "Create synthetic incident revisions and a local append-only event stub.",
        "Provide controllable disconnect, replay and retention fixtures."
      ],
      "developerValue": "Practice event projection, replay and freshness communication.",
      "companyValue": "Inspect whether dashboards remain trustworthy through network interruptions.",
      "delivery": "Use local fixtures; this board is not an emergency-response system.",
      "phases": [
        {
          "id": "events",
          "title": "Specify live events",
          "goal": "Define event identity and projection."
        },
        {
          "id": "replay",
          "title": "Recover transport gaps",
          "goal": "Make replay and mutation coherent."
        },
        {
          "id": "operation",
          "title": "Operate bounded streams",
          "goal": "Handle slow clients and explain freshness."
        }
      ],
      "tickets": [
        {
          "id": "7abfb514-9327-4837-98d4-cea65d595f58",
          "key": "CLIVE-101",
          "title": "Give live incident events stable opaque identifiers",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "events",
          "dependsOn": [],
          "scenario": "Reconnecting clients cannot distinguish replay from new events because IDs change on delivery. Persist event identity.",
          "acceptanceCriteria": [
            "Replay preserves IDs",
            "Distinct events have unique IDs",
            "IDs contain no incident text"
          ],
          "implementationNotes": [
            "Delivery attempts must not mint new event IDs."
          ],
          "verification": [
            "Replay one event twice",
            "Append two equal payloads as distinct events"
          ],
          "deliverables": [
            "Event identity contract"
          ],
          "rollout": "Disable replay until stable IDs exist.",
          "skills": [
            "Event modeling",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e536906c-fa9c-4c33-9735-51a18e1b8cb7",
          "key": "CLIVE-102",
          "title": "Render incident status text independently of severity color",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "events",
          "dependsOn": [],
          "scenario": "Color-only status blocks hide the distinction between investigating and monitoring. Add visible status labels.",
          "acceptanceCriteria": [
            "Every status has text",
            "Unknown status renders explicit fallback",
            "Color is optional reinforcement"
          ],
          "implementationNotes": [
            "Do not infer severity from color tokens."
          ],
          "verification": [
            "Render all fixture statuses",
            "Render unsupported status"
          ],
          "deliverables": [
            "Status presenter and cases"
          ],
          "rollout": "Use text-only presentation if color mapping is wrong.",
          "skills": [
            "Accessibility",
            "State projection"
          ],
          "fieldMix": [
            {
              "field": "Accessibility",
              "percentage": 70
            },
            {
              "field": "Frontend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8f79d82e-e6e3-4c62-bf96-bd3655f0df52",
          "key": "CLIVE-103",
          "title": "Apply live incident updates only to newer revisions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "events",
          "dependsOn": [
            "CLIVE-101",
            "CLIVE-102"
          ],
          "scenario": "A delayed update reopens a resolved incident. Compare revisions before changing the projected card.",
          "acceptanceCriteria": [
            "Newer revisions apply",
            "Equal replay is harmless",
            "Older revisions cannot overwrite"
          ],
          "implementationNotes": [
            "Revision scope is per incident."
          ],
          "verification": [
            "Apply revisions in order",
            "Deliver earlier revision after resolution"
          ],
          "deliverables": [
            "Revision projector and ordering cases"
          ],
          "rollout": "Refresh full cards if ordering cannot be established.",
          "skills": [
            "Ordering",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "541c098e-2239-4661-8393-7c297285f86a",
          "key": "CLIVE-104",
          "title": "Resume incident streams from the last applied event",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "replay",
          "dependsOn": [
            "CLIVE-103"
          ],
          "scenario": "A reconnect misses changes made during disconnection. Send the last applied event ID and replay retained updates.",
          "acceptanceCriteria": [
            "Resume begins after acknowledged ID",
            "Replay preserves event order",
            "Cursor advances after successful projection"
          ],
          "implementationNotes": [
            "Received is not equivalent to applied."
          ],
          "verification": [
            "Reconnect after two missed events",
            "Fail projection before cursor advancement"
          ],
          "deliverables": [
            "Resume coordinator and replay cases"
          ],
          "rollout": "Force snapshot reload instead of uncertain replay.",
          "skills": [
            "SSE",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 20
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f7a30be4-431c-4735-9245-a14ceb757b4d",
          "key": "CLIVE-105",
          "title": "Return a reset contract when incident replay history expired",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "replay",
          "dependsOn": [
            "CLIVE-104"
          ],
          "scenario": "Old clients request a cursor outside retention and appear current with missing changes. Make replay expiry explicit.",
          "acceptanceCriteria": [
            "Expired cursor requests fresh snapshot",
            "Client clears old cursor",
            "Reset has an observable reason"
          ],
          "implementationNotes": [
            "Do not silently start at the newest event."
          ],
          "verification": [
            "Resume retained cursor",
            "Resume expired cursor"
          ],
          "deliverables": [
            "Replay reset contract"
          ],
          "rollout": "Require full reload if reset handling fails.",
          "skills": [
            "Protocol design",
            "Retention"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3637e32d-60db-4d8f-8d61-d454a6663ec6",
          "key": "CLIVE-106",
          "title": "Join incident snapshots and streams at one watermark",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "replay",
          "dependsOn": [
            "CLIVE-104",
            "CLIVE-105"
          ],
          "scenario": "An update between snapshot fetch and stream connect disappears. Establish a snapshot watermark for replay.",
          "acceptanceCriteria": [
            "Snapshot declares its watermark",
            "Stream replays later events",
            "Boundary duplicates remain harmless"
          ],
          "implementationNotes": [
            "Define transaction or adapter ordering explicitly."
          ],
          "verification": [
            "Update before snapshot",
            "Update between snapshot and subscription"
          ],
          "deliverables": [
            "Snapshot-stream handoff and race cases"
          ],
          "rollout": "Use periodic full snapshots while handoff is repaired.",
          "skills": [
            "Consistency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4edd6f7a-4180-42e3-b999-afb767820cf3",
          "key": "CLIVE-107",
          "title": "Reconcile local incident edits with streamed acknowledgements",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "replay",
          "dependsOn": [
            "CLIVE-103",
            "CLIVE-106"
          ],
          "scenario": "Saving an incident and receiving its stream event produces duplicate activity rows. Correlate the committed operation.",
          "acceptanceCriteria": [
            "One committed activity row appears",
            "Rejected edits remain actionable",
            "Unrelated remote events still apply"
          ],
          "implementationNotes": [
            "Do not suppress all events while saving."
          ],
          "verification": [
            "Save and receive acknowledgement",
            "Reject save while another user updates"
          ],
          "deliverables": [
            "Mutation-stream reconciliation"
          ],
          "rollout": "Remove optimistic activity until correlation is correct.",
          "skills": [
            "Optimistic UI",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6c9c7000-5466-450a-8df9-8c6a6ce3b6e0",
          "key": "CLIVE-108",
          "title": "Bound each incident subscriber buffer",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operation",
          "dependsOn": [
            "CLIVE-106"
          ],
          "scenario": "A slow status screen accumulates unbounded events. Cap its queue and require reset when it cannot keep up.",
          "acceptanceCriteria": [
            "Queue respects configured bound",
            "Overflow terminates with reset guidance",
            "Other subscribers remain independent"
          ],
          "implementationNotes": [
            "Never silently discard ordered events."
          ],
          "verification": [
            "Stream to healthy client",
            "Stall client beyond queue capacity"
          ],
          "deliverables": [
            "Subscriber backpressure policy"
          ],
          "rollout": "Disconnect slow subscribers and require fresh snapshots.",
          "skills": [
            "Backpressure",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6ef0cabd-cc06-41fa-bda9-6b745b5d9a5b",
          "key": "CLIVE-109",
          "title": "Show incident-board freshness independently from incident status",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "operation",
          "dependsOn": [
            "CLIVE-105",
            "CLIVE-108"
          ],
          "scenario": "A disconnected screen says All systems normal because incident cards retain their last values. Add transport freshness.",
          "acceptanceCriteria": [
            "Last applied time is visible",
            "Disconnect shows stale state",
            "Reconnect clears stale only after catch-up"
          ],
          "implementationNotes": [
            "Use synthetic clock values in tests."
          ],
          "verification": [
            "Disconnect resolved board",
            "Reconnect with missed open incident"
          ],
          "deliverables": [
            "Freshness banner and recovery cases"
          ],
          "rollout": "Hide aggregate healthy claim while freshness is uncertain.",
          "skills": [
            "UX",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a9e99bf2-dc69-462b-85ac-70af174b3fef",
          "key": "CLIVE-110",
          "title": "Record incident-stream recovery reasons without payload logging",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "operation",
          "dependsOn": [
            "CLIVE-109"
          ],
          "scenario": "Investigating replay failures currently logs full incident descriptions. Add an allowlisted recovery event schema.",
          "acceptanceCriteria": [
            "Includes reset reason and cursor category",
            "Omits descriptions and author names",
            "Malformed IDs are bounded"
          ],
          "implementationNotes": [
            "Correlation identifiers cannot carry user text."
          ],
          "verification": [
            "Capture successful resume",
            "Reject secret-like malformed cursor"
          ],
          "deliverables": [
            "Recovery diagnostics and exclusion checks"
          ],
          "rollout": "Disable stream logging if payload fields appear.",
          "skills": [
            "Logging",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Real-time systems",
              "percentage": 20
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "870ca293-ba3d-4340-bd71-a2142fa7bef0",
      "key": "CAUCT",
      "title": "A realtime reservation window for workshop seats",
      "field": "Real-time systems",
      "summary": "Coordinate expiring seat holds and live availability in a local simulation.",
      "context": "Fictional craft studio Maple offers workshop seats. Implement synthetic reservations without payments or real booking services.",
      "stack": [
        "TypeScript",
        "PostgreSQL adapter",
        "WebSocket",
        "Vitest"
      ],
      "prerequisites": [
        "Create synthetic workshops with small capacities.",
        "Implement local transactional hold storage and injected clocks."
      ],
      "developerValue": "Practice contention, expiry and truthful realtime projections.",
      "companyValue": "Inspect whether concurrent clients avoid overselling and recover uncertain results.",
      "delivery": "Booking simulation only; payment and production capacity planning are excluded.",
      "phases": [
        {
          "id": "holds",
          "title": "Define hold rules",
          "goal": "Specify capacity and ownership."
        },
        {
          "id": "races",
          "title": "Resolve concurrent changes",
          "goal": "Handle expiry and confirmation atomically."
        },
        {
          "id": "clients",
          "title": "Synchronize the audience",
          "goal": "Keep availability and recovery bounded."
        }
      ],
      "tickets": [
        {
          "id": "b1149a73-eb98-44ba-a263-3ca1538e972b",
          "key": "CAUCT-101",
          "title": "Specify workshop seat counts without negative availability",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "holds",
          "dependsOn": [],
          "scenario": "The prototype subtracts all historical holds and displays negative seats. Project availability from current authoritative states.",
          "acceptanceCriteria": [
            "Only active holds consume seats",
            "Confirmed reservations consume seats",
            "Expired holds do not consume seats"
          ],
          "implementationNotes": [
            "Define active using injected time."
          ],
          "verification": [
            "Project mixed states",
            "Use boundary expiry instant"
          ],
          "deliverables": [
            "Availability projection and cases"
          ],
          "rollout": "Hide counts if state cannot be reconciled.",
          "skills": [
            "State modeling",
            "Time"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5c7cf0d8-af2c-4eaa-8915-225612f3ce5b",
          "key": "CAUCT-102",
          "title": "Validate workshop hold quantities before storage",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "holds",
          "dependsOn": [
            "CAUCT-101"
          ],
          "scenario": "A zero-seat request creates a hold and a fractional request breaks counts. Enforce bounded integer quantities.",
          "acceptanceCriteria": [
            "Positive integers within limit pass",
            "Zero and fractions fail",
            "Invalid input creates no record"
          ],
          "implementationNotes": [
            "Keep limits explicit in the local contract."
          ],
          "verification": [
            "Hold two seats",
            "Reject zero and oversized quantities"
          ],
          "deliverables": [
            "Quantity validator and failure cases"
          ],
          "rollout": "Reject new holds if validation is unavailable.",
          "skills": [
            "Validation",
            "Contracts"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "86d754d4-7ef2-4eea-a645-f914809b8b5d",
          "key": "CAUCT-103",
          "title": "Create workshop holds atomically under contention",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "holds",
          "dependsOn": [
            "CAUCT-101",
            "CAUCT-102"
          ],
          "scenario": "Two clients see one available seat and both reserve it. Serialize capacity consumption at storage.",
          "acceptanceCriteria": [
            "At most capacity is consumed",
            "Loser receives unavailable result",
            "No partial hold record remains"
          ],
          "implementationNotes": [
            "A browser availability check is advisory only."
          ],
          "verification": [
            "Create uncontested hold",
            "Race two requests for one seat"
          ],
          "deliverables": [
            "Transactional hold operation"
          ],
          "rollout": "Pause hold creation if capacity invariant fails.",
          "skills": [
            "Transactions",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "04228c7d-6f7b-4246-8630-6979c6c1cd30",
          "key": "CAUCT-104",
          "title": "Scope workshop hold lookup and cancellation to its owner",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "races",
          "dependsOn": [
            "CAUCT-103"
          ],
          "scenario": "Knowing a hold ID lets another user cancel it. Enforce owner scope in the repository boundary.",
          "acceptanceCriteria": [
            "Owner reads and cancels",
            "Foreign owner is denied",
            "Denied calls do not disclose hold details"
          ],
          "implementationNotes": [
            "Synthetic identities remain required in all adapter calls."
          ],
          "verification": [
            "Cancel own hold",
            "Cancel another account's hold"
          ],
          "deliverables": [
            "Scoped hold repository and denial tests"
          ],
          "rollout": "Disable cancellation if scope cannot be established.",
          "skills": [
            "Authorization",
            "Repository design"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "be81a3d4-386e-445e-950b-0e26a2a2ee60",
          "key": "CAUCT-105",
          "title": "Confirm workshop holds only before the expiry boundary",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "races",
          "dependsOn": [
            "CAUCT-103",
            "CAUCT-104"
          ],
          "scenario": "Confirm and expiry cleanup race, creating reservations from expired holds. Add an atomic transition with one time rule.",
          "acceptanceCriteria": [
            "Eligible hold confirms once",
            "Expired hold cannot confirm",
            "Cleanup cannot remove confirmed reservation"
          ],
          "implementationNotes": [
            "Compare time inside the authoritative transition."
          ],
          "verification": [
            "Confirm before boundary",
            "Race confirm with expiry cleanup"
          ],
          "deliverables": [
            "Confirmation transition and boundary cases"
          ],
          "rollout": "Pause confirmation if atomicity fails.",
          "skills": [
            "State machines",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6fb50879-6487-4422-b12f-8ab0c1a538db",
          "key": "CAUCT-106",
          "title": "Replay workshop hold requests with the same idempotency key",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "races",
          "dependsOn": [
            "CAUCT-103"
          ],
          "scenario": "Timeout retry creates two holds for one user's click. Bind the operation key to the normalized request.",
          "acceptanceCriteria": [
            "Same key and payload returns same hold",
            "Different payload conflicts",
            "Keys remain scoped to owner"
          ],
          "implementationNotes": [
            "Store idempotency result with the hold transaction."
          ],
          "verification": [
            "Replay accepted request",
            "Reuse key with different quantity"
          ],
          "deliverables": [
            "Idempotent create contract"
          ],
          "rollout": "Require status lookup while replay support is repaired.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d3454de1-e672-4eaa-8951-c006128c645f",
          "key": "CAUCT-107",
          "title": "Publish workshop availability changes only after commit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "races",
          "dependsOn": [
            "CAUCT-105",
            "CAUCT-106"
          ],
          "scenario": "Clients see seats disappear for a transaction that later rolls back. Publish committed availability through an outbox.",
          "acceptanceCriteria": [
            "Committed changes enqueue events",
            "Rollback emits no event",
            "Replay cannot double-apply availability"
          ],
          "implementationNotes": [
            "Event consumers receive versions, not count deltas alone."
          ],
          "verification": [
            "Commit hold and publish",
            "Roll back after preparing event"
          ],
          "deliverables": [
            "Outbox handoff and rollback cases"
          ],
          "rollout": "Stop live updates and serve authoritative snapshots.",
          "skills": [
            "Outbox",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Real-time systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4fa4cebe-37e4-45e1-b75c-80ffb9380777",
          "key": "CAUCT-108",
          "title": "Rebuild workshop availability after a missed realtime update",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "clients",
          "dependsOn": [
            "CAUCT-107"
          ],
          "scenario": "Dropped socket messages leave the workshop full after holds expire. Detect version gaps and refresh a snapshot.",
          "acceptanceCriteria": [
            "Versions advance monotonically",
            "Gap triggers resync",
            "Stale events cannot reduce version"
          ],
          "implementationNotes": [
            "Snapshot and event versions share one scope."
          ],
          "verification": [
            "Apply contiguous updates",
            "Skip one version and reconnect"
          ],
          "deliverables": [
            "Versioned client projection"
          ],
          "rollout": "Poll snapshots if delta recovery fails.",
          "skills": [
            "Synchronization",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Real-time systems",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "82e6520e-b5f2-426e-b94c-6ca80d5a55d4",
          "key": "CAUCT-109",
          "title": "Display workshop hold countdown as advisory",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "clients",
          "dependsOn": [
            "CAUCT-105",
            "CAUCT-108"
          ],
          "scenario": "A client clock skew shows time remaining after the server expired the hold. Label countdown and reconcile server refusal.",
          "acceptanceCriteria": [
            "Countdown uses server offset estimate",
            "Zero disables local confirmation",
            "Server expiry still wins"
          ],
          "implementationNotes": [
            "A visual timer cannot authorize a reservation."
          ],
          "verification": [
            "Use skewed client clock",
            "Confirm after authoritative expiry"
          ],
          "deliverables": [
            "Countdown presenter and skew cases"
          ],
          "rollout": "Replace countdown with expiry timestamp if offset is unreliable.",
          "skills": [
            "Time",
            "UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9eae6e01-e892-4f2f-98c9-0e2e84ef97d4",
          "key": "CAUCT-110",
          "title": "Bound workshop hold cleanup batches and expose progress",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "clients",
          "dependsOn": [
            "CAUCT-107",
            "CAUCT-108"
          ],
          "scenario": "Cleanup scans every historical hold on each tick. Add bounded cursor batches with repeat-safe transitions.",
          "acceptanceCriteria": [
            "Each batch has fixed limit",
            "Concurrent confirms are preserved",
            "Restart resumes without skipping eligible rows"
          ],
          "implementationNotes": [
            "Use indexed expiry selection in the adapter design."
          ],
          "verification": [
            "Clean several batches",
            "Confirm a selected hold concurrently"
          ],
          "deliverables": [
            "Cleanup worker contract and restart cases"
          ],
          "rollout": "Pause cleanup and rely on read-time expiry until repaired.",
          "skills": [
            "Batch processing",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "257f157a-6e2f-4f0a-9322-abc658a6c403",
      "key": "COBJS",
      "title": "Resumable object uploads with verified completion",
      "field": "Storage systems",
      "summary": "Build a local multipart-upload coordinator with scoped identities and integrity checks.",
      "context": "Fictional document archive Fern stores synthetic byte objects. Use a local S3-compatible adapter or deterministic in-memory provider; no cloud credentials are needed.",
      "stack": [
        "TypeScript",
        "S3-compatible adapter",
        "PostgreSQL adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Generate small deterministic byte fixtures.",
        "Implement local multipart provider responses including timeout and missing parts."
      ],
      "developerValue": "Practice object lifecycle, retry semantics and integrity verification.",
      "companyValue": "Inspect whether uploads avoid corruption, orphan cost and tenant crossover.",
      "delivery": "Submit bounded coordinator changes; external cloud rollout is separate.",
      "phases": [
        {
          "id": "contract",
          "title": "Define upload ownership",
          "goal": "Specify keys, parts and quotas."
        },
        {
          "id": "completion",
          "title": "Complete reliably",
          "goal": "Handle retries and integrity boundaries."
        },
        {
          "id": "recovery",
          "title": "Recover abandoned work",
          "goal": "Reclaim resources and inspect outcomes."
        }
      ],
      "tickets": [
        {
          "id": "de4d8c12-7077-4a6f-9fa2-9f5b81d695c1",
          "key": "COBJS-101",
          "title": "Normalize object names without treating them as filesystem paths",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "The upload API accepts ambiguous separators and empty names. Define an opaque object-name contract.",
          "acceptanceCriteria": [
            "Valid names retain documented characters",
            "Empty and oversized names fail",
            "Normalization collisions are rejected"
          ],
          "implementationNotes": [
            "Object keys are not local file paths."
          ],
          "verification": [
            "Store valid unicode name",
            "Reject colliding normalized names"
          ],
          "deliverables": [
            "Name validator and examples"
          ],
          "rollout": "Reject new ambiguous names while keeping existing reads.",
          "skills": [
            "Object storage",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "be4f0c13-1bc6-491e-97c7-c8bad60c351c",
          "key": "COBJS-102",
          "title": "Bind multipart upload sessions to organization and object identity",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [
            "COBJS-101"
          ],
          "scenario": "A session ID can currently be reused against a different object. Require its original scope on every part operation.",
          "acceptanceCriteria": [
            "Matching owner uploads",
            "Foreign organization is denied",
            "Changed object identity is rejected"
          ],
          "implementationNotes": [
            "Enforce scope in the repository/provider boundary."
          ],
          "verification": [
            "Upload own part",
            "Reuse session against foreign object"
          ],
          "deliverables": [
            "Scoped session adapter and denial cases"
          ],
          "rollout": "Pause multipart writes if scope is uncertain.",
          "skills": [
            "Authorization",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5b6d955f-de17-4a76-9958-2e9b81376658",
          "key": "COBJS-103",
          "title": "Reject multipart uploads exceeding declared size limits",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "contract",
          "dependsOn": [
            "COBJS-102"
          ],
          "scenario": "The coordinator accepts an unlimited part list. Bound declared object size and per-session part count.",
          "acceptanceCriteria": [
            "Valid declared sizes pass",
            "Part count has explicit maximum",
            "Rejected admission creates no provider session"
          ],
          "implementationNotes": [
            "Limits must be checked before remote allocation."
          ],
          "verification": [
            "Admit small fixture",
            "Reject oversized declaration"
          ],
          "deliverables": [
            "Admission policy and allocation checks"
          ],
          "rollout": "Lower admission to a documented safe cap if accounting fails.",
          "skills": [
            "Resource limits",
            "Contracts"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "949898d9-c35e-46b5-ba0b-c8f45af7ef6b",
          "key": "COBJS-104",
          "title": "Retry the same multipart part without creating contradictory receipts",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "completion",
          "dependsOn": [
            "COBJS-102",
            "COBJS-103"
          ],
          "scenario": "A timeout after part acceptance leads to duplicate receipts with different checksums. Bind retries to part number and digest.",
          "acceptanceCriteria": [
            "Same bytes return stable receipt",
            "Different bytes require explicit replacement",
            "Uncertain responses reconcile with provider state"
          ],
          "implementationNotes": [
            "Provider ETag is opaque unless contract says otherwise."
          ],
          "verification": [
            "Retry identical part",
            "Retry changed bytes under same operation"
          ],
          "deliverables": [
            "Part-retry coordinator and cases"
          ],
          "rollout": "Stop retries and expose reconciliation status.",
          "skills": [
            "Idempotency",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "9f0fd846-0b72-4401-847f-d49c31c3e0fd",
          "key": "COBJS-105",
          "title": "Validate ordered multipart completion against acknowledged parts",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "completion",
          "dependsOn": [
            "COBJS-104"
          ],
          "scenario": "Completion silently omits a middle part and produces a shorter object. Check the requested manifest before finalization.",
          "acceptanceCriteria": [
            "Required part numbers are contiguous",
            "Receipts match acknowledged digests",
            "Missing parts prevent completion"
          ],
          "implementationNotes": [
            "Define final-part size exception explicitly."
          ],
          "verification": [
            "Complete ordered fixture",
            "Omit or duplicate middle part"
          ],
          "deliverables": [
            "Completion validator and negative cases"
          ],
          "rollout": "Disable completion until manifest validation recovers.",
          "skills": [
            "Validation",
            "Object storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "610745e9-e43b-4e21-956c-56fe2845c5ce",
          "key": "COBJS-106",
          "title": "Verify completed object content before marking it available",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "completion",
          "dependsOn": [
            "COBJS-105"
          ],
          "scenario": "Provider completion succeeds but the assembled bytes differ from the expected digest. Introduce a verification state.",
          "acceptanceCriteria": [
            "Available requires digest agreement",
            "Mismatch quarantines the object",
            "Verification retries do not republish"
          ],
          "implementationNotes": [
            "Use bounded streaming hashing, not full-memory buffering."
          ],
          "verification": [
            "Verify matching bytes",
            "Flip one completed byte"
          ],
          "deliverables": [
            "Post-completion verifier and corruption cases"
          ],
          "rollout": "Keep newly completed objects unavailable if verification fails.",
          "skills": [
            "Streaming",
            "Hashing"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d8a8754d-2132-4652-b5ef-7342492cda13",
          "key": "COBJS-107",
          "title": "Recover a timeout between multipart finalization and metadata commit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "completion",
          "dependsOn": [
            "COBJS-105",
            "COBJS-106"
          ],
          "scenario": "A crash after provider completion leaves the session looking incomplete. Reconcile provider outcome without creating another object.",
          "acceptanceCriteria": [
            "Recovery locates the finalized identity",
            "Metadata transition repeats safely",
            "Ambiguous provider state stays unresolved"
          ],
          "implementationNotes": [
            "Persist the completion operation before dispatch."
          ],
          "verification": [
            "Crash after finalization",
            "Return inconclusive provider lookup"
          ],
          "deliverables": [
            "Completion journal and crash schedule"
          ],
          "rollout": "Pause automatic completion recovery and retain session metadata.",
          "skills": [
            "Crash consistency",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "70e6f4ca-b857-490e-a52b-9e37f08ba518",
          "key": "COBJS-108",
          "title": "Abort expired multipart sessions without touching completed objects",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "recovery",
          "dependsOn": [
            "COBJS-107"
          ],
          "scenario": "Abandoned sessions retain billable parts. Add expiry cleanup with a guarded session transition.",
          "acceptanceCriteria": [
            "Only expired open sessions abort",
            "Completed objects remain readable",
            "Repeated abort is harmless"
          ],
          "implementationNotes": [
            "Compare session state immediately before provider action."
          ],
          "verification": [
            "Clean abandoned fixture",
            "Race cleanup with completion"
          ],
          "deliverables": [
            "Session cleanup and race case"
          ],
          "rollout": "Disable cleanup if finalization state is uncertain.",
          "skills": [
            "Lifecycle",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "97462569-e274-4c56-a2ad-e878f93cdbab",
          "key": "COBJS-109",
          "title": "Expose multipart upload progress from acknowledged bytes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "recovery",
          "dependsOn": [
            "COBJS-104",
            "COBJS-108"
          ],
          "scenario": "Progress reaches 100 percent before the provider accepts the final part. Count acknowledged bytes separately from verification state.",
          "acceptanceCriteria": [
            "Progress uses accepted parts",
            "Completion remains pending verification",
            "Retransmission does not double-count"
          ],
          "implementationNotes": [
            "Do not treat socket bytes sent as durable storage."
          ],
          "verification": [
            "Upload three parts",
            "Timeout accepted part and reconcile"
          ],
          "deliverables": [
            "Progress projection and cases"
          ],
          "rollout": "Display state-only progress if byte accounting diverges.",
          "skills": [
            "State projection",
            "UX"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "36cd1ef9-3d4c-49e6-9cc2-5f9a57457811",
          "key": "COBJS-110",
          "title": "Export multipart failure diagnostics without signed URLs",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "recovery",
          "dependsOn": [
            "COBJS-109"
          ],
          "scenario": "Support dumps provider receipts containing temporary access URLs. Add an allowlisted diagnostic projection.",
          "acceptanceCriteria": [
            "Includes operation and part counts",
            "Omits signatures and object content",
            "Errors use bounded categories"
          ],
          "implementationNotes": [
            "Signed URLs are bearer capabilities."
          ],
          "verification": [
            "Export failed session",
            "Inject signed URL in provider error"
          ],
          "deliverables": [
            "Diagnostic schema and redaction checks"
          ],
          "rollout": "Disable exports if bearer data appears.",
          "skills": [
            "Logging",
            "Security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "9fa17936-5981-4507-8ee8-cf91ce14aaca",
      "key": "CBLOB",
      "title": "Reference-aware blob retention and deletion",
      "field": "Storage systems",
      "summary": "Manage shared synthetic attachments through references, tombstones and recoverable cleanup.",
      "context": "Fictional archive Moss deduplicates generated attachments across documents within each organization. Use local files and transactional metadata stubs.",
      "stack": [
        "TypeScript",
        "SQLite",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Generate duplicate and unique local byte fixtures.",
        "Create synthetic document references across two organizations."
      ],
      "developerValue": "Practice reclamation races and explicit data-lifecycle guarantees.",
      "companyValue": "Inspect whether storage cleanup avoids broken references and hidden retention.",
      "delivery": "Operate only on a dedicated local fixture directory; no user folders are targeted.",
      "phases": [
        {
          "id": "references",
          "title": "Model blob references",
          "goal": "Separate logical use from physical bytes."
        },
        {
          "id": "deletion",
          "title": "Guard reclamation",
          "goal": "Handle races and failures safely."
        },
        {
          "id": "maintenance",
          "title": "Operate retention",
          "goal": "Bound scanning and verify recovery."
        }
      ],
      "tickets": [
        {
          "id": "35a5e942-c9bf-407a-a42c-175159d478e2",
          "key": "CBLOB-101",
          "title": "Separate attachment display names from blob identities",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "references",
          "dependsOn": [],
          "scenario": "Renaming an attachment currently moves its physical file and breaks another reference. Store display names on references.",
          "acceptanceCriteria": [
            "Rename changes only reference metadata",
            "Blob identity stays stable",
            "Other references keep their names"
          ],
          "implementationNotes": [
            "Content identity cannot depend on a user-facing filename."
          ],
          "verification": [
            "Rename shared attachment",
            "Fail metadata write and inspect file identity"
          ],
          "deliverables": [
            "Reference schema and rename cases"
          ],
          "rollout": "Disable rename if it touches physical blobs.",
          "skills": [
            "Data modeling",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5ff3d4ae-b730-4efa-834c-cd257258ef2d",
          "key": "CBLOB-102",
          "title": "Scope blob deduplication to the owning organization",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "references",
          "dependsOn": [
            "CBLOB-101"
          ],
          "scenario": "Equal bytes across organizations share observable lookup results. Restrict deduplication to the tenant boundary.",
          "acceptanceCriteria": [
            "Same-tenant duplicates reuse safely",
            "Foreign existence is not disclosed",
            "All reference reads include tenant scope"
          ],
          "implementationNotes": [
            "Digest equality is not authorization."
          ],
          "verification": [
            "Deduplicate own fixtures",
            "Probe matching foreign digest"
          ],
          "deliverables": [
            "Scoped blob lookup and denial cases"
          ],
          "rollout": "Disable deduplication if scope isolation fails.",
          "skills": [
            "Tenancy",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6358a006-70f6-488a-b719-e25a6b1d6683",
          "key": "CBLOB-103",
          "title": "Reject references to incomplete synthetic blobs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "references",
          "dependsOn": [
            "CBLOB-101",
            "CBLOB-102"
          ],
          "scenario": "Documents can attach blobs before upload verification ends. Require available status before creating a reference.",
          "acceptanceCriteria": [
            "Available blob can attach",
            "Incomplete blob cannot attach",
            "Denied attachment creates no reference"
          ],
          "implementationNotes": [
            "Status check and reference insertion share a transaction boundary."
          ],
          "verification": [
            "Attach verified fixture",
            "Race verification failure with attach"
          ],
          "deliverables": [
            "Attachment admission and cases"
          ],
          "rollout": "Pause attachments when availability cannot be established.",
          "skills": [
            "State transitions",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "9c919f54-dbc4-484f-b5c9-b8ff89d0ae0a",
          "key": "CBLOB-104",
          "title": "Tombstone unreferenced blobs before physical deletion",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "deletion",
          "dependsOn": [
            "CBLOB-103"
          ],
          "scenario": "Cleanup deletes bytes immediately when count reaches zero, leaving no recoverable decision record. Add a pending-deletion state.",
          "acceptanceCriteria": [
            "Zero references create tombstone",
            "Referenced blobs remain available",
            "Tombstone records eligibility time"
          ],
          "implementationNotes": [
            "Tombstones describe metadata, not proof of physical erasure."
          ],
          "verification": [
            "Remove final reference",
            "Remove one of two references"
          ],
          "deliverables": [
            "Tombstone transition and cases"
          ],
          "rollout": "Pause physical deletion while retaining tombstones.",
          "skills": [
            "Lifecycle",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c008546d-a70a-46cd-80d8-347c79ca4060",
          "key": "CBLOB-105",
          "title": "Prevent a new blob reference racing with reclamation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "deletion",
          "dependsOn": [
            "CBLOB-104"
          ],
          "scenario": "A document attaches a blob while cleanup deletes its file. Coordinate reference admission and deletion eligibility.",
          "acceptanceCriteria": [
            "New reference either cancels eligibility or fails explicitly",
            "Deletion cannot remove newly referenced bytes",
            "Retried admission is safe"
          ],
          "implementationNotes": [
            "Choose and document one atomic state protocol."
          ],
          "verification": [
            "Attach before claim",
            "Race attachment against deletion claim"
          ],
          "deliverables": [
            "Reclamation protocol and interleaving tests"
          ],
          "rollout": "Disable reclamation if the mutual-exclusion invariant fails.",
          "skills": [
            "Concurrency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f5bb3d7e-28d8-4601-94b4-5fd443b6cddf",
          "key": "CBLOB-106",
          "title": "Record physical blob deletion failures without claiming completion",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "deletion",
          "dependsOn": [
            "CBLOB-104",
            "CBLOB-105"
          ],
          "scenario": "Permission errors are swallowed and metadata says Deleted while bytes remain. Persist retryable failure state.",
          "acceptanceCriteria": [
            "Successful deletion records acknowledgement",
            "Failure remains pending",
            "Already absent file is idempotent success"
          ],
          "implementationNotes": [
            "Do not log attachment contents or paths outside fixture scope."
          ],
          "verification": [
            "Delete fixture",
            "Inject permission failure"
          ],
          "deliverables": [
            "Deletion result handling and cases"
          ],
          "rollout": "Pause retries on repeated provider faults.",
          "skills": [
            "Error handling",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "290b4e6e-c948-4fcc-8e78-a9f576ef4d24",
          "key": "CBLOB-107",
          "title": "Reconcile blob metadata after a crash during deletion",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "deletion",
          "dependsOn": [
            "CBLOB-106"
          ],
          "scenario": "A process dies after file removal but before metadata commit. Recovery must distinguish absent bytes from an untouched blob.",
          "acceptanceCriteria": [
            "Missing claimed blob completes metadata",
            "Existing claimed blob retries safely",
            "Unclaimed blob is never deleted"
          ],
          "implementationNotes": [
            "Recovery requires durable deletion claim identity."
          ],
          "verification": [
            "Crash after file removal",
            "Restart with stale unrelated claim"
          ],
          "deliverables": [
            "Deletion reconciliation and restart cases"
          ],
          "rollout": "Stop automatic recovery if claims cannot be verified.",
          "skills": [
            "Crash consistency",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ae654a4f-4354-495d-b44a-0103923a22d6",
          "key": "CBLOB-108",
          "title": "Bound blob reclamation scans by eligibility cursor",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "maintenance",
          "dependsOn": [
            "CBLOB-107"
          ],
          "scenario": "The sweeper repeatedly scans the full blob table. Add indexed bounded batches without skipping concurrent tombstones.",
          "acceptanceCriteria": [
            "Batch size is capped",
            "Cursor order is stable",
            "New eligible rows appear on a subsequent pass"
          ],
          "implementationNotes": [
            "Document cursor reset at end of pass."
          ],
          "verification": [
            "Sweep multiple pages",
            "Insert eligible row during scan"
          ],
          "deliverables": [
            "Sweep pagination and concurrency cases"
          ],
          "rollout": "Reduce to explicit small batches while cursor logic is repaired.",
          "skills": [
            "Pagination",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b1d2e445-0bc4-44a7-9f1c-b686ca1b81ab",
          "key": "CBLOB-109",
          "title": "Protect retained document versions from blob cleanup",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "maintenance",
          "dependsOn": [
            "CBLOB-105",
            "CBLOB-108"
          ],
          "scenario": "Cleanup counts only current document references and breaks retained versions. Include every retained reference authority.",
          "acceptanceCriteria": [
            "Retained versions preserve blobs",
            "Expired versions release references",
            "Cross-tenant records cannot affect counts"
          ],
          "implementationNotes": [
            "Retention policy is a fixture contract, not a legal claim."
          ],
          "verification": [
            "Retain old version",
            "Expire it and inspect eligibility"
          ],
          "deliverables": [
            "Version-aware reference accounting"
          ],
          "rollout": "Pause cleanup until all reference sources reconcile.",
          "skills": [
            "Retention",
            "Data modeling"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "b299c6a9-7dbd-4de1-b8e5-336cdc50f6f0",
          "key": "CBLOB-110",
          "title": "Produce a blob-reclamation report that distinguishes planned and removed bytes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "maintenance",
          "dependsOn": [
            "CBLOB-106",
            "CBLOB-109"
          ],
          "scenario": "Operators report savings from tombstoned bytes that still exist. Separate eligible, attempted and acknowledged removal totals.",
          "acceptanceCriteria": [
            "Planned bytes are labeled",
            "Failures remain outstanding",
            "Only acknowledged removals count as reclaimed"
          ],
          "implementationNotes": [
            "State measurements are local fixture observations."
          ],
          "verification": [
            "Sweep successful fixture batch",
            "Fail half the deletions"
          ],
          "deliverables": [
            "Reclamation report projection"
          ],
          "rollout": "Hide savings totals if acknowledgements cannot be reconciled.",
          "skills": [
            "Observability",
            "Reporting"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "44b0aa09-eac0-47a8-a450-4c9d42212ceb",
      "key": "CKV",
      "title": "A crash-consistent local key-value store",
      "field": "Storage systems",
      "summary": "Implement bounded log, index and compaction behavior in a dedicated fixture directory.",
      "context": "Fictional desktop cache Pebble needs a small embedded key-value engine. Build against generated keys and bytes using an ordinary filesystem adapter; no production database replacement is implied.",
      "stack": [
        "TypeScript",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create a disposable local fixture directory.",
        "Implement fault injection for partial writes, sync failure and process restart."
      ],
      "developerValue": "Practice storage formats, durability boundaries and corruption handling.",
      "companyValue": "Inspect whether an engineer can state and test persistence guarantees.",
      "delivery": "Each ticket adds one narrow engine behavior; publish measured local limits, not database performance claims.",
      "phases": [
        {
          "id": "records",
          "title": "Specify records",
          "goal": "Define bounded encoding and reads."
        },
        {
          "id": "durability",
          "title": "Recover durable writes",
          "goal": "Handle torn records and atomic updates."
        },
        {
          "id": "compaction",
          "title": "Reclaim old storage",
          "goal": "Compact safely and inspect damage."
        }
      ],
      "tickets": [
        {
          "id": "daf3225e-137d-4bc7-8182-34c352037514",
          "key": "CKV-101",
          "title": "Encode local key-value records with explicit length limits",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "records",
          "dependsOn": [],
          "scenario": "Delimiter-based records fail when values contain newlines. Add a length-prefixed binary record format.",
          "acceptanceCriteria": [
            "Arbitrary bytes round-trip",
            "Key and value limits are enforced",
            "Version is encoded explicitly"
          ],
          "implementationNotes": [
            "Specify byte order in the format note."
          ],
          "verification": [
            "Round-trip binary fixture",
            "Reject oversized declared length"
          ],
          "deliverables": [
            "Encoder decoder and format document"
          ],
          "rollout": "Keep old files read-only until conversion is explicit.",
          "skills": [
            "Binary formats",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a01af955-b426-434f-9acc-a21d44485062",
          "key": "CKV-102",
          "title": "Distinguish missing local keys from empty values",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "records",
          "dependsOn": [
            "CKV-101"
          ],
          "scenario": "Empty buffers are interpreted as Not found. Return explicit presence separate from byte length.",
          "acceptanceCriteria": [
            "Empty stored value is found",
            "Absent key is missing",
            "Deletion yields missing"
          ],
          "implementationNotes": [
            "Avoid truthiness checks on encoded values."
          ],
          "verification": [
            "Read empty value",
            "Read deleted key"
          ],
          "deliverables": [
            "Read result contract and cases"
          ],
          "rollout": "Revert callers to explicit result checking.",
          "skills": [
            "API design",
            "Data contracts"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3d1f87ee-1660-428b-8bd1-fd26efcc5268",
          "key": "CKV-103",
          "title": "Build a local key-value index from validated log records",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "records",
          "dependsOn": [
            "CKV-101",
            "CKV-102"
          ],
          "scenario": "Startup trusts offsets without reading record boundaries. Rebuild the index only from validated records.",
          "acceptanceCriteria": [
            "Latest valid record wins",
            "Offsets stay within file bounds",
            "Invalid record reports its position"
          ],
          "implementationNotes": [
            "Do not allocate from untrusted length fields before bounds checks."
          ],
          "verification": [
            "Rebuild repeated keys",
            "Use record extending past EOF"
          ],
          "deliverables": [
            "Startup index and malformed-file cases"
          ],
          "rollout": "Refuse writes to logs that cannot be validated.",
          "skills": [
            "Indexing",
            "Parsing"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "cbca80da-8644-4ab4-a503-e9e38c163942",
          "key": "CKV-104",
          "title": "Declare local write acknowledgement after the durability barrier",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "durability",
          "dependsOn": [
            "CKV-103"
          ],
          "scenario": "Put returns success before the log flush completes. Define durable acknowledgement using the filesystem adapter.",
          "acceptanceCriteria": [
            "Success follows required sync",
            "Sync failure reports uncertain outcome",
            "Failed acknowledgement is not silently retried as new write"
          ],
          "implementationNotes": [
            "Document the adapter's actual durability assumptions."
          ],
          "verification": [
            "Put with successful sync",
            "Inject sync failure after write"
          ],
          "deliverables": [
            "Acknowledgement contract and fault cases"
          ],
          "rollout": "Switch to read-only if durability barriers fail repeatedly.",
          "skills": [
            "Durability",
            "Filesystem"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ed92f3fc-6774-4f5a-ae3e-ccc151879c25",
          "key": "CKV-105",
          "title": "Recover a torn key-value record at the end of the log",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "durability",
          "dependsOn": [
            "CKV-103",
            "CKV-104"
          ],
          "scenario": "A crash leaves a partial final record and startup refuses every key. Recover the valid prefix conservatively.",
          "acceptanceCriteria": [
            "Valid prefix remains readable",
            "Incomplete tail is identified",
            "Middle corruption fails closed"
          ],
          "implementationNotes": [
            "Tail truncation requires an explicit recovery mode."
          ],
          "verification": [
            "Recover partial final record",
            "Corrupt middle record"
          ],
          "deliverables": [
            "Tail recovery and corruption cases"
          ],
          "rollout": "Preserve original log before applying tail repair.",
          "skills": [
            "Crash recovery",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "98c02751-686e-4111-be42-5942dbc0030b",
          "key": "CKV-106",
          "title": "Represent key deletion as an ordered tombstone",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "durability",
          "dependsOn": [
            "CKV-104",
            "CKV-105"
          ],
          "scenario": "Rebuilding the index resurrects deleted keys because deletion only changed memory. Append durable tombstones.",
          "acceptanceCriteria": [
            "Deleted keys stay missing after restart",
            "Later puts can recreate key",
            "Tombstones obey acknowledgement rules"
          ],
          "implementationNotes": [
            "Keep record ordering authoritative."
          ],
          "verification": [
            "Delete and restart",
            "Fail tombstone sync"
          ],
          "deliverables": [
            "Tombstone format and restart cases"
          ],
          "rollout": "Disable deletion if durable ordering is uncertain.",
          "skills": [
            "Log structure",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "00b72a1b-d035-44b4-b4c0-bcce25ce1856",
          "key": "CKV-107",
          "title": "Reject key-value batches that cannot commit atomically",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "durability",
          "dependsOn": [
            "CKV-104",
            "CKV-106"
          ],
          "scenario": "A multi-key update survives restart with only half its changes. Add one bounded batch commit marker protocol.",
          "acceptanceCriteria": [
            "Complete batch applies all records",
            "Uncommitted batch applies none",
            "Batch size is capped"
          ],
          "implementationNotes": [
            "Do not claim filesystem transaction support that the adapter lacks."
          ],
          "verification": [
            "Restart after committed batch",
            "Crash before commit marker"
          ],
          "deliverables": [
            "Batch protocol and fault schedule"
          ],
          "rollout": "Disable batch writes while preserving single-key operations.",
          "skills": [
            "Atomicity",
            "Storage engines"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ac17014d-7abc-48aa-86ba-12316d934641",
          "key": "CKV-108",
          "title": "Compact the local log without changing visible key values",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "compaction",
          "dependsOn": [
            "CKV-106",
            "CKV-107"
          ],
          "scenario": "Repeated updates grow the log. Write a compacted generation from one consistent logical view.",
          "acceptanceCriteria": [
            "Latest live values survive",
            "Deleted keys stay absent",
            "Compaction output validates before activation"
          ],
          "implementationNotes": [
            "Bound memory by documented fixture limits or streaming plan."
          ],
          "verification": [
            "Compare reads before and after",
            "Inject corrupted output record"
          ],
          "deliverables": [
            "Compaction writer and equivalence cases"
          ],
          "rollout": "Discard unactivated compacted generation on failure.",
          "skills": [
            "Compaction",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "88cbf4e0-5570-489a-ab70-d1e8b50cd685",
          "key": "CKV-109",
          "title": "Activate a compacted key-value generation recoverably",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "compaction",
          "dependsOn": [
            "CKV-108"
          ],
          "scenario": "Crashing during compacted-file replacement leaves no selected log. Add a recoverable generation manifest.",
          "acceptanceCriteria": [
            "One valid generation is selected",
            "Interrupted switch retains fallback",
            "Repeated recovery makes same choice"
          ],
          "implementationNotes": [
            "Keep previous generation until activation is durable."
          ],
          "verification": [
            "Crash at switch boundaries",
            "Remove incomplete new generation"
          ],
          "deliverables": [
            "Generation activation and crash tests"
          ],
          "rollout": "Restore the last validated manifest and retain both files.",
          "skills": [
            "Crash consistency",
            "Manifests"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "101d5111-9ef0-4e1d-b849-50e5fa7f92a8",
          "key": "CKV-110",
          "title": "Inspect local key-value corruption without modifying files",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "compaction",
          "dependsOn": [
            "CKV-105",
            "CKV-109"
          ],
          "scenario": "Support has no way to identify damaged record offsets safely. Add a read-only inspection command.",
          "acceptanceCriteria": [
            "Reports format and valid prefix",
            "Never rewrites bytes",
            "Output omits values by default"
          ],
          "implementationNotes": [
            "Restrict command to an explicitly supplied fixture path."
          ],
          "verification": [
            "Inspect healthy log",
            "Inspect malformed length and checksum"
          ],
          "deliverables": [
            "Inspector and immutable-input checks"
          ],
          "rollout": "Remove repair suggestions if they imply automatic destructive changes.",
          "skills": [
            "Diagnostics",
            "CLI"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "643e4728-d41f-4522-88a6-dde5400d0894",
      "key": "CBACK",
      "title": "Verifiable archive backup and restore",
      "field": "Storage systems",
      "summary": "Build manifest-based local backup, validation and staged restoration.",
      "context": "Fictional archive Alder backs up synthetic document metadata and generated blobs into a dedicated local directory. No real organizational data or cloud accounts are required.",
      "stack": [
        "TypeScript",
        "SQLite",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create synthetic metadata and generated blob fixtures.",
        "Provide isolated source backup and restore directories."
      ],
      "developerValue": "Practice consistent snapshots and recoverable restoration.",
      "companyValue": "Inspect whether backup success can be substantiated by a usable restore.",
      "delivery": "Record local restore evidence; production disaster-recovery qualification remains separate.",
      "phases": [
        {
          "id": "manifest",
          "title": "Describe backup content",
          "goal": "Define scope and integrity."
        },
        {
          "id": "capture",
          "title": "Capture coherently",
          "goal": "Handle interruption and version boundaries."
        },
        {
          "id": "restore",
          "title": "Restore into isolation",
          "goal": "Validate before switching authority."
        }
      ],
      "tickets": [
        {
          "id": "4a9be09c-a900-42a0-babf-e7a2c2afa5a7",
          "key": "CBACK-101",
          "title": "Define archive backup manifests with explicit format versions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "manifest",
          "dependsOn": [],
          "scenario": "Backup folders contain unnamed files with no declared schema. Add a bounded manifest describing required objects.",
          "acceptanceCriteria": [
            "Manifest declares version",
            "Entries have size and digest",
            "Duplicate logical paths fail validation"
          ],
          "implementationNotes": [
            "Treat manifest text as untrusted input."
          ],
          "verification": [
            "Parse valid fixture",
            "Reject duplicate and future-version entries"
          ],
          "deliverables": [
            "Manifest schema and parser"
          ],
          "rollout": "Keep unknown backup versions read-only.",
          "skills": [
            "Serialization",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b8a05152-889a-405a-aa00-81b358ced380",
          "key": "CBACK-102",
          "title": "Exclude temporary archive uploads from backup inventories",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "manifest",
          "dependsOn": [
            "CBACK-101"
          ],
          "scenario": "A backup includes partial uploads and later calls them missing documents. Inventory only committed archive references.",
          "acceptanceCriteria": [
            "Committed blobs are listed",
            "Temporary uploads are excluded",
            "Excluded counts are reported separately"
          ],
          "implementationNotes": [
            "Inventory must derive from authoritative metadata state."
          ],
          "verification": [
            "Inventory committed fixture",
            "Add incomplete upload"
          ],
          "deliverables": [
            "Backup inventory projection"
          ],
          "rollout": "Pause backup capture if committed scope is uncertain.",
          "skills": [
            "Data modeling",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c7409114-ef65-4ed5-8b57-e5999bd724fe",
          "key": "CBACK-103",
          "title": "Verify archive backup bytes against manifest digests",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "manifest",
          "dependsOn": [
            "CBACK-101",
            "CBACK-102"
          ],
          "scenario": "Copy completion alone marks backup success. Stream verification of every required object before success.",
          "acceptanceCriteria": [
            "Digest and size both match",
            "Missing object fails verification",
            "Failure identifies logical object safely"
          ],
          "implementationNotes": [
            "Do not buffer entire backups in memory."
          ],
          "verification": [
            "Verify generated fixture",
            "Flip one copied byte"
          ],
          "deliverables": [
            "Streaming verifier and corruption cases"
          ],
          "rollout": "Mark affected backups unusable until reverified.",
          "skills": [
            "Hashing",
            "Streaming"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "56d3d468-c133-4d1b-82bf-8a70a06a4dc5",
          "key": "CBACK-104",
          "title": "Capture archive metadata and blob references at one snapshot boundary",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "capture",
          "dependsOn": [
            "CBACK-102",
            "CBACK-103"
          ],
          "scenario": "A document changes while backup runs and the manifest references an uncopied blob. Define one consistent capture boundary.",
          "acceptanceCriteria": [
            "Manifest reflects one metadata snapshot",
            "Required blobs remain pinned during capture",
            "Concurrent new versions belong to later backups"
          ],
          "implementationNotes": [
            "Specify adapter transaction and pin lifetime."
          ],
          "verification": [
            "Update after snapshot",
            "Delete reference during capture"
          ],
          "deliverables": [
            "Snapshot protocol and race cases"
          ],
          "rollout": "Pause pruning until capture pins are reliable.",
          "skills": [
            "Consistency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e9339028-0541-478e-a477-54faf776a353",
          "key": "CBACK-105",
          "title": "Resume archive backup copying without accepting stale partial files",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "capture",
          "dependsOn": [
            "CBACK-103",
            "CBACK-104"
          ],
          "scenario": "Restarted backup trusts an existing filename although the earlier copy was interrupted. Revalidate reusable files.",
          "acceptanceCriteria": [
            "Matching verified files may be reused",
            "Partial files are recopied",
            "Resume retains original snapshot identity"
          ],
          "implementationNotes": [
            "Reuse decisions require digest agreement."
          ],
          "verification": [
            "Resume with valid copied file",
            "Resume with truncated file"
          ],
          "deliverables": [
            "Copy-resume coordinator and cases"
          ],
          "rollout": "Start a new isolated backup if snapshot identity is lost.",
          "skills": [
            "Recovery",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e01fc9ca-4643-4971-80cd-4b038d9d5b6c",
          "key": "CBACK-106",
          "title": "Finalize archive backups with an explicit complete marker",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "capture",
          "dependsOn": [
            "CBACK-103",
            "CBACK-105"
          ],
          "scenario": "Operators select directories still being copied. Publish a durable completion marker only after required verification.",
          "acceptanceCriteria": [
            "Incomplete directories are not selectable",
            "Marker binds manifest digest",
            "Failure cannot leave valid-looking completion"
          ],
          "implementationNotes": [
            "Marker creation follows verification acknowledgement."
          ],
          "verification": [
            "Finish valid backup",
            "Crash before marker creation"
          ],
          "deliverables": [
            "Finalization protocol and tests"
          ],
          "rollout": "Withdraw completion marker if later validation fails.",
          "skills": [
            "Atomic publication",
            "Durability"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "db04f45e-a8b4-4b97-aea6-cb225bc1683c",
          "key": "CBACK-107",
          "title": "Refuse archive restore paths outside the selected target directory",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "capture",
          "dependsOn": [
            "CBACK-101",
            "CBACK-106"
          ],
          "scenario": "A crafted backup path can escape the restore root. Validate resolved destinations before creating files.",
          "acceptanceCriteria": [
            "Traversal and absolute paths fail",
            "Symlink escape is rejected by adapter policy",
            "Valid files remain inside target"
          ],
          "implementationNotes": [
            "Use a dedicated empty fixture directory."
          ],
          "verification": [
            "Restore valid nested object",
            "Attempt parent traversal or symlink escape"
          ],
          "deliverables": [
            "Restore-path boundary and cases"
          ],
          "rollout": "Abort restore before writes if containment cannot be established.",
          "skills": [
            "Filesystem",
            "Security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a7cca6f0-fe05-4949-9ced-3425f418493d",
          "key": "CBACK-108",
          "title": "Restore archive backups into an isolated staging generation",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "restore",
          "dependsOn": [
            "CBACK-106",
            "CBACK-107"
          ],
          "scenario": "Direct restoration overwrites the active archive before integrity checks finish. Build and validate a separate generation.",
          "acceptanceCriteria": [
            "Active data remains untouched",
            "Staging contains all required records",
            "Failed validation leaves active generation selected"
          ],
          "implementationNotes": [
            "No recursive operations on unspecified user directories."
          ],
          "verification": [
            "Restore valid fixture",
            "Fail halfway through copying"
          ],
          "deliverables": [
            "Staged restore and isolation checks"
          ],
          "rollout": "Discard only the verified staging directory on failure.",
          "skills": [
            "Recovery",
            "Isolation"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "08d2d30b-586d-44fb-b14a-1615075049be",
          "key": "CBACK-109",
          "title": "Switch restored archive authority with a rollback pointer",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "restore",
          "dependsOn": [
            "CBACK-108"
          ],
          "scenario": "A successful staging restore still needs a safe handoff. Activate one generation while retaining the previous pointer.",
          "acceptanceCriteria": [
            "Switch selects one validated generation",
            "Interrupted activation recovers deterministically",
            "Rollback selects prior intact generation"
          ],
          "implementationNotes": [
            "Document concurrent-reader behavior at the switch."
          ],
          "verification": [
            "Activate restored fixture",
            "Crash during pointer update"
          ],
          "deliverables": [
            "Activation record and recovery tests"
          ],
          "rollout": "Restore previous validated pointer if post-switch checks fail.",
          "skills": [
            "Atomicity",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "01cd4850-6f30-46eb-ab01-bb3ec6c0cf0e",
          "key": "CBACK-110",
          "title": "Prove one archive restore through observable consistency checks",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "restore",
          "dependsOn": [
            "CBACK-109"
          ],
          "scenario": "A backup report says Success without reading restored documents. Add a repeatable restore exercise and recorded checks.",
          "acceptanceCriteria": [
            "Restored references resolve",
            "Document counts match manifest scope",
            "Excluded temporary data stays excluded"
          ],
          "implementationNotes": [
            "Report local fixture results and unresolved assumptions."
          ],
          "verification": [
            "Read every small fixture object",
            "Remove one restored blob and detect failure"
          ],
          "deliverables": [
            "Restore exercise and result record"
          ],
          "rollout": "Reclassify the backup as unverified if checks fail.",
          "skills": [
            "Verification",
            "Operations"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "fb8c96f4-a9ca-40d7-889b-29060ac89f1e",
      "key": "CTIER",
      "title": "A local archive cache with explicit integrity and capacity",
      "field": "Storage systems",
      "summary": "Coordinate immutable blob caching, eviction and repair across local storage tiers.",
      "context": "Fictional media archive Ash serves generated byte fixtures through a fast local cache and slower provider stub. Both tiers run locally.",
      "stack": [
        "TypeScript",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create immutable generated blobs with known digests.",
        "Implement controllable cache and origin adapters with read failures."
      ],
      "developerValue": "Practice cache correctness, request coalescing and capacity control.",
      "companyValue": "Inspect whether faster delivery preserves bytes and operating limits.",
      "delivery": "Use dedicated fixture directories and publish measured local observations only.",
      "phases": [
        {
          "id": "reads",
          "title": "Define cache reads",
          "goal": "Keep source authority explicit."
        },
        {
          "id": "capacity",
          "title": "Control cache mutation",
          "goal": "Handle contention and eviction."
        },
        {
          "id": "repair",
          "title": "Repair and observe",
          "goal": "Recover damage without hiding uncertainty."
        }
      ],
      "tickets": [
        {
          "id": "484f9fd8-c8ce-4862-a4f6-654065584e87",
          "key": "CTIER-101",
          "title": "Keep archive cache misses distinct from provider failures",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "reads",
          "dependsOn": [],
          "scenario": "Any cache read error is treated as a miss and hides damaged storage. Define typed outcomes.",
          "acceptanceCriteria": [
            "Missing key is a miss",
            "Permission failure is operational error",
            "Origin reads follow documented fallback policy"
          ],
          "implementationNotes": [
            "Do not swallow arbitrary filesystem exceptions."
          ],
          "verification": [
            "Read absent fixture",
            "Inject permission failure"
          ],
          "deliverables": [
            "Cache result contract"
          ],
          "rollout": "Bypass cache on operational failure while reporting it.",
          "skills": [
            "Error modeling",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "822b4021-ffc3-4c28-90db-4ad05d21248b",
          "key": "CTIER-102",
          "title": "Key archive cache entries by immutable blob identity",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "reads",
          "dependsOn": [
            "CTIER-101"
          ],
          "scenario": "A mutable filename reuses stale cached bytes after replacement. Bind entries to immutable version or digest.",
          "acceptanceCriteria": [
            "Same identity reuses entry",
            "New version uses new key",
            "User labels do not affect identity"
          ],
          "implementationNotes": [
            "Tenant scope remains part of lookup authority."
          ],
          "verification": [
            "Read repeated identity",
            "Replace logical filename with new version"
          ],
          "deliverables": [
            "Cache-key contract and cases"
          ],
          "rollout": "Disable cache reuse if identity is uncertain.",
          "skills": [
            "Caching",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6a40ef22-f586-4bb4-a1e0-160fd48e1ae1",
          "key": "CTIER-103",
          "title": "Verify archive cache fills before promoting temporary bytes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "reads",
          "dependsOn": [
            "CTIER-102"
          ],
          "scenario": "Interrupted origin reads leave files that future requests treat as complete. Stage and verify each fill.",
          "acceptanceCriteria": [
            "Fill checks declared digest",
            "Unverified files stay invisible",
            "Failed fill removes or quarantines its temporary file"
          ],
          "implementationNotes": [
            "Promotion must not expose partial bytes."
          ],
          "verification": [
            "Fill valid fixture",
            "Truncate origin stream"
          ],
          "deliverables": [
            "Verified fill and failure cases"
          ],
          "rollout": "Disable cache writes while serving origin directly.",
          "skills": [
            "Integrity",
            "Atomic publication"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "acc82c94-ef80-4d65-882d-39cb3e4ed5c2",
          "key": "CTIER-104",
          "title": "Coalesce concurrent archive cache fills for one blob",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "capacity",
          "dependsOn": [
            "CTIER-103"
          ],
          "scenario": "Ten simultaneous misses download the same object ten times. Share one fill without joining unrelated keys.",
          "acceptanceCriteria": [
            "Same identity shares fill",
            "Different identities remain independent",
            "Failure releases waiters consistently"
          ],
          "implementationNotes": [
            "Bound the in-flight map and clear settled entries."
          ],
          "verification": [
            "Issue concurrent same-key reads",
            "Fail shared fill then retry"
          ],
          "deliverables": [
            "Fill coordinator and concurrency cases"
          ],
          "rollout": "Disable coalescing if waiters cannot be released.",
          "skills": [
            "Concurrency",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "25f7a74e-d927-467f-8730-c280a02c2d5e",
          "key": "CTIER-105",
          "title": "Enforce archive cache capacity before admitting a fill",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "capacity",
          "dependsOn": [
            "CTIER-103",
            "CTIER-104"
          ],
          "scenario": "Parallel fills exceed the configured cache budget because each sees free space. Reserve capacity atomically.",
          "acceptanceCriteria": [
            "Active reservations count toward limit",
            "Failed fills release reservation",
            "Oversized objects bypass with explanation"
          ],
          "implementationNotes": [
            "Include temporary bytes in capacity accounting."
          ],
          "verification": [
            "Admit fitting concurrent fills",
            "Attempt object larger than budget"
          ],
          "deliverables": [
            "Admission reservations and cases"
          ],
          "rollout": "Stop cache admission until accounting reconciles.",
          "skills": [
            "Capacity planning",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "080a4a24-fbf9-4d93-99fc-92f0f01dd73b",
          "key": "CTIER-106",
          "title": "Avoid evicting archive blobs while active readers hold them",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "capacity",
          "dependsOn": [
            "CTIER-105"
          ],
          "scenario": "Eviction deletes a file while a streaming reader still needs it. Define reader leases and reclamation behavior.",
          "acceptanceCriteria": [
            "Active readers finish or fail explicitly by contract",
            "New reads cannot acquire deleting entry",
            "Released leases permit eviction"
          ],
          "implementationNotes": [
            "Specify platform filesystem assumptions."
          ],
          "verification": [
            "Evict idle fixture",
            "Race eviction with active reader"
          ],
          "deliverables": [
            "Reader-lease protocol and race tests"
          ],
          "rollout": "Pause eviction if active-reader safety is uncertain.",
          "skills": [
            "Concurrency",
            "Filesystem"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6b4973e2-fca0-4e37-99b0-9ed0855cd8cd",
          "key": "CTIER-107",
          "title": "Record archive cache recency without writing on every byte read",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "capacity",
          "dependsOn": [
            "CTIER-104",
            "CTIER-106"
          ],
          "scenario": "Streaming a large blob rewrites recency metadata for every chunk. Update recency at a bounded operation boundary.",
          "acceptanceCriteria": [
            "One read causes bounded metadata writes",
            "Eviction order remains documented",
            "Failed read policy is explicit"
          ],
          "implementationNotes": [
            "Use injected clocks for recency tests."
          ],
          "verification": [
            "Stream many chunks",
            "Fail midway and inspect recency"
          ],
          "deliverables": [
            "Recency policy and write-count checks"
          ],
          "rollout": "Use insertion order temporarily if recency updates regress.",
          "skills": [
            "Performance",
            "Metadata"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "cfce3723-5de7-4def-837a-a6301c3e591c",
          "key": "CTIER-108",
          "title": "Detect corrupted archive cache entries before serving them again",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "repair",
          "dependsOn": [
            "CTIER-103",
            "CTIER-106"
          ],
          "scenario": "A local byte flip persists across reads. Add a bounded verification policy and quarantine path.",
          "acceptanceCriteria": [
            "Verification detects mismatch",
            "Corrupt entry is not reused",
            "Origin repair creates a new verified entry"
          ],
          "implementationNotes": [
            "State whether verification occurs per read or scheduled scan."
          ],
          "verification": [
            "Corrupt fixture then read",
            "Fail origin repair"
          ],
          "deliverables": [
            "Integrity policy and repair cases"
          ],
          "rollout": "Bypass cache for quarantined identities.",
          "skills": [
            "Hashing",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4c67aabb-c755-4c7e-a7d3-77163b88d9b2",
          "key": "CTIER-109",
          "title": "Reconcile archive cache metadata after process restart",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "repair",
          "dependsOn": [
            "CTIER-105",
            "CTIER-108"
          ],
          "scenario": "A restart leaves reservations and temporary files consuming phantom capacity. Rebuild accounting from valid state.",
          "acceptanceCriteria": [
            "Abandoned reservations release",
            "Verified entries remain counted",
            "Unknown files are quarantined rather than silently trusted"
          ],
          "implementationNotes": [
            "Cleanup only within the configured fixture root."
          ],
          "verification": [
            "Restart after successful fill",
            "Crash with partial temporary file"
          ],
          "deliverables": [
            "Startup reconciliation and cases"
          ],
          "rollout": "Start cache read-only until reconciliation completes.",
          "skills": [
            "Crash recovery",
            "Accounting"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bbaa1295-64fb-4db8-b442-ab9ee9a47c57",
          "key": "CTIER-110",
          "title": "Report archive cache hit rates with a defined denominator",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "repair",
          "dependsOn": [
            "CTIER-107",
            "CTIER-109"
          ],
          "scenario": "Dashboard hit rate counts every chunk and exaggerates cache usefulness. Count logical read outcomes explicitly.",
          "acceptanceCriteria": [
            "Denominator is logical read attempts",
            "Bypass and errors are separate",
            "No blob content enters events"
          ],
          "implementationNotes": [
            "Report local measurements without generalized performance claims."
          ],
          "verification": [
            "Read hit miss and bypass fixtures",
            "Retry failed read and inspect counts"
          ],
          "deliverables": [
            "Metrics contract and captured examples"
          ],
          "rollout": "Hide hit-rate panel if event accounting changes.",
          "skills": [
            "Observability",
            "Measurement"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "1de4edb2-d5f4-4590-a0b4-a0e7e23e6c54",
      "key": "CPARSE",
      "title": "A configuration-language parser with usable diagnostics",
      "field": "Compiler and language tooling",
      "summary": "Implement a small explicitly specified parser and recoverable source diagnostics.",
      "context": "Fictional build tool Sprig reads a tiny configuration language with identifiers, strings, lists and assignments. Author the grammar and synthetic source corpus locally; parsing never executes source.",
      "stack": [
        "TypeScript",
        "Vitest",
        "Parser fixtures"
      ],
      "prerequisites": [
        "Write the tiny language grammar and generated source examples.",
        "Create fixtures with Unicode, truncated tokens and nested lists."
      ],
      "developerValue": "Practice source positions, grammar boundaries and error recovery.",
      "companyValue": "Inspect whether tooling errors help users correct configuration safely.",
      "delivery": "Keep each change within the declared grammar; runtime evaluation is excluded.",
      "phases": [
        {
          "id": "lexing",
          "title": "Specify source tokens",
          "goal": "Preserve spans and literal meaning."
        },
        {
          "id": "parsing",
          "title": "Build recoverable syntax",
          "goal": "Handle malformed structure deterministically."
        },
        {
          "id": "tooling",
          "title": "Prepare editor consumers",
          "goal": "Keep diagnostics and printing stable."
        }
      ],
      "tickets": [
        {
          "id": "a473a110-9b11-41f6-9963-9dbfb49e44b4",
          "key": "CPARSE-101",
          "title": "Track configuration token spans across mixed newline styles",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "lexing",
          "dependsOn": [],
          "scenario": "Windows configuration files report errors one line late. Define offsets and line mapping for LF and CRLF.",
          "acceptanceCriteria": [
            "Spans cover exact token bytes or declared code units",
            "CRLF counts as one line break",
            "EOF has a valid location"
          ],
          "implementationNotes": [
            "State the offset unit explicitly."
          ],
          "verification": [
            "Tokenize mixed newline fixture",
            "Locate error at EOF"
          ],
          "deliverables": [
            "Span mapper and boundary cases"
          ],
          "rollout": "Fall back to offsets if line mapping is unreliable.",
          "skills": [
            "Lexing",
            "Source maps"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "6585625f-bce1-4c53-8026-640cdb4ec9be",
          "key": "CPARSE-102",
          "title": "Reject unterminated configuration strings with one useful diagnostic",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "lexing",
          "dependsOn": [
            "CPARSE-101"
          ],
          "scenario": "A missing quote produces dozens of bogus tokens. Add a bounded string error and recovery boundary.",
          "acceptanceCriteria": [
            "Diagnostic identifies opening quote",
            "Lexer makes forward progress",
            "Later valid line can tokenize"
          ],
          "implementationNotes": [
            "Do not guess a closing quote silently."
          ],
          "verification": [
            "Tokenize valid escaped string",
            "Tokenize missing final quote"
          ],
          "deliverables": [
            "String lexer and error cases"
          ],
          "rollout": "Stop at first string error if recovery becomes ambiguous.",
          "skills": [
            "Lexing",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "7aecab38-d395-4bb6-8bf3-fe637b527819",
          "key": "CPARSE-103",
          "title": "Preserve configuration string escape meaning",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "lexing",
          "dependsOn": [
            "CPARSE-102"
          ],
          "scenario": "Backslashes disappear inconsistently between parsed values and printed output. Define recognized escapes and reject unknown ones.",
          "acceptanceCriteria": [
            "Supported escapes decode exactly",
            "Unknown escape reports its span",
            "Decoded values retain nonescaped Unicode"
          ],
          "implementationNotes": [
            "Keep raw span separate from decoded value."
          ],
          "verification": [
            "Decode quote and backslash fixtures",
            "Reject unknown escape"
          ],
          "deliverables": [
            "Escape decoder and round-trip cases"
          ],
          "rollout": "Reject affected literals until decoding is corrected.",
          "skills": [
            "Parsing",
            "Unicode"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "dff169af-864e-4e94-9d54-7b1afe87845c",
          "key": "CPARSE-104",
          "title": "Parse configuration lists without unbounded recursion",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "parsing",
          "dependsOn": [
            "CPARSE-101",
            "CPARSE-103"
          ],
          "scenario": "Deeply nested synthetic lists exhaust the call stack. Enforce a documented nesting limit.",
          "acceptanceCriteria": [
            "Valid nesting parses",
            "Limit breach gives structured diagnostic",
            "Parser consumes bounded work after failure"
          ],
          "implementationNotes": [
            "Do not increase runtime stack limits as the fix."
          ],
          "verification": [
            "Parse at supported depth",
            "Exceed depth limit"
          ],
          "deliverables": [
            "List parser and depth cases"
          ],
          "rollout": "Lower accepted nesting cap if resource behavior is uncertain.",
          "skills": [
            "Parsing",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e1500425-d6e9-409e-853c-17ede27f7d6c",
          "key": "CPARSE-105",
          "title": "Recover configuration assignments at a documented synchronization point",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "parsing",
          "dependsOn": [
            "CPARSE-104"
          ],
          "scenario": "One missing equals sign hides all later keys. Resume at a safe assignment boundary.",
          "acceptanceCriteria": [
            "Error names expected token",
            "Later valid assignments appear",
            "Recovery never loops at same offset"
          ],
          "implementationNotes": [
            "Specify which tokens terminate recovery."
          ],
          "verification": [
            "Parse malformed then valid assignment",
            "Use repeated unexpected delimiters"
          ],
          "deliverables": [
            "Recovery strategy and progress tests"
          ],
          "rollout": "Use fail-fast parsing if recovery corrupts structure.",
          "skills": [
            "Error recovery",
            "Parser design"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "52d40738-f626-41a9-9cf0-c7ac630a2faa",
          "key": "CPARSE-106",
          "title": "Detect duplicate configuration keys with both source locations",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "parsing",
          "dependsOn": [
            "CPARSE-105"
          ],
          "scenario": "Repeated keys silently overwrite earlier values. Report the later assignment with a related earlier location.",
          "acceptanceCriteria": [
            "Duplicate is explicit",
            "Both spans are available",
            "Distinct nested scopes remain independent"
          ],
          "implementationNotes": [
            "Do not normalize identifiers beyond the grammar contract."
          ],
          "verification": [
            "Detect duplicate in one scope",
            "Use same key in separate scopes"
          ],
          "deliverables": [
            "Duplicate-key pass and cases"
          ],
          "rollout": "Reject duplicate-bearing files if diagnostics cannot disambiguate them.",
          "skills": [
            "Static analysis",
            "Scopes"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "4e9b944e-acd0-406f-a6f4-e5dbf8306ef7",
          "key": "CPARSE-107",
          "title": "Preserve configuration comments through syntax-tree editing",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "parsing",
          "dependsOn": [
            "CPARSE-105",
            "CPARSE-106"
          ],
          "scenario": "A key-renaming tool deletes nearby comments because the parser discards trivia. Retain comment attachment with explicit rules.",
          "acceptanceCriteria": [
            "Unchanged comments survive print",
            "Ambiguous attachment is documented",
            "Malformed comments retain source spans"
          ],
          "implementationNotes": [
            "This ticket covers one rename transform only."
          ],
          "verification": [
            "Rename commented key",
            "Rename near malformed trailing comment"
          ],
          "deliverables": [
            "Trivia representation and rename round-trip"
          ],
          "rollout": "Disable rename when comment attachment is uncertain.",
          "skills": [
            "Syntax trees",
            "Tooling"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 80
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ed13ee42-405a-4b8b-ba34-bde6581547e6",
          "key": "CPARSE-108",
          "title": "Print configuration trees with stable parse equivalence",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "tooling",
          "dependsOn": [
            "CPARSE-103",
            "CPARSE-107"
          ],
          "scenario": "Formatting can change string values and list meaning. Add a deterministic printer for the supported syntax.",
          "acceptanceCriteria": [
            "Parse-print-parse preserves semantic tree",
            "Formatting is idempotent",
            "Unsupported nodes fail explicitly"
          ],
          "implementationNotes": [
            "Do not claim preservation of arbitrary source formatting."
          ],
          "verification": [
            "Round-trip all grammar fixtures",
            "Reject unsupported synthetic node"
          ],
          "deliverables": [
            "Printer and equivalence cases"
          ],
          "rollout": "Keep original source when printer cannot represent the tree.",
          "skills": [
            "Pretty printing",
            "Testing"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3a9277ed-ef73-4b94-93aa-ed8dcf0c2c96",
          "key": "CPARSE-109",
          "title": "Bound configuration diagnostic counts for hostile input",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "tooling",
          "dependsOn": [
            "CPARSE-105",
            "CPARSE-108"
          ],
          "scenario": "A large malformed file emits thousands of repeated messages and stalls the editor. Cap diagnostics and include truncation status.",
          "acceptanceCriteria": [
            "Count is bounded",
            "Earliest useful errors remain",
            "Suppressed count is disclosed"
          ],
          "implementationNotes": [
            "Parsing must still terminate within documented input limits."
          ],
          "verification": [
            "Parse ordinary invalid file",
            "Use dense malformed fixture"
          ],
          "deliverables": [
            "Diagnostic budget and stress fixture"
          ],
          "rollout": "Stop parsing at budget exhaustion if recovery remains costly.",
          "skills": [
            "Resource limits",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "32d12811-9e4e-40a9-87c0-74a91d055492",
          "key": "CPARSE-110",
          "title": "Publish a configuration parser compatibility corpus",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "tooling",
          "dependsOn": [
            "CPARSE-108",
            "CPARSE-109"
          ],
          "scenario": "Downstream tools cannot tell whether parser changes altered accepted syntax. Add a versioned local corpus and expected public diagnostics.",
          "acceptanceCriteria": [
            "Corpus covers grammar productions",
            "Invalid cases specify diagnostic categories",
            "No hidden evaluator answers are included"
          ],
          "implementationNotes": [
            "These are public engineering regressions, not grading material."
          ],
          "verification": [
            "Run corpus on current parser",
            "Introduce a deliberate local grammar regression and observe failure"
          ],
          "deliverables": [
            "Corpus manifest and execution record"
          ],
          "rollout": "Revert syntax changes that break declared compatibility unintentionally.",
          "skills": [
            "Compatibility",
            "Regression testing"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "d50423a2-7db9-42a2-aae5-55e8c83682ad",
      "key": "CTYPE",
      "title": "A small expression type checker with explainable errors",
      "field": "Compiler and language tooling",
      "summary": "Type-check a bounded expression language without evaluating submitted expressions.",
      "context": "Fictional rules editor Willow supports numbers, strings, booleans, records and functions in a deliberately small language. Define syntax and type rules locally; no arbitrary code execution is needed.",
      "stack": [
        "TypeScript",
        "Vitest",
        "Typed AST fixtures"
      ],
      "prerequisites": [
        "Create synthetic AST fixtures and a written type-rule table.",
        "Define source spans and structured diagnostic output."
      ],
      "developerValue": "Practice type environments, unification and explainable rejection.",
      "companyValue": "Inspect whether developer tooling catches mistakes without hiding uncertainty.",
      "delivery": "Limit scope to the declared type system; general language compatibility is not claimed.",
      "phases": [
        {
          "id": "rules",
          "title": "Establish type rules",
          "goal": "Handle literals and lexical scope."
        },
        {
          "id": "inference",
          "title": "Resolve expression types",
          "goal": "Explain composition failures."
        },
        {
          "id": "stability",
          "title": "Keep checking predictable",
          "goal": "Bound work and stabilize diagnostics."
        }
      ],
      "tickets": [
        {
          "id": "1ed460c9-579f-466a-9a61-0fedf63492c6",
          "key": "CTYPE-101",
          "title": "Assign explicit types to rules-editor literals",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "rules",
          "dependsOn": [],
          "scenario": "The prototype infers booleans from string truthiness. Type literals from AST node kinds only.",
          "acceptanceCriteria": [
            "Number string and boolean types differ",
            "Empty string stays string",
            "Unknown literal kind fails explicitly"
          ],
          "implementationNotes": [
            "Do not evaluate literal source text."
          ],
          "verification": [
            "Check each supported literal",
            "Reject unsupported node kind"
          ],
          "deliverables": [
            "Literal checker and cases"
          ],
          "rollout": "Reject unknown nodes while supported literals remain available.",
          "skills": [
            "Type systems",
            "AST"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "f8e9ba70-b675-448b-a83b-3abc1c0b564f",
          "key": "CTYPE-102",
          "title": "Resolve expression identifiers through lexical scope",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "rules",
          "dependsOn": [
            "CTYPE-101"
          ],
          "scenario": "Inner bindings overwrite the global environment and leak into sibling expressions. Use scoped environments.",
          "acceptanceCriteria": [
            "Inner shadowing is local",
            "Sibling scope remains unchanged",
            "Unbound names include source location"
          ],
          "implementationNotes": [
            "Environments must not mutate parent bindings accidentally."
          ],
          "verification": [
            "Check nested shadowing",
            "Use name outside its scope"
          ],
          "deliverables": [
            "Scope resolver and cases"
          ],
          "rollout": "Disable nested bindings if scope isolation fails.",
          "skills": [
            "Scoping",
            "Type checking"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "34ce6bc2-e2b9-4efe-bb3c-ca839ad4c016",
          "key": "CTYPE-103",
          "title": "Explain rules-editor operator operand mismatches",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "rules",
          "dependsOn": [
            "CTYPE-101",
            "CTYPE-102"
          ],
          "scenario": "Invalid addition reports Type error without naming either operand type. Add structured expected and actual types.",
          "acceptanceCriteria": [
            "Valid operands infer result",
            "Mismatch identifies operator span",
            "Diagnostic includes both operand types"
          ],
          "implementationNotes": [
            "Keep wording independent from internal object serialization."
          ],
          "verification": [
            "Add two numeric literals",
            "Add number to unsupported record"
          ],
          "deliverables": [
            "Operator rules and diagnostic cases"
          ],
          "rollout": "Reject ambiguous operators with explicit unsupported message.",
          "skills": [
            "Diagnostics",
            "Type rules"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8da7966d-9134-47d4-a6b1-5fdc5251e93c",
          "key": "CTYPE-104",
          "title": "Check function calls for arity before argument inference",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "inference",
          "dependsOn": [
            "CTYPE-102",
            "CTYPE-103"
          ],
          "scenario": "Calling a two-argument function with one argument crashes inference. Validate arity and check only supplied expressions safely.",
          "acceptanceCriteria": [
            "Correct arity checks all arguments",
            "Wrong arity reports counts",
            "Nested argument errors remain inspectable"
          ],
          "implementationNotes": [
            "Avoid fabricating missing AST nodes."
          ],
          "verification": [
            "Check valid call",
            "Call with too few and too many arguments"
          ],
          "deliverables": [
            "Call checker and arity cases"
          ],
          "rollout": "Disable call inference for malformed ASTs.",
          "skills": [
            "Type checking",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b35388eb-5588-4bf1-93fb-147dda14fd63",
          "key": "CTYPE-105",
          "title": "Unify rules-editor type variables with an occurs check",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "inference",
          "dependsOn": [
            "CTYPE-104"
          ],
          "scenario": "A recursive synthetic constraint produces an infinite inferred type. Reject self-containing substitutions.",
          "acceptanceCriteria": [
            "Acyclic constraints unify",
            "Recursive substitution fails with reason",
            "Failure does not corrupt remaining environment"
          ],
          "implementationNotes": [
            "Bound this ticket to monomorphic variable unification."
          ],
          "verification": [
            "Unify variable with number",
            "Attempt variable equal to function containing itself"
          ],
          "deliverables": [
            "Unifier and occurs-check cases"
          ],
          "rollout": "Disable variable inference if substitution integrity fails.",
          "skills": [
            "Unification",
            "Algorithms"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "6f28bdd8-7ead-43d7-8d19-98e7d9fb1159",
          "key": "CTYPE-106",
          "title": "Report missing rules-editor record fields without losing known fields",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "inference",
          "dependsOn": [
            "CTYPE-103",
            "CTYPE-105"
          ],
          "scenario": "Reading an absent field turns the whole record into unknown and suppresses later valid diagnostics. Preserve field-level information.",
          "acceptanceCriteria": [
            "Existing field returns declared type",
            "Missing field names available keys within a cap",
            "Later checks retain known types"
          ],
          "implementationNotes": [
            "Do not expose arbitrary source values in diagnostics."
          ],
          "verification": [
            "Access known field",
            "Access absent field then known field"
          ],
          "deliverables": [
            "Record-access rule and recovery cases"
          ],
          "rollout": "Reject absent-field expression only while preserving surrounding scope.",
          "skills": [
            "Type systems",
            "Error recovery"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "10f9529a-4608-474e-ae6f-ebbc05d16e19",
          "key": "CTYPE-107",
          "title": "Merge rules-editor branch types through explicit compatibility rules",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "inference",
          "dependsOn": [
            "CTYPE-105",
            "CTYPE-106"
          ],
          "scenario": "Conditional branches return incompatible values but the checker chooses the first branch type. Define their common result rule.",
          "acceptanceCriteria": [
            "Compatible branches infer documented type",
            "Incompatible branches report both spans",
            "Condition must be boolean"
          ],
          "implementationNotes": [
            "Do not introduce implicit coercion without a declared rule."
          ],
          "verification": [
            "Check matching branches",
            "Check number versus record branches"
          ],
          "deliverables": [
            "Conditional rule and compatibility cases"
          ],
          "rollout": "Reject mixed branches until the rule is stable.",
          "skills": [
            "Type inference",
            "Control flow"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "b91ba8bf-6445-452f-a499-c24ae8a3a001",
          "key": "CTYPE-108",
          "title": "Make rules-editor diagnostics deterministic across map insertion order",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "stability",
          "dependsOn": [
            "CTYPE-106",
            "CTYPE-107"
          ],
          "scenario": "Equivalent AST construction order changes diagnostic output and noisy snapshots. Sort by source and stable category.",
          "acceptanceCriteria": [
            "Equivalent inputs yield same order",
            "Related locations stay attached",
            "Equal-span tie-breaking is documented"
          ],
          "implementationNotes": [
            "Determinism must not remove distinct failures."
          ],
          "verification": [
            "Reorder environment construction",
            "Create two same-span categories"
          ],
          "deliverables": [
            "Diagnostic ordering and cases"
          ],
          "rollout": "Preserve stable source traversal if sorting loses relationships.",
          "skills": [
            "Determinism",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8963cb6c-1945-444e-a308-210ef64c9faa",
          "key": "CTYPE-109",
          "title": "Cancel obsolete rules-editor checks without publishing stale results",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "stability",
          "dependsOn": [
            "CTYPE-107",
            "CTYPE-108"
          ],
          "scenario": "Editor edits finish out of order and older type errors replace current diagnostics. Scope checking to document version.",
          "acceptanceCriteria": [
            "Only current version publishes",
            "Cancellation releases resources",
            "Late completion cannot overwrite"
          ],
          "implementationNotes": [
            "Include document identity as well as version."
          ],
          "verification": [
            "Complete current check",
            "Resolve old check after replacement"
          ],
          "deliverables": [
            "Versioned checking coordinator"
          ],
          "rollout": "Run serial checks if publication ownership fails.",
          "skills": [
            "Concurrency",
            "Language tooling"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 80
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "85101b60-aeb7-447d-a468-5b67acf76cd7",
          "key": "CTYPE-110",
          "title": "Bound rules-editor inference work with explicit incomplete status",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 210,
          "phaseId": "stability",
          "dependsOn": [
            "CTYPE-105",
            "CTYPE-109"
          ],
          "scenario": "Adversarial nested constraints consume excessive work. Add operation and depth budgets with honest termination status.",
          "acceptanceCriteria": [
            "Supported fixtures complete",
            "Budget exhaustion is explicit",
            "Incomplete checks cannot claim type safety"
          ],
          "implementationNotes": [
            "Use deterministic counters rather than wall time alone."
          ],
          "verification": [
            "Check normal corpus",
            "Exceed constraint budget"
          ],
          "deliverables": [
            "Inference budget and stress cases"
          ],
          "rollout": "Lower limits and mark affected files incomplete until improved.",
          "skills": [
            "Resource limits",
            "Static analysis"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "7f9c9b7a-6c9b-4e03-baba-9fc0db864ade",
      "key": "CLSP",
      "title": "A focused language server for configuration editing",
      "field": "Compiler and language tooling",
      "summary": "Add document versions, diagnostics, completion and safe edits to a local protocol server.",
      "context": "Fictional config editor Hazel speaks a bounded subset of the Language Server Protocol through a local transport adapter. Use a tiny declared configuration grammar and synthetic documents.",
      "stack": [
        "TypeScript",
        "JSON-RPC",
        "Local protocol adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Define the supported protocol subset and configuration grammar.",
        "Create synthetic open/change/close messages and workspace fixtures."
      ],
      "developerValue": "Practice protocol ordering and document-safe editing.",
      "companyValue": "Inspect whether editor assistance preserves current user text and file boundaries.",
      "delivery": "Test through local protocol messages; editor marketplace publishing is excluded.",
      "phases": [
        {
          "id": "documents",
          "title": "Own document state",
          "goal": "Validate lifecycle and positions."
        },
        {
          "id": "features",
          "title": "Provide scoped assistance",
          "goal": "Return current diagnostics and bounded edits."
        },
        {
          "id": "recovery",
          "title": "Handle client interruption",
          "goal": "Cancel stale work and recover protocol errors."
        }
      ],
      "tickets": [
        {
          "id": "52d0c625-6fa3-433e-b09b-1982b1bd8f4c",
          "key": "CLSP-101",
          "title": "Reject configuration edits for unopened language-server documents",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "documents",
          "dependsOn": [],
          "scenario": "A change notification for an unknown URI crashes the document map. Validate document lifecycle.",
          "acceptanceCriteria": [
            "Open establishes document state",
            "Unknown change is handled explicitly",
            "Close releases state"
          ],
          "implementationNotes": [
            "Follow the declared protocol subset's error behavior."
          ],
          "verification": [
            "Open then change fixture",
            "Change unopened document"
          ],
          "deliverables": [
            "Document lifecycle handler and cases"
          ],
          "rollout": "Ignore unsupported lifecycle notifications with bounded diagnostics.",
          "skills": [
            "Protocols",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e6c4bf78-25c2-4f65-a227-d86953e93623",
          "key": "CLSP-102",
          "title": "Convert language-server positions using a declared encoding",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "documents",
          "dependsOn": [
            "CLSP-101"
          ],
          "scenario": "Emoji before an error shifts the underline. Add position conversion matching the negotiated encoding.",
          "acceptanceCriteria": [
            "ASCII positions map correctly",
            "Supplementary characters map correctly",
            "Out-of-range positions are rejected"
          ],
          "implementationNotes": [
            "Do not assume byte offsets equal editor positions."
          ],
          "verification": [
            "Edit after emoji",
            "Request position beyond line end"
          ],
          "deliverables": [
            "Position codec and Unicode cases"
          ],
          "rollout": "Advertise only the verified encoding until others are implemented.",
          "skills": [
            "Unicode",
            "Source positions"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "71d68d80-78db-472a-aa51-fb550b761901",
          "key": "CLSP-103",
          "title": "Apply configuration document edits in the supplied version order",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "documents",
          "dependsOn": [
            "CLSP-101",
            "CLSP-102"
          ],
          "scenario": "Delayed changes replace newer document content. Track monotonic document versions and ordered edits.",
          "acceptanceCriteria": [
            "New valid version applies",
            "Old version cannot overwrite",
            "Invalid range leaves prior snapshot intact"
          ],
          "implementationNotes": [
            "Apply one notification atomically to a cloned snapshot."
          ],
          "verification": [
            "Apply ordered incremental edits",
            "Send stale version and invalid range"
          ],
          "deliverables": [
            "Versioned document store"
          ],
          "rollout": "Request full resynchronization after rejected inconsistent edits.",
          "skills": [
            "Concurrency",
            "Document models"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "7cf186c3-8884-4914-8191-8758916f0066",
          "key": "CLSP-104",
          "title": "Publish configuration diagnostics for the checked document version",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "features",
          "dependsOn": [
            "CLSP-103"
          ],
          "scenario": "Parser results are published after users type more text. Bind diagnostics to the source snapshot checked.",
          "acceptanceCriteria": [
            "Current results publish",
            "Superseded results drop",
            "Closed documents clear diagnostics"
          ],
          "implementationNotes": [
            "Snapshot identity includes URI and version."
          ],
          "verification": [
            "Check unchanged document",
            "Close or edit before check completes"
          ],
          "deliverables": [
            "Diagnostic publication guard"
          ],
          "rollout": "Disable background checking and use explicit validation temporarily.",
          "skills": [
            "Async state",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c4bf974a-ae92-43fc-95a6-65a568455e38",
          "key": "CLSP-105",
          "title": "Complete configuration keys only within valid assignment contexts",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "features",
          "dependsOn": [
            "CLSP-102",
            "CLSP-103"
          ],
          "scenario": "Completion suggests keys inside string literals and comments. Restrict suggestions using syntax context.",
          "acceptanceCriteria": [
            "Assignment context gets known keys",
            "String/comment contexts suppress keys",
            "Incomplete assignment remains supported"
          ],
          "implementationNotes": [
            "Use public grammar metadata, not hidden evaluator assets."
          ],
          "verification": [
            "Complete incomplete key",
            "Request completion inside quoted value"
          ],
          "deliverables": [
            "Context completion and cases"
          ],
          "rollout": "Return no suggestions when context cannot be determined.",
          "skills": [
            "Syntax analysis",
            "Completion"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "7a17d29c-35e1-4431-934b-b895f7baaab5",
          "key": "CLSP-106",
          "title": "Return configuration rename edits only for resolved local bindings",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "features",
          "dependsOn": [
            "CLSP-103",
            "CLSP-105"
          ],
          "scenario": "Rename replaces matching text inside comments and unrelated scopes. Resolve the selected symbol before creating edits.",
          "acceptanceCriteria": [
            "Bound references rename",
            "Shadowed symbols stay unchanged",
            "Unresolved selection yields no edit"
          ],
          "implementationNotes": [
            "This ticket supports one document only."
          ],
          "verification": [
            "Rename binding and references",
            "Select comment text or shadowed name"
          ],
          "deliverables": [
            "Symbol rename and isolation cases"
          ],
          "rollout": "Disable rename if symbol resolution is ambiguous.",
          "skills": [
            "Refactoring",
            "Scopes"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "c85dbf2b-d8cf-4e74-85d3-c4343b2fd161",
          "key": "CLSP-107",
          "title": "Attach expected document versions to configuration code actions",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "features",
          "dependsOn": [
            "CLSP-104",
            "CLSP-106"
          ],
          "scenario": "Applying an old quick fix corrupts newer text. Include the snapshot version in the edit contract.",
          "acceptanceCriteria": [
            "Matching version applies",
            "Changed version is rejected or recomputed",
            "Action describes its actual mutation"
          ],
          "implementationNotes": [
            "Do not apply stale offsets optimistically."
          ],
          "verification": [
            "Apply fresh missing-delimiter fix",
            "Edit before applying old action"
          ],
          "deliverables": [
            "Versioned code action and cases"
          ],
          "rollout": "Hide code actions if client cannot enforce edit versions.",
          "skills": [
            "Protocol design",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "d5738bfd-45f9-4d82-ae5c-e4c33e936545",
          "key": "CLSP-108",
          "title": "Cancel language-server requests without leaking pending work",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recovery",
          "dependsOn": [
            "CLSP-104",
            "CLSP-107"
          ],
          "scenario": "Repeated completion cancellation leaves tasks in memory. Add request-scoped cleanup for all terminal paths.",
          "acceptanceCriteria": [
            "Success removes pending entry",
            "Cancellation removes entry",
            "Late result does not emit another response"
          ],
          "implementationNotes": [
            "Request IDs may be reused only per protocol rules."
          ],
          "verification": [
            "Complete request",
            "Cancel then deliver late result"
          ],
          "deliverables": [
            "Request registry and cleanup tests"
          ],
          "rollout": "Limit concurrency if cleanup cannot be guaranteed.",
          "skills": [
            "Cancellation",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "67ce0bdd-9b38-43a3-8cc8-ef48d35255e5",
          "key": "CLSP-109",
          "title": "Handle malformed language-server messages without losing healthy documents",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 150,
          "phaseId": "recovery",
          "dependsOn": [
            "CLSP-101",
            "CLSP-108"
          ],
          "scenario": "A malformed request resets the whole server and loses open buffers. Isolate parsing and protocol failures.",
          "acceptanceCriteria": [
            "Invalid message gets bounded error",
            "Healthy documents remain intact",
            "Transport stays usable when framing permits"
          ],
          "implementationNotes": [
            "Never log full document contents on parse failure."
          ],
          "verification": [
            "Send valid request after malformed one",
            "Send oversized message"
          ],
          "deliverables": [
            "Protocol error boundary and cases"
          ],
          "rollout": "Close only the offending transport when framing is unrecoverable.",
          "skills": [
            "Error isolation",
            "Input security"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3bc7e34b-b140-481c-8fe6-37b6d3670e46",
          "key": "CLSP-110",
          "title": "Create a reproducible configuration language-server transcript harness",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "recovery",
          "dependsOn": [
            "CLSP-107",
            "CLSP-109"
          ],
          "scenario": "Editor reports are difficult to replay. Record synthetic protocol transcripts with deterministic response assertions.",
          "acceptanceCriteria": [
            "Harness replays open/edit/action/close",
            "Versions and request IDs are explicit",
            "Fixture text is synthetic"
          ],
          "implementationNotes": [
            "Recorded transcripts are public regression cases, not hidden grading answers."
          ],
          "verification": [
            "Replay successful rename",
            "Replay stale action rejection"
          ],
          "deliverables": [
            "Transcript runner and fixtures"
          ],
          "rollout": "Retain prior passing transcripts when behavior changes intentionally.",
          "skills": [
            "Testing",
            "Protocols"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "a5d33835-0e83-4a2f-a546-eb3d2bc0a23e",
      "key": "CBUILD",
      "title": "An incremental build graph with correct invalidation",
      "field": "Compiler and language tooling",
      "summary": "Track local source dependencies and reuse outputs only when inputs match.",
      "context": "Fictional static documentation compiler Rowan transforms synthetic text modules through a deterministic local adapter. It never executes candidate source as code.",
      "stack": [
        "TypeScript",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create a synthetic module graph and deterministic transform stub.",
        "Provide file-change, missing-input and interrupted-output fixtures."
      ],
      "developerValue": "Practice dependency graphs and cache correctness.",
      "companyValue": "Inspect whether build speed improvements preserve output correctness.",
      "delivery": "Measure local fixture behavior; broad compiler-performance claims are excluded.",
      "phases": [
        {
          "id": "graph",
          "title": "Establish dependency identity",
          "goal": "Parse and validate local graph edges."
        },
        {
          "id": "reuse",
          "title": "Invalidate and rebuild",
          "goal": "Reuse only compatible outputs."
        },
        {
          "id": "recovery",
          "title": "Recover interrupted builds",
          "goal": "Publish outputs and explain cache decisions."
        }
      ],
      "tickets": [
        {
          "id": "fc33c331-e03a-4e26-a4af-7cf6ec877175",
          "key": "CBUILD-101",
          "title": "Normalize local build paths without merging distinct modules",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "graph",
          "dependsOn": [],
          "scenario": "Relative spellings create duplicate graph nodes. Define canonical module identity under an explicit workspace root.",
          "acceptanceCriteria": [
            "Equivalent local paths share identity",
            "Escaping paths are rejected",
            "Case behavior is documented per adapter"
          ],
          "implementationNotes": [
            "Do not silently assume case-insensitive filesystems."
          ],
          "verification": [
            "Resolve relative alias",
            "Reject path escaping fixture root"
          ],
          "deliverables": [
            "Module identity resolver"
          ],
          "rollout": "Disable reuse for ambiguous path identities.",
          "skills": [
            "Filesystem",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "651da7ba-a5f8-4792-88a3-01e79fb36470",
          "key": "CBUILD-102",
          "title": "Report missing static-build imports at their source location",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "graph",
          "dependsOn": [
            "CBUILD-101"
          ],
          "scenario": "A missing import yields an internal file error. Map resolution failure to the importing source span.",
          "acceptanceCriteria": [
            "Missing path identifies importer",
            "Valid imports resolve",
            "Error omits unrelated absolute paths"
          ],
          "implementationNotes": [
            "Use synthetic source content only."
          ],
          "verification": [
            "Resolve present import",
            "Reference absent module"
          ],
          "deliverables": [
            "Import diagnostic and cases"
          ],
          "rollout": "Stop affected module build while preserving other diagnostics.",
          "skills": [
            "Resolution",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c1f439a3-1456-42f5-8902-e7111e62c3c9",
          "key": "CBUILD-103",
          "title": "Detect static-build dependency cycles with a readable path",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "graph",
          "dependsOn": [
            "CBUILD-101",
            "CBUILD-102"
          ],
          "scenario": "Recursive imports hang graph traversal. Detect cycles and return the concrete edge path.",
          "acceptanceCriteria": [
            "Acyclic graph builds",
            "Cycle includes involved modules",
            "Repeated traversal terminates"
          ],
          "implementationNotes": [
            "Bound reported cycle length for large inputs."
          ],
          "verification": [
            "Traverse diamond graph",
            "Introduce three-node cycle"
          ],
          "deliverables": [
            "Cycle detector and fixtures"
          ],
          "rollout": "Refuse cyclic graph outputs until cycle policy is defined.",
          "skills": [
            "Graphs",
            "Algorithms"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c3ab5090-6af5-4bbf-8d34-9cbb72fc9d7b",
          "key": "CBUILD-104",
          "title": "Include transform configuration in static-build cache identity",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "reuse",
          "dependsOn": [
            "CBUILD-103"
          ],
          "scenario": "Changing compiler options reuses output produced under older options. Hash normalized inputs and configuration.",
          "acceptanceCriteria": [
            "Same inputs reuse output",
            "Changed options invalidate",
            "Transform version participates in key"
          ],
          "implementationNotes": [
            "Hash canonical configuration, not property insertion order."
          ],
          "verification": [
            "Reorder equivalent config keys",
            "Change output-affecting option"
          ],
          "deliverables": [
            "Cache-key contract and cases"
          ],
          "rollout": "Disable cache reuse after unknown configuration changes.",
          "skills": [
            "Caching",
            "Canonicalization"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "02045752-f08d-46d8-a8ea-b8583457afcc",
          "key": "CBUILD-105",
          "title": "Invalidate transitive static-build dependents after source changes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "reuse",
          "dependsOn": [
            "CBUILD-103",
            "CBUILD-104"
          ],
          "scenario": "Updating a shared module rebuilds it but leaves dependent pages stale. Traverse reverse dependency edges.",
          "acceptanceCriteria": [
            "Direct and transitive dependents rebuild",
            "Unrelated modules remain reusable",
            "Removed edges stop unnecessary invalidation"
          ],
          "implementationNotes": [
            "Use previous and current graph where edge removal matters."
          ],
          "verification": [
            "Change shared leaf",
            "Remove dependency then change old leaf"
          ],
          "deliverables": [
            "Invalidation planner and graph cases"
          ],
          "rollout": "Rebuild all fixture modules if invalidation is uncertain.",
          "skills": [
            "Dependency graphs",
            "Incremental builds"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 50
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "50dfed43-1ba2-4968-a1a9-284176fefbd6",
          "key": "CBUILD-106",
          "title": "Track failed static-build nodes without caching broken outputs",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "reuse",
          "dependsOn": [
            "CBUILD-104",
            "CBUILD-105"
          ],
          "scenario": "A failed transform writes a cache entry that future builds treat as success. Separate failure from reusable output.",
          "acceptanceCriteria": [
            "Only successful validated output caches",
            "Failure retains diagnostics",
            "Next build retries affected node"
          ],
          "implementationNotes": [
            "Never replace last good output with partial bytes silently."
          ],
          "verification": [
            "Build successful node",
            "Fail transform after partial output"
          ],
          "deliverables": [
            "Build result states and failure cases"
          ],
          "rollout": "Clear only affected invalid cache entries and retry.",
          "skills": [
            "Error handling",
            "Build systems"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1d7717fa-7032-4b19-88e6-d899fcd86cf4",
          "key": "CBUILD-107",
          "title": "Make incremental static builds deterministic across worker order",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "reuse",
          "dependsOn": [
            "CBUILD-105",
            "CBUILD-106"
          ],
          "scenario": "Parallel transform completion changes manifest ordering and output hashes. Separate execution scheduling from canonical publication.",
          "acceptanceCriteria": [
            "Equivalent graphs yield identical manifests",
            "Dependencies complete before consumers",
            "Failed nodes cannot publish"
          ],
          "implementationNotes": [
            "Use controllable local transform promises."
          ],
          "verification": [
            "Resolve independent workers in opposite order",
            "Fail one dependency"
          ],
          "deliverables": [
            "Deterministic scheduler and order cases"
          ],
          "rollout": "Use serial execution while ordering invariants are repaired.",
          "skills": [
            "Determinism",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "028709ba-9a8b-44db-bc85-2f0e4a109526",
          "key": "CBUILD-108",
          "title": "Publish a static-build output generation only after all required nodes pass",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recovery",
          "dependsOn": [
            "CBUILD-106",
            "CBUILD-107"
          ],
          "scenario": "Readers see mixed old and new files during a build. Write a staging generation and switch a manifest pointer.",
          "acceptanceCriteria": [
            "Failed builds keep previous generation",
            "Successful generation is complete",
            "Switch recovery selects one valid manifest"
          ],
          "implementationNotes": [
            "Keep prior generation until activation is durable."
          ],
          "verification": [
            "Publish successful fixture",
            "Crash before manifest switch"
          ],
          "deliverables": [
            "Generation publisher and recovery cases"
          ],
          "rollout": "Restore prior manifest on failed post-switch checks.",
          "skills": [
            "Atomic publication",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "083c5c00-c021-4e97-8d3f-06517f405942",
          "key": "CBUILD-109",
          "title": "Coalesce repeated static-build file events without missing deletion",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "recovery",
          "dependsOn": [
            "CBUILD-105",
            "CBUILD-108"
          ],
          "scenario": "Editors emit many change events and a final delete can be swallowed by debounce. Track final invalidation intent per module.",
          "acceptanceCriteria": [
            "Repeated updates coalesce",
            "Deletion remains authoritative",
            "Change during build schedules another pass"
          ],
          "implementationNotes": [
            "File events are hints; resolve actual state before building."
          ],
          "verification": [
            "Burst-save one file",
            "Delete during active build"
          ],
          "deliverables": [
            "Event coordinator and race cases"
          ],
          "rollout": "Use explicit rebuild requests if watcher semantics are unreliable.",
          "skills": [
            "File watching",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "30a3d3b4-3ee5-4a12-88f7-0b88c0792e58",
          "key": "CBUILD-110",
          "title": "Explain why each static-build module was reused or rebuilt",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "recovery",
          "dependsOn": [
            "CBUILD-104",
            "CBUILD-109"
          ],
          "scenario": "Developers cannot distinguish cache misses from invalidation bugs. Emit structured decision reasons without source text.",
          "acceptanceCriteria": [
            "Reasons identify changed input category",
            "Reuse points to compatible key",
            "Diagnostics omit source contents"
          ],
          "implementationNotes": [
            "Local timing observations must state fixture and environment."
          ],
          "verification": [
            "Inspect unchanged build",
            "Change transform version and inspect reasons"
          ],
          "deliverables": [
            "Build decision report"
          ],
          "rollout": "Disable report fields that expose source content.",
          "skills": [
            "Observability",
            "Developer experience"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 80
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "8bed83db-0f26-4d1d-82a8-1f469de2a232",
      "key": "CMIGR",
      "title": "A safe source migration for a deprecated configuration API",
      "field": "Compiler and language tooling",
      "summary": "Transform one deprecated call shape through syntax-aware, reviewable file edits.",
      "context": "Fictional package Laurel replaces configure(name, options) with configure({name, options}). Build synthetic TypeScript-like AST fixtures or use the repository's installed parser; source is analyzed, never executed.",
      "stack": [
        "TypeScript",
        "AST adapter",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Create synthetic supported and ambiguous call-site fixtures.",
        "Define the exact old/new API contract and a dedicated output directory."
      ],
      "developerValue": "Practice conservative automated refactoring and reviewable uncertainty.",
      "companyValue": "Inspect whether migration automation reduces repetitive work without silent semantic changes.",
      "delivery": "Only the declared API migration is covered; ambiguous cases must remain manual.",
      "phases": [
        {
          "id": "discovery",
          "title": "Find eligible calls",
          "goal": "Resolve syntax and binding identity."
        },
        {
          "id": "transform",
          "title": "Produce conservative edits",
          "goal": "Preserve comments and reject ambiguity."
        },
        {
          "id": "delivery",
          "title": "Apply and verify safely",
          "goal": "Make changes reviewable and recoverable."
        }
      ],
      "tickets": [
        {
          "id": "2c38d56a-b1d6-462d-9ee1-a49cfb36130e",
          "key": "CMIGR-101",
          "title": "Identify deprecated configuration imports by resolved binding",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "discovery",
          "dependsOn": [],
          "scenario": "Text search matches unrelated local functions named configure. Discover calls through the imported binding.",
          "acceptanceCriteria": [
            "Imported binding matches",
            "Aliased import matches",
            "Unrelated local name does not match"
          ],
          "implementationNotes": [
            "Scope is the declared module identifier only."
          ],
          "verification": [
            "Find direct and aliased import",
            "Use unrelated local configure"
          ],
          "deliverables": [
            "Call-site discovery and cases"
          ],
          "rollout": "Report candidates without editing if resolution is uncertain.",
          "skills": [
            "Static analysis",
            "Bindings"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "74169c04-1304-4749-a37b-e18bd8da12ce",
          "key": "CMIGR-102",
          "title": "Exclude comments and string literals from configuration migration candidates",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "discovery",
          "dependsOn": [
            "CMIGR-101"
          ],
          "scenario": "A prototype replaces examples inside strings and comments. Use syntax node kinds for candidate selection.",
          "acceptanceCriteria": [
            "Executable call nodes alone qualify",
            "Comment text remains unchanged",
            "String contents remain unchanged"
          ],
          "implementationNotes": [
            "Source analysis does not execute expressions."
          ],
          "verification": [
            "Find real call",
            "Include matching text in comment and string"
          ],
          "deliverables": [
            "Syntax filter and fixtures"
          ],
          "rollout": "Disable text-based fallback entirely.",
          "skills": [
            "AST",
            "Parsing"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "81931904-e124-4978-9ce8-9d5123cb56ec",
          "key": "CMIGR-103",
          "title": "Report ambiguous configuration calls for manual review",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "discovery",
          "dependsOn": [
            "CMIGR-101",
            "CMIGR-102"
          ],
          "scenario": "Spread arguments and reassigned bindings make transformation unsafe. Return explicit skipped reasons.",
          "acceptanceCriteria": [
            "Supported two-argument calls qualify",
            "Spread or reassigned cases skip",
            "Skipped locations are listed"
          ],
          "implementationNotes": [
            "Do not invent argument meaning from names."
          ],
          "verification": [
            "Classify supported call",
            "Classify spread and reassignment"
          ],
          "deliverables": [
            "Eligibility report and cases"
          ],
          "rollout": "Keep ambiguous files unchanged.",
          "skills": [
            "Program analysis",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "40459a57-15b7-4391-a94b-61dd5aa49f06",
          "key": "CMIGR-104",
          "title": "Transform the supported configuration call shape without reordering evaluation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "transform",
          "dependsOn": [
            "CMIGR-103"
          ],
          "scenario": "Wrapping arguments into an object could reorder side-effecting expressions. Preserve the old left-to-right evaluation order.",
          "acceptanceCriteria": [
            "Name expression remains first",
            "Options remains second",
            "No expression duplicates or disappears"
          ],
          "implementationNotes": [
            "Verify syntax structure without executing candidate expressions."
          ],
          "verification": [
            "Transform ordinary expressions",
            "Use synthetic call expressions in both positions"
          ],
          "deliverables": [
            "Transformation and AST-order checks"
          ],
          "rollout": "Revert transformed files if evaluation order cannot be preserved.",
          "skills": [
            "Semantics",
            "Refactoring"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "59496b96-e717-44d6-86ea-c726e6f6897d",
          "key": "CMIGR-105",
          "title": "Preserve configuration-call comments during transformation",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "transform",
          "dependsOn": [
            "CMIGR-104"
          ],
          "scenario": "Comments between arguments vanish in generated output. Attach trivia using a documented preservation rule.",
          "acceptanceCriteria": [
            "Leading and trailing comments survive",
            "Argument comments remain near their expression",
            "Unrepresentable trivia causes skip"
          ],
          "implementationNotes": [
            "Do not silently relocate a directive comment."
          ],
          "verification": [
            "Transform commented call",
            "Use directive-like ambiguous comment"
          ],
          "deliverables": [
            "Trivia-preserving transform and cases"
          ],
          "rollout": "Leave affected call unchanged with a review reason.",
          "skills": [
            "Syntax trees",
            "Comments"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "55207d12-36b8-40be-a69f-53f51641903f",
          "key": "CMIGR-106",
          "title": "Make the configuration migration idempotent",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "transform",
          "dependsOn": [
            "CMIGR-104",
            "CMIGR-105"
          ],
          "scenario": "Running the migration twice wraps an already migrated call again. Recognize new syntax and preserve it.",
          "acceptanceCriteria": [
            "Second run produces no diff",
            "Mixed old/new files transform eligible old calls",
            "Unrelated object arguments remain unchanged"
          ],
          "implementationNotes": [
            "Idempotence is checked on printed source as well as AST."
          ],
          "verification": [
            "Run twice on migrated fixture",
            "Run on mixed file"
          ],
          "deliverables": [
            "Idempotency cases and migration guard"
          ],
          "rollout": "Stop repeated application if the second run changes output.",
          "skills": [
            "Refactoring",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 80
            },
            {
              "field": "Developer tooling",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "21911cae-fa21-42e0-a2e1-e072678ee138",
          "key": "CMIGR-107",
          "title": "Reject overlapping configuration source edits before writing",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "transform",
          "dependsOn": [
            "CMIGR-104",
            "CMIGR-106"
          ],
          "scenario": "Nested eligible calls produce overlapping text edits and corrupt files. Plan edits with deterministic nesting handling.",
          "acceptanceCriteria": [
            "Edits do not overlap",
            "Nested calls follow documented policy",
            "Ambiguous overlap skips file safely"
          ],
          "implementationNotes": [
            "Prefer one syntax-tree rewrite over blind offset patches."
          ],
          "verification": [
            "Transform disjoint calls",
            "Transform nested eligible calls"
          ],
          "deliverables": [
            "Edit planner and overlap cases"
          ],
          "rollout": "Emit preview only for files with unresolved overlaps.",
          "skills": [
            "Algorithms",
            "Source transformation"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "abd17d7c-b233-4cb3-86c4-5cc449833c17",
          "key": "CMIGR-108",
          "title": "Preview configuration migration changes before applying them",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "delivery",
          "dependsOn": [
            "CMIGR-107"
          ],
          "scenario": "Developers need to review the exact transformation scope. Add a dry-run diff and skipped-call summary.",
          "acceptanceCriteria": [
            "Preview writes no source files",
            "Diff reflects proposed bytes",
            "Skipped reasons include locations"
          ],
          "implementationNotes": [
            "Default command mode should be explicit in usage."
          ],
          "verification": [
            "Preview supported fixture",
            "Preview ambiguous file and compare unchanged bytes"
          ],
          "deliverables": [
            "Dry-run report and immutability check"
          ],
          "rollout": "Disable apply mode if preview differs from actual output.",
          "skills": [
            "CLI",
            "Developer experience"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4766fe65-8c01-4d70-a717-78a48bed274d",
          "key": "CMIGR-109",
          "title": "Apply configuration migration files with stale-input protection",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "delivery",
          "dependsOn": [
            "CMIGR-108"
          ],
          "scenario": "A developer edits a file after preview and apply overwrites it. Compare the original digest before replacement.",
          "acceptanceCriteria": [
            "Matching source applies",
            "Changed source is rejected",
            "Failed replacement preserves recoverable original"
          ],
          "implementationNotes": [
            "Restrict writes to the explicit fixture root."
          ],
          "verification": [
            "Apply unchanged preview",
            "Modify file before apply"
          ],
          "deliverables": [
            "Guarded writer and failure cases"
          ],
          "rollout": "Restore preserved original only after checking target identity.",
          "skills": [
            "Concurrency",
            "Filesystem"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "42975b91-4ff2-493c-9961-76f062495875",
          "key": "CMIGR-110",
          "title": "Summarize configuration migration outcomes without claiming full compatibility",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "delivery",
          "dependsOn": [
            "CMIGR-109"
          ],
          "scenario": "A green migration summary implies the whole package is compatible despite skipped sites. Report exact supported outcomes.",
          "acceptanceCriteria": [
            "Counts distinguish changed unchanged and skipped",
            "Follow-up checks are listed",
            "No semantic proof is asserted beyond tested contract"
          ],
          "implementationNotes": [
            "Run parser/type checks available in the fixture harness."
          ],
          "verification": [
            "Summarize complete supported fixture",
            "Summarize mixed skipped case"
          ],
          "deliverables": [
            "Migration report and verification record"
          ],
          "rollout": "Mark migration incomplete when required checks fail.",
          "skills": [
            "Reporting",
            "Verification"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "a33baed1-8262-4f90-a081-caa0818640ce",
      "key": "CFRAME",
      "title": "An emulated device-link framing library",
      "field": "Embedded and edge",
      "summary": "Decode bounded byte streams and recover serial-link framing errors in software.",
      "context": "Fictional environmental-display devices send synthetic noncritical readings to a local gateway. Implement a byte-stream emulator; no physical device, radio, credentials or safety-critical control is involved.",
      "stack": [
        "TypeScript",
        "Byte-stream emulator",
        "Vitest"
      ],
      "prerequisites": [
        "Specify a small frame format with length sequence payload and checksum.",
        "Generate local byte streams with fragmentation corruption and reconnects."
      ],
      "developerValue": "Practice incremental parsing, fixed resource limits and protocol recovery.",
      "companyValue": "Inspect whether a device adapter survives malformed input without corrupting accepted readings.",
      "delivery": "All execution uses software fixtures; hardware timing and production readiness are unqualified.",
      "phases": [
        {
          "id": "format",
          "title": "Define frame boundaries",
          "goal": "Validate bytes before interpreting payloads."
        },
        {
          "id": "stream",
          "title": "Handle partial transport",
          "goal": "Recover fragmented and damaged streams."
        },
        {
          "id": "operation",
          "title": "Bound receiver behavior",
          "goal": "Limit work and explain rejected data."
        }
      ],
      "tickets": [
        {
          "id": "0d475c31-e9f7-47d4-9d51-6d04beb09883",
          "key": "CFRAME-101",
          "title": "Decode emulated device frame integers with explicit byte order",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "format",
          "dependsOn": [],
          "scenario": "A synthetic device length reads as 512 instead of 2 because endpoints disagree on byte order. Specify and implement the format.",
          "acceptanceCriteria": [
            "Length and sequence use documented order",
            "Valid boundary values round-trip",
            "Truncated integer fields fail explicitly"
          ],
          "implementationNotes": [
            "Use byte fixtures rather than host-native integer casts."
          ],
          "verification": [
            "Decode known two-byte values",
            "Provide truncated header"
          ],
          "deliverables": [
            "Integer codec and format examples"
          ],
          "rollout": "Reject frames from unknown format versions.",
          "skills": [
            "Binary protocols",
            "Encoding"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3948ecd1-6416-4492-bfd2-b018fe826261",
          "key": "CFRAME-102",
          "title": "Reject emulated device frames above the receiver limit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "format",
          "dependsOn": [
            "CFRAME-101"
          ],
          "scenario": "An untrusted length prefix causes a large allocation. Validate declared size before reserving payload storage.",
          "acceptanceCriteria": [
            "Supported sizes pass",
            "Oversized lengths fail before allocation",
            "Zero-length policy is explicit"
          ],
          "implementationNotes": [
            "Keep receiver limits independent from sender claims."
          ],
          "verification": [
            "Decode small fixture",
            "Declare maximum integer length"
          ],
          "deliverables": [
            "Frame admission guard and allocation checks"
          ],
          "rollout": "Stop reception if bounded allocation cannot be guaranteed.",
          "skills": [
            "Resource limits",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "81f6c912-1c42-43e4-9fcf-ccd3745e48c9",
          "key": "CFRAME-103",
          "title": "Verify emulated device frame checksums before dispatch",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "format",
          "dependsOn": [
            "CFRAME-101",
            "CFRAME-102"
          ],
          "scenario": "Corrupted readings reach the dashboard because checksum failures are warnings only. Gate payload dispatch on verification.",
          "acceptanceCriteria": [
            "Valid frame dispatches once",
            "Bad checksum dispatches nothing",
            "Failure records a bounded category"
          ],
          "implementationNotes": [
            "Checksum detects corruption and does not authenticate senders."
          ],
          "verification": [
            "Accept valid frame",
            "Flip payload byte without updating checksum"
          ],
          "deliverables": [
            "Checksum gate and corruption cases"
          ],
          "rollout": "Disable payload dispatch if verification is unavailable.",
          "skills": [
            "Integrity",
            "Protocol design"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "acaf701b-d7eb-418c-a71a-a0ac9d7fe153",
          "key": "CFRAME-104",
          "title": "Assemble fragmented emulated frames across arbitrary read boundaries",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "stream",
          "dependsOn": [
            "CFRAME-102",
            "CFRAME-103"
          ],
          "scenario": "A single frame split across reads is discarded as malformed. Maintain incremental parser state.",
          "acceptanceCriteria": [
            "Every legal split yields same frame",
            "Multiple frames in one read decode",
            "Incomplete suffix remains bounded"
          ],
          "implementationNotes": [
            "Transport read boundaries are not message boundaries."
          ],
          "verification": [
            "Test every split of small frame",
            "Feed partial header then disconnect"
          ],
          "deliverables": [
            "Streaming decoder and split cases"
          ],
          "rollout": "Buffer only up to the declared frame limit.",
          "skills": [
            "Streaming",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e2e2ebe1-be3f-478f-b33c-67563411344f",
          "key": "CFRAME-105",
          "title": "Resynchronize emulated device framing after a corrupt header",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "stream",
          "dependsOn": [
            "CFRAME-104"
          ],
          "scenario": "One damaged length prevents decoding all later frames. Recover at a documented sync marker without trusting random payload bytes.",
          "acceptanceCriteria": [
            "Valid later frame can recover",
            "Recovery scans within a cap",
            "Rejected bytes never dispatch as readings"
          ],
          "implementationNotes": [
            "Define marker escaping or ambiguity handling explicitly."
          ],
          "verification": [
            "Corrupt header before valid frame",
            "Embed marker-like bytes in payload"
          ],
          "deliverables": [
            "Resynchronization algorithm and ambiguity cases"
          ],
          "rollout": "Close the link when a safe boundary cannot be found.",
          "skills": [
            "Parser recovery",
            "Protocols"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "b389bc08-6085-4697-a5b7-7f35c28290d1",
          "key": "CFRAME-106",
          "title": "Discard incomplete emulated frames after an idle deadline",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "stream",
          "dependsOn": [
            "CFRAME-104",
            "CFRAME-105"
          ],
          "scenario": "A sender transmits a header and stops, pinning a receive buffer indefinitely. Add an injected idle timer.",
          "acceptanceCriteria": [
            "Active progress refreshes deadline",
            "Expired partial frame releases buffer",
            "New valid frame can start afterward"
          ],
          "implementationNotes": [
            "Use monotonic elapsed time rather than calendar time."
          ],
          "verification": [
            "Complete frame before deadline",
            "Pause midway beyond deadline"
          ],
          "deliverables": [
            "Partial-frame timeout and clock cases"
          ],
          "rollout": "Reset connection on timeout if local recovery is uncertain.",
          "skills": [
            "Timers",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ab4382e3-5fbc-48f0-917b-3fdb50f99d4a",
          "key": "CFRAME-107",
          "title": "Handle emulated device sequence wrap without accepting stale frames",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "stream",
          "dependsOn": [
            "CFRAME-103",
            "CFRAME-106"
          ],
          "scenario": "Sequence 0 after 65535 is rejected as old, while delayed frames sometimes overwrite current readings. Define a bounded modular-order window.",
          "acceptanceCriteria": [
            "Legitimate wrap is accepted",
            "Duplicates do not dispatch twice",
            "Outside-window frames are rejected or require reset"
          ],
          "implementationNotes": [
            "State the maximum reorder window and session boundary."
          ],
          "verification": [
            "Feed wrap boundary sequence",
            "Replay delayed pre-wrap frame"
          ],
          "deliverables": [
            "Sequence policy and boundary cases"
          ],
          "rollout": "Require a new session when sequence ordering is ambiguous.",
          "skills": [
            "Sequence arithmetic",
            "Ordering"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "854f60d7-7363-4a5a-b62e-9d2274fc32b9",
          "key": "CFRAME-108",
          "title": "Apply backpressure when emulated device consumers fall behind",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operation",
          "dependsOn": [
            "CFRAME-104",
            "CFRAME-107"
          ],
          "scenario": "Parsing outruns downstream processing and queues grow indefinitely. Bound accepted-frame buffering.",
          "acceptanceCriteria": [
            "Queue capacity is explicit",
            "Overflow follows documented reject or pause policy",
            "Parser state remains valid"
          ],
          "implementationNotes": [
            "Do not claim lossless delivery under an explicit drop policy."
          ],
          "verification": [
            "Consume at normal speed",
            "Stall consumer past capacity"
          ],
          "deliverables": [
            "Bounded queue and overload cases"
          ],
          "rollout": "Pause emulator input if the consumer cannot keep up.",
          "skills": [
            "Backpressure",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0501efec-16f0-4b37-aa1d-d7bc81f78ecf",
          "key": "CFRAME-109",
          "title": "Reset emulated receiver state on a new link session",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "operation",
          "dependsOn": [
            "CFRAME-106",
            "CFRAME-107"
          ],
          "scenario": "Bytes from a previous connection combine with a new header after reconnect. Clear session-owned parsing state.",
          "acceptanceCriteria": [
            "New session discards partial buffer",
            "Sequence window resets by contract",
            "Completed prior frames remain recorded"
          ],
          "implementationNotes": [
            "Connection identity must not come from payload text alone."
          ],
          "verification": [
            "Reconnect after complete frame",
            "Reconnect mid-header"
          ],
          "deliverables": [
            "Session reset and reconnect cases"
          ],
          "rollout": "Recreate the receiver per connection until state isolation is repaired.",
          "skills": [
            "Lifecycle",
            "State isolation"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Networking",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "43f7d910-f089-4148-993b-cf898c3eafef",
          "key": "CFRAME-110",
          "title": "Expose emulated frame rejection counters without raw payloads",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 90,
          "phaseId": "operation",
          "dependsOn": [
            "CFRAME-108",
            "CFRAME-109"
          ],
          "scenario": "Debug logs contain complete sensor payloads even when only corruption rates are needed. Emit bounded categories.",
          "acceptanceCriteria": [
            "Counts separate size checksum timeout and sequence failures",
            "Payload bytes are omitted",
            "Counter reset scope is documented"
          ],
          "implementationNotes": [
            "Measurements describe the synthetic emulator only."
          ],
          "verification": [
            "Feed valid and corrupt fixtures",
            "Inject secret-like payload and inspect logs"
          ],
          "deliverables": [
            "Receiver metrics contract and samples"
          ],
          "rollout": "Disable detailed logging if payload content escapes.",
          "skills": [
            "Observability",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "a5cfc10b-ed66-44e0-8a0d-923bc81a4353",
      "key": "CTIMER",
      "title": "A deterministic edge-job scheduler emulator",
      "field": "Embedded and edge",
      "summary": "Schedule noncritical local maintenance jobs across clock changes, cancellation and restart.",
      "context": "Fictional kiosk software schedules cache refresh and display housekeeping. Build a software clock and job adapter; do not control real machinery or purchase hardware.",
      "stack": [
        "TypeScript",
        "Fake clock",
        "Vitest"
      ],
      "prerequisites": [
        "Implement injected wall and monotonic clocks.",
        "Create synthetic jobs with controllable completion and failure."
      ],
      "developerValue": "Practice timer semantics, cancellation and bounded scheduling.",
      "companyValue": "Inspect predictable edge resource use and honest execution status.",
      "delivery": "Use deterministic clock advancement; emulator timing does not qualify physical realtime behavior.",
      "phases": [
        {
          "id": "clock",
          "title": "Define time semantics",
          "goal": "Separate elapsed deadlines from calendar schedules."
        },
        {
          "id": "jobs",
          "title": "Control job execution",
          "goal": "Prevent overlap and stale callbacks."
        },
        {
          "id": "restart",
          "title": "Recover scheduler state",
          "goal": "Handle restart and overload deliberately."
        }
      ],
      "tickets": [
        {
          "id": "90c9ed8c-7b45-4801-a2c6-3fcbd6795296",
          "key": "CTIMER-101",
          "title": "Use monotonic time for edge-job timeout deadlines",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "clock",
          "dependsOn": [],
          "scenario": "Moving the emulator wall clock backward extends a running job forever. Measure elapsed timeout against monotonic time.",
          "acceptanceCriteria": [
            "Wall-clock changes do not extend timeout",
            "Deadline fires once",
            "Elapsed duration cannot become negative"
          ],
          "implementationNotes": [
            "Expose both clocks through interfaces."
          ],
          "verification": [
            "Move wall clock during job",
            "Advance monotonic clock past deadline"
          ],
          "deliverables": [
            "Deadline helper and clock cases"
          ],
          "rollout": "Disable timed jobs if monotonic source is unavailable.",
          "skills": [
            "Time",
            "Abstraction"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "47aaebf0-d1c9-4342-9010-2e2db756e741",
          "key": "CTIMER-102",
          "title": "Validate emulated edge-job intervals before scheduling",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "clock",
          "dependsOn": [
            "CTIMER-101"
          ],
          "scenario": "A zero interval creates an immediate callback loop. Enforce a documented supported interval range.",
          "acceptanceCriteria": [
            "Valid intervals register",
            "Zero negative and oversized values fail",
            "Rejected jobs allocate no timer"
          ],
          "implementationNotes": [
            "Do not silently clamp invalid configuration."
          ],
          "verification": [
            "Register valid interval",
            "Reject zero and negative interval"
          ],
          "deliverables": [
            "Interval validator and cases"
          ],
          "rollout": "Reject new registrations if limits cannot be enforced.",
          "skills": [
            "Validation",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "f83fcb4b-c3b0-463f-a9c1-6d1c61dc039d",
          "key": "CTIMER-103",
          "title": "Specify fixed-delay behavior for periodic kiosk maintenance",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "clock",
          "dependsOn": [
            "CTIMER-101",
            "CTIMER-102"
          ],
          "scenario": "Long cache refreshes cause catch-up bursts because scheduling alternates between fixed-rate and fixed-delay behavior. Choose fixed-delay for this job class.",
          "acceptanceCriteria": [
            "Next run starts after completion plus delay",
            "Slow runs do not overlap",
            "Failure still follows documented next-run policy"
          ],
          "implementationNotes": [
            "Limit the change to the declared maintenance class."
          ],
          "verification": [
            "Complete short job",
            "Complete job longer than interval"
          ],
          "deliverables": [
            "Periodic policy and fake-clock cases"
          ],
          "rollout": "Pause periodic jobs while schedule semantics are repaired.",
          "skills": [
            "Scheduling",
            "Time"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8975de5b-931f-48ea-bccc-b0ea6458669d",
          "key": "CTIMER-104",
          "title": "Cancel emulated edge jobs without accepting late callbacks",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "jobs",
          "dependsOn": [
            "CTIMER-103"
          ],
          "scenario": "A cancelled timer callback runs after a replacement job is registered. Bind callbacks to registration generation.",
          "acceptanceCriteria": [
            "Cancel invalidates current generation",
            "Late callback performs no work",
            "Replacement generation can run"
          ],
          "implementationNotes": [
            "Clearing the runtime timer alone is insufficient."
          ],
          "verification": [
            "Cancel before deadline",
            "Deliver old callback after replacement"
          ],
          "deliverables": [
            "Generation guard and race cases"
          ],
          "rollout": "Recreate scheduler instance if generations become inconsistent.",
          "skills": [
            "Cancellation",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "ff3bb741-8c0a-4f55-8b39-9f9c1094f134",
          "key": "CTIMER-105",
          "title": "Prevent overlapping edge jobs that share one local resource",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "jobs",
          "dependsOn": [
            "CTIMER-103",
            "CTIMER-104"
          ],
          "scenario": "Cache refresh and cleanup run simultaneously and contend for the same fixture directory. Add scoped single-flight admission.",
          "acceptanceCriteria": [
            "Same resource runs one job",
            "Different resources remain independent",
            "Failure releases admission"
          ],
          "implementationNotes": [
            "Do not introduce an unbounded global waiting queue."
          ],
          "verification": [
            "Run separate resources",
            "Fail holder while another waits"
          ],
          "deliverables": [
            "Resource admission and cases"
          ],
          "rollout": "Serialize all fixture maintenance temporarily if scoped locking fails.",
          "skills": [
            "Concurrency",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a5511f30-190c-4cc2-807a-5916d2d30109",
          "key": "CTIMER-106",
          "title": "Bound emulated edge-job execution attempts after failure",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "jobs",
          "dependsOn": [
            "CTIMER-104",
            "CTIMER-105"
          ],
          "scenario": "A failed maintenance job retries forever and hides the original error. Add attempt limits and a terminal visible outcome.",
          "acceptanceCriteria": [
            "Attempts have an explicit cap",
            "Success clears pending retry",
            "Exhaustion preserves failure category"
          ],
          "implementationNotes": [
            "Retrying must reuse the same logical operation identity."
          ],
          "verification": [
            "Recover before cap",
            "Fail through exhaustion"
          ],
          "deliverables": [
            "Retry policy and deterministic cases"
          ],
          "rollout": "Disable automatic retry while retaining manual restart.",
          "skills": [
            "Backoff",
            "Failure handling"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8783003f-8413-4206-bf74-90424b3d5560",
          "key": "CTIMER-107",
          "title": "Recover due edge jobs after restart without a catch-up storm",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "jobs",
          "dependsOn": [
            "CTIMER-103",
            "CTIMER-106"
          ],
          "scenario": "Restarting after a long pause runs every missed interval at once. Persist minimal schedule state and coalesce missed runs.",
          "acceptanceCriteria": [
            "At most declared catch-up work runs",
            "Future schedule resumes predictably",
            "Unknown persisted version fails safely"
          ],
          "implementationNotes": [
            "Define which jobs may be skipped because they are housekeeping."
          ],
          "verification": [
            "Restart after one missed run",
            "Restart after many missed intervals"
          ],
          "deliverables": [
            "Recovery policy and restart fixtures"
          ],
          "rollout": "Start housekeeping from a fresh delayed schedule if state is unreadable.",
          "skills": [
            "Persistence",
            "Scheduling"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "37ec8df2-0b3b-4e5c-8a53-fd01e0d32637",
          "key": "CTIMER-108",
          "title": "Keep edge-job priority from starving lower-priority maintenance",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "restart",
          "dependsOn": [
            "CTIMER-105",
            "CTIMER-107"
          ],
          "scenario": "Frequent urgent cache checks prevent cleanup from ever running. Add bounded fairness to the ready queue.",
          "acceptanceCriteria": [
            "High priority gets documented preference",
            "Low priority eventually runs under bounded arrivals",
            "Queue size remains capped"
          ],
          "implementationNotes": [
            "State workload assumptions used for fairness checks."
          ],
          "verification": [
            "Run mixed-priority fixture",
            "Continuously enqueue within supported arrival bound"
          ],
          "deliverables": [
            "Fair queue and execution trace"
          ],
          "rollout": "Use simple round-robin while priority fairness is uncertain.",
          "skills": [
            "Scheduling",
            "Fairness"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "b8e604e0-6103-46d8-87dc-a08391b6f7a1",
          "key": "CTIMER-109",
          "title": "Report emulated edge-job lateness separately from duration",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "restart",
          "dependsOn": [
            "CTIMER-101",
            "CTIMER-108"
          ],
          "scenario": "A slow-started job is blamed on execution time because metrics combine queue delay and work duration. Separate them.",
          "acceptanceCriteria": [
            "Lateness measures due-to-start",
            "Duration measures start-to-finish",
            "Clock corrections do not corrupt elapsed metrics"
          ],
          "implementationNotes": [
            "Report synthetic local observations, not hardware deadlines."
          ],
          "verification": [
            "Queue then execute job",
            "Change wall clock during execution"
          ],
          "deliverables": [
            "Scheduler metric schema and cases"
          ],
          "rollout": "Hide derived latency fields if clock provenance is missing.",
          "skills": [
            "Observability",
            "Measurement"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "10c7a112-109b-4699-8525-01b7d10c7593",
          "key": "CTIMER-110",
          "title": "Provide a read-only edge scheduler timeline for recovery diagnosis",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "restart",
          "dependsOn": [
            "CTIMER-107",
            "CTIMER-109"
          ],
          "scenario": "Engineers cannot explain why a job was skipped after restart. Export bounded state transitions without running jobs.",
          "acceptanceCriteria": [
            "Timeline identifies schedule and attempt IDs",
            "Skipped reasons are explicit",
            "Inspection causes no callbacks or writes"
          ],
          "implementationNotes": [
            "Omit payloads and fixture file contents."
          ],
          "verification": [
            "Inspect completed sequence",
            "Inspect exhausted and skipped job"
          ],
          "deliverables": [
            "Timeline inspector and side-effect checks"
          ],
          "rollout": "Disable inspection fields that expose task payloads.",
          "skills": [
            "Diagnostics",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 50
            },
            {
              "field": "Embedded and edge",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "992e2b16-9300-45f2-bc00-b0b78f58aaa9",
      "key": "CJOUR",
      "title": "A power-loss-tolerant edge event journal",
      "field": "Embedded and edge",
      "summary": "Persist synthetic gateway events in a bounded software flash emulator.",
      "context": "Fictional edge display gateway stores noncritical synthetic readings while disconnected. Implement a byte-array flash emulator with explicit erase/write behavior and injected power cuts; no physical storage device is required.",
      "stack": [
        "TypeScript",
        "Flash-storage emulator",
        "Vitest"
      ],
      "prerequisites": [
        "Specify emulator page size write rules and erase behavior.",
        "Generate synthetic records and deterministic power-cut schedules."
      ],
      "developerValue": "Practice torn writes, wear-aware batching and acknowledged durability.",
      "companyValue": "Inspect whether offline device records remain recoverable within stated constraints.",
      "delivery": "Emulator guarantees are explicit; real flash endurance and device qualification remain separate.",
      "phases": [
        {
          "id": "records",
          "title": "Define durable records",
          "goal": "Encode and validate journal entries."
        },
        {
          "id": "power",
          "title": "Recover interrupted writes",
          "goal": "Handle commits and page boundaries."
        },
        {
          "id": "capacity",
          "title": "Manage finite storage",
          "goal": "Reclaim acknowledged records safely."
        }
      ],
      "tickets": [
        {
          "id": "62abe268-a5d9-4eec-a600-cfe72915d90e",
          "key": "CJOUR-101",
          "title": "Model edge-journal flash writes with explicit emulator constraints",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "records",
          "dependsOn": [],
          "scenario": "The byte-array stub permits writes that real flash-like storage would reject. Declare and enforce the chosen emulator model.",
          "acceptanceCriteria": [
            "Page boundaries are explicit",
            "Forbidden bit transitions fail",
            "Erase resets one selected page"
          ],
          "implementationNotes": [
            "This models selected behavior and does not certify real hardware."
          ],
          "verification": [
            "Write allowed transition",
            "Attempt forbidden transition without erase"
          ],
          "deliverables": [
            "Flash emulator contract and cases"
          ],
          "rollout": "Stop journal writes when adapter behavior violates the declared model.",
          "skills": [
            "Emulation",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2c45d8f3-059d-459f-b5f5-a8ece8f02786",
          "key": "CJOUR-102",
          "title": "Encode edge-journal records with bounded length and checksum",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "records",
          "dependsOn": [
            "CJOUR-101"
          ],
          "scenario": "Truncated synthetic records are indistinguishable from valid short payloads. Add explicit length and integrity fields.",
          "acceptanceCriteria": [
            "Payload bytes round-trip",
            "Length is bounded",
            "Checksum mismatch rejects record"
          ],
          "implementationNotes": [
            "Checksum is corruption detection, not authentication."
          ],
          "verification": [
            "Encode valid record",
            "Flip one stored byte"
          ],
          "deliverables": [
            "Record codec and corruption cases"
          ],
          "rollout": "Keep affected pages read-only for inspection.",
          "skills": [
            "Binary formats",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "4f788f4f-fe84-4a29-a5b9-04cd9f8a072f",
          "key": "CJOUR-103",
          "title": "Assign edge-journal event identities independently from delivery attempts",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "records",
          "dependsOn": [
            "CJOUR-102"
          ],
          "scenario": "Retried uploads mint new event IDs and duplicate accepted readings. Persist identity with the original record.",
          "acceptanceCriteria": [
            "Retry preserves identity",
            "New records get distinct identity",
            "Restart retains stored identity"
          ],
          "implementationNotes": [
            "IDs must not encode raw reading values."
          ],
          "verification": [
            "Retry same record",
            "Restart and compare identities"
          ],
          "deliverables": [
            "Event identity contract and cases"
          ],
          "rollout": "Pause replay if stored identity cannot be recovered.",
          "skills": [
            "Idempotency",
            "Identity"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "30ca4175-6d9e-4ee7-8231-756f56fcff5b",
          "key": "CJOUR-104",
          "title": "Commit edge-journal records only after their marker is durable",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "power",
          "dependsOn": [
            "CJOUR-102",
            "CJOUR-103"
          ],
          "scenario": "A record appears readable before its body finishes writing. Introduce a commit-marker protocol compatible with the emulator.",
          "acceptanceCriteria": [
            "Uncommitted bodies stay invisible",
            "Acknowledgement follows durable marker",
            "Invalid marker cannot authorize partial body"
          ],
          "implementationNotes": [
            "Specify write and flush ordering explicitly."
          ],
          "verification": [
            "Write committed fixture",
            "Cut power before marker"
          ],
          "deliverables": [
            "Commit protocol and cut-point tests"
          ],
          "rollout": "Disable acknowledgement if the durability barrier fails.",
          "skills": [
            "Durability",
            "Atomicity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "6d2fd934-9c5a-4143-ae27-d07ab71d41bc",
          "key": "CJOUR-105",
          "title": "Recover edge-journal scanning after a torn final record",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "power",
          "dependsOn": [
            "CJOUR-104"
          ],
          "scenario": "Startup stops at partial data and loses earlier committed events. Scan the valid committed prefix conservatively.",
          "acceptanceCriteria": [
            "Earlier committed records survive",
            "Incomplete tail is ignored with reason",
            "Middle corruption is not silently skipped"
          ],
          "implementationNotes": [
            "Preserve damaged bytes for explicit local diagnosis."
          ],
          "verification": [
            "Cut final body write",
            "Corrupt an earlier committed record"
          ],
          "deliverables": [
            "Recovery scanner and fault cases"
          ],
          "rollout": "Open journal read-only when corruption is not a tail interruption.",
          "skills": [
            "Recovery",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "12d922db-8d6c-46fc-977f-f6f300f4ec4f",
          "key": "CJOUR-106",
          "title": "Roll edge-journal writes onto a new page without overwriting unread events",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "power",
          "dependsOn": [
            "CJOUR-101",
            "CJOUR-104",
            "CJOUR-105"
          ],
          "scenario": "Page wrap overwrites unacknowledged events. Separate writable capacity from reclaimable pages.",
          "acceptanceCriteria": [
            "Active unread pages remain protected",
            "Full journal returns explicit capacity result",
            "New page starts with validated header"
          ],
          "implementationNotes": [
            "Do not silently discard oldest readings."
          ],
          "verification": [
            "Fill to page boundary",
            "Fill entire journal without acknowledgements"
          ],
          "deliverables": [
            "Page allocator and full-capacity cases"
          ],
          "rollout": "Stop admission when no safe writable page exists.",
          "skills": [
            "Ring buffers",
            "Resource limits"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "db01f212-a266-4994-9d1a-e0796993da8e",
          "key": "CJOUR-107",
          "title": "Recover edge-journal page generation selection after power loss",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "power",
          "dependsOn": [
            "CJOUR-105",
            "CJOUR-106"
          ],
          "scenario": "A cut during page-header activation leaves two pages claiming to be newest. Resolve generations through a declared ordering rule.",
          "acceptanceCriteria": [
            "Recovery chooses valid committed generation",
            "Incomplete header cannot supersede valid page",
            "Ambiguous generations fail visibly"
          ],
          "implementationNotes": [
            "Include wrap behavior in generation comparison."
          ],
          "verification": [
            "Cut header activation",
            "Exercise generation wrap fixture"
          ],
          "deliverables": [
            "Generation selection and boundary tests"
          ],
          "rollout": "Preserve both pages and stop writes on unresolved ambiguity.",
          "skills": [
            "Crash consistency",
            "Sequence arithmetic"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e1024784-a659-4fc1-9426-f4426b8a7e8f",
          "key": "CJOUR-108",
          "title": "Reclaim edge-journal pages only after durable delivery acknowledgements",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "capacity",
          "dependsOn": [
            "CJOUR-103",
            "CJOUR-107"
          ],
          "scenario": "The gateway erases a page after sending bytes, before the receiver acknowledges them. Gate reclamation on durable acknowledgements.",
          "acceptanceCriteria": [
            "Sent-only records remain protected",
            "Acknowledged complete page may erase",
            "Crash before acknowledgement persistence keeps page"
          ],
          "implementationNotes": [
            "Receiver stub must support replay by stable event identity."
          ],
          "verification": [
            "Acknowledge all page records",
            "Timeout after receiver acceptance"
          ],
          "deliverables": [
            "Ack ledger and reclamation cases"
          ],
          "rollout": "Pause erasure if acknowledgement state is uncertain.",
          "skills": [
            "Delivery semantics",
            "Storage"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 40
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7710346a-76da-4620-98bc-ec0ad87291d2",
          "key": "CJOUR-109",
          "title": "Batch edge-journal metadata updates within a declared loss window",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "capacity",
          "dependsOn": [
            "CJOUR-108"
          ],
          "scenario": "A metadata write for every status poll causes unnecessary emulated erase work. Batch only nonauthoritative counters.",
          "acceptanceCriteria": [
            "Event commits remain durable",
            "Batching does not weaken acknowledgement protection",
            "Counter loss window is documented"
          ],
          "implementationNotes": [
            "Do not batch safety-critical authority or claim real endurance improvement."
          ],
          "verification": [
            "Compare emulator operation counts",
            "Cut power before counter flush"
          ],
          "deliverables": [
            "Counter batching and measured local trace"
          ],
          "rollout": "Disable batching if authority depends on buffered counters.",
          "skills": [
            "Performance",
            "Durability"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4d5d951a-fa4c-4fb3-a5d1-8d53858ad443",
          "key": "CJOUR-110",
          "title": "Inspect edge-journal pages without modifying recovery state",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "capacity",
          "dependsOn": [
            "CJOUR-107",
            "CJOUR-109"
          ],
          "scenario": "Debugging currently boots the journal and may erase pages. Add a read-only page inspector.",
          "acceptanceCriteria": [
            "Reports generation and commit validity",
            "Does not erase or rewrite",
            "Payload display is opt-in"
          ],
          "implementationNotes": [
            "Restrict input to explicit synthetic image files."
          ],
          "verification": [
            "Inspect valid image",
            "Inspect torn and corrupt images"
          ],
          "deliverables": [
            "Inspector and no-write assertions"
          ],
          "rollout": "Keep diagnostic mode read-only if recovery suggestions are uncertain.",
          "skills": [
            "Diagnostics",
            "Emulation"
          ],
          "fieldMix": [
            {
              "field": "Developer tooling",
              "percentage": 40
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "558c0723-d030-4cd2-8b38-a2485f2edfa4",
      "key": "CUPDATE",
      "title": "A recoverable edge software-update simulator",
      "field": "Embedded and edge",
      "summary": "Stage, validate and switch synthetic software images in an A/B slot emulator.",
      "context": "Fictional information kiosks receive small generated image blobs through a local update adapter. Simulate slots and boot outcomes in software; do not flash hardware or execute image contents.",
      "stack": [
        "TypeScript",
        "Slot emulator",
        "Filesystem adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Generate inert byte images with manifests and development-only signing fixtures.",
        "Implement simulated boot success failure and power-cut points."
      ],
      "developerValue": "Practice update state machines and recoverable activation.",
      "companyValue": "Inspect whether an engineer can prevent partial rollout from stranding devices under declared conditions.",
      "delivery": "Use local emulator evidence only; signing fixtures never authorize production devices.",
      "phases": [
        {
          "id": "images",
          "title": "Validate update candidates",
          "goal": "Define version and image integrity."
        },
        {
          "id": "slots",
          "title": "Stage and activate",
          "goal": "Keep a recoverable known-good slot."
        },
        {
          "id": "fleet",
          "title": "Handle local rollout outcomes",
          "goal": "Bound retries and explain simulator status."
        }
      ],
      "tickets": [
        {
          "id": "359fe059-9a6c-465c-959e-f3708510044d",
          "key": "CUPDATE-101",
          "title": "Parse edge-update manifests with explicit supported versions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "images",
          "dependsOn": [],
          "scenario": "Unknown manifest fields are treated as executable update instructions. Replace loose parsing with a bounded schema.",
          "acceptanceCriteria": [
            "Known schema parses",
            "Unsupported version rejects",
            "Oversized fields reject before allocation"
          ],
          "implementationNotes": [
            "Manifests are data and never scripts."
          ],
          "verification": [
            "Parse valid inert image manifest",
            "Reject unsupported version"
          ],
          "deliverables": [
            "Manifest parser and cases"
          ],
          "rollout": "Reject new updates when schema identity is uncertain.",
          "skills": [
            "Validation",
            "Update systems"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "66424d07-03b4-4a60-a91e-8f37959ecb60",
          "key": "CUPDATE-102",
          "title": "Verify edge-update image size and digest before staging",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "images",
          "dependsOn": [
            "CUPDATE-101"
          ],
          "scenario": "A truncated synthetic image is marked downloaded. Gate staging on complete integrity verification.",
          "acceptanceCriteria": [
            "Size and digest both match",
            "Mismatch blocks staging",
            "Current active slot stays untouched"
          ],
          "implementationNotes": [
            "Stream verification under an explicit memory bound."
          ],
          "verification": [
            "Verify generated image",
            "Truncate or flip a byte"
          ],
          "deliverables": [
            "Image verifier and corruption cases"
          ],
          "rollout": "Keep failed images quarantined from slot activation.",
          "skills": [
            "Hashing",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Embedded and edge",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "e5875246-81b1-4ab5-8797-fe8532060fda",
          "key": "CUPDATE-103",
          "title": "Validate edge-update manifests using local trust fixtures",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "images",
          "dependsOn": [
            "CUPDATE-101",
            "CUPDATE-102"
          ],
          "scenario": "The simulator accepts any manifest signature. Add a trust adapter using ephemeral development keys.",
          "acceptanceCriteria": [
            "Trusted fixture signature passes",
            "Unknown signer fails",
            "Tampered manifest fails"
          ],
          "implementationNotes": [
            "No private keys enter source control or production configuration."
          ],
          "verification": [
            "Verify local signed fixture",
            "Change signed manifest field"
          ],
          "deliverables": [
            "Trust adapter and negative cases"
          ],
          "rollout": "Disable update acceptance if trusted verification is unavailable.",
          "skills": [
            "Cryptography",
            "Provider interfaces"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5a14f69e-5424-42e9-8366-c2295100fd31",
          "key": "CUPDATE-104",
          "title": "Write edge-update images only into the inactive simulated slot",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "slots",
          "dependsOn": [
            "CUPDATE-102",
            "CUPDATE-103"
          ],
          "scenario": "Update copying overwrites the currently selected image before validation finishes. Restrict staging to the inactive slot.",
          "acceptanceCriteria": [
            "Active slot remains byte-identical",
            "Inactive slot gets candidate bytes",
            "Failed write leaves active selection unchanged"
          ],
          "implementationNotes": [
            "Slot paths must stay inside the fixture root."
          ],
          "verification": [
            "Stage valid image",
            "Fail copy midway"
          ],
          "deliverables": [
            "Slot writer and isolation cases"
          ],
          "rollout": "Abandon inactive candidate and retain active slot.",
          "skills": [
            "Isolation",
            "Filesystem"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "b610907f-ad7e-41ea-abc1-7cd489aa6466",
          "key": "CUPDATE-105",
          "title": "Record edge-update activation intent before changing the boot selector",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "slots",
          "dependsOn": [
            "CUPDATE-104"
          ],
          "scenario": "A power cut during selector change leaves no recoverable activation decision. Journal intent and candidate identity.",
          "acceptanceCriteria": [
            "Intent is durable before selector change",
            "Recovery identifies pending activation",
            "Repeated recovery is deterministic"
          ],
          "implementationNotes": [
            "Do not execute image bytes; use boot-result stubs."
          ],
          "verification": [
            "Cut before selector update",
            "Cut after selector update"
          ],
          "deliverables": [
            "Activation journal and cut-point matrix"
          ],
          "rollout": "Restore prior validated selector when activation state is ambiguous.",
          "skills": [
            "Crash consistency",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Embedded and edge",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "a5a8a264-c9bf-42ef-bc94-21876d1f90fc",
          "key": "CUPDATE-106",
          "title": "Mark an edge-update candidate healthy only after simulated boot confirmation",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "slots",
          "dependsOn": [
            "CUPDATE-105"
          ],
          "scenario": "Merely selecting a slot labels the update successful. Require an explicit boot acknowledgement from the emulator.",
          "acceptanceCriteria": [
            "Selection yields pending health",
            "Confirmation marks success",
            "Missing confirmation reaches bounded failure state"
          ],
          "implementationNotes": [
            "Health means only the declared simulator check."
          ],
          "verification": [
            "Confirm successful boot",
            "Omit confirmation past deadline"
          ],
          "deliverables": [
            "Health transition and timer cases"
          ],
          "rollout": "Keep prior slot available until health acknowledgement commits.",
          "skills": [
            "State transitions",
            "Time"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "245c05eb-20e8-4eee-945c-bccdc1b7bbbd",
          "key": "CUPDATE-107",
          "title": "Roll back failed edge-update boots without retry loops",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "slots",
          "dependsOn": [
            "CUPDATE-105",
            "CUPDATE-106"
          ],
          "scenario": "A failing candidate is selected repeatedly on each restart. Persist failed-candidate disposition and restore the known-good slot.",
          "acceptanceCriteria": [
            "Failed candidate does not auto-reactivate",
            "Prior slot is selected",
            "No valid fallback produces explicit recovery-required state"
          ],
          "implementationNotes": [
            "Do not label fallback existence without validating its metadata."
          ],
          "verification": [
            "Fail candidate boot",
            "Invalidate both slot manifests"
          ],
          "deliverables": [
            "Rollback coordinator and failure cases"
          ],
          "rollout": "Stop automatic activation when no validated fallback exists.",
          "skills": [
            "Recovery",
            "Failure handling"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a215a6f6-d181-4fda-83a5-e7b9ef984e5e",
          "key": "CUPDATE-108",
          "title": "Reject unintended edge-update downgrades under an explicit version policy",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "fleet",
          "dependsOn": [
            "CUPDATE-103",
            "CUPDATE-107"
          ],
          "scenario": "Replaying an older signed image silently reverts a device. Add a declared minimum-version policy with a separate recovery mode.",
          "acceptanceCriteria": [
            "Normal mode rejects lower versions",
            "Equal-version replay is idempotent",
            "Recovery override is explicit and audited locally"
          ],
          "implementationNotes": [
            "Version order must be defined, not string-compared casually."
          ],
          "verification": [
            "Accept newer fixture",
            "Replay older signed fixture"
          ],
          "deliverables": [
            "Version policy and override cases"
          ],
          "rollout": "Disable updates if version comparison is ambiguous.",
          "skills": [
            "Versioning",
            "Security"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7fac0b9c-2b33-46fa-9919-fb58e6f101bd",
          "key": "CUPDATE-109",
          "title": "Limit concurrent downloads in the simulated kiosk update cohort",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "fleet",
          "dependsOn": [
            "CUPDATE-104",
            "CUPDATE-108"
          ],
          "scenario": "A local cohort starts every download at once and overwhelms the provider stub. Bound concurrency and retain per-device outcome.",
          "acceptanceCriteria": [
            "Active transfers stay within limit",
            "Failures release slots",
            "One device retry cannot starve all others"
          ],
          "implementationNotes": [
            "Cohort fixtures contain synthetic device IDs only."
          ],
          "verification": [
            "Update small cohort",
            "Fail one transfer repeatedly"
          ],
          "deliverables": [
            "Download scheduler and fairness cases"
          ],
          "rollout": "Reduce concurrency to one while queue behavior is repaired.",
          "skills": [
            "Scheduling",
            "Resource management"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            },
            {
              "field": "Networking",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "fbe52a33-002e-4e60-89eb-8fd0d29ffd45",
          "key": "CUPDATE-110",
          "title": "Report edge-update stages without overstating fleet success",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "fleet",
          "dependsOn": [
            "CUPDATE-107",
            "CUPDATE-109"
          ],
          "scenario": "Dashboard counts downloaded images as updated kiosks. Project download, staged, boot-pending, healthy and rolled-back separately.",
          "acceptanceCriteria": [
            "Healthy requires committed boot confirmation",
            "Rollback remains visible",
            "Unknown outcomes are not counted successful"
          ],
          "implementationNotes": [
            "Reports describe simulator outcomes, not real-device certification."
          ],
          "verification": [
            "Complete one simulated update",
            "Interrupt another before boot confirmation"
          ],
          "deliverables": [
            "Update status report and consistency checks"
          ],
          "rollout": "Hide aggregate success if per-device authority is unresolved.",
          "skills": [
            "Reporting",
            "State projection"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "fc961195-1ba7-4119-b205-e6722681c911",
      "key": "CCONFIG",
      "title": "Versioned edge configuration with an offline gateway",
      "field": "Embedded and edge",
      "summary": "Deliver and acknowledge bounded synthetic configuration changes through a local gateway emulator.",
      "context": "Fictional information-display gateways receive brightness schedules and cache limits. These settings affect only a software display emulator; no real devices, safety controls or customer data are used.",
      "stack": [
        "TypeScript",
        "Gateway emulator",
        "SQLite adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Define synthetic configuration schema and supported device capabilities.",
        "Implement local control-plane and gateway adapters with delayed messages."
      ],
      "developerValue": "Practice desired/reported state, compatibility and rollback.",
      "companyValue": "Inspect whether remote configuration preserves working settings through offline and partial outcomes.",
      "delivery": "Deliver local simulation changes; hardware validation and external fleet deployment are excluded.",
      "phases": [
        {
          "id": "schema",
          "title": "Specify configuration contracts",
          "goal": "Validate and scope desired settings."
        },
        {
          "id": "apply",
          "title": "Apply settings deliberately",
          "goal": "Handle revisions and partial failures."
        },
        {
          "id": "reconcile",
          "title": "Recover gateway state",
          "goal": "Explain offline drift and bound retries."
        }
      ],
      "tickets": [
        {
          "id": "dc211255-33b3-4696-a153-49d500f51bd6",
          "key": "CCONFIG-101",
          "title": "Validate emulated display brightness and cache-limit settings",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "schema",
          "dependsOn": [],
          "scenario": "The gateway accepts negative cache capacity and brightness above the declared range. Add a bounded schema.",
          "acceptanceCriteria": [
            "Supported ranges pass",
            "Unknown fields reject",
            "Invalid settings do not alter active state"
          ],
          "implementationNotes": [
            "Schema limits are emulator contracts, not hardware ratings."
          ],
          "verification": [
            "Apply valid fixture values",
            "Reject negative and oversized settings"
          ],
          "deliverables": [
            "Configuration schema and cases"
          ],
          "rollout": "Reject incoming updates if schema validation fails.",
          "skills": [
            "Validation",
            "Configuration"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ce445f01-07d2-45a2-935f-600b848d2c3c",
          "key": "CCONFIG-102",
          "title": "Keep desired and reported edge configuration separate",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "schema",
          "dependsOn": [
            "CCONFIG-101"
          ],
          "scenario": "Sending a setting immediately changes the dashboard to Applied before the gateway responds. Store separate desired and reported revisions.",
          "acceptanceCriteria": [
            "Sending changes desired state",
            "Acknowledgement changes reported state",
            "Mismatch appears as pending drift"
          ],
          "implementationNotes": [
            "Delivery is not application acknowledgement."
          ],
          "verification": [
            "Send then acknowledge",
            "Drop delivery and inspect drift"
          ],
          "deliverables": [
            "State model and projection cases"
          ],
          "rollout": "Stop displaying Applied when acknowledgement is absent.",
          "skills": [
            "State modeling",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "0996f722-ed58-4687-9dda-dacdb6027fdf",
          "key": "CCONFIG-103",
          "title": "Scope emulated gateway configuration reads by organization",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "schema",
          "dependsOn": [
            "CCONFIG-101",
            "CCONFIG-102"
          ],
          "scenario": "A guessed gateway ID exposes another organization's desired settings. Enforce tenant scope at repository lookup.",
          "acceptanceCriteria": [
            "Owner reads permitted gateway",
            "Foreign lookup is denied",
            "Denied response omits settings"
          ],
          "implementationNotes": [
            "Synthetic gateway IDs never establish authority alone."
          ],
          "verification": [
            "Read own fixture",
            "Read foreign gateway by known ID"
          ],
          "deliverables": [
            "Scoped repository and denial cases"
          ],
          "rollout": "Disable configuration reads when ownership cannot be verified.",
          "skills": [
            "Authorization",
            "Tenancy"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c8b0ec59-db0c-4020-9f1c-38557fcd0a9f",
          "key": "CCONFIG-104",
          "title": "Reject stale configuration revisions arriving at the edge gateway",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 165,
          "phaseId": "apply",
          "dependsOn": [
            "CCONFIG-102",
            "CCONFIG-103"
          ],
          "scenario": "Delayed delivery overwrites a newer brightness schedule. Compare monotonic desired revisions before applying.",
          "acceptanceCriteria": [
            "Newer revision may apply",
            "Older revision is rejected",
            "Equal matching revision replays safely"
          ],
          "implementationNotes": [
            "Reused revision with different payload is a conflict."
          ],
          "verification": [
            "Deliver increasing revisions",
            "Deliver old or conflicting revision"
          ],
          "deliverables": [
            "Revision guard and ordering cases"
          ],
          "rollout": "Request a fresh authoritative snapshot on conflict.",
          "skills": [
            "Ordering",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ebf7ed24-0496-4538-b4c8-3e18c6f2f134",
          "key": "CCONFIG-105",
          "title": "Stage edge settings before committing a complete configuration",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "apply",
          "dependsOn": [
            "CCONFIG-101",
            "CCONFIG-104"
          ],
          "scenario": "Applying brightness succeeds while cache settings fail, leaving an undocumented mixed state. Validate and stage the complete supported configuration.",
          "acceptanceCriteria": [
            "All fields validate before mutation",
            "Commit selects one complete revision",
            "Failure retains prior active revision"
          ],
          "implementationNotes": [
            "This ticket assumes reversible emulator setters; document that boundary."
          ],
          "verification": [
            "Apply valid full revision",
            "Inject failure during staging"
          ],
          "deliverables": [
            "Staged apply protocol and failure cases"
          ],
          "rollout": "Restore previous configuration if staging cannot remain isolated.",
          "skills": [
            "Transactions",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2fc22cf1-6f8b-4aa3-9b5d-4d57434afc6c",
          "key": "CCONFIG-106",
          "title": "Reject edge settings unsupported by the declared gateway capability version",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "apply",
          "dependsOn": [
            "CCONFIG-104",
            "CCONFIG-105"
          ],
          "scenario": "Older gateway emulators silently ignore new settings while reporting success. Check capability compatibility explicitly.",
          "acceptanceCriteria": [
            "Supported configuration applies",
            "Unsupported fields report incompatibility",
            "Reported revision does not advance on rejection"
          ],
          "implementationNotes": [
            "Do not infer capability from device display names."
          ],
          "verification": [
            "Apply to compatible fixture",
            "Apply new field to older capability"
          ],
          "deliverables": [
            "Compatibility check and cases"
          ],
          "rollout": "Keep existing revision on unsupported gateways.",
          "skills": [
            "Compatibility",
            "Versioning"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ca23fbd7-56da-4fa4-9cb4-d75ecf2ac255",
          "key": "CCONFIG-107",
          "title": "Persist edge-configuration acknowledgement after active settings commit",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "apply",
          "dependsOn": [
            "CCONFIG-105",
            "CCONFIG-106"
          ],
          "scenario": "A crash after applying settings but before reporting leaves the control plane uncertain and repeated applies inconsistent. Reconcile local active revision on restart.",
          "acceptanceCriteria": [
            "Active revision persists with settings",
            "Restart can replay acknowledgement",
            "Uncommitted settings cannot be reported applied"
          ],
          "implementationNotes": [
            "Define commit ordering in the local adapter."
          ],
          "verification": [
            "Crash after settings commit",
            "Crash before commit"
          ],
          "deliverables": [
            "Apply journal and restart cases"
          ],
          "rollout": "Pause new applies until active-state reconciliation completes.",
          "skills": [
            "Crash recovery",
            "Durability"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 40
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "991ce377-7274-4bf4-ac0b-2de42fcaded8",
          "key": "CCONFIG-108",
          "title": "Coalesce offline edge configuration deliveries to the latest eligible revision",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "reconcile",
          "dependsOn": [
            "CCONFIG-104",
            "CCONFIG-107"
          ],
          "scenario": "A gateway reconnects to hundreds of obsolete brightness changes. Deliver the latest complete eligible snapshot deliberately.",
          "acceptanceCriteria": [
            "Obsolete pending revisions are superseded",
            "Latest revision remains auditable",
            "Required transition constraints are checked"
          ],
          "implementationNotes": [
            "Coalescing is permitted only for this replaceable configuration contract."
          ],
          "verification": [
            "Reconnect after several revisions",
            "Include incompatible latest revision"
          ],
          "deliverables": [
            "Offline delivery planner and cases"
          ],
          "rollout": "Send an explicit full snapshot if coalescing cannot prove eligibility.",
          "skills": [
            "Reconciliation",
            "Queue design"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Embedded and edge",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ab2219a4-7d12-4ef8-b433-1e17bf62300f",
          "key": "CCONFIG-109",
          "title": "Expose edge-configuration rollback as a new desired revision",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "reconcile",
          "dependsOn": [
            "CCONFIG-106",
            "CCONFIG-108"
          ],
          "scenario": "Operators lower the revision number to restore older values and gateways reject it as stale. Create a new revision carrying the prior values.",
          "acceptanceCriteria": [
            "Rollback increments revision",
            "Prior values are copied explicitly",
            "Current capability validation still applies"
          ],
          "implementationNotes": [
            "Preserve original revision history."
          ],
          "verification": [
            "Roll back supported values",
            "Attempt rollback containing now-unsupported field"
          ],
          "deliverables": [
            "Rollback command and history cases"
          ],
          "rollout": "Retain current settings if rollback validation fails.",
          "skills": [
            "Versioning",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Embedded and edge",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "683cf607-bf31-439e-a0b3-85ec4d097e89",
          "key": "CCONFIG-110",
          "title": "Summarize edge-configuration drift without logging setting payloads",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 105,
          "phaseId": "reconcile",
          "dependsOn": [
            "CCONFIG-107",
            "CCONFIG-109"
          ],
          "scenario": "Drift diagnosis logs full configuration documents unnecessarily. Report revision gaps and typed rejection reasons.",
          "acceptanceCriteria": [
            "Summary shows desired and reported revisions",
            "Payload values are omitted",
            "Offline uncertainty is explicit"
          ],
          "implementationNotes": [
            "Use aggregate synthetic fleet observations only."
          ],
          "verification": [
            "Inspect converged gateway",
            "Inspect offline and incompatible gateways"
          ],
          "deliverables": [
            "Drift report and data-exclusion cases"
          ],
          "rollout": "Disable detailed diagnostics if configuration values leak.",
          "skills": [
            "Observability",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Embedded and edge",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "2e825222-0287-42c2-8b11-53751e8dc421",
      "key": "PLATENCY",
      "title": "Find the missing seconds in the quote API",
      "summary": "Explain and reduce quote latency under a mixed workload without weakening pricing correctness.",
      "context": "A fictional freight broker sees slow quote responses at dispatch handover. The service looks healthy in average-latency charts, yet a few long requests occupy every worker. Build a small synthetic quote service and controlled dependency stub before taking implementation tickets.",
      "stack": [
        "TypeScript",
        "Node.js",
        "PostgreSQL",
        "OpenTelemetry",
        "k6"
      ],
      "prerequisites": [
        "Create a local quote endpoint and a deterministic carrier-price stub; no repository or dataset is supplied.",
        "Use synthetic routes and a fixed workload manifest. Record runtime, machine resources and instrumentation settings."
      ],
      "developerValue": "Learn to distinguish queueing, dependency delay, CPU work and measurement mistakes using reproducible observations.",
      "companyValue": "Produce a reviewable diagnosis and guarded changes that could guide a team investigating customer-visible latency.",
      "delivery": "Ten tickets in three phases. Estimates assume the local service and generator already exist; all load runs stay in the owned local environment. Budgets are exercise requirements, not measured platform results.",
      "phases": [
        {
          "id": "observe",
          "title": "Establish trustworthy measurements",
          "goal": "Define the traffic shape and separate time spent waiting from time spent working."
        },
        {
          "id": "isolate",
          "title": "Remove demonstrated bottlenecks",
          "goal": "Change one constrained path at a time while checking exact quote outputs."
        },
        {
          "id": "release",
          "title": "Protect the improvement",
          "goal": "Use tail-aware admission and a reversible release gate."
        }
      ],
      "field": "Performance engineering",
      "tickets": [
        {
          "id": "0a2afd0d-53b7-4703-9809-5103abc53e6b",
          "key": "PLATENCY-101",
          "title": "Write down the traffic mix before comparing quote timings",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "observe",
          "dependsOn": [],
          "scenario": "The last benchmark sent one route repeatedly. Dispatch says the slow period contains mostly unique routes and a small number of expensive multi-stop quotes.",
          "acceptanceCriteria": [
            "Create a seeded mix of 70% single-stop, 25% multi-stop and 5% invalid requests across 1,000 synthetic routes.",
            "Record concurrency, arrival rate, seed, payload sizes, runtime and resource limits in the run manifest.",
            "Count every attempted request, including validation failures and client timeouts, against the expected result class."
          ],
          "implementationNotes": [
            "Keep the fixture bounded; random seeds must reproduce both request order and expected quote inputs."
          ],
          "verification": [
            "Replay the same seed twice and compare request identities and expected outputs.",
            "Change the seed and confirm the traffic proportions stay within the declared rounding rule."
          ],
          "deliverables": [
            "Workload manifest and deterministic request generator"
          ],
          "rollout": "Commit the baseline manifest separately; a workload change starts a new comparison series.",
          "skills": [
            "Workload modeling",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0d17d498-ff4c-4758-9150-256f1cd5dbc3",
          "key": "PLATENCY-102",
          "title": "Show quote latency percentiles alongside rejected and timed-out requests",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "observe",
          "dependsOn": [
            "PLATENCY-101"
          ],
          "scenario": "The dashboard median improves when the slowest requests time out and disappear from successful-response measurements.",
          "acceptanceCriteria": [
            "Report p50, p95 and p99 with sample counts for completed requests, and separate timeout, rejection and transport-error counts.",
            "State the observation window and histogram precision; do not average percentiles across workers.",
            "Keep route identifiers, customer IDs and quote payloads out of metric labels."
          ],
          "implementationNotes": [
            "Use bounded result-class labels and merge histogram counts before computing aggregate percentiles."
          ],
          "verification": [
            "Replay a fixture with known short, long and timed-out requests and reconcile all attempts.",
            "Compare merged-worker results with the same samples processed in one worker, within the declared histogram precision."
          ],
          "deliverables": [
            "Latency dashboard definition and aggregation regression fixture"
          ],
          "rollout": "Run the new view beside the existing chart for the synthetic workload; keep raw counters if rendering is reverted.",
          "skills": [
            "Metrics",
            "Latency distributions"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "600e7dbd-d7ec-4981-b0b0-b838ac8639ed",
          "key": "PLATENCY-103",
          "title": "Separate quote queue time from carrier lookup time",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "observe",
          "dependsOn": [
            "PLATENCY-101"
          ],
          "scenario": "A trace labels the entire request as carrier latency, but the stub returns quickly when called outside the API.",
          "acceptanceCriteria": [
            "Record monotonic durations for admission wait, application work and carrier lookup with one request correlation identifier.",
            "Make the phase durations reconcile with total server duration within documented instrumentation overhead.",
            "Record cancellation and missing-span states explicitly instead of inventing zero-duration work."
          ],
          "implementationNotes": [
            "Do not put route payloads or credentials into spans; use a bounded synthetic request identifier for this exercise."
          ],
          "verification": [
            "Inject 100 ms of queue delay and verify it appears outside the carrier span.",
            "Cancel a queued request and confirm the trace distinguishes waiting from a lookup that never started."
          ],
          "deliverables": [
            "Span boundaries and an annotated trace from the controlled stub"
          ],
          "rollout": "Enable sampling locally first; disable extra spans independently if instrumentation changes the measured workload.",
          "skills": [
            "Tracing",
            "Queueing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "00e1a598-b523-44a2-965d-f19546b29b1e",
          "key": "PLATENCY-104",
          "title": "Remove repeated tariff parsing from the quote hot path",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "isolate",
          "dependsOn": [
            "PLATENCY-101",
            "PLATENCY-103"
          ],
          "scenario": "A CPU profile shows every quote parsing the same tariff document, including requests that use the same immutable tariff revision.",
          "acceptanceCriteria": [
            "Parse once per tariff revision and cap retained revisions with an explicit eviction policy.",
            "Keep quote totals and rounding behavior identical to the uncached path for the seeded fixture.",
            "Reject a malformed new revision without replacing the last valid parsed tariff."
          ],
          "implementationNotes": [
            "Measure before and after with the same revision distribution; do not cache request-specific discounts in the shared tariff object."
          ],
          "verification": [
            "Compare every synthetic quote against the uncached implementation across two valid revisions.",
            "Alternate malformed and valid revisions, then force eviction and verify both bounded memory and correct reparsing."
          ],
          "deliverables": [
            "Profile comparison, bounded parsed-tariff cache and regression tests"
          ],
          "rollout": "Gate parsed-tariff reuse behind a switch; reverting uses the original parser and discards only derived cache entries.",
          "skills": [
            "CPU profiling",
            "Cache invalidation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "06afe288-897d-40a0-9dd4-446c48dc4503",
          "key": "PLATENCY-105",
          "title": "Stop expired quotes from holding carrier connections",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "isolate",
          "dependsOn": [
            "PLATENCY-102",
            "PLATENCY-103"
          ],
          "scenario": "A client disconnects after its deadline, but the carrier lookup continues and consumes one of the few available connections.",
          "acceptanceCriteria": [
            "Propagate the remaining deadline through queue admission and the carrier client.",
            "Release the connection and remove queued work when the request is cancelled, including cancellation before dispatch.",
            "Return one bounded timeout outcome without automatically retrying a request whose caller has left."
          ],
          "implementationNotes": [
            "Use the stub to control headers, body completion and connection close separately; wall-clock sleeps alone do not prove cleanup."
          ],
          "verification": [
            "Cancel before dispatch, while waiting for headers and during a streamed response; count active work returning to baseline.",
            "Race normal completion against cancellation and confirm one response classification and no unhandled rejection."
          ],
          "deliverables": [
            "Deadline propagation and deterministic cancellation tests"
          ],
          "rollout": "Canary the deadline path with active-connection counters; restore the previous client only after pending work drains.",
          "skills": [
            "Cancellation",
            "Resource lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Networking",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b7c066b4-1ed2-4072-a170-257242fe4c1e",
          "key": "PLATENCY-106",
          "title": "Bound parallel carrier lookups without serializing every quote",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "isolate",
          "dependsOn": [
            "PLATENCY-101",
            "PLATENCY-105"
          ],
          "scenario": "Multi-stop quotes fan out immediately. A burst exhausts the carrier stub connection pool and slows unrelated single-stop traffic.",
          "acceptanceCriteria": [
            "Apply a configurable global in-flight limit and a bounded admission queue.",
            "Remove cancelled entries promptly and define fairness so a large quote cannot monopolize all new slots.",
            "Preserve the required carrier results or return an explicit incomplete-quote outcome; never silently price from a partial result."
          ],
          "implementationNotes": [
            "Compare limits using the fixed traffic mix and a stub with a declared service-time distribution."
          ],
          "verification": [
            "Run single-stop and multi-stop requests together and verify the configured concurrency ceiling.",
            "Overfill the queue, cancel its head and inject a carrier failure; verify forward progress and no leaked permit."
          ],
          "deliverables": [
            "Admission controller, mixed-traffic measurements and permit invariants"
          ],
          "rollout": "Start with the current safe connection limit; queue rejection is observable and the feature switch restores the previous dispatch path.",
          "skills": [
            "Concurrency control",
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "07d1b067-5c79-4e01-a56e-8bebd6ed1ee3",
          "key": "PLATENCY-107",
          "title": "Check whether quote serialization is blocking unrelated requests",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "isolate",
          "dependsOn": [
            "PLATENCY-101",
            "PLATENCY-103"
          ],
          "scenario": "The largest multi-stop responses correlate with event-loop delay. The team has proposed adding workers before confirming where time is spent.",
          "acceptanceCriteria": [
            "Capture CPU and event-loop delay measurements for small and maximum-size synthetic quote responses.",
            "Separate JSON serialization cost from database and dependency time in the experiment.",
            "Produce a decision note identifying the measured bottleneck, uncertainty and one bounded next change; report when the hypothesis is unsupported."
          ],
          "implementationNotes": [
            "Use three repeated baseline runs after warmup on the same runtime and resource limits; save the measurement commands."
          ],
          "verification": [
            "Repeat with a prebuilt response body to isolate serialization while retaining the same payload size.",
            "Run a small health request concurrently and compare its tail latency with and without the large-response workload."
          ],
          "deliverables": [
            "Reproducible profiling report and supported next-step decision"
          ],
          "rollout": "This investigation changes no serving path; retain the baseline commands for the implementation review.",
          "skills": [
            "Profiling",
            "Experimental design"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "ef36060e-64e7-4bdd-bc48-6e949a361070",
          "key": "PLATENCY-108",
          "title": "Choose an overload policy from the quote deadline budget",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "release",
          "dependsOn": [
            "PLATENCY-102",
            "PLATENCY-105",
            "PLATENCY-106"
          ],
          "scenario": "At overload, a larger queue increases completed work but most quotes arrive after the dispatch screen has already given up.",
          "acceptanceCriteria": [
            "Compare at least two admission policies at 0.5, 1.0 and 1.5 times the measured sustainable arrival rate.",
            "Evaluate deadline success rate, rejection rate, p99 and queue depth together; document the selected tradeoff.",
            "Implement the selected bounded policy and retain exact pricing correctness for every admitted request."
          ],
          "implementationNotes": [
            "Use an open-loop arrival schedule and account for generator saturation; define sustainable rate from the recorded local baseline, not a guessed production number."
          ],
          "verification": [
            "Run three repetitions per load level after fixed warmup and publish spread, request counts and all timeout outcomes.",
            "Inject a carrier slowdown midway through a run and show queue depth remains bounded and recovery does not require restart."
          ],
          "deliverables": [
            "Admission decision record, load results and overload recovery regression"
          ],
          "rollout": "Canary against the declared deadline-success guardrail; revert policy configuration if correctness or rejection behavior differs from the approved contract.",
          "skills": [
            "Capacity planning",
            "Tail latency",
            "Load testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "77d79dd2-3bda-4eb2-9cdb-a5fa887cc121",
          "key": "PLATENCY-109",
          "title": "Make the quote benchmark fail when the generator cannot keep up",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "release",
          "dependsOn": [
            "PLATENCY-101",
            "PLATENCY-102"
          ],
          "scenario": "A promising result came from a generator sharing the API CPU quota. It slowed its own arrivals and reported a workload the service never received.",
          "acceptanceCriteria": [
            "Record scheduled versus actual send time and count requests the generator could not issue.",
            "Invalidate comparisons when dispatch lag exceeds the manifest threshold or achieved load falls below the declared tolerance.",
            "Keep server and generator resource measurements distinguishable even when both run on one development machine."
          ],
          "implementationNotes": [
            "Document the local topology and quota allocation; do not require a paid load-testing service."
          ],
          "verification": [
            "Throttle the generator deliberately and verify the run is rejected as incomparable.",
            "Run a valid low-load fixture and reconcile planned, sent, completed and failed request totals."
          ],
          "deliverables": [
            "Generator health gate and an intentionally invalid benchmark sample"
          ],
          "rollout": "Add the gate to the local benchmark command before accepting further performance comparisons.",
          "skills": [
            "Benchmark validity",
            "Load generation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "89dcf11d-aaff-4001-838f-3201ca47d6a3",
          "key": "PLATENCY-110",
          "title": "Gate quote changes on repeated tail-latency and correctness checks",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "release",
          "dependsOn": [
            "PLATENCY-104",
            "PLATENCY-106",
            "PLATENCY-108",
            "PLATENCY-109"
          ],
          "scenario": "The team can demonstrate one fast run, but it has no rule for accepting noisy results or reverting a change that prices correctly only at low concurrency.",
          "acceptanceCriteria": [
            "Use the fixed workload and three paired runs after warmup; report all runs and median p99 with spread.",
            "For this exercise require unchanged fixture outputs, no higher timeout rate and at least 15% lower median p99 at the declared baseline arrival rate.",
            "Mark an unstable or generator-invalid result inconclusive and stop promotion; retain the prior configuration and a documented rollback command."
          ],
          "implementationNotes": [
            "The 15% threshold is an exercise acceptance budget on the declared machine, not a universal performance promise."
          ],
          "verification": [
            "Run the candidate and baseline in alternating order and retain raw histograms and output comparisons.",
            "Introduce a known pricing regression and a deliberately slow candidate separately; both must block the release gate for the relevant reason."
          ],
          "deliverables": [
            "Repeatable release check, run artifacts and rollback rehearsal notes"
          ],
          "rollout": "Promote only within the synthetic environment after the gate passes; restore the previous configuration and repeat the same workload to verify recovery.",
          "skills": [
            "Performance regression",
            "Release verification"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "e9d0551d-7419-432e-947d-50e5387b3f13",
      "key": "PQUERY",
      "title": "Keep the operations inbox fast as history grows",
      "summary": "Tune a tenant-scoped PostgreSQL inbox using plans, representative distributions and reversible changes.",
      "context": "A fictional maintenance service lists open work orders beside years of closed history. A query that was cheap in a small demo now scans far more rows than it returns. Recreate the schema and synthetic workload locally; no customer database or supplied fixture is assumed.",
      "stack": [
        "PostgreSQL",
        "SQL",
        "TypeScript",
        "pg_stat_statements"
      ],
      "prerequisites": [
        "Create an isolated local database with tenants, work orders and assignment history.",
        "Seed 200,000 synthetic work orders with documented skew and a repeatable random seed; record PostgreSQL version, settings and resource limits."
      ],
      "developerValue": "Practice reading execution plans, balancing read and write cost, and validating performance without weakening tenant boundaries.",
      "companyValue": "Create reproducible query diagnostics and reversible index or query proposals for an operational application.",
      "delivery": "Ten tickets from workload definition to guarded migration. Estimates exclude database setup and predecessor tickets; all destructive data fixtures remain local and synthetic.",
      "phases": [
        {
          "id": "baseline",
          "title": "Reproduce the slow inbox",
          "goal": "Make skew, query behavior and baseline measurements inspectable."
        },
        {
          "id": "tune",
          "title": "Change the expensive paths",
          "goal": "Reduce unnecessary reads while preserving filter, ordering and authorization semantics."
        },
        {
          "id": "guard",
          "title": "Check write cost and deployment behavior",
          "goal": "Choose a supported improvement and rehearse its migration and rollback."
        }
      ],
      "field": "Performance engineering",
      "tickets": [
        {
          "id": "c93946e4-c4ea-4a15-ad08-a200a122ddf1",
          "key": "PQUERY-101",
          "title": "Seed an inbox where one tenant owns most of the closed history",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "The existing fixture spreads rows evenly across tenants. It cannot reproduce the large account whose open-work view is slow.",
          "acceptanceCriteria": [
            "Seed 200,000 rows across 100 tenants with one tenant owning 60% of rows and documented open/closed ratios.",
            "Include tied creation times, unassigned work and tenants with no matching rows.",
            "Generate deterministic expected inbox IDs for named filter and ordering cases."
          ],
          "implementationNotes": [
            "Keep tenant identities fictitious and use a manifest so row counts and skew are explicit."
          ],
          "verification": [
            "Rebuild from the same seed and compare per-tenant counts and expected inbox results.",
            "Run the empty-tenant and timestamp-tie cases and verify a deterministic order."
          ],
          "deliverables": [
            "Seed generator, distribution summary and expected-result fixtures"
          ],
          "rollout": "Load only a disposable development database; make the rebuild command reject an unrecognized database target.",
          "skills": [
            "Synthetic datasets",
            "SQL"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d2f744ef-8f09-4053-9bfc-6695907b27d6",
          "key": "PQUERY-102",
          "title": "Capture buffer reads and row estimates for the slow inbox query",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "PQUERY-101"
          ],
          "scenario": "The ticket says the query takes seconds but contains no plan, parameters or indication of whether the cache was warm.",
          "acceptanceCriteria": [
            "Save EXPLAIN ANALYZE with buffers for the large, median and empty tenant fixtures.",
            "Record query parameters, statistics freshness, cache-warmup procedure and database resource settings.",
            "Identify estimate-versus-actual row differences and time-consuming nodes without claiming a fix from plan shape alone."
          ],
          "implementationNotes": [
            "Use SELECT-only plans here; running ANALYZE on mutating statements would execute them."
          ],
          "verification": [
            "Repeat each parameter case three times after the declared warmup and report all durations.",
            "Verify the captured query returns the fixture IDs from the baseline contract."
          ],
          "deliverables": [
            "Annotated plans and reproducible capture command"
          ],
          "rollout": "Keep the baseline artifacts unchanged when evaluating candidate queries; new fixture revisions get new run labels.",
          "skills": [
            "Execution plans",
            "Measurement"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "149520ab-ea32-4694-9413-635139c3061b",
          "key": "PQUERY-103",
          "title": "Count hidden assignment queries made by one inbox request",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "baseline",
          "dependsOn": [
            "PQUERY-101"
          ],
          "scenario": "The main SQL query is quick, but the API loads the latest assignee separately for every visible work order.",
          "acceptanceCriteria": [
            "Record the query count for page sizes 1, 20 and 100 without storing raw tenant payloads in logs.",
            "Add a request-level assertion exposing query growth proportional to returned rows.",
            "Preserve assignment ordering, including equal timestamps and work orders with no history."
          ],
          "implementationNotes": [
            "Instrument the local database client boundary so lazy ORM loads are counted as well as explicit queries."
          ],
          "verification": [
            "Request all three page sizes and compare total database calls.",
            "Use a work order with multiple assignment records and verify the selected assignee matches the documented tie-breaker."
          ],
          "deliverables": [
            "Query-count regression and assignment fixture"
          ],
          "rollout": "Enable detailed counting in the local investigation only; retain a bounded aggregate if instrumentation is later adapted for deployment.",
          "skills": [
            "N+1 diagnosis",
            "ORM behavior"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "64ae1231-84de-443c-9165-2b34f6f1be9c",
          "key": "PQUERY-104",
          "title": "Batch latest-assignee lookup for the current inbox page",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "tune",
          "dependsOn": [
            "PQUERY-102",
            "PQUERY-103"
          ],
          "scenario": "Fetching one assignee per work order makes latency increase with page size even after the main inbox query is tuned.",
          "acceptanceCriteria": [
            "Resolve assignments in a bounded number of queries independent of page size up to 100.",
            "Preserve tenant scope in every lookup and return one deterministic latest assignment per visible work order.",
            "Return identical response data to the baseline fixture, including missing assignments."
          ],
          "implementationNotes": [
            "Compare a batched lookup and a lateral or window-query alternative; record the chosen tradeoff using the seeded distribution."
          ],
          "verification": [
            "Compare complete responses and query counts for page sizes 1, 20 and 100.",
            "Inject a foreign-tenant assignment ID into the request fixture and verify it cannot be returned."
          ],
          "deliverables": [
            "Batched implementation, response equivalence tests and query-count results"
          ],
          "rollout": "Switch the lookup path independently; revert to the previous implementation if equivalence or tenant checks fail.",
          "skills": [
            "Query design",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "b24a4a9d-abdc-42d9-a75d-4fbfea5d2920",
          "key": "PQUERY-105",
          "title": "Evaluate a partial index for open work without slowing closure updates",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "tune",
          "dependsOn": [
            "PQUERY-101",
            "PQUERY-102"
          ],
          "scenario": "Only a small fraction of work orders remain open. A broad index makes the open inbox faster but adds substantial storage and maintenance cost.",
          "acceptanceCriteria": [
            "Compare the current plan with at least one partial index aligned with the actual open-state predicate and order.",
            "Measure index size, inbox latency and update throughput for work moving into and out of the indexed state.",
            "Keep the candidate only if its read benefit and write tradeoff satisfy explicitly stated exercise budgets."
          ],
          "implementationNotes": [
            "Use three paired runs on the same synthetic data and settings; do not force index use or disable planner options to manufacture a result."
          ],
          "verification": [
            "Run open, closed and mixed-state filters and verify both result equivalence and selected plans.",
            "Close and reopen a fixed batch while reading the inbox; report lock waits, write duration and index size."
          ],
          "deliverables": [
            "Index decision record, migration draft and comparative measurements"
          ],
          "rollout": "Apply the index in the isolated database first; the rollback drops only the added index and preserves all work-order data.",
          "skills": [
            "Indexing",
            "Read/write tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "1c29710e-8ef0-4ee5-ab11-353c848386f2",
          "key": "PQUERY-106",
          "title": "Replace deep offset paging with a stable inbox cursor",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "tune",
          "dependsOn": [
            "PQUERY-101",
            "PQUERY-102"
          ],
          "scenario": "An operator reaches old open work through hundreds of pages. Each offset request scans and discards an increasing number of matching rows.",
          "acceptanceCriteria": [
            "Use a stable sort tuple with a unique tie-breaker and an opaque versioned cursor.",
            "Bind the cursor to the tenant and filter contract; reject mismatched or malformed cursors.",
            "Document concurrent-insert behavior and preserve a bounded page size without promising a snapshot across requests."
          ],
          "implementationNotes": [
            "Measure shallow and deep page requests against the same fixture; keep the response contract explicit for clients migrating from offsets."
          ],
          "verification": [
            "Traverse the unchanged fixture and compare all returned IDs with the expected sorted set without duplicates or omissions.",
            "Insert a tied-timestamp row between requests and test the documented behavior; reject a cursor from another tenant."
          ],
          "deliverables": [
            "Cursor contract, implementation and depth-comparison report"
          ],
          "rollout": "Offer the cursor route as an explicit version and migrate the local client behind a switch; retain the offset route during rehearsal.",
          "skills": [
            "Pagination",
            "Query performance"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6b8fafaf-dd3d-4015-92ce-6f75d78ce455",
          "key": "PQUERY-107",
          "title": "Explain the bad prepared plan used for the largest tenant",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "tune",
          "dependsOn": [
            "PQUERY-101",
            "PQUERY-102",
            "PQUERY-105"
          ],
          "scenario": "The same prepared inbox statement serves tiny tenants and the dominant tenant. A plan that works for one distribution performs poorly for the other.",
          "acceptanceCriteria": [
            "Reproduce the plan difference with documented preparation and execution sequences.",
            "Compare statistics correction, query restructuring and bounded per-query planning choices; select a justified option.",
            "Keep tenant scope and result ordering unchanged, and document planning overhead as part of the decision."
          ],
          "implementationNotes": [
            "Do not change a global planner setting as an unexplained workaround; record the exact PostgreSQL version because planning behavior matters."
          ],
          "verification": [
            "Alternate large and small tenant executions across repeated sessions and retain planning plus execution measurements.",
            "Rebuild statistics after a distribution change and verify the selected solution remains correct or clearly flags an invalid baseline."
          ],
          "deliverables": [
            "Prepared-plan reproduction and a supported mitigation with regression cases"
          ],
          "rollout": "Limit any configuration change to the affected query path; remove it and restore the baseline query if small-tenant latency breaches its budget.",
          "skills": [
            "Query planning",
            "Data skew"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3850f93e-fd71-4f66-ab9c-f88e4fc04c00",
          "key": "PQUERY-108",
          "title": "Rehearse the inbox index migration while writes continue",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "guard",
          "dependsOn": [
            "PQUERY-105"
          ],
          "scenario": "The proposed index works after a clean restore. Nobody has checked what happens when creation is interrupted while the application is updating work orders.",
          "acceptanceCriteria": [
            "Run the migration with a bounded concurrent write fixture and record locks and write failures.",
            "Detect an interrupted or invalid index and define an idempotent retry procedure.",
            "Provide an explicit rollback that does not remove an index belonging to another migration."
          ],
          "implementationNotes": [
            "Use PostgreSQL-supported online index operations with their transaction restrictions; record commands and ownership checks in the runbook."
          ],
          "verification": [
            "Interrupt index creation in the disposable database, inspect its state and exercise recovery.",
            "Compare work-order counts and IDs before and after migration, retry and rollback while the write fixture runs."
          ],
          "deliverables": [
            "Migration, interruption rehearsal and operator recovery notes"
          ],
          "rollout": "Require the local concurrent-write rehearsal before proposing deployment; stop if lock duration or data reconciliation violates the stated budget.",
          "skills": [
            "Database migrations",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 10
            }
          ],
          "patterns": []
        },
        {
          "id": "a447fb87-a48d-46db-a62c-1395756cbdf7",
          "key": "PQUERY-109",
          "title": "Keep performance fixtures useful after the inbox schema changes",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "guard",
          "dependsOn": [
            "PQUERY-101",
            "PQUERY-104",
            "PQUERY-106"
          ],
          "scenario": "A new nullable column changed the seed loader. The benchmark still completes, but most rows now take a cheap fallback path that users rarely see.",
          "acceptanceCriteria": [
            "Validate row counts, state distributions, null ratios and assignment fan-out before a run.",
            "Reject fixtures whose version or invariants do not match the query comparison manifest.",
            "Retain representative expected responses so a faster wrong query cannot pass."
          ],
          "implementationNotes": [
            "Express fixture invariants separately from the query implementation; avoid asserting only that SQL returns some rows."
          ],
          "verification": [
            "Deliberately skew null ratios and remove assignment history; the fixture gate must report both changes.",
            "Regenerate the approved fixture and run the same checks successfully without hand-edited counts."
          ],
          "deliverables": [
            "Fixture-validation command and schema-change procedure"
          ],
          "rollout": "Run validation before every benchmark; invalid data stops comparison and is rebuilt in the disposable database.",
          "skills": [
            "Regression fixtures",
            "Data validation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "bff7ea37-a75c-4696-85bb-b6088d15d13f",
          "key": "PQUERY-110",
          "title": "Publish the inbox query decision with both latency and write cost",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "guard",
          "dependsOn": [
            "PQUERY-104",
            "PQUERY-106",
            "PQUERY-107",
            "PQUERY-108",
            "PQUERY-109"
          ],
          "scenario": "The review has several attractive charts but no single explanation of which changes should ship together or what would trigger rollback.",
          "acceptanceCriteria": [
            "Compare baseline and candidate with three paired warmed runs at fixed concurrency, reporting p95, p99, query count and buffer reads.",
            "For the exercise require at least 20% lower median p95 for the dominant-tenant open view, no more than 10% loss in closure-update throughput and exact fixture equivalence.",
            "List the retained and rejected changes, noisy or inconclusive cases, migration order and rollback triggers."
          ],
          "implementationNotes": [
            "These relative thresholds are local exercise gates; report all repetitions and do not claim production improvement from synthetic results."
          ],
          "verification": [
            "Run both large and median tenant workloads alongside the closure-update fixture.",
            "Rehearse rollback and rerun correctness plus the baseline workload to confirm recovery is understood."
          ],
          "deliverables": [
            "Query-performance decision, raw run results and migration handoff"
          ],
          "rollout": "Advance only the documented candidate within the exercise environment; keep previous query and index definitions available for a bounded rollback.",
          "skills": [
            "Performance evaluation",
            "Engineering tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "932216f7-640e-4a54-8e90-40a3d812dd51",
      "key": "PWEB",
      "title": "Make a large scheduling screen respond to the next click",
      "summary": "Investigate browser loading, rendering and interaction costs while preserving usable scheduling workflows.",
      "context": "A fictional repair coordinator opens a week containing 2,000 jobs. The initial page loads, but filtering and selecting a job can freeze the interface. Build a synthetic scheduling screen with keyboard operation before measuring changes.",
      "stack": [
        "TypeScript",
        "React",
        "CSS Modules",
        "Playwright",
        "Browser Performance API"
      ],
      "prerequisites": [
        "Create a local schedule UI with 2,000 synthetic jobs, long labels, empty results and deterministic responses.",
        "Record browser version, viewport, device emulation, CPU/network throttling and build mode for every comparison."
      ],
      "developerValue": "Connect bundle, rendering and interaction measurements to user-visible behavior without losing accessibility.",
      "companyValue": "Produce a bounded performance investigation and regression workflow for dense operational interfaces.",
      "delivery": "Ten tickets across measurement, implementation and regression phases. Lab timings apply only to the documented local browser setup; field-user performance is not inferred.",
      "phases": [
        {
          "id": "measure",
          "title": "Capture the slow interactions",
          "goal": "Record repeatable navigation and interaction traces with correct results."
        },
        {
          "id": "improve",
          "title": "Reduce avoidable browser work",
          "goal": "Change loading and rendering paths while preserving navigation and assistive-technology behavior."
        },
        {
          "id": "sustain",
          "title": "Guard responsiveness",
          "goal": "Cover memory, interrupted work and regression budgets in a repeatable browser check."
        }
      ],
      "field": "Performance engineering",
      "tickets": [
        {
          "id": "051d4b8e-4108-4694-86df-527da501464c",
          "key": "PWEB-101",
          "title": "Record the schedule workflow that freezes after filtering",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "measure",
          "dependsOn": [],
          "scenario": "The issue report says the screen feels slow. Developers reproduce it with different data and disagree about which interaction is responsible.",
          "acceptanceCriteria": [
            "Define a deterministic sequence: load 2,000 jobs, filter by technician, select the final visible job and clear the filter.",
            "Record build mode, browser version, viewport and any throttling alongside trace timestamps.",
            "Assert the selected job and final result count so an incomplete interaction cannot appear fast."
          ],
          "implementationNotes": [
            "Use only synthetic names and job descriptions; record navigation and interaction phases separately."
          ],
          "verification": [
            "Replay the sequence twice and confirm identical selected IDs and result counts.",
            "Run with an empty technician result and verify the sequence reports that expected state rather than timing an absent control."
          ],
          "deliverables": [
            "Browser workflow fixture and annotated baseline trace"
          ],
          "rollout": "Keep the baseline workflow versioned before changing the page; fixture changes invalidate direct timing comparisons.",
          "skills": [
            "Browser profiling",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "2ea40150-782a-43d7-a60d-e18c6c05617b",
          "key": "PWEB-102",
          "title": "Identify which schedule code is shipped before the first interaction",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "measure",
          "dependsOn": [
            "PWEB-101"
          ],
          "scenario": "The screen downloads export and map code before the user opens either feature. The team needs sizes and dependency paths before splitting bundles.",
          "acceptanceCriteria": [
            "Report transferred and parsed script sizes for the production build with cache state recorded.",
            "Identify the dependency paths for export and map features and their actual use in the baseline workflow.",
            "Separate first-load transfers from subsequent navigation and avoid adding compressed sizes to uncompressed sizes."
          ],
          "implementationNotes": [
            "Use local build artifacts and browser network records; do not compare development bundles with production output."
          ],
          "verification": [
            "Capture cold-cache and warm-cache navigation separately.",
            "Open the export and map features after baseline load and verify which additional resources are requested."
          ],
          "deliverables": [
            "Bundle inventory and a justified split proposal"
          ],
          "rollout": "This ticket changes no loading behavior; preserve the measured build identifier for the implementation comparison.",
          "skills": [
            "Bundle analysis",
            "Network loading"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f3cf9b8b-5c55-4fba-aa93-d06127c8819a",
          "key": "PWEB-103",
          "title": "Measure long tasks caused by filtering rather than counting renders alone",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "measure",
          "dependsOn": [
            "PWEB-101"
          ],
          "scenario": "A render counter improved after memoization, but typing still stalls because sorting and formatting happen before React commits.",
          "acceptanceCriteria": [
            "Record input-event start, result commit and long-task observations around the filter workflow.",
            "Attribute measured time to filtering, sorting, rendering and layout where supported; label gaps as unknown.",
            "Keep measurements bounded and remove observers when the screen is left."
          ],
          "implementationNotes": [
            "A lab interaction duration is not a claim about field Core Web Vitals; name the measured boundary explicitly."
          ],
          "verification": [
            "Inject a known synchronous filter delay and verify it appears in the recorded interaction.",
            "Navigate away and back repeatedly and confirm only one active observer set remains."
          ],
          "deliverables": [
            "Interaction measurement helper and trace interpretation notes"
          ],
          "rollout": "Enable the helper only for the local profiling build; detach it without changing application behavior.",
          "skills": [
            "Main-thread work",
            "Instrumentation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "121eb091-931c-41d9-9f09-65e6724581e1",
          "key": "PWEB-104",
          "title": "Load the schedule export code when export is requested",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "improve",
          "dependsOn": [
            "PWEB-102"
          ],
          "scenario": "The spreadsheet export dependency adds work to every schedule visit even though the baseline user never exports.",
          "acceptanceCriteria": [
            "Move export-only code behind an explicit load boundary and preserve the generated file contents.",
            "Show a keyboard-accessible loading state and prevent duplicate export starts while the module loads.",
            "Handle module-load failure with a retry action without losing selected filters."
          ],
          "implementationNotes": [
            "Compare initial transfer and parse work in the same production build configuration; do not defer code required to display the schedule."
          ],
          "verification": [
            "Verify the initial workflow makes no export-module request, then trigger export and compare the file with the baseline fixture.",
            "Fail the module request once and confirm retry succeeds with the original filter state."
          ],
          "deliverables": [
            "Deferred export implementation, network comparison and failure regression"
          ],
          "rollout": "Keep a loading-boundary switch in the exercise; revert to eager loading if export compatibility fails.",
          "skills": [
            "Code splitting",
            "Failure states"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "836709ef-eb4b-46e5-9e98-93fdfabb1a65",
          "key": "PWEB-105",
          "title": "Render only the visible schedule rows without losing keyboard position",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 270,
          "phaseId": "improve",
          "dependsOn": [
            "PWEB-101",
            "PWEB-103"
          ],
          "scenario": "Every filter mounts hundreds of offscreen job rows. A first virtualization attempt is faster but drops focus when the selected row scrolls away.",
          "acceptanceCriteria": [
            "Bound mounted rows by viewport and overscan while retaining stable job identity.",
            "Define and implement keyboard movement, focus restoration and accessible row position information.",
            "Support long wrapped labels and the empty state without overlapping rows or selecting a different job after filtering."
          ],
          "implementationNotes": [
            "Document the chosen virtualization semantics and test with zoom and a narrow viewport; do not hide all nonvisible records from search without an explicit alternative."
          ],
          "verification": [
            "Traverse beyond the initial viewport with the keyboard, filter the selected row out and verify the declared focus behavior.",
            "Measure mounted nodes and interaction duration at 200 and 2,000 jobs while checking the selected job ID."
          ],
          "deliverables": [
            "Bounded row rendering, accessibility checks and before/after traces"
          ],
          "rollout": "Gate virtualization independently; reverting renders the full list while preserving selected IDs and filter state.",
          "skills": [
            "Rendering performance",
            "Accessible interaction"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "Accessibility",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "07fbda9b-1a86-4ce2-b53f-4dbdbb22a93f",
          "key": "PWEB-106",
          "title": "Reuse formatted job data only while its inputs remain unchanged",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "improve",
          "dependsOn": [
            "PWEB-103"
          ],
          "scenario": "Date and duration formatting dominates repeated filters. A broad memoization patch reuses labels after the schedule time zone changes.",
          "acceptanceCriteria": [
            "Cache or precompute expensive formatting with all relevant inputs, including locale and time zone, in the invalidation rule.",
            "Bound retained derived data and remove entries for jobs no longer present.",
            "Keep visible labels identical to the uncached formatter across updates and daylight-saving boundary fixtures."
          ],
          "implementationNotes": [
            "Measure formatting calls and interaction time together; memoization alone is not evidence of a useful improvement."
          ],
          "verification": [
            "Change the time zone and job start time independently, comparing every visible label with the baseline formatter.",
            "Replace the dataset repeatedly and check that retained derived entries stay within the declared bound."
          ],
          "deliverables": [
            "Derived-data cache, invalidation regressions and profiling comparison"
          ],
          "rollout": "Disable derived-data reuse through one path if stale labels appear; the original formatter remains the reference behavior.",
          "skills": [
            "Memoization",
            "Invalidation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5ec679ad-812d-4ff5-9615-acb8c8584bfe",
          "key": "PWEB-107",
          "title": "Let a new filter supersede expensive work already in progress",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "improve",
          "dependsOn": [
            "PWEB-101",
            "PWEB-103",
            "PWEB-105"
          ],
          "scenario": "Fast typing schedules several expensive filter computations. Results from an earlier query briefly replace the latest selection and consume time after they are irrelevant.",
          "acceptanceCriteria": [
            "Choose a bounded scheduling or worker strategy and explain why it fits the measured bottleneck.",
            "Publish results only for the current dataset and query revision; discard superseded work safely.",
            "Preserve responsive keyboard input and a clear pending state without moving focus or showing stale result counts."
          ],
          "implementationNotes": [
            "If using a worker, include transfer/serialization cost in the comparison and terminate it when the screen unmounts."
          ],
          "verification": [
            "Complete an older query after a newer query and verify only current results appear.",
            "Type and clear rapidly while replacing the dataset, then inspect responsiveness, final IDs and worker or task cleanup.",
            "Repeat baseline and selected-strategy runs three times under the same recorded browser workload; compare input-latency distributions and long-task counts, including worker transfer and serialization overhead when applicable."
          ],
          "deliverables": [
            "Scheduling decision, implementation and out-of-order completion tests"
          ],
          "rollout": "Canary the alternate filter path locally; reverting cancels its work and restores synchronous filtering with the same query state.",
          "skills": [
            "Scheduling",
            "Concurrency correctness"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "a0f4d22e-6a0e-47ab-97c5-323e1372ce05",
          "key": "PWEB-108",
          "title": "Find retained job rows after repeated schedule navigation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "sustain",
          "dependsOn": [
            "PWEB-105",
            "PWEB-107"
          ],
          "scenario": "The screen starts responsive and degrades after operators open and close it throughout a shift. Detached rows remain reachable through subscriptions.",
          "acceptanceCriteria": [
            "Identify a reproducible retention path using repeated mount, interaction and unmount cycles.",
            "Release listeners, workers and subscriptions owned by the screen without cancelling shared application resources.",
            "Define a post-cleanup retained-object bound on the declared browser and distinguish temporary allocation from a leak."
          ],
          "implementationNotes": [
            "Use heap snapshots and retaining paths; do not claim a leak from one process-memory sample."
          ],
          "verification": [
            "Run 20 navigation cycles and inspect retained job objects after the same cleanup procedure at each checkpoint.",
            "Navigate away during a pending filter and verify no late update, leaked listener or unhandled exception."
          ],
          "deliverables": [
            "Retention diagnosis, lifecycle fix and repeatable memory check"
          ],
          "rollout": "Revert only the offending optimization if cleanup cannot be demonstrated; keep the regression cycle in the local suite.",
          "skills": [
            "Memory profiling",
            "Resource cleanup"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e3c17fe1-bc7b-4077-b1ee-91f938847ae2",
          "key": "PWEB-109",
          "title": "Make the schedule performance run include slow devices and empty results",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "sustain",
          "dependsOn": [
            "PWEB-101",
            "PWEB-104",
            "PWEB-105"
          ],
          "scenario": "The fastest desktop run became the benchmark. It misses the narrow layout and empty-filter transition used by coordinators on older laptops.",
          "acceptanceCriteria": [
            "Define two repeatable local profiles with explicit viewport, throttling and cache state.",
            "Run nonempty, empty and large-label workflows and assert visual state plus selected identity.",
            "Separate trace artifacts by profile and build revision; invalid runs report failure instead of a zero timing."
          ],
          "implementationNotes": [
            "Emulation defines an exercise profile, not a claim to reproduce every physical device."
          ],
          "verification": [
            "Execute both profiles three times with a fixed warmup rule and retain all measurements.",
            "Remove a required result element deliberately and confirm the run fails its correctness check before reporting success."
          ],
          "deliverables": [
            "Browser profile matrix and repeatable benchmark command"
          ],
          "rollout": "Use both profiles in local release review; revise profiles only with a recorded reason and a new baseline.",
          "skills": [
            "Performance testing",
            "Browser automation"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d4707980-8df9-4c48-ba7a-ad7ae4a293c3",
          "key": "PWEB-110",
          "title": "Approve schedule optimizations only when the measured interaction improves",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "sustain",
          "dependsOn": [
            "PWEB-104",
            "PWEB-105",
            "PWEB-106",
            "PWEB-107",
            "PWEB-108",
            "PWEB-109"
          ],
          "scenario": "Several changes reduced different counters. The team needs a release decision tied to the actual filter-and-select workflow and its accessibility contract.",
          "acceptanceCriteria": [
            "Compare three paired runs per declared profile and require at least 20% lower median filter-to-result duration on the constrained profile.",
            "Require unchanged selected IDs, keyboard behavior and empty-state behavior, with no increase beyond 10% in initial transferred script bytes.",
            "Report all timings, spread, retained-object observations and inconclusive results; document which changes are included and why."
          ],
          "implementationNotes": [
            "The numerical budgets apply only to this fixture and lab profile. Preserve raw traces so reviewers can assess attribution and noise."
          ],
          "verification": [
            "Run the complete workflow against baseline and candidate in alternating order.",
            "Revert the combined candidate and verify both functional behavior and measured baseline recovery under the same profiles."
          ],
          "deliverables": [
            "Release decision, paired trace bundle and rollback rehearsal"
          ],
          "rollout": "Promote the chosen combination only after the exercise gates pass; keep each optimization independently reversible where state compatibility permits.",
          "skills": [
            "Performance budgets",
            "Release decisions"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Accessibility",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "5ae7dc5a-eb3b-4e8b-8a2f-dffda17fb2de",
      "key": "PBATCH",
      "title": "Import a large supplier catalog without exhausting the worker",
      "summary": "Make a bounded catalog import stream, recover and report progress under explicit resource limits.",
      "context": "A fictional wholesaler imports supplier rows into a staging catalog. The current prototype reads the entire file into memory and restarts from zero after a failure. Build the prototype and generated CSV fixture locally before measuring improvements.",
      "stack": [
        "TypeScript",
        "Node.js streams",
        "PostgreSQL",
        "CSV"
      ],
      "prerequisites": [
        "Generate a deterministic 250,000-row synthetic CSV with quoted newlines, invalid records and a stated maximum record size.",
        "Create a disposable staging database and an import process constrained to 256 MiB; record runtime and available CPU."
      ],
      "developerValue": "Practice streaming, backpressure, allocation analysis and resumable work while retaining exact import semantics.",
      "companyValue": "Develop a repeatable import performance and recovery exercise that exposes memory, throughput and data-quality tradeoffs.",
      "delivery": "Ten tickets in three phases. All data and failures are locally generated; throughput targets are relative to the declared baseline and do not imply a production service-level guarantee.",
      "phases": [
        {
          "id": "characterize",
          "title": "Define input and resource behavior",
          "goal": "Establish a representative file and honest end-to-end measurements."
        },
        {
          "id": "stream",
          "title": "Bound the import pipeline",
          "goal": "Control buffering and write work without dropping or duplicating records."
        },
        {
          "id": "operate",
          "title": "Recover and verify",
          "goal": "Resume safely, report useful progress and gate throughput improvements."
        }
      ],
      "field": "Performance engineering",
      "tickets": [
        {
          "id": "c80696ed-e263-44af-b91f-17ea4c4cd20e",
          "key": "PBATCH-101",
          "title": "Generate a catalog file that includes difficult CSV boundaries",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "characterize",
          "dependsOn": [],
          "scenario": "The demonstration file has one short record per line. It cannot expose parsers that split quoted descriptions or allocate one enormous record.",
          "acceptanceCriteria": [
            "Generate 250,000 deterministic rows including quoted delimiters, embedded newlines, multibyte text and declared invalid cases.",
            "Publish expected accepted/rejected counts and a digest of normalized accepted records.",
            "Declare a maximum record size and include an intentionally oversized record in a separate failure fixture."
          ],
          "implementationNotes": [
            "Use invented supplier identifiers and descriptions; fixture generation must not require a downloaded customer file."
          ],
          "verification": [
            "Regenerate with the same seed and compare file digest and expected counts.",
            "Parse with a reference implementation and verify quoted newlines do not change record boundaries."
          ],
          "deliverables": [
            "Fixture generator, manifest and expected normalized digest"
          ],
          "rollout": "Version the fixture before profiling; keep the oversized fixture separate so the normal baseline has a defined completion result.",
          "skills": [
            "CSV contracts",
            "Synthetic data"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "d60b7c84-d0c8-4007-be0a-feaa375640f8",
          "key": "PBATCH-102",
          "title": "Measure peak import memory across parsing, validation and writes",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "characterize",
          "dependsOn": [
            "PBATCH-101"
          ],
          "scenario": "The worker exits near the end of an import, but the existing memory sample is taken only after garbage collection and misses the peak.",
          "acceptanceCriteria": [
            "Record process RSS, managed heap, buffered-record count and stage throughput at a fixed documented sampling interval.",
            "Report peak values and exit outcome, including resource-limit termination.",
            "Separate input-read completion from database-commit completion in elapsed time."
          ],
          "implementationNotes": [
            "Document sampling limitations and resource limits; do not report a killed run as a completed low-memory run."
          ],
          "verification": [
            "Run the whole-file baseline and retain its peak or termination outcome.",
            "Inject a slow writer and verify the timeline shows buffered work accumulating before completion."
          ],
          "deliverables": [
            "Resource timeline and baseline measurement command"
          ],
          "rollout": "Keep measurement output outside imported data; retain failed-run artifacts for the streaming comparison.",
          "skills": [
            "Memory measurement",
            "Pipeline profiling"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6e1eb2db-8f56-4d4d-8a71-cbe69bd221db",
          "key": "PBATCH-103",
          "title": "Attribute import time to parsing, validation and database waits",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "characterize",
          "dependsOn": [
            "PBATCH-101",
            "PBATCH-102"
          ],
          "scenario": "A proposal to increase database concurrency assumes writes dominate, but expensive normalization may already saturate one CPU core.",
          "acceptanceCriteria": [
            "Measure stage service time and time blocked on downstream capacity separately.",
            "Compare parse-only, parse-plus-validation and complete-import runs using the same input.",
            "Reconcile accepted and rejected records between stages and identify the supported bottleneck hypothesis."
          ],
          "implementationNotes": [
            "Use bounded aggregate timing rather than one log entry per record, which would alter the measured workload."
          ],
          "verification": [
            "Inject a known validation delay and show its contribution in the stage report.",
            "Inject writer delay instead and confirm it appears as downstream wait rather than parser CPU time."
          ],
          "deliverables": [
            "Stage comparison report and aggregate instrumentation"
          ],
          "rollout": "Use the instrumentation in local benchmarks first; disable it independently if overhead makes comparisons unreliable.",
          "skills": [
            "Bottleneck analysis",
            "Instrumentation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ad86adb6-2274-4dcd-9277-1388401c7a98",
          "key": "PBATCH-104",
          "title": "Stream records without buffering the rest of the catalog",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "stream",
          "dependsOn": [
            "PBATCH-101",
            "PBATCH-102",
            "PBATCH-103"
          ],
          "scenario": "Switching to a streaming file reader did not reduce memory because validation still accumulates every parsed row before writing starts.",
          "acceptanceCriteria": [
            "Connect reading, parsing, validation and writing through bounded buffers with downstream backpressure.",
            "Reject an oversized record explicitly without allowing unbounded parser accumulation.",
            "Preserve normalized accepted-record digest and rejection reasons from the baseline fixture."
          ],
          "implementationNotes": [
            "Express buffer bounds in records and bytes where record sizes vary; a stream API alone does not establish bounded memory."
          ],
          "verification": [
            "Pause the writer and assert parser progress stops within the declared buffering bound.",
            "Split quoted multibyte records across small input chunks and compare complete results with the reference fixture."
          ],
          "deliverables": [
            "Streaming pipeline, buffer invariants and peak-memory comparison"
          ],
          "rollout": "Keep the whole-file implementation only as a small-fixture reference; stop and retain the source file if the streaming result digest differs.",
          "skills": [
            "Streaming",
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "613477c9-a754-4375-ab8d-2f6e21052b62",
          "key": "PBATCH-105",
          "title": "Batch staging writes without changing duplicate-SKU behavior",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "stream",
          "dependsOn": [
            "PBATCH-104"
          ],
          "scenario": "Single-row inserts dominate after streaming is introduced. A bulk-insert experiment is faster but resolves duplicate supplier SKUs differently.",
          "acceptanceCriteria": [
            "Document duplicate-SKU ordering and preserve it across batch boundaries.",
            "Cap batch rows and serialized bytes, with bounded transaction duration.",
            "Return deterministic accepted/rejected outcomes when one batch includes invalid or conflicting records."
          ],
          "implementationNotes": [
            "Compare at least three bounded batch sizes on the fixed fixture; do not choose the largest solely from one fast run."
          ],
          "verification": [
            "Place duplicate SKUs on either side of a batch boundary and compare normalized results with the reference behavior.",
            "Inject a write failure midway through a batch and verify the declared atomicity and retry outcome."
          ],
          "deliverables": [
            "Batched writer, batch-size measurements and duplicate regressions"
          ],
          "rollout": "Canary in staging with batch size configurable; reducing it must preserve semantics and allow work to continue from a valid checkpoint.",
          "skills": [
            "Batching",
            "Transaction semantics"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3faa0be0-16a5-4755-bc9f-5e4367b6807e",
          "key": "PBATCH-106",
          "title": "Stop validation workers from creating an unbounded reorder queue",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "stream",
          "dependsOn": [
            "PBATCH-103",
            "PBATCH-104",
            "PBATCH-105"
          ],
          "scenario": "Parallel validation improves throughput until one slow record delays output. Later completed records accumulate while the writer waits for order.",
          "acceptanceCriteria": [
            "Define a bounded in-flight window and preserve required source ordering without retaining unlimited completed work.",
            "Propagate cancellation and fatal validation failure through every active stage.",
            "Select worker concurrency from repeated measurements that include serialization and coordination overhead."
          ],
          "implementationNotes": [
            "If the measured validation stage is not CPU-bound, document that result and retain a simpler bounded path instead of adding workers without benefit."
          ],
          "verification": [
            "Delay the first record while later records complete and assert both in-flight and retained-result bounds.",
            "Fail one worker during the import and verify controlled shutdown, deterministic checkpoint state and no silent record loss."
          ],
          "deliverables": [
            "Concurrency decision, bounded ordering implementation and fault tests"
          ],
          "rollout": "Keep a single-worker configuration available; drain or cancel active work before changing concurrency during a rehearsal.",
          "skills": [
            "Parallel processing",
            "Ordering",
            "Memory bounds"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "9256487d-229e-4393-89f2-30a7e0ac9c62",
          "key": "PBATCH-107",
          "title": "Report import progress from committed records instead of bytes read",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "operate",
          "dependsOn": [
            "PBATCH-104",
            "PBATCH-105"
          ],
          "scenario": "The UI reaches 100% while thousands of records are still queued for the database. Operators assume they can close the import.",
          "acceptanceCriteria": [
            "Expose bytes consumed, records accepted/rejected, committed records and terminal state as separate counters.",
            "Mark completion only after all accepted records are committed and final reconciliation succeeds.",
            "Avoid a remaining-time promise when throughput is unstable; report an unknown estimate explicitly."
          ],
          "implementationNotes": [
            "Keep progress updates throttled and monotonic within one attempt; resumed attempts must disclose their checkpoint origin."
          ],
          "verification": [
            "Pause the final write and verify the import remains nonterminal despite input exhaustion.",
            "Inject rejection and retry cases and reconcile counters with the final staging contents."
          ],
          "deliverables": [
            "Progress contract and end-of-input regression"
          ],
          "rollout": "Introduce the progress fields before changing the UI completion rule; retain committed counters if the display is reverted.",
          "skills": [
            "Progress reporting",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 40
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "10743c54-223f-4a0f-a4ea-9ddd53e0c09a",
          "key": "PBATCH-108",
          "title": "Resume an interrupted catalog import from a committed checkpoint",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "PBATCH-104",
            "PBATCH-105",
            "PBATCH-107"
          ],
          "scenario": "An import loses its process after several committed batches. Restarting from a byte offset inside a quoted multiline record corrupts the next batch.",
          "acceptanceCriteria": [
            "Bind checkpoints to source digest, parser configuration and import identity.",
            "Checkpoint only a valid record boundary whose writes are committed, with an explicit idempotency rule for uncertain completion.",
            "Reject a changed source or configuration and preserve the previous import for inspection."
          ],
          "implementationNotes": [
            "A raw newline is not a CSV record boundary. State whether resumption seeks to a validated boundary or replays and skips already committed record identities."
          ],
          "verification": [
            "Terminate after commit but before checkpoint acknowledgement, resume and compare the final digest with an uninterrupted import.",
            "Change one source byte and attempt resumption; no additional staging writes may occur."
          ],
          "deliverables": [
            "Checkpoint protocol, resume implementation and interruption matrix"
          ],
          "rollout": "Enable resumption only after the failure matrix passes; retain the source and last valid checkpoint when recovery is refused.",
          "skills": [
            "Checkpointing",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Data engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "1d4eda25-2403-4a60-ae0c-401a49e647dc",
          "key": "PBATCH-109",
          "title": "Prove temporary import resources disappear after cancellation",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "operate",
          "dependsOn": [
            "PBATCH-104",
            "PBATCH-106",
            "PBATCH-108"
          ],
          "scenario": "Cancelled imports leave temporary files and open connections. A subsequent run inherits resource pressure and appears slower for an unrelated reason.",
          "acceptanceCriteria": [
            "Define ownership and cleanup for temporary files, file descriptors, workers and database connections.",
            "Cancel safely at read, validation and commit stages while preserving the last valid recovery checkpoint.",
            "Make repeated cancellation safe and keep the source fixture intact."
          ],
          "implementationNotes": [
            "Check resource inventories before and after; avoid asserting cleanup from a completion message alone."
          ],
          "verification": [
            "Cancel at each controlled stage and verify owned resources return to the declared baseline.",
            "Run cancellation twice, then resume or start a fresh import and confirm correct results without restarting the environment."
          ],
          "deliverables": [
            "Cleanup implementation, resource inventory and cancellation regressions"
          ],
          "rollout": "Run cleanup rehearsal before accepting performance results; quarantine uncertain staging state for explicit recovery rather than deleting it silently.",
          "skills": [
            "Resource lifecycle",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bcf0fe31-b169-442d-a494-4a20848247ec",
          "key": "PBATCH-110",
          "title": "Set a throughput gate that also enforces import memory and correctness",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "PBATCH-105",
            "PBATCH-106",
            "PBATCH-108",
            "PBATCH-109"
          ],
          "scenario": "The fastest batch configuration exceeds the worker memory budget and fails on interrupted runs. Throughput alone is selecting the wrong candidate.",
          "acceptanceCriteria": [
            "Run three paired baseline/candidate comparisons with the same source, database state and resource limits.",
            "Require completion within the 256 MiB process budget, exact normalized digest and at least 20% higher median committed-record throughput than a completing baseline.",
            "If the whole-file baseline cannot complete, report that fact and compare throughput against a documented completing bounded baseline; never calculate improvement from a killed run."
          ],
          "implementationNotes": [
            "Include reset and warmup procedures, peaks, repetitions and recovery observations in the report; the budgets are local exercise conditions."
          ],
          "verification": [
            "Run normal and slow-writer fixtures and publish all memory peaks and completion outcomes.",
            "Repeat the commit/checkpoint interruption case with the chosen batch and concurrency settings, then verify final digest and resource cleanup."
          ],
          "deliverables": [
            "Performance gate, raw measurements and chosen operating configuration"
          ],
          "rollout": "Promote only the configuration satisfying every gate in the synthetic environment; restore the prior bounded configuration if memory or recovery regresses.",
          "skills": [
            "Performance budgets",
            "Data integrity"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "0dce159a-d7f5-41f9-8a92-a36a34e76367",
      "key": "PCACHE",
      "title": "Keep product availability caching correct during a traffic spike",
      "summary": "Measure cache value, prevent refill storms and bound staleness without hiding origin failures.",
      "context": "A fictional equipment-rental service caches availability summaries. A campaign sends repeated reads, while stock updates and shared expiry times create bursts against the origin. Build a local origin stub and cache-backed read API using synthetic depots and products.",
      "stack": [
        "TypeScript",
        "Redis",
        "HTTP",
        "k6"
      ],
      "prerequisites": [
        "Create a deterministic local availability origin and Redis-backed reader with synthetic tenant, depot and product data.",
        "Use a seeded hot-key distribution and controlled time; record cache capacity, TTLs, runtime and machine limits."
      ],
      "developerValue": "Learn to evaluate caching through avoided work, bounded staleness, concurrency and recovery rather than hit rate alone.",
      "companyValue": "Produce a reviewable cache policy and failure exercise for a read-heavy service with changing business data.",
      "delivery": "Ten tickets in three phases. Availability is informational; booking remains an authoritative origin operation. All load and failure experiments use owned local services.",
      "phases": [
        {
          "id": "model",
          "title": "Define cache meaning and baseline",
          "goal": "Specify keys, freshness and measurements before optimization."
        },
        {
          "id": "control",
          "title": "Bound cache work and staleness",
          "goal": "Handle simultaneous misses, updates and failure without serving another tenant or hiding stale data."
        },
        {
          "id": "recover",
          "title": "Validate degraded and release behavior",
          "goal": "Exercise cache loss, policy changes and measurable promotion gates."
        }
      ],
      "field": "Performance engineering",
      "tickets": [
        {
          "id": "02a941ba-09b0-4aad-b909-cd250c648ffb",
          "key": "PCACHE-101",
          "title": "Specify which availability responses may be reused",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Two requests for the same product receive different answers because depot and tenant affect availability. The prototype cache key contains only the product ID.",
          "acceptanceCriteria": [
            "Include tenant, depot, product and response-schema version in an unambiguous cache-key contract.",
            "State the maximum informational freshness window and keep booking decisions on the authoritative origin.",
            "Define which errors and absence responses are cacheable, with a separate bounded lifetime where appropriate."
          ],
          "implementationNotes": [
            "Use opaque synthetic identifiers and avoid leaking sensitive request values through diagnostic key labels."
          ],
          "verification": [
            "Request the same product from two depots and tenants and verify no shared response.",
            "Construct delimiter-collision inputs and confirm distinct semantic keys remain distinct."
          ],
          "deliverables": [
            "Cache-key and freshness contract with boundary fixtures"
          ],
          "rollout": "Introduce a new key namespace for the contract; expiry cleans old derived entries without rewriting authoritative availability.",
          "skills": [
            "Cache semantics",
            "Tenant isolation"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "164eced6-74a0-4fcd-81e8-8a49d1d7979c",
          "key": "PCACHE-102",
          "title": "Measure saved origin work instead of celebrating the hit ratio",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [
            "PCACHE-101"
          ],
          "scenario": "The cache reports a high hit ratio, but every hit still triggers a synchronous origin validation and costs almost as much as a miss.",
          "acceptanceCriteria": [
            "Record hits, misses, stale responses, origin calls, origin work duration and end-to-end request latency separately.",
            "Use bounded labels and report the same workload window and request counts for all rates.",
            "Define avoided origin calls against an uncached run of the identical seeded requests."
          ],
          "implementationNotes": [
            "Do not combine cache and origin error outcomes into successful hits; expose failures and retries explicitly."
          ],
          "verification": [
            "Replay a repeated-key fixture and reconcile request count with cache outcomes and actual stub calls.",
            "Enable synchronous validation deliberately and verify the report reveals that high hit rate did not remove origin work."
          ],
          "deliverables": [
            "Cache effectiveness report and aggregate counters"
          ],
          "rollout": "Run counters beside the existing local behavior before policy changes; preserve raw attempt counts for comparisons.",
          "skills": [
            "Cache measurement",
            "Latency analysis"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "1fe083b2-747b-435f-9201-fe47d7b33e6a",
          "key": "PCACHE-103",
          "title": "Create a hot-key workload that exposes synchronized expiry",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "model",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-102"
          ],
          "scenario": "Uniform random keys miss often but never reproduce the traffic surge that arrives when the most popular products expire together.",
          "acceptanceCriteria": [
            "Generate a seeded workload where 80% of reads target 20 hot product/depot keys and the remainder sample a larger declared set.",
            "Include a synchronized-expiry phase, a cold start and a quiet recovery period.",
            "Record scheduled and achieved arrivals, timeouts and origin concurrency so generator saturation is visible."
          ],
          "implementationNotes": [
            "Use a controllable clock for unit-level expiry cases and a documented arrival schedule for load runs."
          ],
          "verification": [
            "Repeat the seed and compare key frequencies and expiry schedule.",
            "Run the uncached and cached paths against the same origin-delay fixture and retain all outcome counts."
          ],
          "deliverables": [
            "Hot-key generator and baseline workload manifest"
          ],
          "rollout": "Version the workload independently of cache implementation; changing the distribution starts a new comparison baseline.",
          "skills": [
            "Workload design",
            "Load testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 80
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "6c00414d-61f7-41e8-ad01-4c1b8b9bdb73",
          "key": "PCACHE-104",
          "title": "Coalesce simultaneous availability misses for one key",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "control",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-103"
          ],
          "scenario": "Hundreds of requests miss the same just-expired key and each starts an identical origin read.",
          "acceptanceCriteria": [
            "Share one bounded in-flight fill per semantic key within the declared process scope.",
            "Give each waiter its own deadline and release the in-flight entry on success, failure and cancellation.",
            "Keep different tenants and keys independent, and document that process-local coalescing does not coordinate multiple instances."
          ],
          "implementationNotes": [
            "Use a deterministic origin latch to prove fan-in; a fast origin can hide duplicate concurrent fills in a timing-only test."
          ],
          "verification": [
            "Release 100 simultaneous same-key reads and verify one origin fill with identical successful results.",
            "Cancel some waiters and fail the fill; verify remaining outcomes, cleanup and a successful subsequent retry."
          ],
          "deliverables": [
            "Single-flight implementation and concurrency/failure regressions"
          ],
          "rollout": "Gate coalescing locally; disabling it preserves the same freshness contract and drains existing waiters before removing entries.",
          "skills": [
            "Request coalescing",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0413ca4f-f697-42fe-9f4c-25d5b60e9bc4",
          "key": "PCACHE-105",
          "title": "Spread cache refill times without extending the freshness ceiling",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-103"
          ],
          "scenario": "A bulk warmup writes every popular key with the same lifetime. They expire in one wave and overload the origin.",
          "acceptanceCriteria": [
            "Apply bounded expiry variation that never exceeds the declared maximum freshness window.",
            "Make the randomness injectable for repeatable tests and preserve explicit short-lived negative-cache policy.",
            "Report refill concurrency before and after under the synchronized-expiry fixture."
          ],
          "implementationNotes": [
            "Define whether jitter shortens lifetime or schedules refresh earlier; do not silently extend a business freshness bound."
          ],
          "verification": [
            "Generate many lifetimes with a fixed seed and verify all are positive and within the contractual ceiling.",
            "Replay the warmup/expiry workload and compare peak origin concurrency while checking response ages."
          ],
          "deliverables": [
            "Expiry policy, deterministic boundary tests and refill comparison"
          ],
          "rollout": "Roll out the new expiry policy only for newly written entries; reverting changes future writes while existing entries remain within the original ceiling.",
          "skills": [
            "Expiry policies",
            "Traffic smoothing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "3023627c-74b0-44f3-832a-10c5f94d3626",
          "key": "PCACHE-106",
          "title": "Serve stale availability only within an explicit degraded-read policy",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "control",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-102",
            "PCACHE-104"
          ],
          "scenario": "During a short origin outage the cache can show useful recent information, but the prototype serves old availability indefinitely and presents it as current.",
          "acceptanceCriteria": [
            "Define fresh, stale-but-allowed and expired states with explicit age limits and response metadata.",
            "Choose bounded background refresh behavior and retain authoritative booking checks.",
            "After the hard age limit, return an explicit unavailable outcome rather than an apparently current availability summary."
          ],
          "implementationNotes": [
            "The policy concerns informational reads only. Preserve origin-error visibility and do not cache authorization failures as product absence."
          ],
          "verification": [
            "Advance the clock across both boundaries during origin success and failure, checking age metadata and result state.",
            "Run concurrent stale reads with a blocked refresh and verify bounded origin work and transition to unavailable after the hard limit."
          ],
          "deliverables": [
            "Freshness state machine, degraded-read implementation and boundary matrix"
          ],
          "rollout": "Canary with response-age and stale-outcome counters; disable stale serving immediately if clients fail to present the declared state.",
          "skills": [
            "Freshness modeling",
            "Graceful degradation"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ba777e5b-971a-410d-854d-c0284ffea4c2",
          "key": "PCACHE-107",
          "title": "Prevent a delayed refill from restoring availability older than an update",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "control",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-104",
            "PCACHE-106"
          ],
          "scenario": "An origin read starts before a stock update, then finishes after invalidation and writes the old value back into the cache.",
          "acceptanceCriteria": [
            "Associate fills and updates with an explicit revision or generation rule.",
            "Reject an obsolete fill after a newer invalidation or value is known within the chosen coordination scope.",
            "Document behavior when invalidation delivery is delayed and preserve the hard freshness ceiling as a backstop."
          ],
          "implementationNotes": [
            "Use atomic cache operations where a check-and-set race matters; explain limits across multiple readers rather than claiming perfect global freshness."
          ],
          "verification": [
            "Hold an old origin response, apply a newer update, then release it and verify the cached revision does not go backward.",
            "Repeat the sequence with duplicate invalidations and a cache reconnect; verify the declared recovery behavior and age bound."
          ],
          "deliverables": [
            "Revision protocol, race regression and coordination-limit note"
          ],
          "rollout": "Introduce the revisioned namespace gradually; on uncertainty discard derived cache state and use the bounded origin path.",
          "skills": [
            "Race conditions",
            "Cache invalidation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8a9a9049-ba50-4b07-a590-fab2e5742ce7",
          "key": "PCACHE-108",
          "title": "Keep origin traffic bounded when the cache becomes unavailable",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "recover",
          "dependsOn": [
            "PCACHE-102",
            "PCACHE-104",
            "PCACHE-106"
          ],
          "scenario": "A cache outage redirects the full request rate to the origin. The supposed fallback turns a small infrastructure fault into a wider outage.",
          "acceptanceCriteria": [
            "Set cache-client timeouts and bound origin fallback concurrency and queue length.",
            "Return an explicit overload or unavailable response when the fallback budget is exhausted.",
            "Recover cache use without a synchronized refill storm or continuing to queue expired callers."
          ],
          "implementationNotes": [
            "Exercise cache disconnect, slow response and recovery separately; do not rely only on a clean process shutdown."
          ],
          "verification": [
            "Run the hot-key load while making cache operations hang and assert bounded connection and origin work counts.",
            "Restore the cache during overload and verify queue drainage, timeout accounting and correct tenant-specific responses."
          ],
          "deliverables": [
            "Degraded-cache policy, failure injection and recovery traces"
          ],
          "rollout": "Canary the bounded fallback configuration locally; retain a switch that fails informational reads explicitly if fallback threatens the origin budget.",
          "skills": [
            "Fault isolation",
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "72d58451-28e2-4539-924c-aa4745397272",
          "key": "PCACHE-109",
          "title": "Version availability cache payloads without flushing every tenant at once",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "PCACHE-101",
            "PCACHE-105",
            "PCACHE-107"
          ],
          "scenario": "A response-field change makes older cached payloads unreadable. Flushing all keys would force a simultaneous cold start across the service.",
          "acceptanceCriteria": [
            "Write a new payload/key version and reject incompatible old payloads safely.",
            "Define a bounded warming or lazy-fill strategy and retain per-tenant scope.",
            "Make rollback behavior explicit when older readers encounter values written during the new release."
          ],
          "implementationNotes": [
            "Treat cache payloads as derived data; do not migrate authoritative stock records as part of this change."
          ],
          "verification": [
            "Run old and new readers against mixed-version fixtures and verify the documented compatibility behavior.",
            "Switch versions under the hot-key workload and measure origin refill concurrency without a global flush."
          ],
          "deliverables": [
            "Payload-version contract, compatibility tests and rollout procedure"
          ],
          "rollout": "Canary a small synthetic tenant set, then expand; rollback restores the prior namespace and lets unused versioned entries expire.",
          "skills": [
            "Schema compatibility",
            "Cache rollout"
          ],
          "fieldMix": [
            {
              "field": "Platform engineering",
              "percentage": 40
            },
            {
              "field": "API design",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "8bc9bf49-f0a2-44ca-ac51-d5462e96f097",
          "key": "PCACHE-110",
          "title": "Choose the cache policy from freshness, origin load and tail latency together",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "PCACHE-104",
            "PCACHE-105",
            "PCACHE-106",
            "PCACHE-107",
            "PCACHE-108",
            "PCACHE-109"
          ],
          "scenario": "One policy gives the highest hit rate by serving older data. Another is fresh but overloads the origin at expiry. The team needs a decision tied to the actual contract.",
          "acceptanceCriteria": [
            "Run three paired repetitions of cold, warm, synchronized-expiry and cache-outage phases on the declared workload.",
            "For the warm phase require at least 60% fewer origin calls than uncached reads, no cross-tenant result and no response beyond the hard freshness limit.",
            "Require bounded origin concurrency in every phase and publish p95/p99, rejection and stale-response rates; mark invalid or noisy runs inconclusive."
          ],
          "implementationNotes": [
            "The avoided-call threshold is an exercise budget for the seeded hot-key distribution. Do not infer a production hit rate or freshness guarantee from it."
          ],
          "verification": [
            "Reconcile all attempted reads with results, cache states and actual origin calls for baseline and candidate.",
            "Revert the chosen configuration and repeat the outage/recovery phase, checking correctness and bounded work after rollback."
          ],
          "deliverables": [
            "Cache-policy decision, raw measurements and recovery handoff"
          ],
          "rollout": "Promote only the policy satisfying correctness and degraded-mode gates; rollback uses the documented namespace and bounded origin policy.",
          "skills": [
            "Performance tradeoffs",
            "Resilience testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "db38a42a-5068-4d2f-8c64-3e0473bb51c1",
      "key": "RRETENTION",
      "title": "Expire support attachments without losing control of exceptions",
      "summary": "Implement explicit retention clocks, protected exceptions and bounded purge recovery.",
      "context": "A fictional support service keeps uploaded diagnostic files indefinitely. The exercise policy expires attachments 30 days after case closure, while a separately authorized investigation hold pauses removal. These are invented product rules, not legal advice or compliance certification.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Object storage adapter"
      ],
      "prerequisites": [
        "Create synthetic cases, attachment metadata and a fake object store with controllable failures.",
        "Use an injected UTC clock and an authorized operator fixture; no real support uploads are needed."
      ],
      "developerValue": "Practice temporal policy, deletion races, exception authority and truthful recovery reporting.",
      "companyValue": "Develop inspectable retention behavior that a company can review against its own approved data policy.",
      "delivery": "Ten scoped tickets using local synthetic records. Policy approval, real account access and production deletion are outside the exercise.",
      "phases": [
        {
          "id": "policy",
          "title": "Define expiry and exceptions",
          "goal": "Make retention decisions explainable and correctly scoped."
        },
        {
          "id": "purge",
          "title": "Apply removal safely",
          "goal": "Recheck authority and recover partial failures."
        },
        {
          "id": "operate",
          "title": "Verify ongoing retention",
          "goal": "Measure backlog and rehearse policy changes without obscuring retained data."
        }
      ],
      "field": "Privacy engineering",
      "tickets": [
        {
          "id": "f6e832ae-82db-42c6-88a6-3a6cd9062497",
          "key": "RRETENTION-101",
          "title": "Calculate attachment expiry from the case closure instant",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "policy",
          "dependsOn": [],
          "scenario": "Files uploaded long before a case closes are being removed too early because the prototype starts the retention clock at upload.",
          "acceptanceCriteria": [
            "Use case closure plus 30 elapsed days as the exercise expiry instant.",
            "Keep open cases ineligible and represent missing closure data explicitly.",
            "Return the policy version and reason with each eligibility decision."
          ],
          "implementationNotes": [
            "Use UTC instants and an injected clock; do not substitute local calendar dates."
          ],
          "verification": [
            "Evaluate immediately before and at expiry.",
            "Evaluate open and missing-closure fixtures without scheduling deletion."
          ],
          "deliverables": [
            "Retention decision function and boundary fixtures"
          ],
          "rollout": "Run decisions in preview mode before enabling any removal path.",
          "skills": [
            "Temporal modeling",
            "Data lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2d085eba-9d03-4742-a6dc-a51ed12f605e",
          "key": "RRETENTION-102",
          "title": "Inventory every storage location used by one support attachment",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "policy",
          "dependsOn": [
            "RRETENTION-101"
          ],
          "scenario": "Removing the primary upload leaves its thumbnail and a cached diagnostic preview behind.",
          "acceptanceCriteria": [
            "List primary object, derived previews, metadata and any backup copy in a bounded data-flow inventory.",
            "Assign an owner and retention behavior to each location.",
            "Mark unknown or external copies explicitly instead of declaring removal complete."
          ],
          "implementationNotes": [
            "Use the fictional architecture and local adapters; do not discover or copy real customer data."
          ],
          "verification": [
            "Trace one synthetic upload through each declared location.",
            "Add an unknown derived location and verify the inventory marks coverage incomplete."
          ],
          "deliverables": [
            "Attachment lifecycle map and location registry"
          ],
          "rollout": "Review the registry before wiring purge adapters; new derived stores require an inventory update.",
          "skills": [
            "Data mapping",
            "Storage lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "fb83a7c5-0dac-4b0d-a2b0-8d48246d6dd0",
          "key": "RRETENTION-103",
          "title": "Require scoped authority to place an attachment on investigation hold",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "policy",
          "dependsOn": [
            "RRETENTION-101"
          ],
          "scenario": "Any support member can currently set a permanent hold with no reason, and the flag has no owner for later review.",
          "acceptanceCriteria": [
            "Require tenant-scoped hold authority, a bounded reason category and a review date.",
            "Append hold creation and release records with actor and policy version.",
            "Deny a foreign-tenant or ordinary-member hold command before mutation."
          ],
          "implementationNotes": [
            "Keep free-text case content out of generic audit logs; an audit records the privileged action and safe identifiers."
          ],
          "verification": [
            "Create and release a hold as the authorized synthetic operator.",
            "Attempt both commands from another tenant and an unprivileged member; verify no change."
          ],
          "deliverables": [
            "Hold commands and authorization regressions"
          ],
          "rollout": "Introduce hold management before purge activation so active exceptions can be represented.",
          "skills": [
            "Authorization",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "ff8e19b3-a4a0-4d27-bffb-7b1406f8f038",
          "key": "RRETENTION-104",
          "title": "Preview the attachment purge set with stable decision reasons",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "purge",
          "dependsOn": [
            "RRETENTION-101",
            "RRETENTION-102",
            "RRETENTION-103"
          ],
          "scenario": "Operators cannot tell why two similarly aged attachments are treated differently by the retention job.",
          "acceptanceCriteria": [
            "Return bounded pages of eligible, held and ineligible records with policy and decision timestamp.",
            "Keep preview tenant-scoped and omit file contents and unrestricted object URLs.",
            "State that preview is advisory and execution rechecks current eligibility."
          ],
          "implementationNotes": [
            "Use stable cursor ordering; a preview must never claim to lock the future purge set."
          ],
          "verification": [
            "Compare expiry and hold fixtures with the decision function.",
            "Place a hold after preview and verify the preview itself causes no deletion."
          ],
          "deliverables": [
            "Purge-preview endpoint and scoped pagination tests"
          ],
          "rollout": "Expose preview to authorized local operators first; disable the view independently of lifecycle records.",
          "skills": [
            "Operational tooling",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "53096897-e90d-4401-ac1c-347e4eb16136",
          "key": "RRETENTION-105",
          "title": "Recheck holds when a queued attachment purge begins",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "purge",
          "dependsOn": [
            "RRETENTION-103",
            "RRETENTION-104"
          ],
          "scenario": "An attachment becomes held after the purge queue is populated, but the worker trusts the old eligibility flag and removes it anyway.",
          "acceptanceCriteria": [
            "Re-evaluate current policy and hold state before issuing removal.",
            "Define coordination between hold creation and a purge already crossing its irreversible boundary.",
            "Return an explicit conflict or too-late state without claiming a newly created hold restored deleted bytes."
          ],
          "implementationNotes": [
            "Model the race using a controlled storage adapter; document the exact serialization boundary."
          ],
          "verification": [
            "Pause before removal, place a hold and verify the object remains.",
            "Race hold creation with confirmed removal and verify the declared conflict outcome and truthful audit."
          ],
          "deliverables": [
            "Purge/hold transition protocol and race tests"
          ],
          "rollout": "Keep deletion disabled until both race orderings pass; preserve metadata for any ambiguous external operation.",
          "skills": [
            "Concurrency",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "e2dbb92c-0e45-4b9c-8b14-9d2b636fc0c6",
          "key": "RRETENTION-106",
          "title": "Retry partial attachment removal without forgetting derived copies",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "purge",
          "dependsOn": [
            "RRETENTION-102",
            "RRETENTION-105"
          ],
          "scenario": "The primary object is gone but thumbnail removal timed out. A retry treats the missing primary as success for the entire attachment.",
          "acceptanceCriteria": [
            "Track per-location progress and idempotent removal outcomes.",
            "Distinguish not-found from authorization and transport failure.",
            "Mark the purge complete only when every required location is confirmed or an explicit unresolved exception remains."
          ],
          "implementationNotes": [
            "Keep evidence of unresolved copies in restricted operational records; do not expose storage credentials in failure text."
          ],
          "verification": [
            "Fail thumbnail removal after primary success, retry and verify both locations are reconciled.",
            "Inject a forbidden response and confirm it remains unresolved rather than being treated as already absent."
          ],
          "deliverables": [
            "Per-location purge state and partial-failure regressions"
          ],
          "rollout": "Retry only incomplete locations; stop promotion when a provider cannot give a trustworthy deletion outcome.",
          "skills": [
            "Idempotency",
            "Partial failure"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0fb4fb2c-c3fa-4c63-bb7b-4eae198a7a7b",
          "key": "RRETENTION-107",
          "title": "Record a reopened case without silently resetting attachment history",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "purge",
          "dependsOn": [
            "RRETENTION-101",
            "RRETENTION-105"
          ],
          "scenario": "Reopening a case overwrites its closure timestamp. Support can no longer explain whether an attachment was eligible when a purge started.",
          "acceptanceCriteria": [
            "Append case lifecycle events and derive the current retention clock under an explicit reopening rule.",
            "Preserve previous decisions and completed removal history.",
            "Prevent reopening from implying deleted attachments can be recovered."
          ],
          "implementationNotes": [
            "Define the exercise rule before coding: reopening pauses eligibility; a later closure starts a new 30-day period for remaining attachments."
          ],
          "verification": [
            "Reopen before expiry and verify ineligibility, then close again and verify the new boundary.",
            "Reopen after confirmed purge and show the attachment remains removed with its original decision history."
          ],
          "deliverables": [
            "Reopening policy and historical decision tests"
          ],
          "rollout": "Version the policy and preview changed eligibility before activating the new clock behavior.",
          "skills": [
            "Lifecycle history",
            "Policy versioning"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "730afd07-8bf9-446a-8a56-b58fa10f7b49",
          "key": "RRETENTION-108",
          "title": "Report retention backlog without listing customer file names",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "operate",
          "dependsOn": [
            "RRETENTION-104",
            "RRETENTION-106"
          ],
          "scenario": "The only retention report exports every filename to a general analytics dashboard.",
          "acceptanceCriteria": [
            "Expose aggregate eligible, held, failed and completed counts plus oldest eligible age.",
            "Keep filenames, object keys and case content out of generic metrics.",
            "Provide authorized drilldown through the scoped operational view instead of metric labels."
          ],
          "implementationNotes": [
            "Use bounded outcome categories and distinguish zero eligible records from unavailable measurements."
          ],
          "verification": [
            "Reconcile aggregate counts with a synthetic fixture containing each outcome.",
            "Insert sensitive-looking filenames and verify no value reaches the metric payload."
          ],
          "deliverables": [
            "Retention metrics and sanitized payload tests"
          ],
          "rollout": "Run aggregate reporting beside the restricted preview; remove the old filename-based dashboard after validation.",
          "skills": [
            "Observability",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "7ce555bb-3f68-4e7f-97e0-e6a3a0650a84",
          "key": "RRETENTION-109",
          "title": "Rehearse a shorter retention policy without deleting on preview",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "operate",
          "dependsOn": [
            "RRETENTION-104",
            "RRETENTION-105",
            "RRETENTION-107"
          ],
          "scenario": "Product proposes reducing the exercise retention period from 30 to 14 days. Applying the constant immediately would make a large backlog eligible at once.",
          "acceptanceCriteria": [
            "Create a new policy version and produce a tenant-scoped impact preview.",
            "Define activation time, bounded purge batches and preserved hold semantics.",
            "Document that rollback can stop future deletion but cannot restore confirmed removed objects."
          ],
          "implementationNotes": [
            "Treat 14 days as a proposed fictional rule requiring review in the exercise workflow, not a real-world policy recommendation."
          ],
          "verification": [
            "Compare old and new decisions at activation boundaries with active holds.",
            "Cancel activation and verify no objects were removed by the preview; rehearse stopping after one controlled purge batch."
          ],
          "deliverables": [
            "Policy-change plan, impact report and stop procedure"
          ],
          "rollout": "Require the explicit local activation command after review; retain previous policy and append the activation record.",
          "skills": [
            "Change management",
            "Retention policy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "75fcf31a-1b97-42b2-b150-3449b2dbcc36",
          "key": "RRETENTION-110",
          "title": "Verify retention recovery after an interrupted purge run",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "operate",
          "dependsOn": [
            "RRETENTION-106",
            "RRETENTION-108",
            "RRETENTION-109"
          ],
          "scenario": "The purge process crashes between provider acknowledgement and state persistence. The dashboard cannot tell which objects remain.",
          "acceptanceCriteria": [
            "Reconcile uncertain per-location states through the declared provider contract.",
            "Preserve held and not-yet-eligible objects while converging repeated retries.",
            "Produce a report separating confirmed removal, retained exceptions and unresolved provider outcomes."
          ],
          "implementationNotes": [
            "Use synthetic objects and deterministic crash points; a completed job record alone does not prove every copy is gone."
          ],
          "verification": [
            "Interrupt before and after each storage acknowledgement and compare actual fixture objects with recorded states.",
            "Repeat reconciliation and verify no duplicate privileged transition and no newly removed held object."
          ],
          "deliverables": [
            "Crash matrix, reconciliation procedure and truthful retention report"
          ],
          "rollout": "Enable scheduled local purge only after recovery cases pass; unresolved states remain visible for authorized review.",
          "skills": [
            "Recovery engineering",
            "Data lifecycle verification"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "89f008a8-4896-4778-85be-be486e5ad541",
      "key": "RDELETE",
      "title": "Delete a workspace member profile across owned stores",
      "summary": "Coordinate scoped profile removal, derived-store cleanup and truthful completion reporting.",
      "context": "A fictional collaboration product lets a member request removal of their personal profile. Search, notifications and cached displays retain copies after the primary row disappears. The exercise uses a documented product deletion policy and synthetic identities.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Queue adapter",
        "Search adapter"
      ],
      "prerequisites": [
        "Create local profile, search-index and notification fixtures with controlled provider failures.",
        "Define synthetic members, organizations and a current-session authorization fixture."
      ],
      "developerValue": "Practice distributed cleanup, identity scope, idempotency and accurate user-facing lifecycle states.",
      "companyValue": "Produce a reviewable deletion workflow and copy inventory for adaptation to an approved company policy.",
      "delivery": "Ten tickets across request, cleanup and reconciliation phases. No live accounts are deleted; the brief does not certify legal erasure or removal from undeclared third parties.",
      "phases": [
        {
          "id": "request",
          "title": "Accept a scoped removal request",
          "goal": "Define identity, authority and the product deletion contract."
        },
        {
          "id": "cleanup",
          "title": "Remove declared copies",
          "goal": "Coordinate idempotent cleanup and prevent data from returning."
        },
        {
          "id": "reconcile",
          "title": "Reconcile exceptions and completion",
          "goal": "Make partial progress and recovery inspectable."
        }
      ],
      "field": "Privacy engineering",
      "tickets": [
        {
          "id": "0b8e4c17-e8d0-472b-968c-fd9eb0c117c3",
          "key": "RDELETE-101",
          "title": "Separate profile removal from leaving one organization",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 75,
          "phaseId": "request",
          "dependsOn": [],
          "scenario": "A member belongs to two organizations. The current button says delete account but removes only the active membership.",
          "acceptanceCriteria": [
            "Define distinct commands for leaving one organization and removing the global personal profile.",
            "List owned stores affected by each command and any retained records under the fictional policy.",
            "Show the command scope and expected access change before submission."
          ],
          "implementationNotes": [
            "Do not infer global identity from an organization-local display name or email field."
          ],
          "verification": [
            "Trace a two-organization member through both commands and compare affected records.",
            "Verify a membership-only request leaves the other organization and global profile unchanged."
          ],
          "deliverables": [
            "Deletion scope contract and multi-organization fixtures"
          ],
          "rollout": "Introduce distinct command names before enabling cleanup adapters.",
          "skills": [
            "Domain boundaries",
            "Identity scope"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "43fb0b51-6fd4-4537-a26c-603e8256a141",
          "key": "RDELETE-102",
          "title": "Verify the current member before accepting profile removal",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "request",
          "dependsOn": [
            "RDELETE-101"
          ],
          "scenario": "A request body supplies a profile ID and the API trusts it even when it differs from the authenticated member.",
          "acceptanceCriteria": [
            "Resolve the subject from the current authorized session and declared command scope.",
            "Reject substituted profile IDs and stale sessions before creating a request.",
            "Return a safe request reference without exposing another profile’s existence."
          ],
          "implementationNotes": [
            "Reuse an explicit authentication provider fixture; this ticket does not invent a new identity-assurance claim."
          ],
          "verification": [
            "Submit as the matching synthetic member and verify the request subject.",
            "Substitute a second member’s ID and revoke the session; both cases must create no request."
          ],
          "deliverables": [
            "Authorized request endpoint and subject-substitution tests"
          ],
          "rollout": "Gate request creation before enabling background work; rollback disables new requests while preserving accepted ones.",
          "skills": [
            "Authorization",
            "Session validation"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 70
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "855b626f-4d06-44f8-b19e-6cc945781c9c",
          "key": "RDELETE-103",
          "title": "Make repeated removal requests return the same active operation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "request",
          "dependsOn": [
            "RDELETE-102"
          ],
          "scenario": "A double-click starts two cleanup chains that race and send contradictory completion messages.",
          "acceptanceCriteria": [
            "Use a subject-scoped active-operation uniqueness rule and a stable request identity.",
            "Return the existing operation for a duplicate accepted request.",
            "Preserve previous terminal history when a genuinely new eligible request is allowed by the policy."
          ],
          "implementationNotes": [
            "Create the request and dispatch intent transactionally; a retry must not depend on process memory."
          ],
          "verification": [
            "Submit concurrent duplicates and verify one operation plus one dispatch intent.",
            "Lose the first response and retry, confirming the same safe operation reference."
          ],
          "deliverables": [
            "Idempotent request creation and concurrency regressions"
          ],
          "rollout": "Apply the uniqueness constraint before deploying the accepting endpoint.",
          "skills": [
            "Idempotency",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "244362bc-1d2c-4460-99aa-5180b5d9c0e0",
          "key": "RDELETE-104",
          "title": "Stop new profile-derived writes after removal begins",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "cleanup",
          "dependsOn": [
            "RDELETE-101",
            "RDELETE-103"
          ],
          "scenario": "The notification worker recreates a cached profile card while cleanup is deleting it.",
          "acceptanceCriteria": [
            "Record a lifecycle boundary that profile-derived writers check before producing new copies.",
            "Define how already queued work is cancelled or rejected for the removal generation.",
            "Preserve required nonpersonal operational records without copying the removed profile into them."
          ],
          "implementationNotes": [
            "Use a generation or tombstone contract with explicit retention; do not keep the entire deleted profile inside a tombstone."
          ],
          "verification": [
            "Queue a notification before removal and release it afterward; no new profile copy may appear.",
            "Race an edit with removal and verify one declared outcome with no profile resurrection."
          ],
          "deliverables": [
            "Write barrier and profile-resurrection race tests"
          ],
          "rollout": "Deploy the writer check before activating cleanup; stop new operations if a writer cannot honor it.",
          "skills": [
            "Lifecycle coordination",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "7acc04de-a5aa-471d-b1cf-83a53477830e",
          "key": "RDELETE-105",
          "title": "Remove profile documents from search using the removal generation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "cleanup",
          "dependsOn": [
            "RDELETE-104"
          ],
          "scenario": "A delayed indexing event arrives after a search document was deleted and makes the profile searchable again.",
          "acceptanceCriteria": [
            "Bind indexing and removal to a comparable subject generation or explicit suppression rule.",
            "Make repeated search deletion safe and keep stale indexing events from restoring the profile.",
            "Keep cleanup tenant/subject-scoped so similarly named profiles remain searchable."
          ],
          "implementationNotes": [
            "Treat the search adapter as eventually consistent and define the observation needed before declaring that location complete."
          ],
          "verification": [
            "Delete a profile, replay its older indexing event and verify it stays absent after the adapter’s declared convergence condition.",
            "Search for a same-name profile in another organization and verify it remains unaffected."
          ],
          "deliverables": [
            "Search cleanup adapter and stale-event regressions"
          ],
          "rollout": "Canary on synthetic subjects; retain unresolved search state if the adapter cannot establish the expected convergence.",
          "skills": [
            "Search indexing",
            "Event ordering"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "1a37295e-ff69-4306-b063-cf48728f494e",
          "key": "RDELETE-106",
          "title": "Track notification and cache cleanup separately from the primary profile row",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "cleanup",
          "dependsOn": [
            "RDELETE-104",
            "RDELETE-105"
          ],
          "scenario": "The operation reports success after deleting the database row even though a notification snapshot and cache entry still show the member’s details.",
          "acceptanceCriteria": [
            "Track required locations with independent pending, confirmed and failed states.",
            "Differentiate already absent from unavailable or unauthorized provider responses.",
            "Advance overall completion only when the declared required locations satisfy the policy."
          ],
          "implementationNotes": [
            "The location registry is versioned for each operation so a later implementation change cannot silently rewrite its promised scope."
          ],
          "verification": [
            "Fail cache cleanup after database removal and verify a partial state with a retryable location.",
            "Return an authorization error from notifications and confirm it cannot be counted as confirmed absence."
          ],
          "deliverables": [
            "Location progress model and partial-cleanup fixtures"
          ],
          "rollout": "Enable adapters one at a time in the local exercise; unsupported locations remain explicitly unresolved.",
          "skills": [
            "Workflow modeling",
            "Partial failure"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "044cc393-ee27-47a8-880e-1b495aa505f1",
          "key": "RDELETE-107",
          "title": "Keep the removal status page useful after the profile is gone",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "reconcile",
          "dependsOn": [
            "RDELETE-102",
            "RDELETE-106"
          ],
          "scenario": "Deleting the profile also removes the data needed to render progress, leaving the requester with a broken page before cleanup is finished.",
          "acceptanceCriteria": [
            "Provide a narrowly scoped status mechanism independent of the removed profile display fields.",
            "Expose progress categories and unresolved exceptions without returning deleted content or internal storage identifiers.",
            "Define status access expiry and deny access to unrelated operations."
          ],
          "implementationNotes": [
            "Use the exercise authentication contract or an explicitly scoped expiring receipt; do not place a reusable access secret in generic analytics."
          ],
          "verification": [
            "Read progress before and after primary-profile removal.",
            "Attempt another subject’s operation and an expired receipt/session; verify denial without detail leakage."
          ],
          "deliverables": [
            "Minimal status response and post-removal access tests"
          ],
          "rollout": "Publish the status contract before enabling destructive cleanup; retain safe operation metadata for its declared lifetime.",
          "skills": [
            "Minimal disclosure",
            "Access control"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Frontend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "8abfc949-7b4c-4dd4-aee2-17f3b3013e79",
          "key": "RDELETE-108",
          "title": "Reapply profile suppression before a restored backup becomes readable",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "reconcile",
          "dependsOn": [
            "RDELETE-104",
            "RDELETE-106"
          ],
          "scenario": "A restore rehearsal brings back a profile that was removed after the backup was taken.",
          "acceptanceCriteria": [
            "Define a minimal removal ledger and a restore gate that reconciles post-backup removals before serving reads.",
            "State the retention and access boundaries of the ledger without storing full profile snapshots.",
            "Keep the restored environment unavailable if reconciliation is incomplete or the ledger cannot be trusted."
          ],
          "implementationNotes": [
            "Use local database snapshots and synthetic subjects; a backup exception must be visible in the policy rather than called immediate erasure."
          ],
          "verification": [
            "Restore a snapshot containing a later-removed profile and verify suppression before any simulated read endpoint is enabled.",
            "Make the ledger unavailable and verify the restore gate fails closed."
          ],
          "deliverables": [
            "Restore reconciliation protocol and backup resurrection rehearsal"
          ],
          "rollout": "Add the gate to the local restore runbook before accepting the deletion workflow as complete for its declared stores.",
          "skills": [
            "Backup recovery",
            "Deletion semantics"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "53909b87-4bb2-4788-b966-dd267f78573f",
          "key": "RDELETE-109",
          "title": "Retry a removal operation after losing a provider acknowledgement",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "reconcile",
          "dependsOn": [
            "RDELETE-103",
            "RDELETE-105",
            "RDELETE-106"
          ],
          "scenario": "A provider removes a copy but the cleanup process crashes before recording the result. Retrying currently converts the missing object into a fatal error.",
          "acceptanceCriteria": [
            "Reconcile uncertain acknowledgement states using the provider’s declared lookup/removal contract.",
            "Make repeated cleanup converge without recreating data or duplicating completion notifications.",
            "Retain a distinct unresolved state when the provider cannot confirm the outcome."
          ],
          "implementationNotes": [
            "Use deterministic crash points around dispatch, provider completion and local persistence."
          ],
          "verification": [
            "Crash after external removal and before local update, then retry and verify truthful convergence.",
            "Inject repeated provider timeout and verify bounded retries plus visible unresolved status."
          ],
          "deliverables": [
            "Acknowledgement-loss regression and retry procedure"
          ],
          "rollout": "Retry only through the recorded operation identity; unresolved high-impact states require authorized review in the exercise.",
          "skills": [
            "Distributed recovery",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "4ca2f27a-e7d1-47ad-9927-9b1138f9a5aa",
          "key": "RDELETE-110",
          "title": "Produce a removal report that names remaining exceptions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 270,
          "phaseId": "reconcile",
          "dependsOn": [
            "RDELETE-107",
            "RDELETE-108",
            "RDELETE-109"
          ],
          "scenario": "The proposed confirmation says all your data is deleted even when a declared backup copy or unavailable provider remains.",
          "acceptanceCriteria": [
            "Generate a bounded report of completed locations, retained policy exceptions and unresolved outcomes.",
            "Bind the report to the operation and policy versions and distinguish requested time from observed completion time.",
            "Avoid claiming global erasure or legal compliance beyond the declared local scope."
          ],
          "implementationNotes": [
            "The report is workflow status, not noCV Outcome Evidence or Ownership Evidence; practice completion grants neither."
          ],
          "verification": [
            "Generate reports for complete, partial and backup-exception fixtures and compare their language with actual store state.",
            "Attempt report access as another subject and verify no operation details leak."
          ],
          "deliverables": [
            "Truthful completion report and scope/authorization tests"
          ],
          "rollout": "Use the report only after reconciliation; corrections append a new status record rather than rewriting earlier confirmations.",
          "skills": [
            "Privacy communication",
            "Auditability"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 80
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "5541d678-05d0-41ca-a883-491dc2a791b9",
      "key": "REXPORT",
      "title": "Deliver a personal data export with a narrow access boundary",
      "summary": "Build a scoped asynchronous export, redact unrelated records and expire its downloadable artifact.",
      "context": "A fictional learning workspace offers a member a portable copy of their own profile, notes and activity settings. Shared documents contain contributions from other people. The product export policy specifies included fields and shared-record handling; this is an engineering exercise, not a legal portability claim.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "JSON",
        "Object storage adapter"
      ],
      "prerequisites": [
        "Create synthetic members, private notes and shared-document contributions in a local database.",
        "Provide fake queue and object-storage adapters with controllable expiry and failure."
      ],
      "developerValue": "Practice export scoping, consistency, streaming and expiring access without leaking other members’ data.",
      "companyValue": "Create a reviewable export contract and cross-subject regression suite for an approved product policy.",
      "delivery": "Ten tickets from field inventory to delivery and cleanup. Artifacts contain only synthetic data, and all download links resolve through local provider doubles.",
      "phases": [
        {
          "id": "scope",
          "title": "Specify the export boundary",
          "goal": "Define authorized subjects, included fields and shared-record rules."
        },
        {
          "id": "assemble",
          "title": "Build a consistent artifact",
          "goal": "Generate bounded exports with explicit version and failure behavior."
        },
        {
          "id": "deliver",
          "title": "Deliver and expire access",
          "goal": "Restrict retrieval and verify cleanup and disclosure behavior."
        }
      ],
      "field": "Privacy engineering",
      "tickets": [
        {
          "id": "077c4e9a-6377-474e-8da8-3a97a0a7819e",
          "key": "REXPORT-101",
          "title": "List exportable member fields before serializing database rows",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "scope",
          "dependsOn": [],
          "scenario": "A prototype exports complete ORM objects, including internal moderation flags and provider tokens.",
          "acceptanceCriteria": [
            "Create an explicit allowlist for profile, private-note and settings fields.",
            "Exclude credentials, internal operational fields and unrelated-member data.",
            "Version the export schema and document omitted field categories."
          ],
          "implementationNotes": [
            "Build export DTOs independently of database model serialization."
          ],
          "verification": [
            "Export a synthetic row containing token-like and internal fields and verify they are absent.",
            "Add an unknown database column and confirm it does not enter the artifact automatically."
          ],
          "deliverables": [
            "Export field contract and allowlist tests"
          ],
          "rollout": "Review the field contract before enabling generation; new fields require an explicit schema change.",
          "skills": [
            "Data minimization",
            "Serialization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "f44598d1-e7ca-4f2e-8fef-a56102688269",
          "key": "REXPORT-102",
          "title": "Define how shared document contributions appear in a personal export",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "scope",
          "dependsOn": [
            "REXPORT-101"
          ],
          "scenario": "Exporting a whole shared document would include other members’ private comments and mentions.",
          "acceptanceCriteria": [
            "Specify which subject-owned contributions and necessary context are included.",
            "Define redaction or omission for unrelated-member fields and private comments.",
            "Represent omitted shared content honestly rather than implying the export is a complete document history."
          ],
          "implementationNotes": [
            "Use a mixed-author fixture; access to a workspace does not by itself settle the product export policy."
          ],
          "verification": [
            "Export a document with two authors, private comments and a deleted contribution.",
            "Verify exported context does not reveal an unrelated private field or silently change the subject’s contribution text."
          ],
          "deliverables": [
            "Shared-record export policy and mixed-author fixtures"
          ],
          "rollout": "Keep shared-content export disabled until its policy and regression examples are reviewed.",
          "skills": [
            "Privacy boundaries",
            "Content modeling"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "55684b80-9d66-4f19-aa51-c8e37add4265",
          "key": "REXPORT-103",
          "title": "Bind export creation to the current authorized subject",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 135,
          "phaseId": "scope",
          "dependsOn": [
            "REXPORT-101",
            "REXPORT-102"
          ],
          "scenario": "The endpoint accepts any member ID and relies on the UI to submit the current user.",
          "acceptanceCriteria": [
            "Resolve export scope from the authenticated subject and approved workspace access.",
            "Reject substituted IDs and revoked sessions before queueing work.",
            "Record a safe operation reference without embedding personal fields in job identifiers."
          ],
          "implementationNotes": [
            "Authorization also belongs at the data-access boundary used by background assembly."
          ],
          "verification": [
            "Create an export as the matching synthetic member.",
            "Attempt another member’s ID and a revoked membership, checking that no job or artifact is created."
          ],
          "deliverables": [
            "Scoped export command and cross-subject denial tests"
          ],
          "rollout": "Deploy command and repository checks together before queue activation.",
          "skills": [
            "Authorization",
            "Repository boundaries"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f284d4db-3f78-41f4-b72e-fdfb7cecca73",
          "key": "REXPORT-104",
          "title": "Freeze the export selection without holding a long database transaction",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "assemble",
          "dependsOn": [
            "REXPORT-103"
          ],
          "scenario": "Notes added midway through an export appear inconsistently, and the worker holds a transaction open while uploading the archive.",
          "acceptanceCriteria": [
            "Declare the export consistency boundary and record a cutoff or snapshot reference.",
            "Keep database selection consistent with that boundary while assembling outside an unbounded transaction.",
            "Expose generation time and the selection boundary in the manifest."
          ],
          "implementationNotes": [
            "Choose a method supported by the local schema; do not promise a global snapshot across unrelated stores without a protocol."
          ],
          "verification": [
            "Edit and add notes during a paused assembly and verify the documented inclusion rule.",
            "Slow artifact upload and verify no long-lived database transaction is retained solely for transfer."
          ],
          "deliverables": [
            "Selection protocol and concurrent-edit export tests"
          ],
          "rollout": "Version the consistency contract; failed assembly may retry against the same frozen selection or start a clearly new operation.",
          "skills": [
            "Snapshot semantics",
            "Transactions"
          ],
          "fieldMix": [
            {
              "field": "Database engineering",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5dd961ce-6670-43d5-9497-f225c6960c61",
          "key": "REXPORT-105",
          "title": "Stream large note exports with bounded intermediate storage",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "assemble",
          "dependsOn": [
            "REXPORT-101",
            "REXPORT-104"
          ],
          "scenario": "A member with many notes causes the worker to build one large JSON string and exceed its resource budget.",
          "acceptanceCriteria": [
            "Stream the chosen format with bounded buffering and valid escaping.",
            "Keep ordering and manifest counts deterministic for the frozen selection.",
            "Remove incomplete temporary artifacts on controlled failure while preserving retry metadata."
          ],
          "implementationNotes": [
            "Use a synthetic large-note fixture and declared memory/disk limits; do not require real user content."
          ],
          "verification": [
            "Export the same selection through small and large chunk sizes and compare parsed records and digest.",
            "Interrupt output after a multibyte value and verify no incomplete artifact becomes downloadable."
          ],
          "deliverables": [
            "Streaming exporter, resource report and interrupted-write regression"
          ],
          "rollout": "Keep completed artifacts unpublished until final validation; retry writes to a new temporary object identity.",
          "skills": [
            "Streaming",
            "Artifact integrity"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2487e66c-2aeb-40c1-9f4a-50d4e35e3838",
          "key": "REXPORT-106",
          "title": "Validate the export manifest before marking assembly complete",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "assemble",
          "dependsOn": [
            "REXPORT-102",
            "REXPORT-105"
          ],
          "scenario": "The archive download succeeds even when one source query failed and an entire section is missing.",
          "acceptanceCriteria": [
            "Record schema version, section counts, selection boundary and artifact digest.",
            "Distinguish intentionally omitted sections from failed required sections.",
            "Mark ready only after required sections and digest validation succeed."
          ],
          "implementationNotes": [
            "A digest establishes artifact consistency, not completeness beyond the declared export contract."
          ],
          "verification": [
            "Fail the required private-note query and verify the export remains non-ready and non-downloadable, with the required-section failure reported explicitly.",
            "Corrupt a completed temporary artifact and verify publication is blocked."
          ],
          "deliverables": [
            "Manifest validator and incomplete-section fixtures"
          ],
          "rollout": "Place manifest validation before the ready transition; keep failed artifacts inaccessible and eligible for cleanup.",
          "skills": [
            "Integrity checks",
            "State transitions"
          ],
          "fieldMix": [
            {
              "field": "Storage systems",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "72f7ca97-7e1e-4f8b-9c59-2f22591b5417",
          "key": "REXPORT-107",
          "title": "Issue a short-lived download capability only after subject authorization",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "deliver",
          "dependsOn": [
            "REXPORT-103",
            "REXPORT-106"
          ],
          "scenario": "A predictable artifact URL lets one member retrieve another member’s completed export.",
          "acceptanceCriteria": [
            "Authorize every capability request against the current subject and export operation.",
            "Scope the capability to one object and a declared short lifetime.",
            "Keep capabilities out of generic logs, analytics and unrelated API responses."
          ],
          "implementationNotes": [
            "Use a local storage adapter implementing the capability contract; an opaque URL alone is not authorization."
          ],
          "verification": [
            "Request and use a valid capability for the matching export.",
            "Attempt another subject’s operation, an expired capability and an altered object reference; all must fail without bytes."
          ],
          "deliverables": [
            "Download capability endpoint and scope/expiry tests"
          ],
          "rollout": "Enable downloads only after complete artifacts exist; disable capability issuance independently during an incident.",
          "skills": [
            "Capability security",
            "Access control"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0e96ad48-8f0c-4997-afea-e5d8d141e5f6",
          "key": "REXPORT-108",
          "title": "Revoke export access when the subject loses the required session",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "deliver",
          "dependsOn": [
            "REXPORT-103",
            "REXPORT-107"
          ],
          "scenario": "A member signs out all sessions after an account concern, but a previously issued export link remains usable longer than the product policy allows.",
          "acceptanceCriteria": [
            "Define the revocation guarantee and the limits of direct object-store capabilities.",
            "Choose a bounded retrieval design that meets the stated exercise policy and document its latency/availability tradeoff.",
            "Prevent new access after revocation and state how an already-started transfer is handled."
          ],
          "implementationNotes": [
            "Do not promise immediate revocation of an independently valid signed URL without a mechanism that can enforce it."
          ],
          "verification": [
            "Issue access, revoke the session and attempt a new download under the chosen design.",
            "Revoke during a paused transfer and verify the documented in-flight behavior and resource cleanup."
          ],
          "deliverables": [
            "Revocation design decision and enforced retrieval tests"
          ],
          "rollout": "Roll out the chosen retrieval path under a new capability version; stop issuing the old form before claiming the new guarantee.",
          "skills": [
            "Revocation",
            "Security tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "57283d9b-6214-4318-96d4-0509f54e68ac",
          "key": "REXPORT-109",
          "title": "Expire export artifacts and incomplete assembly objects separately",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "deliver",
          "dependsOn": [
            "REXPORT-105",
            "REXPORT-106",
            "REXPORT-107"
          ],
          "scenario": "Completed exports expire after a day, but failed assembly objects remain indefinitely under a different prefix.",
          "acceptanceCriteria": [
            "Define bounded lifetimes for ready, failed and abandoned temporary artifacts.",
            "Recheck active assembly ownership before removing a temporary object.",
            "Confirm object removal separately from expired download access."
          ],
          "implementationNotes": [
            "Use an injected clock and per-operation object registry; prefix age alone cannot distinguish an active write."
          ],
          "verification": [
            "Advance time through each lifecycle and verify correct removal eligibility.",
            "Race cleanup with an active assembly lease and verify either safe retention or the declared cancellation path."
          ],
          "deliverables": [
            "Artifact cleanup policy and lifecycle race tests"
          ],
          "rollout": "Run a scoped preview before local cleanup; retain unresolved storage outcomes for reconciliation.",
          "skills": [
            "Retention",
            "Resource ownership"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Storage systems",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "308965e9-7221-4913-bcff-a24d6aba55f5",
          "key": "REXPORT-110",
          "title": "Review the export for cross-member disclosure and delivery failures",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 270,
          "phaseId": "deliver",
          "dependsOn": [
            "REXPORT-102",
            "REXPORT-106",
            "REXPORT-108",
            "REXPORT-109"
          ],
          "scenario": "The happy-path export looks correct, but nobody has reviewed shared records, access revocation and abandoned files together.",
          "acceptanceCriteria": [
            "Run a fixture matrix covering two members, two organizations, shared contributions and private notes.",
            "Reconcile manifest counts and allowed fields with the declared policy and actual artifact.",
            "Report tested boundaries, omitted content and unresolved provider limitations without a blanket privacy certification."
          ],
          "implementationNotes": [
            "The exercise review is a reproducible engineering check; it does not create noCV evidence or legal assurance by itself."
          ],
          "verification": [
            "Attempt creation, polling and download across subject/organization boundaries.",
            "Exercise interrupted assembly, expiry and session revocation, then inventory remaining local artifacts."
          ],
          "deliverables": [
            "Export review report and reproducible disclosure/failure matrix"
          ],
          "rollout": "Enable the complete local flow only when required cases pass; keep unsupported content categories explicitly out of the export contract.",
          "skills": [
            "Privacy testing",
            "Failure analysis"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "5a7aba25-dae9-4ba7-b408-b09d834e441f",
      "key": "RCONSENT",
      "title": "Keep communication preferences consistent across dispatch channels",
      "summary": "Version user choices, enforce purpose-specific dispatch checks and recover delayed preference updates.",
      "context": "A fictional event workspace offers optional product announcements and operational booking messages. Its product policy treats these as separate purposes. A stale audience cache currently sends optional messages after a member opts out. The brief implements fictional preference rules and makes no legal-consent certification.",
      "stack": [
        "TypeScript",
        "PostgreSQL",
        "Queue adapter",
        "Email provider double"
      ],
      "prerequisites": [
        "Create synthetic members, versioned notice text and two purpose-tagged message types.",
        "Use a fake dispatch provider with controllable queueing and acknowledgement; send no real messages."
      ],
      "developerValue": "Practice purpose modeling, versioned user choices, dispatch-time checks and consistency under retries.",
      "companyValue": "Create an inspectable preference workflow that can be reviewed against a company-approved communication policy.",
      "delivery": "Ten tickets using provider doubles and synthetic choices. No live mailing lists, legal advice or real outreach are part of the project.",
      "phases": [
        {
          "id": "choices",
          "title": "Model explicit choices",
          "goal": "Make purpose, notice version and user intent distinguishable."
        },
        {
          "id": "dispatch",
          "title": "Enforce choices at delivery",
          "goal": "Handle stale audiences and queued work with current policy checks."
        },
        {
          "id": "review",
          "title": "Review history and consistency",
          "goal": "Reconcile replicas and explain what was actually enforced."
        }
      ],
      "field": "Privacy engineering",
      "tickets": [
        {
          "id": "bf9f3515-0d28-4e3f-b32c-5fd608177db2",
          "key": "RCONSENT-101",
          "title": "Separate optional announcements from booking operations",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "choices",
          "dependsOn": [],
          "scenario": "A single email-enabled flag suppresses booking confirmations when a member opts out of product announcements.",
          "acceptanceCriteria": [
            "Define separate purpose identifiers and allowed message categories.",
            "Specify defaults and unknown-purpose behavior under the fictional product policy.",
            "Keep preference evaluation explicit for each dispatch request."
          ],
          "implementationNotes": [
            "Do not infer a legal basis from a message label; the exercise uses a declared product rule."
          ],
          "verification": [
            "Evaluate announcement and booking fixtures with optional announcements disabled.",
            "Reject an unknown purpose instead of silently treating it as operational."
          ],
          "deliverables": [
            "Purpose registry and preference truth table"
          ],
          "rollout": "Introduce purpose tags before migrating existing preference checks.",
          "skills": [
            "Domain modeling",
            "Policy evaluation"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 80
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "764d8d1f-e8f3-46bf-b491-0b4da9a84521",
          "key": "RCONSENT-102",
          "title": "Record the notice version shown when a preference changes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "choices",
          "dependsOn": [
            "RCONSENT-101"
          ],
          "scenario": "The database stores only the latest boolean, so support cannot tell which choice text the member saw.",
          "acceptanceCriteria": [
            "Append subject, purpose, choice, UTC instant and notice version for each accepted change.",
            "Preserve the prior event and derive current state deterministically.",
            "Reject unknown notice versions and keep notice content immutable once referenced.",
            "Derive the subject from authenticated authority and enforce subject/tenant authorization for preference mutations at the repository boundary."
          ],
          "implementationNotes": [
            "Use bounded metadata; do not collect device fingerprints or unrelated browsing history to record a choice."
          ],
          "verification": [
            "Change a preference twice under two published notice versions and inspect the retained events.",
            "Submit an unknown version and verify no state change or append.",
            "Attempt a foreign subject and a foreign tenant through the mutation boundary; verify denial with no preference state change or appended event."
          ],
          "deliverables": [
            "Versioned preference events and immutable notice fixtures"
          ],
          "rollout": "Publish notice versions before accepting their changes; corrections create new versions.",
          "skills": [
            "Event history",
            "Versioning"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "750a64f0-3ba2-447b-b9d4-d61ee3eff84c",
          "key": "RCONSENT-103",
          "title": "Make the preference form submit the user’s explicit final choice",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "choices",
          "dependsOn": [
            "RCONSENT-102"
          ],
          "scenario": "An autosave race restores a checked box after the user turns it off and navigates away.",
          "acceptanceCriteria": [
            "Represent pending, saved and failed states without presenting an unconfirmed value as saved.",
            "Use version-aware updates so an older response cannot overwrite a newer choice.",
            "Keep controls keyboard-operable and associate errors with the affected purpose."
          ],
          "implementationNotes": [
            "Do not use preselected optional choices or obscured controls as a substitute for the declared interaction contract."
          ],
          "verification": [
            "Complete two opposite updates out of order and verify the latest accepted choice appears.",
            "Fail a save and navigate back; the form must distinguish persisted state from the unsaved attempt."
          ],
          "deliverables": [
            "Preference form state and out-of-order response tests"
          ],
          "rollout": "Deploy with the versioned API; reverting the UI must not rewrite stored preference events.",
          "skills": [
            "Form state",
            "Accessible interaction"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            },
            {
              "field": "Accessibility",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7f253f55-67c7-4d35-8514-9055f61e44bd",
          "key": "RCONSENT-104",
          "title": "Recheck optional-message eligibility immediately before provider dispatch",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "dispatch",
          "dependsOn": [
            "RCONSENT-101",
            "RCONSENT-102"
          ],
          "scenario": "An audience list was built yesterday. A member who opted out this morning still receives the queued announcement.",
          "acceptanceCriteria": [
            "Evaluate current purpose-specific preference at the dispatch boundary.",
            "Suppress ineligible work with a recorded safe reason and no provider call.",
            "Define behavior when preference state is unavailable; optional delivery must not assume permission from a stale list."
          ],
          "implementationNotes": [
            "The audience snapshot is planning input, not final dispatch authority."
          ],
          "verification": [
            "Queue while enabled, opt out, then release the job and verify no provider request.",
            "Make the preference repository unavailable and verify the declared hold/suppression path without sending."
          ],
          "deliverables": [
            "Dispatch guard and stale-audience regressions"
          ],
          "rollout": "Deploy the guard before replaying old queue entries; monitor bounded suppression categories.",
          "skills": [
            "Authorization timing",
            "Queue processing"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Platform engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "92a73782-0f41-4a1e-8468-fc0736fde413",
          "key": "RCONSENT-105",
          "title": "Bind a queued announcement to its purpose and content revision",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "dispatch",
          "dependsOn": [
            "RCONSENT-101",
            "RCONSENT-104"
          ],
          "scenario": "An operator edits a queued campaign from a booking reminder into promotional content while retaining the original operational tag.",
          "acceptanceCriteria": [
            "Freeze purpose and content revision for each queued delivery request.",
            "Require a new reviewed request when a material content/purpose change occurs.",
            "Reject dispatch when the referenced purpose or content revision cannot be resolved."
          ],
          "implementationNotes": [
            "Use synthetic content and a local review state; this ticket sends nothing outside the provider double."
          ],
          "verification": [
            "Edit the source campaign after queueing and verify the queued revision remains identifiable.",
            "Attempt to retag optional content as operational through a mutable field and verify the request is rejected."
          ],
          "deliverables": [
            "Immutable dispatch request contract and revision tests"
          ],
          "rollout": "Version the queue payload and hold unresolved legacy jobs for explicit conversion.",
          "skills": [
            "Immutable inputs",
            "Purpose limitation"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3588ccaf-5c6a-418b-8f6b-9a1e1a2d8d9e",
          "key": "RCONSENT-106",
          "title": "Stop an opt-out retry from being lost behind an older opt-in event",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "dispatch",
          "dependsOn": [
            "RCONSENT-102",
            "RCONSENT-104"
          ],
          "scenario": "Preference events reach a delivery replica out of order. A delayed older opt-in restores eligibility after a newer opt-out.",
          "acceptanceCriteria": [
            "Apply a subject/purpose ordering rule with comparable revisions.",
            "Ignore older duplicates while preserving their receipt for bounded diagnosis.",
            "Expose replica freshness and define dispatch behavior when current ordering cannot be established."
          ],
          "implementationNotes": [
            "Wall-clock arrival order is not a reliable source revision; document the authority issuing revisions."
          ],
          "verification": [
            "Deliver opt-out, then older opt-in, then duplicate opt-out and verify current state remains disabled.",
            "Create a missing-revision gap and verify optional dispatch follows the declared fail-closed or authoritative-read path."
          ],
          "deliverables": [
            "Replica ordering protocol and event permutation tests"
          ],
          "rollout": "Canary replica reads with authoritative comparisons; disable replica-based optional dispatch if gaps cannot be resolved.",
          "skills": [
            "Event ordering",
            "Consistency"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d75a61ce-6f11-4c53-a9e2-9156e7143965",
          "key": "RCONSENT-107",
          "title": "Explain which queued messages an opt-out can still prevent",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "review",
          "dependsOn": [
            "RCONSENT-103",
            "RCONSENT-104",
            "RCONSENT-105"
          ],
          "scenario": "The settings page promises instant cancellation even when the provider has already accepted a message that cannot be recalled.",
          "acceptanceCriteria": [
            "Define queued, dispatching, provider-accepted and completed boundaries.",
            "Describe prevention guarantees in user-facing copy consistent with those states.",
            "Cancel controllable work and report when a provider-accepted message is beyond the supported recall boundary."
          ],
          "implementationNotes": [
            "Do not claim that recording a preference change reverses an already completed delivery."
          ],
          "verification": [
            "Opt out at each controlled boundary and compare provider calls with displayed status.",
            "Simulate a provider without recall support and verify the interface does not show a false cancellation success."
          ],
          "deliverables": [
            "Cancellation state contract and truthful settings copy"
          ],
          "rollout": "Publish the clarified contract with the dispatch guard; preserve accepted-delivery history under the declared retention policy.",
          "skills": [
            "State semantics",
            "Product communication"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "dfc34299-dab1-4af3-9c5f-b2ac3e76b6ab",
          "key": "RCONSENT-108",
          "title": "Expose preference history only to its subject and scoped support role",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "review",
          "dependsOn": [
            "RCONSENT-102",
            "RCONSENT-107"
          ],
          "scenario": "A support page returns all members’ preference histories after checking only that the requester has any staff role.",
          "acceptanceCriteria": [
            "Apply subject or tenant-scoped support authorization at the repository boundary.",
            "Return purpose, choice, notice version and time without unrelated contact details.",
            "Audit privileged history access using safe identifiers and bounded reason categories."
          ],
          "implementationNotes": [
            "An audit event records access, not an inference about why a person made their choice."
          ],
          "verification": [
            "Read the matching subject’s history and an authorized support fixture.",
            "Attempt a foreign-tenant subject and an unscoped staff role; verify denial and no history leakage."
          ],
          "deliverables": [
            "Scoped history endpoint and access regressions"
          ],
          "rollout": "Enable the history view after repository-level checks pass; keep analytics separate from preference content.",
          "skills": [
            "Access control",
            "Minimal disclosure"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Privacy engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        },
        {
          "id": "d441dfe4-aa51-43d0-b7f0-290b45163fb0",
          "key": "RCONSENT-109",
          "title": "Reconcile audience caches without restoring old optional choices",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "review",
          "dependsOn": [
            "RCONSENT-104",
            "RCONSENT-106"
          ],
          "scenario": "A nightly audience rebuild copies an old export over the current preference cache.",
          "acceptanceCriteria": [
            "Bind rebuild inputs to a declared cutoff and subject/purpose revisions.",
            "Prevent rebuild writes from replacing newer authoritative or replicated choices.",
            "Report missing and contradictory inputs as reconciliation exceptions."
          ],
          "implementationNotes": [
            "Treat audience caches as derived state; preserve current choice authority outside the rebuild."
          ],
          "verification": [
            "Run a rebuild while a member opts out and verify the newer revision wins.",
            "Feed contradictory same-revision values and verify the rebuild stops or quarantines them without guessing."
          ],
          "deliverables": [
            "Audience reconciliation and concurrent-choice tests"
          ],
          "rollout": "Build into a new cache generation and switch only after consistency checks; retain the prior generation for diagnosis.",
          "skills": [
            "Cache reconciliation",
            "Conflict handling"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "91ae98b2-019e-4078-9c93-a2d73d4d4271",
          "key": "RCONSENT-110",
          "title": "Rehearse preference enforcement from settings through provider acknowledgement",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 270,
          "phaseId": "review",
          "dependsOn": [
            "RCONSENT-103",
            "RCONSENT-105",
            "RCONSENT-106",
            "RCONSENT-107",
            "RCONSENT-108",
            "RCONSENT-109"
          ],
          "scenario": "Unit tests cover the checkbox and worker separately, but not a user changing a preference while replicas lag and provider requests are in flight.",
          "acceptanceCriteria": [
            "Run a deterministic end-to-end matrix of opt-in/out, replica delay, queued work and provider acknowledgement.",
            "Reconcile every provider request with the exact purpose, content and evaluated preference revisions.",
            "Report tested conditions and unavoidable in-flight limits without claiming legal consent compliance."
          ],
          "implementationNotes": [
            "All deliveries terminate at a fake provider; the exercise never sends messages to real recipients."
          ],
          "verification": [
            "Exercise out-of-order events and opt-out at each dispatch boundary.",
            "Fail preference lookup and provider acknowledgement separately, then verify retries cannot send an ineligible optional message."
          ],
          "deliverables": [
            "Preference-enforcement rehearsal and decision trace"
          ],
          "rollout": "Enable the full synthetic workflow only after the matrix passes; hold optional dispatch when authority or revision consistency is unresolved.",
          "skills": [
            "Workflow testing",
            "Policy enforcement"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 40
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "df8e1208-e1cc-413d-9e0a-2dad2eb5bde9",
      "key": "RTELEMETRY",
      "title": "Measure a workflow without collecting its private content",
      "summary": "Build an allowlisted telemetry boundary, useful aggregates and controlled diagnostic access.",
      "context": "A fictional document workspace wants to measure upload completion and failure. Its prototype sends filenames, document titles and raw errors to general analytics. Replace that path with a minimal event contract using synthetic traffic.",
      "stack": [
        "TypeScript",
        "JSON Schema",
        "HTTP collector double",
        "SQL"
      ],
      "prerequisites": [
        "Create synthetic upload workflows and a local collector that captures received payloads.",
        "Define measurement questions and a separate restricted diagnostic store fixture."
      ],
      "developerValue": "Practice minimization, safe failure handling and correct aggregates.",
      "companyValue": "Produce useful operational measurements with a reviewable collection boundary and disclosure regression suite.",
      "delivery": "Ten tickets using synthetic data. No claim of anonymization, privacy certification or measured customer behavior is made.",
      "phases": [
        {
          "id": "contract",
          "title": "Specify minimal measurement",
          "goal": "Define useful questions and an allowlisted event schema."
        },
        {
          "id": "boundary",
          "title": "Enforce collection limits",
          "goal": "Reject accidental content, separate diagnostics and bound retention."
        },
        {
          "id": "aggregate",
          "title": "Verify useful reporting",
          "goal": "Reconcile aggregates and test disclosure under failures."
        }
      ],
      "field": "Privacy engineering",
      "tickets": [
        {
          "id": "d894ff32-ed06-4fc9-aa15-05ce68a0a240",
          "key": "RTELEMETRY-101",
          "title": "Translate upload questions into bounded telemetry events",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 60,
          "phaseId": "contract",
          "dependsOn": [],
          "scenario": "Product wants to understand upload failures, but the event captures the entire form submission.",
          "acceptanceCriteria": [
            "Define attempted, accepted, completed and failed events with bounded reason categories.",
            "Map every field to a stated measurement question.",
            "Exclude filenames, document text, form values and unrestricted URLs."
          ],
          "implementationNotes": [
            "Counts describe workflow outcomes, not ability, attention or authorship."
          ],
          "verification": [
            "Answer the stated questions from a synthetic sequence.",
            "Remove a field without a measurement purpose and verify the report remains possible."
          ],
          "deliverables": [
            "Question map and minimal event contract"
          ],
          "rollout": "Review the contract before changing collection; unknown fields remain disallowed.",
          "skills": [
            "Event modeling",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 80
            },
            {
              "field": "Data engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "ca51ee9c-678e-4b6d-b704-5837c27ff255",
          "key": "RTELEMETRY-102",
          "title": "Reject unknown telemetry fields at the sending boundary",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [
            "RTELEMETRY-101"
          ],
          "scenario": "Spreading an error object into an event accidentally includes headers and document metadata.",
          "acceptanceCriteria": [
            "Build payloads through a runtime schema with unknown-field rejection.",
            "Expose a typed interface that does not accept arbitrary payload spreading.",
            "Report rejection without echoing the rejected payload."
          ],
          "implementationNotes": [
            "The runtime boundary must handle loosely typed callers as well as normal TypeScript code."
          ],
          "verification": [
            "Send a valid completion and inspect the collector payload.",
            "Add token-like headers, nested objects and unknown properties; no event may reach the collector."
          ],
          "deliverables": [
            "Telemetry boundary and rejection tests"
          ],
          "rollout": "Route events through the boundary before retiring the old sender.",
          "skills": [
            "Runtime validation",
            "Information boundaries"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4ae8c056-86ba-401d-b122-724f2aa886e4",
          "key": "RTELEMETRY-103",
          "title": "Use a short-lived workflow correlation ID with a defined scope",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "contract",
          "dependsOn": [
            "RTELEMETRY-101",
            "RTELEMETRY-102"
          ],
          "scenario": "Analytics uses the account email as a permanent join key for all uploads.",
          "acceptanceCriteria": [
            "Use a random operation ID limited to one workflow and its bounded retry window.",
            "Exclude account, document and contact identifiers from the ID.",
            "Document linkability within the operation rather than calling the event anonymous."
          ],
          "implementationNotes": [
            "Keep subject mapping outside the generic sink; collect correlation only when required for the stated question."
          ],
          "verification": [
            "Retry one operation and verify intended correlation, then start another with a new ID.",
            "Inspect IDs and payloads for subject or document fields."
          ],
          "deliverables": [
            "Correlation lifecycle and identifier tests"
          ],
          "rollout": "Version the schema and stop emitting direct identifiers before comparing reports.",
          "skills": [
            "Pseudonymous identifiers",
            "Retention scope"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 100
            }
          ],
          "patterns": []
        },
        {
          "id": "8620bd55-16c3-46ce-abf8-52420eccda58",
          "key": "RTELEMETRY-104",
          "title": "Map upload errors to safe categories before analytics dispatch",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "boundary",
          "dependsOn": [
            "RTELEMETRY-102"
          ],
          "scenario": "An unfamiliar storage exception contains a signed URL. The fallback serializes it into analytics.",
          "acceptanceCriteria": [
            "Map known failures to bounded categories and unknown failures to a generic category.",
            "Never send raw messages, stacks, headers or signed URLs through generic telemetry.",
            "Route justified detailed diagnostics through a separate restricted interface."
          ],
          "implementationNotes": [
            "Do not rely on a regular expression to find every possible secret in an arbitrary object."
          ],
          "verification": [
            "Classify known storage, validation and timeout errors.",
            "Inject an unfamiliar nested error with a token-like URL and verify only the generic category is emitted."
          ],
          "deliverables": [
            "Safe classifier and nested-error fixtures"
          ],
          "rollout": "Deploy the safe fallback before expanding error coverage.",
          "skills": [
            "Error handling",
            "Safe defaults"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "35f5de4a-47fc-414e-b58f-68953de9ddd0",
          "key": "RTELEMETRY-105",
          "title": "Keep restricted upload diagnostics out of the analytics transport",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "boundary",
          "dependsOn": [
            "RTELEMETRY-103",
            "RTELEMETRY-104"
          ],
          "scenario": "Support needs a detailed failure record, but the proposed implementation reuses analytics permissions and transport.",
          "acceptanceCriteria": [
            "Create a separate diagnostic store with tenant-scoped access.",
            "Collect only justified fields with a bounded retention period.",
            "Use safe references for an authorized diagnostic lookup rather than exposing details in counters."
          ],
          "implementationNotes": [
            "Use synthetic errors; omit credentials and private upload bytes even from this exercise diagnostic store."
          ],
          "verification": [
            "Read a diagnostic as an authorized scoped operator.",
            "Attempt cross-tenant access and inspect analytics requests to verify no diagnostic details pass through them."
          ],
          "deliverables": [
            "Restricted diagnostics and transport-separation tests"
          ],
          "rollout": "Enable diagnostics independently; analytics must work when diagnostics are disabled.",
          "skills": [
            "Access separation",
            "Operational privacy"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "48670ee9-cd20-4a55-bbf4-cc6c36ec6a55",
          "key": "RTELEMETRY-106",
          "title": "Drop telemetry safely when validation or the collector fails",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "boundary",
          "dependsOn": [
            "RTELEMETRY-102",
            "RTELEMETRY-104"
          ],
          "scenario": "The validation failure handler prints the original event, leaking the content the guard rejected.",
          "acceptanceCriteria": [
            "Never log the rejected event payload.",
            "Keep optional analytics failure independent of upload completion with bounded buffers and retries.",
            "Count dropped events through safe categories so gaps remain visible."
          ],
          "implementationNotes": [
            "A collector outage must not block the workflow or grow an unlimited in-memory queue."
          ],
          "verification": [
            "Fail validation and inspect captured logs and requests for the rejected marker.",
            "Disconnect the collector under sustained synthetic events and verify bounded buffering and successful uploads."
          ],
          "deliverables": [
            "Safe fallback and outage regressions"
          ],
          "rollout": "Ship the fallback before stricter validation; drop optional events rather than exposing raw content.",
          "skills": [
            "Failure containment",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ff0198b3-696b-4f46-a50d-deb1fea7808e",
          "key": "RTELEMETRY-107",
          "title": "Expire raw workflow events while preserving only approved aggregates",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "boundary",
          "dependsOn": [
            "RTELEMETRY-103",
            "RTELEMETRY-105",
            "RTELEMETRY-106"
          ],
          "scenario": "Correlation-bearing raw events remain forever although reporting needs only daily counts.",
          "acceptanceCriteria": [
            "Version fictional raw-event and aggregate retention rules.",
            "Remove expired raw events from the declared sink and replay buffers.",
            "Report unresolved copies and avoid assuming aggregates cannot identify people."
          ],
          "implementationNotes": [
            "Use injected time and local adapters; retention values are exercise inputs, not real-world policy advice."
          ],
          "verification": [
            "Advance beyond raw expiry and verify sink and replay cleanup while permitted counts remain.",
            "Fail one cleanup adapter and verify its unresolved location appears in the report."
          ],
          "deliverables": [
            "Telemetry retention job and copy-reconciliation cases"
          ],
          "rollout": "Preview eligibility before removal and version aggregate definitions when collection changes.",
          "skills": [
            "Retention engineering",
            "Aggregation"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 60
            },
            {
              "field": "Data engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4fd76377-2c25-4355-8224-20e4b15853cc",
          "key": "RTELEMETRY-108",
          "title": "Suppress small-group reports under the exercise disclosure rule",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 270,
          "phaseId": "aggregate",
          "dependsOn": [
            "RTELEMETRY-101",
            "RTELEMETRY-103",
            "RTELEMETRY-107"
          ],
          "scenario": "Filtering a report to a tiny group reveals one person’s workflow even when source events omit email.",
          "acceptanceCriteria": [
            "Apply an exercise threshold of 10 distinct synthetic subjects through a separately restricted aggregation fixture.",
            "Prevent supported filter combinations and complementary totals from releasing a suppressed value.",
            "Document that thresholding addresses a specific disclosure path and does not prove anonymity or differential privacy."
          ],
          "implementationNotes": [
            "Do not add permanent subject IDs to the general event sink to support this exercise; define the separate aggregation boundary and tested query family."
          ],
          "verification": [
            "Query small, large and overlapping groups and inspect API plus report downloads.",
            "Attempt deduction from a total and complementary group; verify the declared release rule suppresses the relevant results."
          ],
          "deliverables": [
            "Report-release rule, disclosure fixtures and limitations"
          ],
          "rollout": "Keep fine-grained reports disabled until the rule and tested limits are reviewed.",
          "skills": [
            "Disclosure control",
            "Aggregation boundaries"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 70
            },
            {
              "field": "Data engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "fe1d176e-5aa8-4b9a-8ad3-faa7ad5256c4",
          "key": "RTELEMETRY-109",
          "title": "Reconcile upload outcome counts without hiding dropped telemetry",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "aggregate",
          "dependsOn": [
            "RTELEMETRY-101",
            "RTELEMETRY-106",
            "RTELEMETRY-107"
          ],
          "scenario": "The success percentage rises during a collector outage because failed uploads lose terminal events.",
          "acceptanceCriteria": [
            "Define denominators and windows from the event contract.",
            "Expose incomplete operations and dropped events instead of treating missing completion as success.",
            "Mark comparisons incomplete when collection gaps prevent a supported result."
          ],
          "implementationNotes": [
            "Keep uncertainty visible; never invent missing user behavior with model guesses."
          ],
          "verification": [
            "Replay success, failure, duplicate and missing-terminal sequences and reconcile counts.",
            "Simulate asymmetric loss and verify the report is incomplete rather than improved."
          ],
          "deliverables": [
            "Outcome aggregation and collection-gap regressions"
          ],
          "rollout": "Compare the new calculation with the old one on synthetic traces before changing the report.",
          "skills": [
            "Metrics correctness",
            "Uncertainty"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Data engineering",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "5d610747-4591-44af-8cd4-c394bc8885db",
          "key": "RTELEMETRY-110",
          "title": "Test telemetry collection with planted private-content markers",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 270,
          "phaseId": "aggregate",
          "dependsOn": [
            "RTELEMETRY-102",
            "RTELEMETRY-104",
            "RTELEMETRY-105",
            "RTELEMETRY-106",
            "RTELEMETRY-107",
            "RTELEMETRY-108",
            "RTELEMETRY-109"
          ],
          "scenario": "The contract looks safe, but errors, retries and report downloads may bypass the sending boundary.",
          "acceptanceCriteria": [
            "Plant unique synthetic markers in filenames, titles, headers, errors and form values.",
            "Exercise success, retry, validation failure, collector outage and report download paths.",
            "Verify markers never reach generic telemetry or logs while required aggregate questions remain answerable."
          ],
          "implementationNotes": [
            "Passing supports only inspected conditions and boundaries, not a blanket no-leak guarantee."
          ],
          "verification": [
            "Search collector captures, fallback logs and downloaded reports for every marker.",
            "Add a deliberate bypass to the test sender and confirm the regression detects it; verify the guarded implementation passes."
          ],
          "deliverables": [
            "Disclosure regression matrix and boundary review"
          ],
          "rollout": "Run the matrix when schemas or sending paths change; block the exercise release on a prohibited disclosure.",
          "skills": [
            "Privacy testing",
            "Defense in depth"
          ],
          "fieldMix": [
            {
              "field": "Privacy engineering",
              "percentage": 50
            },
            {
              "field": "Quality engineering",
              "percentage": 50
            }
          ],
          "patterns": []
        }
      ]
    },
    {
      "id": "f23c3a94-95e0-4d93-9654-9475fc67ceec",
      "key": "PPOLICY",
      "title": "Untangle partner pricing without changing issued quotes",
      "field": "Backend",
      "summary": "Evolve a quoting module as partner contracts diverge, while keeping calculations reproducible and abstractions proportional to the problem.",
      "context": "A fictional equipment-rental service supports direct customers and two reseller contracts. Pricing now lives in a long conditional with subclasses left over from a discontinued campaign. Build a local TypeScript quoting module and synthetic fixtures; no starter repository, real charges, tax advice, or payment connection is supplied. Amounts use integer cents and the exercise supports USD only.",
      "stack": [
        "TypeScript",
        "Node.js",
        "Vitest"
      ],
      "prerequisites": [
        "Pure functions",
        "Object composition",
        "Integer arithmetic"
      ],
      "developerValue": "Practice choosing, testing, and removing object-design abstractions around versioned business rules and tenant isolation.",
      "companyValue": "Review changes that let a team introduce a contract without silently changing existing quotes, together with the maintenance costs of the chosen design.",
      "delivery": "Ten linked tickets in three phases. Create the declared local fixtures and module; deliver reproducible quotes, a migration comparison, and a short design decision record.",
      "phases": [
        {
          "id": "baseline",
          "title": "Pin down the contract",
          "goal": "Make quote inputs and current calculations explicit."
        },
        {
          "id": "variation",
          "title": "Support controlled variation",
          "goal": "Introduce contract differences without mutable rule leakage."
        },
        {
          "id": "simplify",
          "title": "Migrate and simplify",
          "goal": "Keep version boundaries stable and remove unsupported complexity."
        }
      ],
      "tickets": [
        {
          "id": "3fc1c4b6-77ab-4198-a325-cfeeb4fd4539",
          "key": "PPOLICY-101",
          "title": "Capture the reseller examples before splitting the pricing branch",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Support cannot explain why a reseller receives a different total after a harmless-looking cleanup. Recreate a small baseline: direct pricing uses list price; reseller A gets 10% off; reseller B gets 15% off only from ten units. Round the final discount down to whole cents.",
          "acceptanceCriteria": [
            "Record input, contract identity, quantity, list amount, discount, and final amount for each example.",
            "Cover quantities 1, 9, 10, and 11 plus a list amount that produces a fractional-cent discount.",
            "Document whether a function table or Strategy interface would make the current three rules easier to change; either is acceptable with reasons."
          ],
          "implementationNotes": [
            "Keep the baseline independent of the replacement implementation; reject non-integer quantities and negative list amounts."
          ],
          "verification": [
            "Check manually calculated expected totals against the baseline fixtures.",
            "Introduce an off-by-one tier boundary and confirm the relevant fixture fails."
          ],
          "deliverables": [
            "Characterization fixtures and a one-page abstraction decision"
          ],
          "rollout": "Use this baseline as the comparison gate for later local changes; retain the original calculations until all differences are explained.",
          "skills": [
            "Characterization testing",
            "Domain modeling",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "strategy",
              "activity": "COMPARE",
              "focus": "Compare a small function table with interchangeable pricing strategies before adding an interface to three fixed contract rules."
            }
          ]
        },
        {
          "id": "34c7f9de-da05-47bf-8864-da3084479aac",
          "key": "PPOLICY-102",
          "title": "Stop incomplete quote requests reaching the calculator",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "PPOLICY-101"
          ],
          "scenario": "The batch caller sometimes omits the pricing revision and the web caller sends quantity as text. Both currently reach calculation through a partially populated options object.",
          "acceptanceCriteria": [
            "A quote request requires tenant, contract revision, nonempty product identity, positive integer quantity, and a nonnegative integer unit price.",
            "Construction fails with field-level errors before any pricing rule runs.",
            "Compare a staged Builder with a validated constructor or factory; select the smallest interface that cannot expose an incomplete request."
          ],
          "implementationNotes": [
            "Do not silently fill the contract revision from a mutable global default; runtime input validation remains necessary with TypeScript."
          ],
          "verification": [
            "Construct equivalent valid requests from the synthetic batch and web inputs.",
            "Reject missing revision, quantity 'ten', and quantity zero while asserting the calculator was not called."
          ],
          "deliverables": [
            "Validated request construction API and invalid-input fixtures"
          ],
          "rollout": "Route the two local callers through validation together; keep error mapping compatible with their declared response contracts.",
          "skills": [
            "Input validation",
            "API design",
            "Type modeling"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "API design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "builder",
              "activity": "COMPARE",
              "focus": "Assess whether staged construction adds value for quote inputs, or a validated immutable constructor provides the same guarantees more clearly."
            }
          ]
        },
        {
          "id": "5c0ee958-87db-4c38-816f-b7134ef73970",
          "key": "PPOLICY-103",
          "title": "Add a capped volume contract without editing the existing rules",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "PPOLICY-101",
            "PPOLICY-102"
          ],
          "scenario": "Reseller C needs 20% off from twenty units, capped at 5,000 cents per quote. The current conditional is also used by the other resellers, whose issued quotes must remain reproducible.",
          "acceptanceCriteria": [
            "Select a pricing rule by explicit contract and revision, returning a typed error for an unknown combination.",
            "Implement the threshold and cap while preserving every existing baseline result.",
            "Return a stable rule identity and a breakdown showing the uncapped discount and applied cap."
          ],
          "implementationNotes": [
            "Use composition or a function-valued Strategy; adding a class hierarchy is not required. Keep rule evaluation free of I/O."
          ],
          "verification": [
            "Exercise quantities 19 and 20 with discounts below, at, and above 5,000 cents.",
            "Request a retired or unknown revision and confirm no fallback contract is used."
          ],
          "deliverables": [
            "Capped pricing rule, selector, and regression fixtures"
          ],
          "rollout": "Enable reseller C only in the synthetic scenario set; keep the previous selector available for baseline replay.",
          "skills": [
            "Strategy selection",
            "Pure functions",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "System design",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "strategy",
              "activity": "APPLY",
              "focus": "Isolate the capped volume calculation behind the same contract used by existing rules, without adding reseller-specific branches to the caller."
            }
          ]
        },
        {
          "id": "b1ac5413-b296-4a2f-9f36-40377947fecc",
          "key": "PPOLICY-104",
          "title": "Share quote assembly between the portal and nightly import",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "variation",
          "dependsOn": [
            "PPOLICY-103"
          ],
          "scenario": "The portal and nightly CSV import each construct their own rule selector. A contract was enabled in the portal but missing from the import, producing different errors for the same customer.",
          "acceptanceCriteria": [
            "Both callers resolve the same contract revisions through one composition boundary.",
            "Caller-specific input parsing stays outside pricing rule creation.",
            "Compare an overridable Factory Method in a shared import workflow with an injected creation function; document the chosen extension boundary."
          ],
          "implementationNotes": [
            "Do not introduce dynamic module loading or a dependency-injection container for this local module."
          ],
          "verification": [
            "Feed equivalent portal and CSV inputs and compare rule identities, amounts, and unknown-contract errors.",
            "Inject a selector construction failure and confirm neither caller emits a partial quote."
          ],
          "deliverables": [
            "Shared assembly boundary and caller contract tests"
          ],
          "rollout": "Migrate one local caller at a time with parity tests; revert caller wiring if an unexplained difference appears.",
          "skills": [
            "Composition roots",
            "Refactoring",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "factory-method",
              "activity": "COMPARE",
              "focus": "Choose between an overridable creation step and an injected factory function for two workflows that must build the same pricing components."
            }
          ]
        },
        {
          "id": "b7f2c7d6-2fb4-4933-9e64-c2d8f49f0baf",
          "key": "PPOLICY-105",
          "title": "Keep calculation and explanation revisions in the same contract family",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "variation",
          "dependsOn": [
            "PPOLICY-104"
          ],
          "scenario": "A quote calculated with reseller C revision 2 displays revision 1 explanation text, which omits the cap. Separate registries allow a valid calculator to be paired with an incompatible explainer.",
          "acceptanceCriteria": [
            "Resolve calculator and structured explainer as one contract family with a shared revision identity.",
            "Reject a family whose members declare different revisions before serving a quote.",
            "Compare an Abstract Factory with one immutable family record; preserve independent tests for calculation and explanation."
          ],
          "implementationNotes": [
            "Explanation output must use the actual calculation breakdown rather than recalculating the discount or parsing a display string."
          ],
          "verification": [
            "Generate explanations for capped and uncapped quotes and reconcile every reported amount.",
            "Deliberately pair revision 2 calculation with revision 1 explanation and assert assembly rejection."
          ],
          "deliverables": [
            "Contract-family resolver, mismatch fixture, and design comparison"
          ],
          "rollout": "Run family validation at local startup; keep the prior complete family available rather than rolling back individual members.",
          "skills": [
            "Abstract factories",
            "Version compatibility",
            "Invariant testing"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "abstract-factory",
              "activity": "COMPARE",
              "focus": "Keep the calculator and explainer revision-compatible as a family while evaluating whether a factory interface adds value beyond an immutable record."
            }
          ]
        },
        {
          "id": "d6d7cee3-4c58-45eb-80fc-7ee46fc8ee80",
          "key": "PPOLICY-106",
          "title": "Remove the rounding hook that bypasses the quote cap",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "variation",
          "dependsOn": [
            "PPOLICY-105"
          ],
          "scenario": "An inherited calculate method calls a reseller override after the cap check. That override recomputes the discount, so the supposed fixed algorithm no longer enforces its own invariant.",
          "acceptanceCriteria": [
            "Make the order explicit: validate, evaluate the selected rule, apply its declared cap, then derive the final amount and explanation.",
            "No extension point can change the applied amount after the final invariant check.",
            "Replace the unsafe Template Method hook with a narrower composed operation or justify a sealed algorithm with constrained inputs."
          ],
          "implementationNotes": [
            "Preserve published rule revision behavior where valid; represent the defective synthetic revision explicitly instead of rewriting issued quote fixtures."
          ],
          "verification": [
            "Reproduce the subclass cap bypass and show the corrected pipeline respects the cap.",
            "Supply an extension returning a negative or over-subtotal discount and verify a typed failure."
          ],
          "deliverables": [
            "Pipeline refactor and cap-bypass regression"
          ],
          "rollout": "Compare old and corrected revision outputs in a local replay; activate a new revision only after listing intentional differences.",
          "skills": [
            "Inheritance refactoring",
            "Domain invariants",
            "Regression analysis"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "template-method",
              "activity": "REFACTOR",
              "focus": "Constrain or replace the inherited algorithm hooks so a reseller extension cannot undo a discount cap after validation."
            },
            {
              "pattern": "strategy",
              "activity": "APPLY",
              "focus": "Move the variable discount calculation into a narrow composed operation whose result is checked by the common quoting pipeline."
            }
          ]
        },
        {
          "id": "5004cd3b-3768-48f3-8d0c-1d8293ccadf8",
          "key": "PPOLICY-107",
          "title": "Keep a cloned contract draft from changing the live tier table",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "variation",
          "dependsOn": [
            "PPOLICY-103"
          ],
          "scenario": "A sales-operations preview shallow-copies a contract and changes a nested tier. The original contract shares the array and immediately starts quoting the draft rate.",
          "acceptanceCriteria": [
            "A draft receives its own identity, source revision reference, and independently editable tier values.",
            "Editing, reordering, or deleting a draft tier cannot affect the published contract or another draft.",
            "Reject unsupported values during cloning instead of silently dropping them through JSON serialization."
          ],
          "implementationNotes": [
            "Limit the prototype to a declared data-only contract schema; do not clone provider handles, functions, or process state."
          ],
          "verification": [
            "Clone two drafts, mutate nested data in one, and compare all three contract snapshots.",
            "Attempt to clone an invalid tier boundary and confirm no partial draft is returned."
          ],
          "deliverables": [
            "Schema-aware prototype copy and aliasing regression fixtures"
          ],
          "rollout": "Use the new copy path for synthetic previews; existing published fixture revisions remain immutable.",
          "skills": [
            "Copy semantics",
            "Immutability",
            "Schema validation"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "prototype",
              "activity": "REFACTOR",
              "focus": "Replace a shallow contract clone with a schema-aware draft copy that preserves provenance while preventing shared mutable tier arrays."
            }
          ]
        },
        {
          "id": "31acf123-bf3f-4788-aed6-44e052a52718",
          "key": "PPOLICY-108",
          "title": "Remove the process-wide current-partner setting",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "simplify",
          "dependsOn": [
            "PPOLICY-104",
            "PPOLICY-107"
          ],
          "scenario": "The quote singleton stores currentPartner before resolving a contract. Two overlapping synthetic requests can change that value between validation and calculation, applying one tenant's negotiated rate to another.",
          "acceptanceCriteria": [
            "Tenant and contract identity travel explicitly through each quote operation.",
            "Remove mutable request state from the Singleton; shared immutable rule definitions may remain cached.",
            "Any remaining cache uses tenant, contract, and revision in its identity and cannot expose another tenant's rule configuration."
          ],
          "implementationNotes": [
            "Do not serialize all requests behind a global lock to hide the leak; preserve independent concurrent execution."
          ],
          "verification": [
            "Interleave requests for two tenants at a controlled barrier and assert both receive their own rate.",
            "Repeat the test after a failed request and a cache hit to detect stale tenant state."
          ],
          "deliverables": [
            "Explicit request context and tenant-isolation concurrency regression"
          ],
          "rollout": "Switch the local composition root to stateless quotation; discard the old mutable cache on rollback or restart.",
          "skills": [
            "Tenant isolation",
            "Dependency injection",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 50
            }
          ],
          "patterns": [
            {
              "pattern": "singleton",
              "activity": "REMOVE",
              "focus": "Remove a globally mutable partner context that leaks negotiated rules across overlapping requests, while allowing immutable shared definitions."
            }
          ]
        },
        {
          "id": "87cb58d7-9f09-4be8-ad06-e8c1fbdf547c",
          "key": "PPOLICY-109",
          "title": "Pin a quote to one rule family during a revision switch",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "simplify",
          "dependsOn": [
            "PPOLICY-105",
            "PPOLICY-106",
            "PPOLICY-108"
          ],
          "scenario": "A local replay switches a partner from revision 2 to 3 while quotes are in progress. Resolving the calculator at request start and the explainer at response time can produce a mixed-revision quote even after family validation.",
          "acceptanceCriteria": [
            "Resolve and retain one immutable family snapshot for the complete quote operation.",
            "Switches affect only newly started operations; stored quotes retain inputs, family revision, and sufficient breakdown for deterministic replay.",
            "A malformed replacement family is rejected without displacing the last valid selection, and rollback selects a previous complete family."
          ],
          "implementationNotes": [
            "Use an in-process deterministic scheduler for the exercise; a distributed configuration service is outside scope."
          ],
          "verification": [
            "Pause a quote between calculation and explanation, switch revisions, and verify each concurrent quote is internally consistent.",
            "Reject an incompatible family, perform a rollback, and replay an earlier quote against its pinned revision."
          ],
          "deliverables": [
            "Atomic family selection, interleaving tests, and revision-switch runbook"
          ],
          "rollout": "Exercise old/new/rollback sequences against synthetic requests; report differences by explicit revision without modifying prior quote records.",
          "skills": [
            "Versioned configuration",
            "Concurrency",
            "Deterministic replay"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "abstract-factory",
              "activity": "REFACTOR",
              "focus": "Make family resolution yield a stable snapshot so a revision switch cannot mix products created at different moments in the same operation."
            }
          ]
        },
        {
          "id": "ba578554-b3c6-4040-8f0c-a517b10aa52a",
          "key": "PPOLICY-110",
          "title": "Retire the campaign subclass ladder after the migration",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "simplify",
          "dependsOn": [
            "PPOLICY-106",
            "PPOLICY-109"
          ],
          "scenario": "Five subclass layers still exist for a campaign that ended in the synthetic history. Only one leaf is constructible, but changing an error message requires following overridden methods through every layer.",
          "acceptanceCriteria": [
            "Map reachable construction paths and separate archived-revision replay requirements from unused extension points.",
            "Remove unused Factory Method and Template Method layers while preserving supported quote and error contracts.",
            "Show the before/after change surface for adding a new rule, and retain an abstraction only where it supports a stated variation."
          ],
          "implementationNotes": [
            "Keep archived calculations callable through explicit revision lookup; deleting old classes must not make existing fixture quotes unreplayable."
          ],
          "verification": [
            "Run the complete quote matrix and replay fixtures after simplifying the hierarchy.",
            "Request an unsupported campaign revision and confirm the same explicit failure, with no fallback to a current rule."
          ],
          "deliverables": [
            "Hierarchy simplification, construction-path inventory, and maintenance comparison"
          ],
          "rollout": "Remove dead paths in a separate local change after parity is established; revert the simplification if any supported revision becomes inaccessible.",
          "skills": [
            "Legacy refactoring",
            "Dead-code analysis",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "factory-method",
              "activity": "REMOVE",
              "focus": "Remove unused overridable creation layers once supported rule revisions have one explicit composition path."
            },
            {
              "pattern": "template-method",
              "activity": "REMOVE",
              "focus": "Collapse campaign inheritance hooks that no longer represent a live variation while preserving archived quote replay."
            }
          ]
        }
      ]
    },
    {
      "id": "c53257d1-9494-4266-a422-aff06e782168",
      "key": "PDOC",
      "title": "Make a document editor predictable as operations grow",
      "field": "Frontend",
      "summary": "Build a bounded browser editor whose tree operations, history, subscriptions, and exports remain coherent under failures and repeated use.",
      "context": "A fictional support team edits reusable troubleshooting documents with paragraphs, links, and nested sections. The browser prototype has separate toolbar and keyboard handlers, an unreliable undo stack, and mutable shared formatting objects. Create a local editor and synthetic documents; no starter assets, rich-text engine, collaborative backend, or production service is supplied.",
      "stack": [
        "TypeScript",
        "React",
        "Vitest",
        "Playwright"
      ],
      "prerequisites": [
        "Browser events",
        "Immutable updates",
        "Accessible form controls"
      ],
      "developerValue": "Practice relating object and state patterns to real UI behavior, including undo semantics, bounded traversal, lifecycle cleanup, and memory tradeoffs.",
      "companyValue": "Review whether editor changes preserve user work, keep controls consistent, and reduce maintenance effort without concealing document corruption.",
      "delivery": "Ten tickets across document structure, interaction consistency, and safe evolution. Build the stated local fixtures and return an editor demo, operation tests, and a short design record.",
      "phases": [
        {
          "id": "document",
          "title": "Establish document operations",
          "goal": "Make structure and editing commands consistent."
        },
        {
          "id": "interaction",
          "title": "Coordinate interaction",
          "goal": "Keep history, controls, and subscriptions tied to one document state."
        },
        {
          "id": "evolution",
          "title": "Exercise larger and changing documents",
          "goal": "Measure sharing and preserve compatibility under export and restoration."
        }
      ],
      "tickets": [
        {
          "id": "acb1e99c-e059-424a-90c0-b6e640121822",
          "key": "PDOC-101",
          "title": "Give nested sections and paragraphs one structural contract",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "document",
          "dependsOn": [],
          "scenario": "The outline view handles top-level paragraphs but crashes when a section contains another section. The current arrays do not distinguish leaves from containers or validate imported structure.",
          "acceptanceCriteria": [
            "Represent paragraphs as leaves and sections as containers with stable node identities and explicit discriminated types.",
            "Render and count text nodes consistently through three nested section levels.",
            "Reject duplicate node identities, cycles in programmatic input, and depth above the declared maximum of twenty."
          ],
          "implementationNotes": [
            "A Composite may use plain immutable data rather than classes. Keep document structure separate from React elements and DOM nodes."
          ],
          "verification": [
            "Render empty, flat, and nested synthetic documents and compare outline counts.",
            "Feed a duplicate identity and a cyclic structure to validation and assert bounded rejection without rendering."
          ],
          "deliverables": [
            "Document model, validator, and nested outline example"
          ],
          "rollout": "Enable the new model only after validating local sample documents; preserve an untouched input copy when migration rejects a document.",
          "skills": [
            "Tree modeling",
            "Input validation",
            "Component composition"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 80
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "composite",
              "activity": "APPLY",
              "focus": "Give leaf paragraphs and nested section containers a consistent traversal contract without coupling the document tree to rendered UI elements."
            }
          ]
        },
        {
          "id": "f62d3166-5845-46dc-9975-eec05d87a574",
          "key": "PDOC-102",
          "title": "Make Find next follow document order through collapsed sections",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "document",
          "dependsOn": [
            "PDOC-101"
          ],
          "scenario": "Find next walks visible DOM elements, so collapsing a section removes its paragraphs from search. Keyboard users cannot tell whether a result was skipped or the query ended.",
          "acceptanceCriteria": [
            "Traverse paragraph text in document preorder, independent of collapsed presentation state.",
            "Find next visits each matching node once, wraps explicitly, and reports position and total through an accessible status message.",
            "An empty query yields no results; a removed node cannot remain the active match after document revision changes."
          ],
          "implementationNotes": [
            "Use an Iterator or generator over a stable document snapshot; do not query the DOM to discover content."
          ],
          "verification": [
            "Find a match inside a collapsed section and verify the section opens and focus moves to its paragraph control.",
            "Delete the active result and change the query to no matches; confirm stale focus targets and counts are cleared."
          ],
          "deliverables": [
            "Snapshot traversal and keyboard search regression"
          ],
          "rollout": "Replace local search traversal while retaining the existing search control; fall back to document start when no prior result identity survives.",
          "skills": [
            "Iterators",
            "Keyboard interaction",
            "State invalidation"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Accessibility",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "iterator",
              "activity": "APPLY",
              "focus": "Traverse the document model in a stable order so search behavior does not change when presentation hides a section."
            }
          ]
        },
        {
          "id": "a6521057-dd7d-49ca-978e-a1038ae0473c",
          "key": "PDOC-103",
          "title": "Route toolbar and keyboard deletion through one command",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "document",
          "dependsOn": [
            "PDOC-101"
          ],
          "scenario": "Toolbar deletion removes an entire selected section, but the keyboard shortcut deletes only its heading and leaves orphaned paragraphs. The two handlers also record different undo entries.",
          "acceptanceCriteria": [
            "Both entry points issue one document command with target identity and expected document revision.",
            "Deleting a section removes its subtree atomically, updates selection to a documented surviving neighbor, and creates one history entry.",
            "Stale, missing, and protected-root targets return explicit failures with no document or history change."
          ],
          "implementationNotes": [
            "Command execution belongs outside presentation event handlers; do not store DOM references in history."
          ],
          "verification": [
            "Delete the same nested section through toolbar and keyboard and compare document, selection, and history results.",
            "Issue deletion against an old revision and the protected root; assert no partial update."
          ],
          "deliverables": [
            "Shared delete command and entry-point parity tests"
          ],
          "rollout": "Move both handlers in one local change to prevent mixed semantics; retain saved synthetic documents for replay if the command is reverted.",
          "skills": [
            "Command modeling",
            "Atomic state updates",
            "Interaction testing"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "command",
              "activity": "APPLY",
              "focus": "Represent deletion as one validated document operation shared by toolbar, keyboard, and history so entry points cannot diverge."
            }
          ]
        },
        {
          "id": "a95b295c-df6f-4b16-91ce-4689de6c5df7",
          "key": "PDOC-104",
          "title": "Restore selection together with content when undoing a deletion",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "interaction",
          "dependsOn": [
            "PDOC-103"
          ],
          "scenario": "Undo restores paragraph text but leaves the caret pointing to the deleted node identity. A second edit then modifies the wrong paragraph. History currently keeps an editable reference to the live tree.",
          "acceptanceCriteria": [
            "A history entry captures enough immutable document and selection state to restore one completed command consistently.",
            "Undo and redo restore content and logical selection, and a new edit after undo clears the redo branch.",
            "Retain at most fifty entries and disclose the boundary when older history is discarded; failed commands create no entry."
          ],
          "implementationNotes": [
            "Compare a Memento snapshot with inverse commands for this bounded editor; do not serialize focusable elements or browser event objects."
          ],
          "verification": [
            "Delete, undo, redo, undo, then type; verify the intended restored paragraph receives the edit.",
            "Mutate the live document after recording history and assert old entries remain unchanged; exercise the fifty-entry limit."
          ],
          "deliverables": [
            "Bounded undo/redo history and selection restoration tests"
          ],
          "rollout": "Start a new local history session on the upgraded model; existing saved document content remains readable even when transient old history is discarded.",
          "skills": [
            "Undo semantics",
            "Immutability",
            "Memory bounds"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "memento",
              "activity": "COMPARE",
              "focus": "Evaluate immutable state snapshots against inverse commands for restoring both document content and logical selection within a bounded undo history."
            }
          ]
        },
        {
          "id": "6868304d-900b-441b-9116-c72dbd15616a",
          "key": "PDOC-105",
          "title": "Stop closed editor tabs from receiving document updates",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "interaction",
          "dependsOn": [
            "PDOC-103"
          ],
          "scenario": "Opening and closing the preview panel twenty times makes one edit trigger twenty-one outline refreshes. Subscriptions remain in the document store after the panel unmounts.",
          "acceptanceCriteria": [
            "Each subscription has an idempotent unsubscribe operation tied to the subscribing component's lifetime.",
            "One committed document operation sends one versioned notification to each active subscriber, including when callbacks subscribe or unsubscribe during delivery.",
            "A failed subscriber does not stop delivery to other subscribers, and errors are reported without logging document content."
          ],
          "implementationNotes": [
            "Keep the Observer surface small and define whether delivery is synchronous; avoid a global application event bus for this document-local need."
          ],
          "verification": [
            "Mount and unmount the preview twenty times, edit once, and assert only active listeners run.",
            "Have one listener throw and another unsubscribe during delivery; verify remaining delivery and the next notification set."
          ],
          "deliverables": [
            "Subscription lifecycle fix and repeated-mount regression"
          ],
          "rollout": "Replace document-local subscriptions together; reset transient listeners on reload without changing saved document data.",
          "skills": [
            "Resource lifecycle",
            "Observer delivery",
            "Failure isolation"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "observer",
              "activity": "REFACTOR",
              "focus": "Repair subscription ownership and notification semantics so repeated panel mounts do not retain listeners or multiply document update work."
            }
          ]
        },
        {
          "id": "4eb95e06-4e73-455a-b30e-14cebf2068d8",
          "key": "PDOC-106",
          "title": "Untangle the toolbar's direct calls into three side panels",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "interaction",
          "dependsOn": [
            "PDOC-103",
            "PDOC-105"
          ],
          "scenario": "Selecting a link makes the toolbar call the inspector, the inspector call the outline, and the outline call the toolbar again. A new panel added another circular dependency and occasional repeated selection updates.",
          "acceptanceCriteria": [
            "Define one direction for selection intents and one authoritative logical selection state.",
            "Toolbar, inspector, and outline remain consistent without importing or invoking each other's component instances.",
            "Compare a document-scoped Mediator with reducer-driven state and callbacks; retain the simpler option that exposes event flow clearly."
          ],
          "implementationNotes": [
            "Do not move every unrelated editor concern into a central god object; keep document commands and formatting rules separately testable."
          ],
          "verification": [
            "Select a nested link from each panel and compare selection and enabled toolbar actions.",
            "Send the same selection intent twice and remove the selected node; assert bounded updates and a consistent empty selection."
          ],
          "deliverables": [
            "Interaction dependency refactor and selection-flow decision record"
          ],
          "rollout": "Migrate the three selection participants together in the local editor; retain command behavior and shortcut bindings during the change.",
          "skills": [
            "State ownership",
            "Dependency design",
            "UI architecture"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "mediator",
              "activity": "COMPARE",
              "focus": "Compare a document-scoped coordinator with reducer state to remove circular panel calls without creating a central object that owns every editor feature."
            }
          ]
        },
        {
          "id": "96b79ce6-223c-4957-a0cc-7fa4d58888cd",
          "key": "PDOC-107",
          "title": "Prevent edit actions while a replacement document is importing",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "interaction",
          "dependsOn": [
            "PDOC-104",
            "PDOC-106"
          ],
          "scenario": "Import sets isLoading but leaves isEditable true. A user types while the asynchronous parser runs, then the parsed document replaces those edits without a warning.",
          "acceptanceCriteria": [
            "Define explicit ready, importing, and import-failed states and legal transitions, including cancel and retry.",
            "Edit commands are rejected during replacement import, and controls expose their disabled reason accessibly.",
            "A failed or cancelled import preserves the prior document and selection; a late result from a cancelled attempt cannot replace them."
          ],
          "implementationNotes": [
            "A tagged union and transition function can implement State semantics; separate state representation from parsing work."
          ],
          "verification": [
            "Delay parsing, attempt a keyboard edit, and verify no hidden edit or unexpected replacement occurs.",
            "Cancel one import, start another, then resolve results in reverse order; only the current successful attempt may install a document."
          ],
          "deliverables": [
            "Import state transitions and delayed-result interaction tests"
          ],
          "rollout": "Replace boolean flags with the explicit local state model; keep the last valid document available until a replacement commits.",
          "skills": [
            "State machines",
            "Race handling",
            "Accessible feedback"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 70
            },
            {
              "field": "Accessibility",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "state",
              "activity": "APPLY",
              "focus": "Represent import lifecycle and command eligibility with explicit states so contradictory loading/editing flags cannot erase user work."
            }
          ]
        },
        {
          "id": "74682930-3a00-4410-910f-5e2eda81baad",
          "key": "PDOC-108",
          "title": "Measure whether sharing text styles is worth the indirection",
          "type": "TASK",
          "priority": "LOW",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "evolution",
          "dependsOn": [
            "PDOC-101",
            "PDOC-104"
          ],
          "scenario": "A generated 20,000-paragraph fixture repeats twelve formatting combinations. A proposed style pool reduces duplicate objects, but its mutable shared entries can change many paragraphs when one is edited.",
          "acceptanceCriteria": [
            "Compare plain immutable style values with Flyweight style identities using the same declared fixture and measurement procedure.",
            "If pooling is retained, intrinsic styles are immutable and per-paragraph selection or editing state stays outside the pool.",
            "Report memory observations and edit/undo latency across five runs, including environment and variance; retain the simpler representation if benefits are inconclusive."
          ],
          "implementationNotes": [
            "Measure the model separately from DOM rendering and keep the fixture size fixed; do not claim production performance from one browser snapshot."
          ],
          "verification": [
            "Change one paragraph's style and undo it without changing any other paragraph.",
            "Attempt to mutate an interned style and verify prevention; repeat opening and closing documents to check that unused pools are released."
          ],
          "deliverables": [
            "Reproducible comparison, isolation tests, and keep-or-remove decision"
          ],
          "rollout": "Keep style pooling behind a local representation switch until correctness and measurements support it; preserve a conversion back to plain values.",
          "skills": [
            "Memory profiling",
            "Immutability",
            "Performance experiments"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Frontend",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "flyweight",
              "activity": "COMPARE",
              "focus": "Measure immutable sharing of repeated formatting against plain values, while excluding mutable per-paragraph state from the shared objects."
            }
          ]
        },
        {
          "id": "a8b4d579-8a38-466e-9cb2-b7592c3e8646",
          "key": "PDOC-109",
          "title": "Add text and outline export without teaching nodes about file formats",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "evolution",
          "dependsOn": [
            "PDOC-101",
            "PDOC-102"
          ],
          "scenario": "Every new export format adds another method to paragraph and section objects. The team needs plain text and a structured outline, and expects document node types to change less often than export formats.",
          "acceptanceCriteria": [
            "Both exporters handle every supported node type and preserve documented section order and paragraph boundaries.",
            "Keep export operations outside the document data model using a Visitor or exhaustive discriminated-union functions, with a written choice.",
            "An unknown node type fails with its identity and type instead of silently losing its content."
          ],
          "implementationNotes": [
            "Treat link labels as text and serialize structured output through a serializer; exporting must not mutate document state or trigger network requests."
          ],
          "verification": [
            "Export a nested fixture containing empty sections and links and compare explicit expected outputs.",
            "Introduce an unsupported node kind and assert both exporters fail visibly while leaving the input unchanged."
          ],
          "deliverables": [
            "Two export operations, exhaustive handling tests, and variation tradeoff note"
          ],
          "rollout": "Add exports as local downloads after fixture comparison; disable one format independently if its contract changes.",
          "skills": [
            "Tree operations",
            "Exhaustive handling",
            "Serialization"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "visitor",
              "activity": "COMPARE",
              "focus": "Separate growing export operations from relatively stable node types, comparing a Visitor with exhaustive functions and their cost when a new node type arrives."
            }
          ]
        },
        {
          "id": "27225e52-7e31-4ec9-993b-d82e8ac6cf4e",
          "key": "PDOC-110",
          "title": "Reject stale history after replacing the document",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "evolution",
          "dependsOn": [
            "PDOC-104",
            "PDOC-107",
            "PDOC-109"
          ],
          "scenario": "A delayed keyboard event queues Undo just before a successful import installs another document. The old history entry then restores part of the previous document into the replacement because both documents happen to contain node p1.",
          "acceptanceCriteria": [
            "Bind commands and history entries to a document session identity as well as a revision.",
            "Replacement import commits document, logical selection, session identity, and history reset as one state transition.",
            "Stale queued commands and incompatible snapshots fail without modifying the active document; cancellation preserves the previous session and valid history."
          ],
          "implementationNotes": [
            "Build a deterministic event-order harness rather than timing-dependent sleeps; this ticket does not require collaborative editing or remote persistence."
          ],
          "verification": [
            "Interleave queued Undo, successful import, and duplicate node identities; assert the replacement never receives previous-session content.",
            "Fail and cancel imports at each transition boundary, then verify undo remains valid only for the preserved session."
          ],
          "deliverables": [
            "Session-bound command/history contract and interleaving regression matrix"
          ],
          "rollout": "Introduce session identities at the local editor boundary and clear incompatible transient history once; preserve saved content separately for recovery.",
          "skills": [
            "Concurrency modeling",
            "State transitions",
            "History integrity"
          ],
          "fieldMix": [
            {
              "field": "Frontend",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Quality engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "command",
              "activity": "REFACTOR",
              "focus": "Bind queued editor operations to the session that created them so delayed commands cannot operate on a replacement document with reused node IDs."
            },
            {
              "pattern": "memento",
              "activity": "REFACTOR",
              "focus": "Give history snapshots an explicit document-session boundary and install replacement content together with a coherent history reset."
            }
          ]
        }
      ]
    },
    {
      "id": "a2a00730-a060-4d04-babd-f76268a10ce7",
      "key": "PPROVIDER",
      "title": "Evolve a notification boundary with predictable failure behavior",
      "field": "Integrations",
      "summary": "Support two incompatible notification providers while keeping domain decisions, instrumentation, and overload behavior explicit.",
      "context": "A fictional maintenance scheduler sends appointment notices through two providers. Their request shapes, error codes, and acknowledgement semantics differ. Build two local scripted provider doubles and a TypeScript application module; use synthetic recipients, block external network access, and never send real notifications. No provider accounts, starter repository, or production delivery qualification is supplied.",
      "stack": [
        "TypeScript",
        "Node.js",
        "Vitest",
        "Local HTTP stubs"
      ],
      "prerequisites": [
        "HTTP contracts",
        "Asynchronous cancellation",
        "Dependency injection"
      ],
      "developerValue": "Practice placing provider boundaries, comparing wrappers and coordinators, and testing ordering, cancellation, and resource limits under controlled faults.",
      "companyValue": "Review whether a provider change can be made without rewriting scheduling rules, leaking recipient data, or turning one provider failure into wider exhaustion.",
      "delivery": "Ten tickets over three phases. Create local provider doubles and contract fixtures, evolve the integration layer, and supply a fault replay plus an operational handoff.",
      "phases": [
        {
          "id": "boundary",
          "title": "Define the provider boundary",
          "goal": "Separate scheduling intentions from transport details."
        },
        {
          "id": "composition",
          "title": "Compose cross-cutting behavior",
          "goal": "Keep orchestration and wrapper ordering visible and testable."
        },
        {
          "id": "resilience",
          "title": "Contain provider failure",
          "goal": "Bound outstanding work and verify recovery without duplicate delivery."
        }
      ],
      "tickets": [
        {
          "id": "7912caf4-7c81-42e0-81bd-143826fc60f0",
          "key": "PPROVIDER-101",
          "title": "Normalize the second provider's acknowledgement without inventing delivery",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "boundary",
          "dependsOn": [],
          "scenario": "Provider A returns accepted plus a request ID; provider B returns queued with a nested reference. The existing mapper calls both delivered, even though neither acknowledgement confirms a recipient received the notice.",
          "acceptanceCriteria": [
            "Define a shared result contract for accepted, rejected, and unknown outcomes with provider identity and an optional provider reference.",
            "Map both declared acknowledgement shapes to accepted while preserving their references; never map acknowledgement alone to delivered.",
            "Malformed success payloads and unknown response codes return a typed integration error without exposing raw recipient data."
          ],
          "implementationNotes": [
            "Use an Adapter for each local stub; preserve unsupported semantics explicitly rather than forcing every response into a success boolean."
          ],
          "verification": [
            "Map representative A and B acknowledgements and compare the shared contract.",
            "Return a success status with a missing required reference and an undocumented state; assert explicit failure."
          ],
          "deliverables": [
            "Provider adapters, shared result contract, and mapping fixtures"
          ],
          "rollout": "Run both adapters against local scripted responses before selecting B for synthetic requests; retain A's mapping for regression comparison.",
          "skills": [
            "Adapter contracts",
            "Response validation",
            "Error modeling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "adapter",
              "activity": "APPLY",
              "focus": "Translate incompatible acknowledgement payloads into a shared contract without overstating queued or accepted messages as delivered."
            }
          ]
        },
        {
          "id": "ed6c44e0-a42c-4e6e-92af-aba377ad8812",
          "key": "PPROVIDER-102",
          "title": "Keep provider SDK types out of appointment rules",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "boundary",
          "dependsOn": [
            "PPROVIDER-101"
          ],
          "scenario": "Rescheduling logic imports provider B's request object and recognizes its numeric error codes. A provider SDK change now forces changes in domain tests that never make a network request.",
          "acceptanceCriteria": [
            "Appointment logic depends on a small notification port using domain-owned request and result types.",
            "Place provider-specific mapping, serialization, and error interpretation in adapters selected at the composition boundary.",
            "Run appointment decisions against an in-memory port double with no provider package imports or transport initialization."
          ],
          "implementationNotes": [
            "Keep this a module boundary in one process; the exercise does not justify splitting the application into services."
          ],
          "verification": [
            "Replace A with B through composition wiring and run the same appointment behavior cases.",
            "Make the port return rejected and unknown outcomes and verify the domain does not treat either as successful acceptance."
          ],
          "deliverables": [
            "Domain notification port and provider-free appointment tests"
          ],
          "rollout": "Migrate one appointment use case to the port, compare results, then migrate the remaining local caller; revert adapter wiring if parity fails.",
          "skills": [
            "Dependency inversion",
            "Module boundaries",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 50
            }
          ],
          "patterns": [
            {
              "pattern": "ports-and-adapters",
              "activity": "APPLY",
              "focus": "Move vendor request types and error codes behind a domain-owned notification port so scheduling rules can run without initializing transport code."
            }
          ]
        },
        {
          "id": "2f77f80b-4e74-4a0e-b7fd-2487d2a646d2",
          "key": "PPROVIDER-103",
          "title": "Validate notice inputs before choosing a provider",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "boundary",
          "dependsOn": [
            "PPROVIDER-102"
          ],
          "scenario": "An invalid synthetic recipient passes provider selection and fails differently for A and B. Another path checks the notification preference only after the stub has already accepted the request.",
          "acceptanceCriteria": [
            "Validate appointment identity, synthetic recipient format, and declared notice preference before any adapter call.",
            "Define the order and short-circuit behavior of validation stages, returning stable reason codes.",
            "Compare a Chain of Responsibility with an explicit sequence of validation functions; a skipped preference check must be structurally impossible."
          ],
          "implementationNotes": [
            "Use only synthetic .invalid addresses; do not contact any external address or interpret this exercise as a compliance certification."
          ],
          "verification": [
            "Accept valid synthetic input and assert each required check runs before one provider call.",
            "Reject malformed recipient and disabled preference with a provider-call count of zero; verify the documented first error when both fail."
          ],
          "deliverables": [
            "Ordered preflight validation and no-send regression fixtures"
          ],
          "rollout": "Apply the shared validation path to both local providers together; leave explicit rejection visible to the scheduler.",
          "skills": [
            "Validation pipelines",
            "Side-effect boundaries",
            "Error contracts"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "chain-of-responsibility",
              "activity": "COMPARE",
              "focus": "Choose an ordered, short-circuiting validation structure that guarantees notice preferences are checked before any provider side effect."
            }
          ]
        },
        {
          "id": "bf3f66cd-0c09-4618-a3c9-0fab79a98327",
          "key": "PPROVIDER-104",
          "title": "Decouple notice format from the selected transport",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "composition",
          "dependsOn": [
            "PPROVIDER-102",
            "PPROVIDER-103"
          ],
          "scenario": "ReminderEmailProviderA and CancellationEmailProviderA have matching ProviderB subclasses. Adding a third notice type is multiplying classes even though formatting and transport are independent choices.",
          "acceptanceCriteria": [
            "Separate notice-content construction from provider transport, with two notice types runnable through both local providers.",
            "Document required transport capabilities and reject incompatible content before sending; do not silently drop a cancellation reason.",
            "Compare a Bridge between notice abstraction and transport with two composed functions, avoiding one subclass for every combination."
          ],
          "implementationNotes": [
            "Use plain text only in the exercise; user-provided content remains data and is never executed as a template or command."
          ],
          "verification": [
            "Exercise all four type/provider combinations and compare semantic content after adaptation.",
            "Configure a transport without a required capability and assert rejection before any stub call."
          ],
          "deliverables": [
            "Independent content/transport composition and capability matrix tests"
          ],
          "rollout": "Replace combination classes after all four fixtures pass; keep the declared provider contract stable while moving formatting code.",
          "skills": [
            "Composition",
            "Capability contracts",
            "Design comparison"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 50
            }
          ],
          "patterns": [
            {
              "pattern": "bridge",
              "activity": "COMPARE",
              "focus": "Separate independently varying notice content and provider transport so their combinations do not require a growing subclass matrix."
            }
          ]
        },
        {
          "id": "c1c9aece-fc81-4906-8d9d-b34aafde8214",
          "key": "PPROVIDER-105",
          "title": "Record one bounded telemetry event around each provider attempt",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "composition",
          "dependsOn": [
            "PPROVIDER-102"
          ],
          "scenario": "Adapter A logs full payloads while B logs nothing on exceptions. The team cannot compare local attempt outcomes without exposing synthetic recipient and notice content in generic logs.",
          "acceptanceCriteria": [
            "Wrap provider attempts with a common duration and outcome recorder that emits exactly one completion event per attempt.",
            "Limit event fields to operation identity, provider, outcome category, elapsed duration, and declared adapter version; omit recipient, body, and credentials.",
            "A telemetry sink failure cannot change the provider result or mask an adapter exception."
          ],
          "implementationNotes": [
            "Use a Decorator or explicit higher-order function; inject clock and event sink for deterministic tests, and avoid high-cardinality recipient labels."
          ],
          "verification": [
            "Run accepted, rejected, thrown-error, and cancellation cases and assert one correctly categorized event each.",
            "Make the sink throw and inspect all event payloads for synthetic secret and recipient markers."
          ],
          "deliverables": [
            "Attempt telemetry wrapper and privacy/failure regression fixtures"
          ],
          "rollout": "Enable the wrapper on local stubs first; disable the sink independently while preserving attempt behavior and correlation identities.",
          "skills": [
            "Instrumentation",
            "Data minimization",
            "Exception handling"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "decorator",
              "activity": "APPLY",
              "focus": "Add consistent attempt instrumentation around interchangeable adapters without embedding logging behavior in each provider mapping."
            }
          ]
        },
        {
          "id": "4c2d743d-33f2-4e00-9d4e-1d8077af8ebf",
          "key": "PPROVIDER-106",
          "title": "Replace the scheduler's six-call notification sequence with one bounded operation",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "composition",
          "dependsOn": [
            "PPROVIDER-103",
            "PPROVIDER-104",
            "PPROVIDER-105"
          ],
          "scenario": "Every scheduling handler must validate, format, select an adapter, initialize telemetry, call send, and map the result in the right order. One handler skips validation and another catches all failures as accepted.",
          "acceptanceCriteria": [
            "Expose one application operation that coordinates the declared preflight, content, adapter, and result steps.",
            "Return typed accepted, rejected, and unknown outcomes without concealing which stage failed.",
            "Keep policy and transport modules independently testable; the Facade must not absorb appointment rules, template storage, or unrelated administration."
          ],
          "implementationNotes": [
            "This operation makes at most one provider attempt. Automatic failover and retries are excluded until duplicate-acceptance behavior is defined."
          ],
          "verification": [
            "Call the operation from reminder and cancellation flows and compare stage order and result handling.",
            "Fail every stage in turn and assert later side effects do not run; preserve an unknown outcome after ambiguous transport completion."
          ],
          "deliverables": [
            "Notification Facade and stage-failure test matrix"
          ],
          "rollout": "Move the two local scheduling handlers behind the operation with parity fixtures; revert one caller only if its behavior remains explicit.",
          "skills": [
            "Application boundaries",
            "Error propagation",
            "Orchestration testing"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "facade",
              "activity": "APPLY",
              "focus": "Offer scheduling callers one explicit notification operation while preserving distinct validation, content, and transport responsibilities underneath."
            }
          ]
        },
        {
          "id": "0d91053c-96ea-4cf9-86e4-141a14223b6a",
          "key": "PPROVIDER-107",
          "title": "Remove the transparent send proxy that retries an ambiguous timeout",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "composition",
          "dependsOn": [
            "PPROVIDER-106"
          ],
          "scenario": "A transparent Proxy automatically repeats any timed-out call. The local stub can accept a notice and drop the response, so the hidden retry records two accepted deliveries while the application sees one success.",
          "acceptanceCriteria": [
            "Remove hidden retry behavior from the send proxy and expose ambiguous completion as unknown.",
            "If a retry is explicitly requested, preserve the original operation identity and require a declared provider deduplication contract; otherwise refuse the retry.",
            "Record attempt identities separately from operation identity so the handoff can explain what was tried without claiming recipient delivery."
          ],
          "implementationNotes": [
            "Keep the exercise local and deterministic; a timeout does not prove a provider rejected the operation, and selecting the other provider is not a safe default."
          ],
          "verification": [
            "Have the stub accept then lose its response; assert one attempt and an unknown outcome with hidden retries disabled.",
            "Try an explicit retry against a stub lacking deduplication support and confirm it is refused; test convergence on a deduplicating stub."
          ],
          "deliverables": [
            "Proxy simplification, explicit retry contract, and ambiguous-timeout reproduction"
          ],
          "rollout": "Disable automatic retry in the local composition first; review stored unknown operations before any explicit retry experiment.",
          "skills": [
            "Idempotency",
            "Failure semantics",
            "Abstraction review"
          ],
          "fieldMix": [
            {
              "field": "Integrations",
              "percentage": 50
            },
            {
              "field": "Distributed systems",
              "percentage": 50
            }
          ],
          "patterns": [
            {
              "pattern": "proxy",
              "activity": "REMOVE",
              "focus": "Remove transparent retry behavior that changes send semantics after ambiguous completion, exposing retry decisions and operation identity to the application."
            }
          ]
        },
        {
          "id": "d67a0795-d5ed-4ed5-9924-b73324cc2fc6",
          "key": "PPROVIDER-108",
          "title": "Pause a failing provider and admit one recovery probe",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "resilience",
          "dependsOn": [
            "PPROVIDER-105",
            "PPROVIDER-107"
          ],
          "scenario": "Provider B returns transport failures for every synthetic request. Callers continue spending the full timeout on each attempt even though the service needs a short recovery window.",
          "acceptanceCriteria": [
            "Open the circuit after three consecutive declared transport failures, reject further attempts locally for thirty simulated seconds, and then admit one recovery probe.",
            "A successful probe closes the circuit; a failed probe reopens it. Validation errors and provider business rejections do not count as transport failures.",
            "Track circuits independently per provider, return a distinct circuit-open outcome, and never report rejected local attempts as provider calls."
          ],
          "implementationNotes": [
            "Use an injected monotonic clock and explicit transition logic; no real-time sleeps, external service, or automatic cross-provider failover is required."
          ],
          "verification": [
            "Advance the fake clock through closed, open, and half-open states and assert allowed call counts.",
            "Race several requests at the recovery boundary and confirm exactly one probe; verify A remains usable while B is open."
          ],
          "deliverables": [
            "Circuit Breaker state transitions and deterministic recovery tests"
          ],
          "rollout": "Enable the breaker around B's local stub first, observe transitions, and preserve unknown-operation records when resetting circuit state.",
          "skills": [
            "Circuit breakers",
            "State transitions",
            "Deterministic timing"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 50
            },
            {
              "field": "Integrations",
              "percentage": 30
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "circuit-breaker",
              "activity": "APPLY",
              "focus": "Stop repeated attempts to a failing provider with explicit failure classification and a single controlled recovery probe."
            }
          ]
        },
        {
          "id": "1f51b94e-fafe-4b4a-b2ee-a30b8d36398f",
          "key": "PPROVIDER-109",
          "title": "Keep one slow provider from occupying every notification slot",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "resilience",
          "dependsOn": [
            "PPROVIDER-107"
          ],
          "scenario": "Twenty stalled B requests consume the module's shared work pool. A's immediate responses cannot start, and callers keep adding pending requests until memory grows.",
          "acceptanceCriteria": [
            "Give each provider at most three active attempts and five queued operations, with a typed overload result when its queue is full.",
            "Queued cancellations remove work before execution; every completion or failure releases its slot exactly once.",
            "A stalled B provider cannot consume A's admission capacity, and queue wait contributes to the caller's overall deadline."
          ],
          "implementationNotes": [
            "Use bounded in-process queues and local promise gates; do not add an external broker or unbounded task buffers."
          ],
          "verification": [
            "Saturate B, submit A work, and verify A starts promptly while B's active and queued counts stay within bounds.",
            "Cancel queued work, throw inside an attempt, and resolve an attempt twice through a faulty stub; verify no slot leak or over-release."
          ],
          "deliverables": [
            "Per-provider Bulkhead and overload/cancellation regression harness"
          ],
          "rollout": "Start with the declared local limits and record saturation behavior; reject new work explicitly while draining queues before a configuration change.",
          "skills": [
            "Concurrency limits",
            "Backpressure",
            "Resource lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "bulkhead",
              "activity": "APPLY",
              "focus": "Partition active and queued capacity by provider so stalled requests cannot exhaust another provider's execution slots or grow an unbounded queue."
            }
          ]
        },
        {
          "id": "9f938194-3082-4ed3-b244-f68ef3b23f9b",
          "key": "PPROVIDER-110",
          "title": "Prove wrapper order preserves deadlines, probe limits, and attempt counts",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "resilience",
          "dependsOn": [
            "PPROVIDER-108",
            "PPROVIDER-109"
          ],
          "scenario": "The breaker, queue, telemetry, and adapter work in isolation, but a half-open probe can expire while queued and leave the circuit stuck. Another wrapper order records circuit-open rejections as actual provider attempts.",
          "acceptanceCriteria": [
            "Document wrapper order and distinguish operation admission, queue wait, probe reservation, and physical provider attempt.",
            "An overall deadline or cancellation releases queue capacity and any unused probe reservation, with no adapter call after cancellation commits.",
            "Telemetry reconciles submitted, locally rejected, cancelled, and actually attempted operations; terminal outcomes and slot release occur once under every tested interleaving."
          ],
          "implementationNotes": [
            "Use a deterministic fake scheduler and clock. Change composition boundaries where needed rather than adding retries that could duplicate an accepted notice."
          ],
          "verification": [
            "Exercise a half-open probe queued behind slow work, then cancel it and verify a later eligible request can probe.",
            "Race deadline expiry with adapter completion and circuit opening; assert exact attempt counts, bounded slots, and one terminal outcome."
          ],
          "deliverables": [
            "Reviewed composition order, interleaving matrix, and local failure-recovery runbook"
          ],
          "rollout": "Run the full fault replay against both local providers before selecting the new composition; preserve a configuration switch and unknown-operation list for rollback analysis.",
          "skills": [
            "Composition semantics",
            "Concurrency testing",
            "Operational reasoning"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "decorator",
              "activity": "REFACTOR",
              "focus": "Make wrapper ordering explicit so instrumentation describes real attempts and cancellation is respected across queue, breaker, and adapter boundaries."
            },
            {
              "pattern": "circuit-breaker",
              "activity": "REFACTOR",
              "focus": "Release unused half-open probe reservations when queued operations expire or are cancelled, preserving a path to later recovery."
            },
            {
              "pattern": "bulkhead",
              "activity": "REFACTOR",
              "focus": "Coordinate queue admission and slot release with the overall operation deadline without leaking capacity during concurrent completion and cancellation."
            }
          ]
        }
      ]
    },
    {
      "id": "4ac38ae8-76d6-4511-bb71-557947944989",
      "key": "PDSL",
      "title": "Make fulfillment rules understandable without executing scripts",
      "field": "Compiler and language tooling",
      "summary": "Replace a growing set of warehouse eligibility switches with a small, bounded rule language that support can inspect and engineers can evolve.",
      "context": "A fictional fulfillment product routes parcels using destination zone, weight in grams, and service level. Its next release needs nested eligibility rules, but arbitrary customer scripts are out of scope. Create a local TypeScript baseline and synthetic parcel/rule fixtures; no starter repository or fixtures are supplied. Keep parsing and evaluation in a local practice application with no network, filesystem, or host-code expressions in the language.",
      "stack": [
        "TypeScript",
        "Node.js",
        "Vitest",
        "JSON"
      ],
      "prerequisites": [
        "Recursive data structures",
        "Parser error handling",
        "Discriminated unions"
      ],
      "developerValue": "Practice expression modeling, language compatibility, bounded evaluation, and deciding whether object-oriented patterns improve a small interpreter.",
      "companyValue": "Review concrete tradeoffs around rule changes, diagnostic quality, resource limits, and the cost of adding an operator without breaking saved rules.",
      "delivery": "Ten tickets across language definition, evaluation, and evolution. Author a minimal local baseline for individual tickets or build the complete synthetic rule engine and compatibility report.",
      "phases": [
        {
          "id": "define",
          "title": "Define the language boundary",
          "goal": "Give saved rules an explicit grammar, tree shape, and useful diagnostics."
        },
        {
          "id": "evaluate",
          "title": "Evaluate and inspect",
          "goal": "Make rule behavior deterministic and inspectable without mutable shared state."
        },
        {
          "id": "evolve",
          "title": "Evolve within limits",
          "goal": "Add syntax safely, bound adversarial inputs, and preserve old rule versions."
        }
      ],
      "tickets": [
        {
          "id": "511541ad-7588-43fb-9a03-a6de91595b07",
          "key": "PDSL-101",
          "title": "Settle literal and operator precedence before saving warehouse rules",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "define",
          "dependsOn": [],
          "scenario": "Operations wrote zone == 'north' OR service == 'express' AND weightGrams < 500. Two engineers read it differently, and there is no grammar to decide which parcels qualify.",
          "acceptanceCriteria": [
            "Define parentheses, AND-before-OR precedence, quoted strings, and nonnegative integer gram literals with unambiguous examples.",
            "Reject unknown operators, decimal weights, and trailing tokens with a stable code and source range.",
            "A parse result carries a language version; invalid input cannot produce a saved rule object."
          ],
          "implementationNotes": [
            "Keep the grammar limited to the three documented parcel fields; do not translate input into JavaScript or expose general function calls."
          ],
          "verification": [
            "Parse the disputed expression and its parenthesized alternative into different expected trees.",
            "Reject an unterminated string and an extra closing parenthesis without a stack trace in the public diagnostic."
          ],
          "deliverables": [
            "Versioned grammar note, parser entry point, and synthetic parsing cases"
          ],
          "rollout": "Use the grammar for newly authored local rules first; retain the original text when reverting the parser version.",
          "skills": [
            "Grammar design",
            "Input validation",
            "Error contracts"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 80
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "interpreter",
              "activity": "APPLY",
              "focus": "Use an explicit expression grammar as the interpreter boundary so precedence and permitted operations are reviewable before execution."
            }
          ]
        },
        {
          "id": "60734a38-6f9a-4135-8791-b3d57a2a3b5d",
          "key": "PDSL-102",
          "title": "Represent nested all-of and any-of rules without special-case depth handling",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "define",
          "dependsOn": [
            "PDSL-101"
          ],
          "scenario": "The current rule model has separate fields for one AND group and one OR group. A warehouse needs (north OR west) AND (express OR under-500g), which cannot be represented without duplicated conditions.",
          "acceptanceCriteria": [
            "Model comparisons and nested all-of/any-of groups through one expression contract while preserving child order.",
            "Reject empty groups and enforce a documented maximum of 16 levels and 1,000 nodes at construction.",
            "Serialize and parse a valid tree without changing its grouping, field types, or language version."
          ],
          "implementationNotes": [
            "Compare a discriminated-union tree with a class hierarchy; choose the smaller representation that supports the required operations."
          ],
          "verification": [
            "Round-trip a four-level mixed rule and compare every node and child position.",
            "Reject a seventeenth level and a reused mutable child that would change an already constructed rule."
          ],
          "deliverables": [
            "Expression model, boundary tests, and a short representation decision"
          ],
          "rollout": "Convert only synthetic flat rules first and compare their trees; retain flat input conversion until nested-rule behavior is checked.",
          "skills": [
            "Tree modeling",
            "Immutability",
            "Serialization"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 75
            },
            {
              "field": "System design",
              "percentage": 25
            }
          ],
          "patterns": [
            {
              "pattern": "composite",
              "activity": "COMPARE",
              "focus": "Compare uniform leaf/group composition with the existing fixed-depth structure, retaining type safety without requiring a class per node."
            }
          ]
        },
        {
          "id": "4027bc4e-2695-41bf-9f7b-38e77e1820bf",
          "key": "PDSL-103",
          "title": "Point rule editors to invalid fields before evaluation starts",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "define",
          "dependsOn": [
            "PDSL-102"
          ],
          "scenario": "A rule containing weightGrams == 'heavy' parses successfully, then fails when a parcel reaches the evaluator. Support needs all actionable type errors from the saved rule before attempting a run.",
          "acceptanceCriteria": [
            "Validate permitted field/operator/literal combinations in a pass that does not evaluate parcel data.",
            "Return diagnostics in source order with node path and source range, capped at 50 with an omitted count.",
            "Keep the rule tree unchanged and report an unknown node kind as an unsupported-language error."
          ],
          "implementationNotes": [
            "Compare a visitor with an exhaustive traversal function; document how adding a node forces the validator to handle it."
          ],
          "verification": [
            "Collect distinct string/number mismatch diagnostics from separate branches in stable order.",
            "Pass a synthetic unknown node and a 70-error tree; verify safe rejection and the diagnostic cap."
          ],
          "deliverables": [
            "Static rule validator and support-facing diagnostic examples"
          ],
          "rollout": "Run validation on synthetic saved rules in report-only mode before blocking new invalid saves.",
          "skills": [
            "Static analysis",
            "Tree traversal",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "visitor",
              "activity": "COMPARE",
              "focus": "Keep validation separate from evaluation and compare visitor dispatch with an exhaustive function for adding independent tree operations."
            }
          ]
        },
        {
          "id": "4bb83e06-e123-4769-96d2-971b9909db51",
          "key": "PDSL-104",
          "title": "Stop treating an absent parcel weight as a zero-weight match",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "evaluate",
          "dependsOn": [
            "PDSL-103"
          ],
          "scenario": "A carrier feed omitted weightGrams and the evaluator coerced it to zero. The parcel passed a weight limit despite having no measurement; OR branches also mask inconsistent missing-value behavior.",
          "acceptanceCriteria": [
            "Define true, false, and unknown outcomes with explicit AND/OR truth tables and no implicit string/number coercion.",
            "Missing referenced inputs produce unknown with the relevant field path; only true authorizes the synthetic routing decision.",
            "Repeated evaluation of the same rule and parcel returns the same outcome and bounded explanation without mutating either input."
          ],
          "implementationNotes": [
            "Short-circuit only when the declared three-valued semantics permit it; retain enough information to explain the final outcome."
          ],
          "verification": [
            "Exercise every pair in both truth tables, including false AND unknown and true OR unknown.",
            "Evaluate missing, null, zero, and numeric-string weights and assert the distinct documented results."
          ],
          "deliverables": [
            "Typed evaluation result, truth-table regression cases, and explanation format"
          ],
          "rollout": "Compare decisions against a synthetic parcel corpus; keep unknown outcomes in a review queue and revert the evaluator by version.",
          "skills": [
            "Evaluation semantics",
            "Null handling",
            "Determinism"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "Backend",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "interpreter",
              "activity": "REFACTOR",
              "focus": "Replace coercion spread across conditions with one explicit interpreter result model and consistent missing-value semantics."
            }
          ]
        },
        {
          "id": "022b09ca-1619-4447-9972-cfc10e6fb86a",
          "key": "PDSL-105",
          "title": "Keep draft rule builders from changing previously saved expressions",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "evaluate",
          "dependsOn": [
            "PDSL-103"
          ],
          "scenario": "The rule editor reuses a builder to produce two templates. Adding a condition to the second template mutates the first because both saved objects reference the builder's child array.",
          "acceptanceCriteria": [
            "A build operation returns an immutable validated expression with no writable references to builder state.",
            "Incomplete drafts identify missing fields without emitting a partially valid saved rule.",
            "Building twice and then editing the draft cannot change either earlier result or its serialized bytes."
          ],
          "implementationNotes": [
            "Compare a builder with ordinary validated object construction; retain staged construction only where it improves the editor's incomplete-state handling."
          ],
          "verification": [
            "Build two rules from one draft and edit a nested child; verify both saved rule snapshots stay unchanged.",
            "Attempt to build a comparison without a literal and confirm no persisted rule identity is allocated."
          ],
          "deliverables": [
            "Draft-to-rule construction API and shared-reference regression reproduction"
          ],
          "rollout": "Switch local editor saves behind a construction flag; old saved rules stay readable if the editor construction path is reverted.",
          "skills": [
            "Object construction",
            "Immutability",
            "API ergonomics"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 50
            },
            {
              "field": "Frontend",
              "percentage": 30
            },
            {
              "field": "API design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "builder",
              "activity": "COMPARE",
              "focus": "Assess whether staged rule construction earns its complexity and make the handoff from a mutable draft to an immutable expression explicit."
            }
          ]
        },
        {
          "id": "172a295f-b744-44b6-823e-9107379427a3",
          "key": "PDSL-106",
          "title": "Give the support inspector a stable walk through nested conditions",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 120,
          "phaseId": "evaluate",
          "dependsOn": [
            "PDSL-102"
          ],
          "scenario": "The support inspector duplicates recursive loops for a tree outline, field usage report, and copyable diagnostics. These loops disagree on child order and sometimes skip a nested condition.",
          "acceptanceCriteria": [
            "Expose a read-only depth-first iterator that yields each node once with a stable path and parent path.",
            "The outline and field usage report consume the same traversal contract while retaining their own presentation rules.",
            "Early termination releases traversal state, and malformed cycles are rejected instead of looping indefinitely."
          ],
          "implementationNotes": [
            "Do not expose the mutable traversal stack or allow consumers to rewrite children during iteration."
          ],
          "verification": [
            "Walk a mixed tree and compare the complete path order used by both consumers.",
            "Break after the first leaf, then start a fresh iteration; also supply a manually constructed cycle and assert a bounded error."
          ],
          "deliverables": [
            "Traversal API, two migrated consumers, and cycle/early-exit checks"
          ],
          "rollout": "Compare inspector output before replacing the duplicated traversals; restore the old read path if ordering changes unexpectedly.",
          "skills": [
            "Iteration",
            "Tree traversal",
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "iterator",
              "activity": "APPLY",
              "focus": "Provide a shared traversal contract for independent tree consumers without exposing the representation or coupling their presentation logic."
            }
          ]
        },
        {
          "id": "d46bdac6-42cd-4b3b-ba42-bcfdab980e22",
          "key": "PDSL-107",
          "title": "Measure whether interning field symbols actually reduces rule-cache memory",
          "type": "TASK",
          "priority": "LOW",
          "difficulty": "ADVANCED",
          "estimateMinutes": 180,
          "phaseId": "evaluate",
          "dependsOn": [
            "PDSL-104"
          ],
          "scenario": "A heap profile suggests thousands of cached rules repeat the same field and operator metadata. The proposed optimization shares entire nodes, including source locations and tenant rule identifiers.",
          "acceptanceCriteria": [
            "Benchmark an authored 10,000-rule synthetic corpus before and after sharing only immutable context-free symbols.",
            "Keep source spans, rule identities, and parcel evaluation state outside shared symbols, and bound or evict the intern pool.",
            "Report retained heap, parse time, and identical rule outcomes across repeated runs; retain the optimization only if the measured tradeoff justifies it."
          ],
          "implementationNotes": [
            "State runtime, corpus seed, warmup, and measurement variability; a decision to remove the pool is an acceptable result."
          ],
          "verification": [
            "Compare all evaluation outcomes and source-specific diagnostics with pooling enabled and disabled.",
            "Load many distinct invalid symbols and verify rejection cannot grow the intern pool without bound or reuse another rule's source range."
          ],
          "deliverables": [
            "Reproducible heap comparison and an evidence-backed keep-or-remove decision"
          ],
          "rollout": "Default pooling off until the local measurements pass review; disabling it must leave serialized rule content unchanged.",
          "skills": [
            "Memory profiling",
            "Caching",
            "Benchmark design"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "flyweight",
              "activity": "COMPARE",
              "focus": "Test whether sharing intrinsic symbol metadata saves enough memory while keeping source, tenant, and evaluation context out of shared objects."
            }
          ]
        },
        {
          "id": "492a894f-ccbe-4e15-962f-09fe7a0260a5",
          "key": "PDSL-108",
          "title": "Add membership expressions without leaving tree operations behind",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "evolve",
          "dependsOn": [
            "PDSL-104",
            "PDSL-106"
          ],
          "scenario": "Warehouse rules repeat long chains such as zone == 'north' OR zone == 'west'. Adding IN to evaluation alone would leave validation, inspection, and serialization unaware of the new node.",
          "acceptanceCriteria": [
            "Add string-set membership with a 50-item limit, explicit duplicate handling, and no implicit type conversion.",
            "Update parsing, validation, evaluation, inspection, and serialization, with an exhaustive mechanism that exposes unhandled node kinds.",
            "Compare visitor-based operations with node-local methods for this change and explain which extension axis becomes easier or harder."
          ],
          "implementationNotes": [
            "New syntax uses a new language version; existing rules retain their old version and behavior, including missing-field outcomes."
          ],
          "verification": [
            "Compare membership and equivalent OR rules over present, absent, matching, and nonmatching zones.",
            "Run every tree operation on the new node; reject a 51-item set and an older parser receiving the new version."
          ],
          "deliverables": [
            "Membership implementation, operation coverage matrix, and extension tradeoff note"
          ],
          "rollout": "Enable authoring for the new version after all operations support it; turn off new authoring without rewriting saved older rules.",
          "skills": [
            "Language evolution",
            "Exhaustiveness",
            "Design tradeoffs"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 70
            },
            {
              "field": "System design",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "visitor",
              "activity": "COMPARE",
              "focus": "Use a real new-node change to compare operation-oriented visitors with node-local methods and make the extension cost visible in the patch."
            },
            {
              "pattern": "composite",
              "activity": "REFACTOR",
              "focus": "Integrate the membership leaf into the uniform expression tree without adding special group traversal paths or weakening node validation."
            }
          ]
        },
        {
          "id": "788ea190-f734-4160-b2c4-c1eb4e35308f",
          "key": "PDSL-109",
          "title": "Bound rule parsing and explanation work before expensive allocation",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "evolve",
          "dependsOn": [
            "PDSL-104",
            "PDSL-108"
          ],
          "scenario": "The editor rejects a deeply nested rule only after parsing its entire text. A pasted megabyte of repeated parentheses stalls the local worker, and explanations allocate one message for every attempted comparison.",
          "acceptanceCriteria": [
            "Reject source text above 64 KiB before tokenization and enforce depth, node, and literal limits as input is consumed.",
            "Bound evaluation steps and explanation entries independently; return distinct stable limit codes without partial routing approval.",
            "After a rejected rule, the same process can evaluate a small valid rule with no retained traversal or explanation state."
          ],
          "implementationNotes": [
            "Use deterministic operation budgets rather than relying solely on wall-clock time; no regex features with unbounded backtracking are required by this language."
          ],
          "verification": [
            "Exercise just-below and just-above each declared bound with reproducible generated inputs.",
            "Alternate rejected and valid rules for 100 runs; confirm bounded diagnostics and unchanged valid outcomes."
          ],
          "deliverables": [
            "Limit enforcement changes, adversarial local cases, and resource-bound report"
          ],
          "rollout": "Publish the limit codes in the local editor before enforcing them; revert language authoring if needed while retaining safe evaluator limits.",
          "skills": [
            "Resource limits",
            "Parser robustness",
            "Failure recovery"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 50
            },
            {
              "field": "Security",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "interpreter",
              "activity": "REFACTOR",
              "focus": "Make resource accounting part of the interpreter contract so nested expressions cannot bypass limits through separate parsing or explanation paths."
            }
          ]
        },
        {
          "id": "7e46d0c0-1ec7-44ad-aacd-89d46e7b901d",
          "key": "PDSL-110",
          "title": "Ship a rule-language upgrade with a reversible authoring boundary",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 240,
          "phaseId": "evolve",
          "dependsOn": [
            "PDSL-105",
            "PDSL-108",
            "PDSL-109"
          ],
          "scenario": "The membership release introduces version 2 rules, but a rollback plan assumes every stored rule can still be opened by the version 1 editor. Saving an unrecognized node would silently discard a condition.",
          "acceptanceCriteria": [
            "Route evaluation by saved language version and fail closed for unknown versions without rewriting the original rule bytes.",
            "Keep unsupported rules read-only in an older editor and require an explicit conversion preview before creating a new version.",
            "Demonstrate a rollback sequence that stops version 2 authoring while preserving version 2 evaluation or explicitly pausing those rules."
          ],
          "implementationNotes": [
            "Record conversion warnings and original version lineage; a builder must not invent defaults for unsupported expression nodes."
          ],
          "verification": [
            "Run a mixed-version synthetic corpus before upgrade, after upgrade, and through the documented rollback sequence.",
            "Open a version 2 rule in the old editor and submit an unknown-version rule; verify neither path loses conditions or approves routing."
          ],
          "deliverables": [
            "Compatibility matrix, conversion preview, and rehearsed local rollback runbook"
          ],
          "rollout": "Stage evaluation support before new authoring, then enable one synthetic warehouse; retain versioned evaluators until all dependent rules are explicitly retired.",
          "skills": [
            "Compatibility",
            "Release planning",
            "Versioned data"
          ],
          "fieldMix": [
            {
              "field": "Compiler and language tooling",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "interpreter",
              "activity": "APPLY",
              "focus": "Keep interpreter semantics tied to stored language versions so deploying or reverting authoring code cannot silently change routing behavior."
            },
            {
              "pattern": "builder",
              "activity": "REFACTOR",
              "focus": "Make version conversion an explicit construction step with a preview instead of rebuilding unknown nodes with guessed defaults."
            }
          ]
        }
      ]
    },
    {
      "id": "0909ba43-5033-42cd-85a6-86a00937c69d",
      "key": "PMIGRATE",
      "title": "Replace an account service one tenant at a time",
      "field": "System design",
      "summary": "Evolve a long-lived account module while preserving tenant boundaries, client contracts, and a credible route back from partial migration.",
      "context": "A fictional B2B scheduling service stores account settings in a legacy module whose database access leaks into HTTP handlers. A replacement must support existing clients and migration by tenant. Build a local modular application, a synthetic two-tenant dataset, and controllable old/new adapters; no baseline repository or fixtures are supplied. Keep the exercise in one application and local database, with no live customer traffic.",
      "stack": [
        "TypeScript",
        "Node.js",
        "PostgreSQL",
        "Vitest"
      ],
      "prerequisites": [
        "REST contracts",
        "Tenant authorization",
        "Transactions",
        "Dependency injection"
      ],
      "developerValue": "Practice incremental migration, dependency boundaries, compatibility testing, and removing abstractions that obscure behavior rather than enabling change.",
      "companyValue": "Inspect a migration plan with measurable parity, explicit write ownership, tenant-safe routing, and rollback limits instead of accepting a rewrite diagram alone.",
      "delivery": "Ten tickets in three migration phases. An individual ticket needs a minimal local reproduction of its legacy behavior; the full project ends with a rehearsed synthetic tenant cutover and retirement checklist.",
      "phases": [
        {
          "id": "boundary",
          "title": "Establish a stable boundary",
          "goal": "Capture old behavior and remove hidden tenant state before routing changes."
        },
        {
          "id": "transition",
          "title": "Compare and route deliberately",
          "goal": "Introduce the replacement without duplicate effects or unexamined abstractions."
        },
        {
          "id": "retire",
          "title": "Cut over and retire",
          "goal": "Prove write ownership, compatibility, and recovery before removing legacy paths."
        }
      ],
      "tickets": [
        {
          "id": "a01f0881-6ef8-42ec-877b-5b9d389b551f",
          "key": "PMIGRATE-101",
          "title": "Put legacy account lookups behind a contract the replacement can keep",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "boundary",
          "dependsOn": [],
          "scenario": "Three HTTP handlers each translate a legacy account row differently. One returns an absent timezone as null, another inserts UTC, and a third exposes an internal migration flag.",
          "acceptanceCriteria": [
            "Create a narrow account-read facade with explicit tenant and account identifiers and one documented public response shape.",
            "Capture the intended null, not-found, and permission behavior before routing the three handlers through it.",
            "Keep legacy storage columns and migration flags out of the public response while preserving required client fields."
          ],
          "implementationNotes": [
            "Use the facade to bound a specific compatibility surface; do not add a generic wrapper around every repository method."
          ],
          "verification": [
            "Exercise all three handlers against synthetic missing, configured, and null-timezone accounts and compare their response contracts.",
            "Request another tenant's account and assert denial with no internal migration metadata in the response."
          ],
          "deliverables": [
            "Account-read facade and legacy response characterization cases"
          ],
          "rollout": "Move one local handler at a time through the facade and compare response snapshots; revert a handler without changing stored account data.",
          "skills": [
            "Compatibility",
            "API boundaries",
            "Characterization testing"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "facade",
              "activity": "APPLY",
              "focus": "Give callers one stable account-read contract while containing legacy row translation and keeping the boundary deliberately narrow."
            }
          ]
        },
        {
          "id": "9481cd3b-715d-4254-8f42-da4085c39081",
          "key": "PMIGRATE-102",
          "title": "Remove the process-wide current-tenant account client",
          "type": "BUG",
          "priority": "URGENT",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "boundary",
          "dependsOn": [
            "PMIGRATE-101"
          ],
          "scenario": "The legacy account client is a singleton with a mutable currentTenant field. Two overlapping requests can overwrite that field between authorization and the database query, selecting the wrong tenant's settings.",
          "acceptanceCriteria": [
            "Remove mutable request or tenant context from the process-wide client and pass authorized scope explicitly into the service/repository boundary.",
            "Every account query constrains both tenant and account identity, including background lookups and the not-found path.",
            "Connection pooling may remain shared, but tests and request handlers cannot alter another operation's tenant context."
          ],
          "implementationNotes": [
            "Distinguish safe shared infrastructure lifetime from unsafe shared request state; replacing the singleton with a different global container is insufficient."
          ],
          "verification": [
            "Interleave two tenant requests with barriers at authorization and lookup; assert each receives only its own settings.",
            "Omit tenant scope and use a cross-tenant account identifier in direct service calls; verify rejection before data is returned."
          ],
          "deliverables": [
            "Explicit-scope account access change and deterministic overlap reproduction"
          ],
          "rollout": "Block further migration until the scope checks pass; revert optional routing changes if needed while retaining the tenant-isolation fix.",
          "skills": [
            "Tenant isolation",
            "Concurrency",
            "Dependency lifetimes"
          ],
          "fieldMix": [
            {
              "field": "Security",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "singleton",
              "activity": "REMOVE",
              "focus": "Remove singleton-held tenant state while preserving safe shared connection infrastructure, using an interleaved request failure to justify the lifetime change."
            }
          ]
        },
        {
          "id": "114b45f9-e50b-4aba-872c-471bc60bd1ca",
          "key": "PMIGRATE-103",
          "title": "Separate account policy from legacy SQL and replacement storage",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "boundary",
          "dependsOn": [
            "PMIGRATE-102"
          ],
          "scenario": "The rule that a suspended account cannot enable a new booking channel lives inside a legacy SQL helper. The replacement adapter would bypass that rule if handlers called it directly.",
          "acceptanceCriteria": [
            "Place the account policy in an application operation depending on explicit read/write ports instead of concrete database helpers.",
            "Run the same operation against old and new storage adapters with identical authorization and suspended-account behavior.",
            "Keep transaction and expected-revision requirements explicit in the port contract; adapters cannot report success after a failed commit."
          ],
          "implementationNotes": [
            "Introduce ports for the needed use case only; do not create a universal repository abstraction or change the application into microservices."
          ],
          "verification": [
            "Run a shared contract suite for both adapters over active, suspended, and missing accounts.",
            "Inject a stale revision and commit failure in each adapter and verify no enabled channel or success response is produced."
          ],
          "deliverables": [
            "Account operation, two local adapters, and shared behavior contract"
          ],
          "rollout": "Keep the legacy adapter selected while introducing the boundary; enable the replacement only after parity cases pass.",
          "skills": [
            "Dependency inversion",
            "Domain policy",
            "Transaction contracts"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "ports-and-adapters",
              "activity": "REFACTOR",
              "focus": "Move account policy above concrete storage and give both adapters the same explicit authorization, revision, and transaction obligations."
            }
          ]
        },
        {
          "id": "c3f3b65f-2f31-4003-a67c-fb108636f1d0",
          "key": "PMIGRATE-104",
          "title": "Shadow account reads without duplicating booking-channel writes",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "transition",
          "dependsOn": [
            "PMIGRATE-103"
          ],
          "scenario": "The migration proposal mirrors every request to the replacement and compares responses. Some apparent reads update lastSeenAt, and write mirroring would enable a booking channel twice through different storage paths.",
          "acceptanceCriteria": [
            "Define an allowlist of side-effect-free reads that may run against both implementations for synthetic tenant comparison.",
            "Return the active implementation's response without letting shadow timeouts or failures change client behavior.",
            "Record bounded field-level parity differences without account content, and route every command to exactly one active implementation."
          ],
          "implementationNotes": [
            "Use the migration boundary to incrementally replace routes; do not call a mutating operation just because its HTTP verb is GET."
          ],
          "verification": [
            "Inject a replacement timeout and mismatched timezone; verify the active result remains correct and a bounded mismatch is recorded.",
            "Run an enable-channel command and a last-seen update; assert one write owner and zero shadow side effects."
          ],
          "deliverables": [
            "Safe shadow-read routing, mismatch report, and side-effect inventory"
          ],
          "rollout": "Enable shadow reads for one synthetic tenant with an independent off switch; disable comparison without changing command ownership.",
          "skills": [
            "Incremental migration",
            "Side-effect analysis",
            "Observability"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "strangler-fig",
              "activity": "APPLY",
              "focus": "Replace a bounded read surface gradually while keeping command ownership singular and making shadow failures independent of served responses."
            }
          ]
        },
        {
          "id": "49f73a1b-189e-40b2-b4af-f42b73633f8c",
          "key": "PMIGRATE-105",
          "title": "Preserve tenant scope and conditional reads through the migration proxy",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "transition",
          "dependsOn": [
            "PMIGRATE-104"
          ],
          "scenario": "A local migration proxy forwards the account identifier but drops the authorized tenant context and If-None-Match value. The new path both loses cache semantics and trusts a tenant header supplied by the caller.",
          "acceptanceCriteria": [
            "Forward server-derived tenant scope and conditional-read metadata through a typed proxy boundary without trusting caller-supplied scope.",
            "Preserve documented ETag, not-modified, not-found, and error behavior for both active implementations.",
            "Reject missing authorized scope before forwarding and keep proxy diagnostics free of credentials and full account bodies."
          ],
          "implementationNotes": [
            "The proxy controls access and delegation; keep storage mapping in adapters rather than accumulating business rules in the proxy."
          ],
          "verification": [
            "Send matching and stale ETags through old and new routes and compare their public conditional responses.",
            "Spoof a tenant header, omit authorized context, and force an adapter error; assert denial and sanitized error output."
          ],
          "deliverables": [
            "Proxy context contract and conditional-read/tenant regression cases"
          ],
          "rollout": "Exercise the proxy with local synthetic clients before enabling tenant routing; route back through the corrected legacy boundary on failure.",
          "skills": [
            "Delegation boundaries",
            "HTTP semantics",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 40
            },
            {
              "field": "System design",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "proxy",
              "activity": "REFACTOR",
              "focus": "Keep access control and delegation transparent to the account contract while ensuring proxy forwarding cannot weaken tenant or cache semantics."
            }
          ]
        },
        {
          "id": "08c74343-ebf8-4714-b4ff-dc6bf42ee583",
          "key": "PMIGRATE-106",
          "title": "Decide whether a separate account summary read model earns its lag",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "transition",
          "dependsOn": [
            "PMIGRATE-103",
            "PMIGRATE-104"
          ],
          "scenario": "The account summary joins five tables and is the slowest synthetic endpoint. A CQRS proposal introduces a projection, but support must see a just-disabled booking channel immediately after issuing the command.",
          "acceptanceCriteria": [
            "Compare an indexed transactional query with a separate projection using a declared synthetic dataset and equivalent authorization boundaries.",
            "For the projection option, expose freshness/version semantics and define a read-after-write path that cannot show a disabled channel as enabled after an acknowledged command.",
            "Document latency, write cost, rebuild behavior, and operational complexity; implement the selected option and justify rejecting the other."
          ],
          "implementationNotes": [
            "CQRS does not require separate services or event sourcing here; evaluate command/query separation within the existing local application."
          ],
          "verification": [
            "Measure both options with identical account counts and query mix, reporting warmup and repeated-run variability.",
            "Pause projection updates, issue a disable command, and exercise the declared freshness strategy; test an interrupted rebuild without cross-tenant reads."
          ],
          "deliverables": [
            "Read-model comparison, selected implementation, and freshness/rebuild contract"
          ],
          "rollout": "Canary the selected read path for one synthetic tenant; retain the transactional path until freshness and rebuild failure checks pass.",
          "skills": [
            "Read-model design",
            "Consistency",
            "Performance analysis",
            "Tradeoff analysis"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 30
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "cqrs",
              "activity": "COMPARE",
              "focus": "Compare command/query separation with an indexed query using freshness, rebuild, and write-cost requirements rather than assuming a projection is necessary."
            }
          ]
        },
        {
          "id": "63ede710-2e17-4fef-b54d-334b6c0a8e31",
          "key": "PMIGRATE-107",
          "title": "Delete account facade layers that only rename the same call",
          "type": "CHORE",
          "priority": "LOW",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "transition",
          "dependsOn": [
            "PMIGRATE-101",
            "PMIGRATE-103"
          ],
          "scenario": "A timezone field now crosses AccountFacade, AccountGatewayFacade, AccountServiceFacade, and AccountAccessFacade. Three wrappers have one consumer, add no behavior, and make a one-field change touch twelve files.",
          "acceptanceCriteria": [
            "Trace the timezone read and identify which boundary owns compatibility, policy, authorization, and persistence responsibilities.",
            "Remove pass-through facades that add no independent responsibility while retaining the public compatibility boundary and storage port.",
            "The timezone response, authorization behavior, and adapter substitution remain unchanged with fewer forwarding sites to maintain."
          ],
          "implementationNotes": [
            "Do not replace deleted facades with a dynamic service locator or merge authorization checks into controllers only."
          ],
          "verification": [
            "Run the same response and adapter-substitution cases before and after the simplification.",
            "Exercise cross-tenant denial and a storage failure through the simplified path; verify neither is swallowed by forwarding code."
          ],
          "deliverables": [
            "Focused simplification patch and a before/after responsibility map"
          ],
          "rollout": "Land the forwarding cleanup separately from routing changes so a regression can be traced and reverted without changing migration state.",
          "skills": [
            "Refactoring",
            "Responsibility analysis",
            "Maintainability"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 60
            },
            {
              "field": "Backend",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "facade",
              "activity": "REMOVE",
              "focus": "Remove redundant facade layers with no compatibility or policy responsibility while retaining the one boundary that protects callers from the legacy model."
            }
          ]
        },
        {
          "id": "cadaa88f-1e22-4b30-91d3-9d285e73e3ee",
          "key": "PMIGRATE-108",
          "title": "Transfer tenant write ownership without accepting commands on both sides",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "retire",
          "dependsOn": [
            "PMIGRATE-105",
            "PMIGRATE-106"
          ],
          "scenario": "Two local application instances cache the tenant migration flag at different times. During cutover, one writes the legacy table while another writes the replacement, leaving two conflicting account revisions.",
          "acceptanceCriteria": [
            "Represent write ownership with a durable tenant migration revision and reject commands using a stale ownership revision at the write boundary.",
            "Backfill replacement data and reconcile it through the final legacy revision under the ownership fence; do not open the new writer while any committed legacy change remains unapplied.",
            "Define a cutover sequence that drains or rejects in-flight old-owner commands before the new owner accepts writes.",
            "Document and rehearse how rollback handles writes already accepted by the new owner; switching a read flag alone cannot declare rollback complete."
          ],
          "implementationNotes": [
            "Keep the exercise in one local database and explicit transactions; do not claim cross-database atomicity or solve stale ownership with cache TTL alone."
          ],
          "verification": [
            "Copy tenant data, commit a later legacy write, then interleave commands from two instances around cutover; assert the new owner includes that write and a single accepted ownership lineage loses no successful writes.",
            "Crash after ownership transfer and attempt rollback after a new-side write; verify the recovery procedure detects and reconciles that write before reopening old ownership."
          ],
          "deliverables": [
            "Tenant cutover command, stale-owner rejection checks, and write-aware rollback drill"
          ],
          "rollout": "Rehearse with one synthetic tenant and a paused writer; expand only after cutover and rollback counts reconcile.",
          "skills": [
            "Migration fencing",
            "Concurrency",
            "Transactional state",
            "Recovery planning"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "strangler-fig",
              "activity": "APPLY",
              "focus": "Make incremental replacement include durable write ownership and a data-aware rollback boundary, rather than treating tenant routing as a cosmetic flag."
            }
          ]
        },
        {
          "id": "3a2a767b-6d6d-46a0-a261-e6d7f01c5c2c",
          "key": "PMIGRATE-109",
          "title": "Catch replacement-adapter drift before declaring tenant parity",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "retire",
          "dependsOn": [
            "PMIGRATE-103",
            "PMIGRATE-105",
            "PMIGRATE-107"
          ],
          "scenario": "Both adapters pass the happy-path tests, but the replacement sorts equal-name accounts differently and rounds stored revision values when decoding a database result. Parity dashboards currently compare only HTTP status codes.",
          "acceptanceCriteria": [
            "Extend the shared port contract to stable sort tie-breakers, null handling, exact revisions, and documented domain error mapping.",
            "Run a fixed synthetic corpus against each adapter and compare normalized semantic results rather than timestamps or implementation-only columns.",
            "A mismatch report identifies the contract case and differing public fields without dumping tenant data or silently accepting expected failures."
          ],
          "implementationNotes": [
            "Keep adapter-specific SQL assertions separate from the shared behavior contract so the suite does not require identical internal implementations."
          ],
          "verification": [
            "Use equal-name accounts, null settings, and large valid revision values to verify exact contract parity.",
            "Inject a deliberate order reversal and stale-revision acceptance into one local adapter; confirm the comparison fails with an actionable case identifier."
          ],
          "deliverables": [
            "Expanded adapter contract suite and sanitized parity report"
          ],
          "rollout": "Require a clean contract report before moving the next synthetic tenant; keep mismatched tenants on their current owner until the discrepancy is resolved.",
          "skills": [
            "Contract testing",
            "Data fidelity",
            "Regression diagnosis"
          ],
          "fieldMix": [
            {
              "field": "Quality engineering",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "ports-and-adapters",
              "activity": "APPLY",
              "focus": "Use the shared port as a behavioral contract for interchangeable adapters, testing semantic parity without binding the contract to either storage implementation."
            }
          ]
        },
        {
          "id": "a1cb85cf-cd9f-4008-bb8a-8181ba0d94ba",
          "key": "PMIGRATE-110",
          "title": "Retire the legacy account path only after the last caller is accounted for",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "retire",
          "dependsOn": [
            "PMIGRATE-108",
            "PMIGRATE-109"
          ],
          "scenario": "All interactive tenants use the replacement, but a weekly synthetic export still imports the legacy repository directly. Deleting the old table based on request traffic would break that job and erase the only rollback copy.",
          "acceptanceCriteria": [
            "Inventory HTTP, scheduled, and direct module callers and migrate remaining accesses through the supported contract.",
            "Define observable retirement criteria including zero old-owner tenants, a complete job cycle, reconciled data, and an explicit rollback-retention decision.",
            "Separate code-path removal from any destructive schema change and provide a rehearsed restore path for the retained synthetic snapshot."
          ],
          "implementationNotes": [
            "Remove obsolete migration facades and proxy branches once their responsibilities end; keep the public account contract independent of temporary migration machinery."
          ],
          "verification": [
            "Run the weekly export and interactive contract suite with legacy routing disabled; assert no code path queries the retired repository.",
            "Leave one synthetic old-owner tenant or omit a scheduled caller and confirm retirement validation blocks removal; rehearse restoring the retained data snapshot."
          ],
          "deliverables": [
            "Caller inventory, retirement checks, cleanup patch, and synthetic restore report"
          ],
          "rollout": "Disable legacy routing, observe one full synthetic job cycle, then remove unused code; schedule schema deletion separately after the retention decision.",
          "skills": [
            "Dependency analysis",
            "Migration completion",
            "Operational handoff"
          ],
          "fieldMix": [
            {
              "field": "System design",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "strangler-fig",
              "activity": "APPLY",
              "focus": "Complete the replacement by accounting for background callers and rollback data, with explicit criteria for retiring the old implementation."
            },
            {
              "pattern": "proxy",
              "activity": "REMOVE",
              "focus": "Remove migration-only routing branches after the transition ends so temporary delegation machinery does not become a permanent maintenance layer."
            }
          ]
        }
      ]
    },
    {
      "id": "39d8a4b2-0b08-47eb-8eed-1720fae20f48",
      "key": "PRECOVER",
      "title": "Recover interrupted returns without refunding twice",
      "field": "Distributed systems",
      "summary": "Coordinate return inspection, replacement stock, and refunds across controllable provider boundaries while keeping uncertain outcomes visible.",
      "context": "A fictional equipment retailer lets customers choose a refund or replacement after inspection. Its payment and stock providers can time out after accepting an operation, so retrying the whole return is unsafe. Create a local TypeScript application, PostgreSQL state/outbox tables, and synthetic provider doubles with controllable outcomes; no starter code or fixtures are supplied. Use invented orders and integer minor-unit amounts only, with no real payments or external provider calls.",
      "stack": [
        "TypeScript",
        "Node.js",
        "PostgreSQL",
        "Vitest"
      ],
      "prerequisites": [
        "SQL transactions",
        "Idempotent commands",
        "Async failure handling",
        "State modeling"
      ],
      "developerValue": "Practice durable workflow state, ambiguous provider outcomes, compensation, concurrency isolation, and recovery that survives process restarts.",
      "companyValue": "Inspect whether a proposed workflow preserves refund and inventory invariants, contains provider failures, and gives operators a bounded recovery path.",
      "delivery": "Ten tickets over command intake, provider recovery, and operational rehearsal. Build controllable synthetic dependencies for an individual issue or deliver the complete local returns workflow with failure drills.",
      "phases": [
        {
          "id": "commit",
          "title": "Accept one durable intent",
          "goal": "Make return decisions, commands, and pending work consistent before calling providers."
        },
        {
          "id": "recover",
          "title": "Handle partial and uncertain outcomes",
          "goal": "Coordinate effects and compensation while containing independent provider failures."
        },
        {
          "id": "operate",
          "title": "Rehearse bounded recovery",
          "goal": "Make operator replay, restart behavior, and overload limits inspectable."
        }
      ],
      "tickets": [
        {
          "id": "abb1e684-4877-4e04-800c-473070d5dd6c",
          "key": "PRECOVER-101",
          "title": "Reject return decisions that skip inspection or reverse a completed refund",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "commit",
          "dependsOn": [],
          "scenario": "The return endpoint accepts a caller-supplied status string. A replacement can be requested before inspection, and a stale browser tab can move a refunded return back to awaiting-inspection.",
          "acceptanceCriteria": [
            "Define explicit commands and permitted transitions for awaiting inspection, approved, rejected, processing, completed, and needs-review states.",
            "Require an expected revision and authorized merchant scope for each decision; terminal outcomes cannot be overwritten by a stale command.",
            "Return stable invalid-transition and revision-conflict errors while preserving an append-only transition history."
          ],
          "implementationNotes": [
            "Compare a transition table with state objects; choose the representation that makes allowed transitions and guards easiest to inspect."
          ],
          "verification": [
            "Exercise the approved-refund and rejected-inspection paths and compare their recorded transition order.",
            "Attempt a pre-inspection replacement, a post-refund reversal, and a cross-merchant decision; verify no state or history mutation."
          ],
          "deliverables": [
            "Return transition contract and invalid-transition regression cases"
          ],
          "rollout": "Route local return decisions through the explicit transition API before adding provider effects; retain transition history when reverting the UI.",
          "skills": [
            "State modeling",
            "Concurrency control",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "Backend",
              "percentage": 50
            },
            {
              "field": "System design",
              "percentage": 30
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "state",
              "activity": "COMPARE",
              "focus": "Compare guarded state objects with an explicit transition table for preventing illegal return actions without requiring a class for every status."
            }
          ]
        },
        {
          "id": "3739ff4f-03b0-4ae1-987b-195df9cf5d5e",
          "key": "PRECOVER-102",
          "title": "Bind a repeated refund request to its original merchant and intent",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "commit",
          "dependsOn": [
            "PRECOVER-101"
          ],
          "scenario": "The browser retries an approved 4,500-minor-unit refund after a lost response. The current deduplication key is global, and changing the amount while reusing the key overwrites the queued request.",
          "acceptanceCriteria": [
            "Persist an immutable refund command with merchant, return, amount, currency, and a canonical intent hash scoped to its request key.",
            "Identical retries return the existing command identity and current status; changed intent under the same scoped key returns a conflict.",
            "Concurrent identical requests create one accepted command, and command history never rewrites the original amount or target return."
          ],
          "implementationNotes": [
            "Represent the operation as a durable command rather than relying on an in-memory callback or HTTP response cache; amounts use integer minor units."
          ],
          "verification": [
            "Submit the same intent concurrently and retry after a simulated lost response; compare one command identity and one accepted history entry.",
            "Reuse the key with a new amount and from another merchant; assert conflict for changed scoped intent and independent authorized identities across merchants."
          ],
          "deliverables": [
            "Durable refund command contract and scoped idempotency reproduction"
          ],
          "rollout": "Enable durable command intake before dispatching synthetic refunds; disable new intake without deleting accepted command identities.",
          "skills": [
            "Command modeling",
            "Idempotency",
            "Intent hashing"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Backend",
              "percentage": 30
            },
            {
              "field": "Database engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "command",
              "activity": "APPLY",
              "focus": "Capture refund intent as an immutable durable command so retries refer to the same operation and cannot quietly change its merchant, amount, or target."
            }
          ]
        },
        {
          "id": "7165322e-68ac-4394-a263-1b56017e4dce",
          "key": "PRECOVER-103",
          "title": "Commit approved return work and its dispatch record together",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "commit",
          "dependsOn": [
            "PRECOVER-102"
          ],
          "scenario": "The application marks a return processing, then publishes a refund job. If it crashes between those steps, the return is stuck forever; publishing first can instead process a refund for a rolled-back decision.",
          "acceptanceCriteria": [
            "Commit the accepted command, return transition, and outbox record in one database transaction with a deterministic dispatch identity.",
            "A bounded dispatcher claims due records safely across two instances and retries using the same operation identity.",
            "Treat dispatch as at-least-once: acknowledgment loss can redeliver, but downstream handling deduplicates the effect and pending records remain observable."
          ],
          "implementationNotes": [
            "Do not hold the database transaction open during a provider call; use explicit lease expiry and attempt limits for dispatch recovery."
          ],
          "verification": [
            "Crash before and after commit and compare return, command, and outbox records for atomic presence or absence.",
            "Lose a dispatch acknowledgment and run two dispatchers through lease expiry; assert one logical refund intent despite repeat delivery."
          ],
          "deliverables": [
            "Transactional outbox write path, dispatcher, and crash-boundary checks"
          ],
          "rollout": "Start with dispatch paused and reconcile synthetic pending counts; enable one dispatcher before rehearsing a second instance and restart.",
          "skills": [
            "Transactional outbox",
            "Job leases",
            "At-least-once delivery"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "transactional-outbox",
              "activity": "APPLY",
              "focus": "Bind state and dispatch intent to one commit while accepting repeat delivery and preserving deterministic identities for downstream deduplication."
            }
          ]
        },
        {
          "id": "13789c97-3005-4ad9-b071-6acac9cba754",
          "key": "PRECOVER-104",
          "title": "Persist replacement progress across stock reservation and shipment creation",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "recover",
          "dependsOn": [
            "PRECOVER-103"
          ],
          "scenario": "A replacement reserves the last unit, then shipment creation fails. Retrying from the beginning makes another reservation, while immediately issuing a refund would ignore stock still held for the customer.",
          "acceptanceCriteria": [
            "Persist separate reservation and shipment steps with stable provider operation keys and explicit pending, confirmed, failed, and uncertain outcomes.",
            "Resume from recorded progress after restart; a confirmed reservation is reused instead of repeated when shipment creation is retried.",
            "On a confirmed shipment failure, schedule release of the reservation before offering the declared refund fallback; uncertain effects remain unresolved until checked."
          ],
          "implementationNotes": [
            "Use a durable orchestrated workflow in the local application; compensation is another fallible operation, not a database rollback of an external effect."
          ],
          "verification": [
            "Reserve stock, crash before shipment confirmation, and resume; assert one reservation lineage and the correct next step.",
            "Return a confirmed shipment rejection and then a reservation-release timeout; verify the workflow remains visible and does not silently refund or reserve again."
          ],
          "deliverables": [
            "Replacement step model and reservation/shipment recovery cases"
          ],
          "rollout": "Enable the replacement path for one synthetic order type; pause new workflows while allowing existing recorded steps to reconcile on rollback.",
          "skills": [
            "Workflow orchestration",
            "Compensation",
            "Uncertain outcomes"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 20
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "saga",
              "activity": "APPLY",
              "focus": "Coordinate durable replacement steps and fallible compensation so a partial provider success can be resumed or reconciled without repeating earlier effects."
            },
            {
              "pattern": "state",
              "activity": "APPLY",
              "focus": "Represent uncertain provider outcomes separately from confirmed failures so workflow transitions cannot invent a successful rollback or completed refund."
            }
          ]
        },
        {
          "id": "e1245d90-d1f1-43cf-97e4-b874834702f9",
          "key": "PRECOVER-105",
          "title": "Open the refund circuit without declaring timed-out refunds failed",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 210,
          "phaseId": "recover",
          "dependsOn": [
            "PRECOVER-103",
            "PRECOVER-104"
          ],
          "scenario": "The synthetic refund provider begins timing out. The proposed circuit breaker maps every timeout to failed and releases queued retries when it closes, even though some timed-out refunds were accepted by the provider.",
          "acceptanceCriteria": [
            "Define closed, open, and half-open behavior with a controllable clock, a bounded failure window, and a limited number of half-open probes.",
            "Opening the circuit defers new provider attempts without converting existing uncertain refund outcomes into confirmed failures.",
            "Reconcile ambiguous operation identities through the provider's status lookup before resubmission; a reopened circuit preserves pending work and retry timing."
          ],
          "implementationNotes": [
            "Use provider idempotency and status lookup contracts in addition to the breaker; a circuit breaker alone cannot prevent duplicate money movement."
          ],
          "verification": [
            "Advance a fake clock through the failure threshold, open window, and half-open success/failure paths and assert bounded probe calls.",
            "Simulate provider acceptance followed by timeout, then close the circuit; verify reconciliation finds the original refund and no second refund is created."
          ],
          "deliverables": [
            "Refund circuit policy, uncertain-outcome reconciliation, and clock-driven cases"
          ],
          "rollout": "Observe the synthetic failure window before enabling deferral; disabling the breaker must not bypass uncertain-outcome reconciliation.",
          "skills": [
            "Failure containment",
            "Retry semantics",
            "Provider reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 50
            },
            {
              "field": "Site reliability",
              "percentage": 30
            },
            {
              "field": "Integrations",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "circuit-breaker",
              "activity": "APPLY",
              "focus": "Bound attempts during provider failure while keeping circuit health separate from each refund's durable and potentially uncertain business outcome."
            }
          ]
        },
        {
          "id": "9bf58749-4d68-407b-8204-488d0352241a",
          "key": "PRECOVER-106",
          "title": "Keep stalled stock calls from consuming every refund execution slot",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 180,
          "phaseId": "recover",
          "dependsOn": [
            "PRECOVER-104",
            "PRECOVER-105"
          ],
          "scenario": "Stock reservations and refunds share a 12-slot provider pool. Twelve hanging stock requests prevent an otherwise healthy refund provider from receiving work, and the pending promise list grows without a limit.",
          "acceptanceCriteria": [
            "Give stock and refund operations independent concurrency limits and bounded waiting queues with explicit admission outcomes.",
            "Timeout, cancellation, and provider rejection each release a slot exactly once while preserving durable work for the declared retry policy.",
            "When stock capacity is saturated, refund work continues within its configured limit and neither queue exceeds its cap."
          ],
          "implementationNotes": [
            "Document what is isolated by the pools and what remains shared, including database capacity; do not claim full fault isolation from separate counters alone."
          ],
          "verification": [
            "Hold all stock operations behind a barrier and complete a refund batch without exceeding either provider's concurrency limit.",
            "Cancel queued work, time out running calls, and overfill both queues; assert no leaked permits or unbounded pending promises."
          ],
          "deliverables": [
            "Provider capacity limits, admission contract, and saturation reproduction"
          ],
          "rollout": "Start with conservative synthetic pool limits and expose queue depth/rejection counts; pause intake before lowering limits below active work.",
          "skills": [
            "Concurrency limits",
            "Backpressure",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Performance engineering",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "bulkhead",
              "activity": "APPLY",
              "focus": "Separate provider execution capacity so a stalled stock dependency cannot consume refund slots, with bounded queues and explicit permit cleanup."
            }
          ]
        },
        {
          "id": "57404c29-4ac6-4008-937b-f593c355b691",
          "key": "PRECOVER-107",
          "title": "Stop compensation retries when a replacement has already shipped",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 300,
          "phaseId": "recover",
          "dependsOn": [
            "PRECOVER-104",
            "PRECOVER-105",
            "PRECOVER-106"
          ],
          "scenario": "A shipment-create response was lost, so the return entered compensation. A later status lookup confirms the replacement shipped; the queued compensation still plans to release stock and refund the customer.",
          "acceptanceCriteria": [
            "Revalidate confirmed external progress and the workflow revision before each compensation step; a stale plan cannot execute against newer shipment state.",
            "Represent irreversible shipment completion and conflicting provider facts explicitly, moving unresolved cases to needs-review with a bounded reason trail.",
            "An authorized resolution records its cited synthetic provider references and chosen next action without deleting earlier uncertainty or issuing an unapproved second benefit."
          ],
          "implementationNotes": [
            "Compensation must follow the declared return policy and current confirmed facts; never model an external shipment as a reversible local transaction."
          ],
          "verification": [
            "Queue compensation, then reveal a confirmed shipment before its next step; assert the stale compensation is stopped and no refund is issued.",
            "Race two resolution attempts and return contradictory provider status responses; verify one revision wins and unresolved contradictions remain visible."
          ],
          "deliverables": [
            "Compensation guards, conflict-resolution contract, and late-confirmation race cases"
          ],
          "rollout": "Enable automatic compensation only for confirmed reversible states; keep conflict resolution explicit and retain a pause control for all pending compensation.",
          "skills": [
            "Compensation policy",
            "Race conditions",
            "Operational resolution"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 60
            },
            {
              "field": "System design",
              "percentage": 20
            },
            {
              "field": "Backend",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "saga",
              "activity": "REFACTOR",
              "focus": "Make compensation conditional on current durable and provider-confirmed facts, including irreversible progress and a visible unresolved state."
            }
          ]
        },
        {
          "id": "ad630bea-5316-49dc-8464-48c61ae32673",
          "key": "PRECOVER-108",
          "title": "Preview the exact return command before an operator requests replay",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 120,
          "phaseId": "operate",
          "dependsOn": [
            "PRECOVER-102",
            "PRECOVER-107"
          ],
          "scenario": "Support can currently click Retry beside a return without seeing whether it will check a refund status, retry a reservation, or attempt compensation. The button also lets a stale page replay a command that already completed.",
          "acceptanceCriteria": [
            "Show the immutable command identity, target return, intended next operation, current revision, and the reason replay is eligible or blocked.",
            "A preview is read-only; replay requires an explicit authorized command with expected revision and a fresh eligibility check.",
            "Reusing the replay request key returns the existing replay result, while completed or unresolved-ineligible operations cannot be forced through this path."
          ],
          "implementationNotes": [
            "Show only synthetic operational identifiers and bounded explanations; replay cannot edit the original refund amount or target operation."
          ],
          "verification": [
            "Preview one eligible status-check command and one completed command; confirm the preview performs no provider calls or writes.",
            "Complete a command after preview, then request replay with its stale revision; also try an unauthorized merchant and assert rejection."
          ],
          "deliverables": [
            "Replay preview and command endpoint contracts with stale/denied cases"
          ],
          "rollout": "Expose preview before enabling the replay action; disable replay writes independently while keeping history and explanations available.",
          "skills": [
            "Operational UX",
            "Command authorization",
            "Optimistic concurrency"
          ],
          "fieldMix": [
            {
              "field": "API design",
              "percentage": 40
            },
            {
              "field": "Backend",
              "percentage": 40
            },
            {
              "field": "Security",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "command",
              "activity": "APPLY",
              "focus": "Expose durable command intent for safe preview and explicit replay while keeping the original operation immutable and rechecking eligibility at execution."
            }
          ]
        },
        {
          "id": "cae47a97-3935-473b-bc6f-9c717638059d",
          "key": "PRECOVER-109",
          "title": "Rehearse returns recovery at every commit and provider acknowledgment boundary",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 330,
          "phaseId": "operate",
          "dependsOn": [
            "PRECOVER-103",
            "PRECOVER-107",
            "PRECOVER-108"
          ],
          "scenario": "The happy-path demo succeeds, but no one has restarted the application between a provider accepting an operation and the database recording its result. A green HTTP test does not establish whether accepted refunds survive recovery correctly.",
          "acceptanceCriteria": [
            "Create a deterministic crash matrix covering command commit, outbox claim, provider acceptance, acknowledgment persistence, and compensation progress.",
            "After each restart, reconcile durable commands, provider operations, and return state; no confirmed effect disappears and no logical refund is applied twice.",
            "Distinguish eventual completion under a recovered provider from explicit unresolved state when the provider remains unavailable or contradictory."
          ],
          "implementationNotes": [
            "Use process restarts and durable local database state, not only thrown exceptions inside one transaction; reset synthetic provider state deliberately between cases."
          ],
          "verification": [
            "Run every crash point twice with the same seeded workload and compare final command/effect counts and unresolved reason codes.",
            "Keep status lookup unavailable after an acceptance timeout and verify the drill stops at a visible unresolved state rather than manufacturing completion."
          ],
          "deliverables": [
            "Restart harness, crash-boundary matrix, and reconciled synthetic effect report"
          ],
          "rollout": "Run the full drill before enabling a new workflow version; pause new intake and drain or reconcile recorded work before reverting code.",
          "skills": [
            "Fault injection",
            "Durable recovery",
            "Invariant testing",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "Distributed systems",
              "percentage": 40
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "transactional-outbox",
              "activity": "APPLY",
              "focus": "Verify the outbox's durable intent and repeat-delivery behavior at actual restart boundaries instead of assuming publication and acknowledgment are atomic."
            },
            {
              "pattern": "saga",
              "activity": "APPLY",
              "focus": "Exercise workflow resumption and compensation after partial external effects, accepting explicit unresolved states when provider facts cannot be established."
            }
          ]
        },
        {
          "id": "3155f1d2-c3c9-442d-9f0b-9bef6178b8a8",
          "key": "PRECOVER-110",
          "title": "Tune recovery capacity without creating a retry surge when a provider returns",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "PRECOVER-105",
            "PRECOVER-106",
            "PRECOVER-109"
          ],
          "scenario": "A ten-minute synthetic outage leaves 2,000 deferred returns. When the circuit closes, every due retry enters the refund pool together, crowding out new work and exhausting the shared database connection budget.",
          "acceptanceCriteria": [
            "Define bounded admission and fair scheduling between new and recovery work, with retry jitter generated from a reproducible test seed.",
            "Coordinate half-open probes, provider pool limits, and the shared database budget so reopening cannot enqueue or execute the entire backlog at once.",
            "Report backlog age, queue occupancy, rejection/defer counts, and completion time for the declared local load; justify selected limits and remaining shared bottlenecks."
          ],
          "implementationNotes": [
            "No universal throughput target is assumed; state machine resources, workload, and acceptable service objectives before comparing capacity settings."
          ],
          "verification": [
            "Recover a seeded 2,000-return backlog while submitting new work and verify bounded concurrency, queue sizes, and progress for both classes.",
            "Make the provider fail again during recovery and cancel waiting work; assert permits are released, retries remain durable, and no tight retry loop forms."
          ],
          "deliverables": [
            "Recovery scheduling policy, reproducible saturation run, and capacity tradeoff report"
          ],
          "rollout": "Enable recovery scheduling with conservative limits and a pause control; reduce admission before shrinking active pools and preserve pending command identities.",
          "skills": [
            "Capacity planning",
            "Fair scheduling",
            "Retry budgets",
            "Load testing"
          ],
          "fieldMix": [
            {
              "field": "Performance engineering",
              "percentage": 40
            },
            {
              "field": "Site reliability",
              "percentage": 40
            },
            {
              "field": "Distributed systems",
              "percentage": 20
            }
          ],
          "patterns": [
            {
              "pattern": "bulkhead",
              "activity": "REFACTOR",
              "focus": "Extend dependency capacity isolation with fair new/recovery admission and an explicit shared database budget so bounded pools do not hide another bottleneck."
            },
            {
              "pattern": "circuit-breaker",
              "activity": "REFACTOR",
              "focus": "Coordinate half-open probes and reopening with durable retry scheduling so a healthy transition does not release the entire outage backlog at once."
            }
          ]
        }
      ]
    },
    {
      "key": "SMEM",
      "title": "Repair a packet arena before it becomes shared infrastructure",
      "field": "Systems programming",
      "summary": "Build a bounded arena with explicit alignment, lifetime and corruption behavior.",
      "context": "A fictional telemetry collector copies decoded packet fields into a small native arena. The prototype misaligns wide values and reuses memory while readers still hold views. Create a local Rust crate or C library with generated byte fixtures; no device traffic or production allocator replacement is supplied.",
      "stack": [
        "Rust or C",
        "Property tests",
        "AddressSanitizer or Miri"
      ],
      "prerequisites": [
        "Pointers and slices",
        "Integer overflow",
        "Memory alignment"
      ],
      "developerValue": "Practice representation invariants, lifetimes, unsafe-boundary review and memory diagnostics.",
      "companyValue": "Review a component whose allocation failures and corruption cases are explicit before reuse in latency-sensitive code.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "fda2eb6f-d3ed-4893-872f-42640a99f50f",
          "key": "SMEM-101",
          "title": "Specify aligned arena offsets without relying on host luck",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Eight-byte fields happen to work on one machine because the backing buffer begins aligned; a sliced buffer starts at an odd address.",
          "acceptanceCriteria": [
            "Round every allocation to its declared power-of-two alignment",
            "Reject zero and unsupported alignments",
            "Report requested size and remaining capacity without exposing addresses"
          ],
          "implementationNotes": [
            "Use checked integer arithmetic before changing the cursor."
          ],
          "verification": [
            "Allocate mixed one-, four-, and eight-byte records and verify every offset.",
            "Start near the numeric limit and confirm overflow leaves the cursor unchanged."
          ],
          "deliverables": [
            "Arena layout contract and boundary tests"
          ],
          "rollout": "Keep the current copy path until the layout suite passes on two target architectures.",
          "skills": [
            "Alignment",
            "Checked arithmetic"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 80
            },
            {
              "field": "Embedded and edge",
              "percentage": 20
            }
          ],
          "patterns": []
        },
        {
          "id": "35311dcc-1cc7-4b71-925b-589c340e88f8",
          "key": "SMEM-102",
          "title": "Return exhaustion without handing out a partial slice",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A capacity miss advances the arena cursor before returning an error, so the following small allocation also fails.",
          "acceptanceCriteria": [
            "An exhausted allocation returns a typed capacity error",
            "Cursor and prior bytes remain unchanged after failure",
            "A later fitting allocation can still succeed"
          ],
          "implementationNotes": [
            "Do not grow the backing region or panic on caller-controlled sizes."
          ],
          "verification": [
            "Fill the arena exactly and inspect the final valid allocation.",
            "Request one byte too many, then allocate a smaller record and verify state."
          ],
          "deliverables": [
            "Atomic allocation update and exhaustion regression"
          ],
          "rollout": "Treat exhaustion as backpressure in the local collector; never retry without changing capacity or workload.",
          "skills": [
            "Failure atomicity",
            "Resource bounds"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "504c08c1-bc84-404a-8ee2-80301eeddda6",
          "key": "SMEM-103",
          "title": "Invalidate borrowed packet views when the arena resets",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SMEM-101",
            "SMEM-102"
          ],
          "scenario": "A decoder stores a view into the arena across reset and later reads bytes belonging to a different packet.",
          "acceptanceCriteria": [
            "Views carry the generation in which they were created",
            "Reset advances generation before storage is reused",
            "Stale view access fails deterministically in the safe API"
          ],
          "implementationNotes": [
            "Keep unsafe reads inside one reviewed boundary; do not claim runtime checks prove arbitrary raw pointers safe."
          ],
          "verification": [
            "Read several current-generation views before reset.",
            "Reset, reuse the same offset, and reject the older view."
          ],
          "deliverables": [
            "Generation-bound view API and stale-view reproduction"
          ],
          "rollout": "Migrate the decoder through the checked view API before enabling reset reuse.",
          "skills": [
            "Lifetimes",
            "Memory safety",
            "Generations"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "27b222b2-948b-4771-85aa-14fdc1ed778a",
          "key": "SMEM-104",
          "title": "Free large spill blocks without double-releasing arena pages",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "SMEM-102"
          ],
          "scenario": "Oversized records spill to separate blocks. Error cleanup releases a spill block, then arena teardown releases the same block again.",
          "acceptanceCriteria": [
            "Each spill block has one recorded owner",
            "Cleanup is safe when invoked repeatedly",
            "Arena teardown releases only blocks still attached"
          ],
          "implementationNotes": [
            "Model ownership explicitly; a boolean freed flag cannot authorize access after release."
          ],
          "verification": [
            "Allocate and release several spill blocks in different orders.",
            "Inject a decode error after spill allocation and run teardown twice under a memory checker."
          ],
          "deliverables": [
            "Spill ownership model and double-free regression"
          ],
          "rollout": "Disable spill allocation if the checker reports any invalid release.",
          "skills": [
            "Ownership",
            "Cleanup",
            "Memory diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "da3ab846-6a35-4a5c-bc1e-956374a3de95",
          "key": "SMEM-105",
          "title": "Coalesce adjacent free spans without corrupting the index",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SMEM-101",
            "SMEM-104"
          ],
          "scenario": "The free-span list merges with the previous range but forgets the next range, leaving overlapping entries that can be allocated twice.",
          "acceptanceCriteria": [
            "Free spans remain ordered, nonoverlapping, and maximal",
            "Freeing in any order yields the same canonical span set",
            "Double-free and out-of-range spans are rejected"
          ],
          "implementationNotes": [
            "Update the span index under one mutation boundary and preserve the arena on validation failure."
          ],
          "verification": [
            "Free three adjacent blocks in all six orders and compare the final index.",
            "Attempt an overlapping release and prove no index entry changes."
          ],
          "deliverables": [
            "Canonical coalescing algorithm and permutation tests"
          ],
          "rollout": "Run shadow invariant checks in the local benchmark before using reclaimed spans.",
          "skills": [
            "Data structures",
            "Invariants",
            "Property testing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 75
            },
            {
              "field": "Quality engineering",
              "percentage": 25
            }
          ],
          "patterns": []
        },
        {
          "id": "08274454-1425-4d2a-ad93-c6452c131f7d",
          "key": "SMEM-106",
          "title": "Bound fragmentation before adding a more complex allocator",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SMEM-105"
          ],
          "scenario": "The team proposes size classes after one trace shows poor reuse, but the trace mixes long-lived metadata with short-lived packet records.",
          "acceptanceCriteria": [
            "Measure internal and external fragmentation separately",
            "Replay at least three declared lifetime distributions",
            "Compare reset-only, free-list, and size-class approaches with correctness held constant"
          ],
          "implementationNotes": [
            "Do not select an allocator from mean throughput alone; retain raw workload seeds and peak memory."
          ],
          "verification": [
            "Reproduce each workload and its fragmentation measurements.",
            "Change the seed and show the report identifies noncomparable runs."
          ],
          "deliverables": [
            "Allocator comparison with workload manifest"
          ],
          "rollout": "Adopt additional complexity only if the declared workload crosses an agreed bound.",
          "skills": [
            "Benchmarking",
            "Allocator design",
            "Experimental design"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5a906b2f-9d95-48d7-8a5b-dcc610e1b236",
          "key": "SMEM-107",
          "title": "Contain unsafe decoding behind a length-checked cursor",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SMEM-103"
          ],
          "scenario": "Several parsers perform pointer arithmetic independently; one reads a declared payload length before confirming those bytes remain.",
          "acceptanceCriteria": [
            "One cursor owns offset advancement and remaining-length checks",
            "Primitive reads define endianness and alignment behavior",
            "A failed read returns no partially initialized value"
          ],
          "implementationNotes": [
            "Fuzz only the local parser process and cap input length, nesting, and execution time."
          ],
          "verification": [
            "Decode a complete packet containing every primitive type.",
            "Truncate at every byte boundary and run the corpus under sanitizer or Miri."
          ],
          "deliverables": [
            "Checked decode cursor, fuzz corpus, and unsafe-boundary note"
          ],
          "rollout": "Route one packet family at a time through the cursor and retain the prior decoder for comparison.",
          "skills": [
            "Unsafe code review",
            "Binary parsing",
            "Fuzzing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Security",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "808bc159-f44e-44f3-b2cb-17fd30f14616",
          "key": "SMEM-108",
          "title": "Expose arena pressure without logging packet contents",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SMEM-102",
            "SMEM-106"
          ],
          "scenario": "Operators can see allocation failures only in verbose decoder logs that include synthetic payload bytes and unbounded record labels.",
          "acceptanceCriteria": [
            "Publish bounded counters for allocations, spills, resets, and exhaustion",
            "Record capacity and high-water mark without payload content",
            "Reject unbounded caller-provided metric dimensions"
          ],
          "implementationNotes": [
            "Metrics are diagnostic observations for this component, not proof of production capacity."
          ],
          "verification": [
            "Drive allocations and reconcile counters with the deterministic workload.",
            "Supply a unique record label per request and confirm it cannot become a dimension."
          ],
          "deliverables": [
            "Bounded arena telemetry and reconciliation test"
          ],
          "rollout": "Enable metrics before changing allocation policy; remove verbose payload logging.",
          "skills": [
            "Observability",
            "Privacy",
            "Cardinality control"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6b2eedee-57ee-4ae5-a811-778eab500fbd",
          "key": "SMEM-109",
          "title": "Recover a persisted arena snapshot only when its layout matches",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SMEM-105",
            "SMEM-107"
          ],
          "scenario": "A warm-start experiment maps a snapshot written by an older layout and interprets its free-list metadata as current records.",
          "acceptanceCriteria": [
            "Snapshot header binds format version, byte order, size, and checksum",
            "Recovery validates every offset before exposing records",
            "Unknown versions fail closed without modifying the snapshot"
          ],
          "implementationNotes": [
            "Use generated snapshots only; memory mapping does not make untrusted offsets safe."
          ],
          "verification": [
            "Write and restore a current snapshot with identical logical records.",
            "Corrupt each header field and one nested offset, then confirm rejection."
          ],
          "deliverables": [
            "Versioned snapshot reader and corruption matrix"
          ],
          "rollout": "Keep cold reconstruction as the default until compatible recovery is repeatable.",
          "skills": [
            "Persistence formats",
            "Validation",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Storage systems",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "f587f003-d80b-4966-9f94-2178df30a59d",
          "key": "SMEM-110",
          "title": "Hand off the arena with explicit reasons not to use it",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SMEM-106",
            "SMEM-108",
            "SMEM-109"
          ],
          "scenario": "A second team wants the arena for long-lived session objects even though reset semantics and spill behavior were designed for packet batches.",
          "acceptanceCriteria": [
            "Document supported lifetimes, alignment, capacity, thread-safety, and reset rules",
            "List measured bounds and unresolved risks with reproduction commands",
            "Include rejection examples for workloads better served by standard allocation"
          ],
          "implementationNotes": [
            "Do not present local benchmark results as universal performance claims."
          ],
          "verification": [
            "Have a reviewer reproduce one supported workload from a clean checkout.",
            "Apply the documented long-lived workload and confirm the guide recommends against adoption."
          ],
          "deliverables": [
            "Usage contract, decision record, and reproducible handoff"
          ],
          "rollout": "Require a separate review before any new workload adopts the component.",
          "skills": [
            "Technical writing",
            "API contracts",
            "Operational handoff"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "2a56d313-8b40-49e7-83a7-21d05effd695"
    },
    {
      "key": "SCONCUR",
      "title": "Make a native work queue survive real thread interleavings",
      "field": "Systems programming",
      "summary": "Implement bounded scheduling, cancellation and shutdown without hidden liveness failures.",
      "context": "A fictional image-indexing utility runs CPU-only synthetic jobs through a Rust worker pool. Its prototype loses wakeups, blocks shutdown, and treats cancellation as completion. Build a local library and deterministic concurrency harness; image content, GPU work, and production deployment are excluded.",
      "stack": [
        "Rust",
        "Threads",
        "Loom or deterministic scheduler",
        "Criterion"
      ],
      "prerequisites": [
        "Mutexes and condition variables",
        "Atomics",
        "Thread lifecycle"
      ],
      "developerValue": "Practice happens-before reasoning, ownership transfer, cancellation and liveness testing.",
      "companyValue": "Review a worker primitive whose overload and shutdown behavior are predictable before it supports build or media workloads.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "f7ca3509-29b6-4f65-99e1-3d7576662142",
          "key": "SCONCUR-101",
          "title": "Define queue ownership before starting worker threads",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Workers borrow configuration from a stack-owned builder that disappears after start, while the queue handle can outlive the pool.",
          "acceptanceCriteria": [
            "Pool-owned state outlives every worker",
            "Queue handles cannot submit after terminal shutdown",
            "Dropping the final handle has documented behavior"
          ],
          "implementationNotes": [
            "Avoid leaked static references and process-wide mutable state."
          ],
          "verification": [
            "Create, submit, join, and drop a pool repeatedly under a leak checker.",
            "Drop external handles in different orders and verify workers cannot access released state."
          ],
          "deliverables": [
            "Ownership diagram and lifecycle tests"
          ],
          "rollout": "Keep the single-thread runner until lifecycle checks pass.",
          "skills": [
            "Ownership",
            "Thread lifecycle"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "6643c73d-d80b-4f64-85fd-86aaeb056e16",
          "key": "SCONCUR-102",
          "title": "Reject work when the bounded queue is full",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "Producers append without limit while workers are paused, and the process consumes all available memory.",
          "acceptanceCriteria": [
            "Capacity is explicit and positive",
            "Submission returns accepted, timed out, or closed",
            "A rejected job remains caller-owned"
          ],
          "implementationNotes": [
            "Do not hide backpressure behind an unbounded overflow list."
          ],
          "verification": [
            "Fill the queue, release one slot, and submit the next job.",
            "Keep workers paused and confirm memory and queue length remain bounded."
          ],
          "deliverables": [
            "Bounded submission API and overload tests"
          ],
          "rollout": "Start with conservative capacity and surface rejections to the local caller.",
          "skills": [
            "Backpressure",
            "API design"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c19d2098-1bff-474d-bd87-1de398309af2",
          "key": "SCONCUR-103",
          "title": "Close the lost-wakeup gap between predicate and sleep",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SCONCUR-101",
            "SCONCUR-102"
          ],
          "scenario": "A producer signals just before a worker begins waiting; queued work then sleeps until another submission arrives.",
          "acceptanceCriteria": [
            "Workers test the queue predicate under the same synchronization boundary as waiting",
            "Spurious wakeups preserve correctness",
            "One job is claimed by one worker"
          ],
          "implementationNotes": [
            "Document the predicate, mutex, and notification order in code comments beside the wait loop."
          ],
          "verification": [
            "Exercise enqueue before, during, and after worker wait.",
            "Force the historical interleaving and prove the queued job completes without a second signal."
          ],
          "deliverables": [
            "Correct wait loop and deterministic lost-wakeup test"
          ],
          "rollout": "Run the old and new pools against the same scheduler trace before switching.",
          "skills": [
            "Condition variables",
            "Happens-before",
            "Concurrency testing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Quality engineering",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "f3824461-238d-4078-b064-2ab8f7ce08aa",
          "key": "SCONCUR-104",
          "title": "Keep cancellation distinct from successful completion",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "SCONCUR-103"
          ],
          "scenario": "A cancelled indexing job resolves the same completion channel as a finished job, so callers publish an empty index.",
          "acceptanceCriteria": [
            "Result distinguishes success, cancellation, job failure, and pool shutdown",
            "Cancellation before claim prevents execution",
            "Cancellation after claim is cooperative and observable"
          ],
          "implementationNotes": [
            "Do not terminate worker threads asynchronously while they own locks or memory."
          ],
          "verification": [
            "Cancel queued and running cooperative jobs and inspect distinct outcomes.",
            "Use a job that ignores cancellation and verify shutdown reports the unresolved work."
          ],
          "deliverables": [
            "Cancellation state model and race tests"
          ],
          "rollout": "Callers must handle cancellation explicitly before adopting the new result type.",
          "skills": [
            "Cancellation",
            "State modeling"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "151ac8b4-f24b-452e-a4c5-1fb309e47eda",
          "key": "SCONCUR-105",
          "title": "Prevent priority work from starving maintenance forever",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SCONCUR-102",
            "SCONCUR-104"
          ],
          "scenario": "A continuous stream of interactive jobs keeps cache-maintenance tasks queued indefinitely.",
          "acceptanceCriteria": [
            "Scheduling policy defines a bounded wait for every admitted class",
            "Interactive latency remains measured under mixed load",
            "Class selection is deterministic for a declared seed"
          ],
          "implementationNotes": [
            "Do not claim fairness from average completion time; report per-class tail wait."
          ],
          "verification": [
            "Replay a mixed workload and verify the declared service ratio.",
            "Saturate the interactive class and confirm maintenance still advances."
          ],
          "deliverables": [
            "Fair scheduler policy, simulator, and latency report"
          ],
          "rollout": "Canary the policy in the synthetic workload and retain FIFO fallback.",
          "skills": [
            "Scheduling",
            "Fairness",
            "Performance analysis"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ed040569-ec1e-4543-92d6-a7a6e43d8ea1",
          "key": "SCONCUR-106",
          "title": "Remove a lock-order inversion in completion reporting",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SCONCUR-103",
            "SCONCUR-104"
          ],
          "scenario": "The worker holds the queue lock while acquiring a result lock; the joining thread holds the result lock while closing the queue.",
          "acceptanceCriteria": [
            "Declare a single lock order or remove nested acquisition",
            "Completion remains visible before join returns",
            "Shutdown cannot wait while holding a lock needed by workers"
          ],
          "implementationNotes": [
            "Keep callbacks outside internal locks because caller code is untrusted by the synchronization design."
          ],
          "verification": [
            "Complete and join jobs from several workers under the deterministic scheduler.",
            "Force the prior opposing acquisition order and verify progress."
          ],
          "deliverables": [
            "Lock graph, refactor, and deadlock regression"
          ],
          "rollout": "Enable lock-wait diagnostics during the local transition.",
          "skills": [
            "Deadlock analysis",
            "Lock ordering"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "797d56ef-bcbb-4353-be8d-6623e8c56f68",
          "key": "SCONCUR-107",
          "title": "Prove the atomic queue fast path has a safe memory order",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SCONCUR-102",
            "SCONCUR-103"
          ],
          "scenario": "A lock-free experiment publishes a slot index before all job fields are visible, producing rare partially initialized reads on a weakly ordered target.",
          "acceptanceCriteria": [
            "Every atomic operation has a stated synchronization role",
            "Publication makes complete job data visible before claim",
            "Wraparound cannot confuse a reused slot with an older generation"
          ],
          "implementationNotes": [
            "Prefer the mutex implementation unless measured need and model checking justify the atomic path."
          ],
          "verification": [
            "Model-check bounded producers, consumers, and slot reuse.",
            "Weaken the publication ordering in a mutation and ensure the model detects an invalid read."
          ],
          "deliverables": [
            "Memory-order argument, model, and comparison with mutex path"
          ],
          "rollout": "Keep the atomic implementation disabled unless correctness and workload benefit are both demonstrated.",
          "skills": [
            "Atomics",
            "Memory models",
            "Model checking"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Performance engineering",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "4095442e-43f4-4c14-b085-d1f24c90f716",
          "key": "SCONCUR-108",
          "title": "Drain accepted jobs without hanging process shutdown",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SCONCUR-104",
            "SCONCUR-106"
          ],
          "scenario": "Shutdown closes submissions but waits forever for a worker blocked on an external test double that never returns.",
          "acceptanceCriteria": [
            "Shutdown defines stop-accepting, drain, cancel, and terminal states",
            "A deadline reports unfinished job identities without detaching live threads",
            "Repeated shutdown calls return the same terminal outcome"
          ],
          "implementationNotes": [
            "Use controlled local jobs; do not kill threads or the host process to simulate recovery."
          ],
          "verification": [
            "Drain a pool whose jobs complete before the deadline.",
            "Block one job past the deadline and confirm bounded return with an unresolved record."
          ],
          "deliverables": [
            "Shutdown protocol and stuck-job test"
          ],
          "rollout": "Callers keep the old process exit path until they handle unresolved shutdown results.",
          "skills": [
            "Graceful shutdown",
            "Recovery",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7d717d6a-c13b-4544-9463-3bbc2e2d619e",
          "key": "SCONCUR-109",
          "title": "Capture a concurrency failure without megabytes of logs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SCONCUR-105",
            "SCONCUR-106"
          ],
          "scenario": "A rare stall produces per-poll logs from every worker, changing timing and obscuring the last useful state transition.",
          "acceptanceCriteria": [
            "Record a bounded ring of queue and worker transitions",
            "Events use monotonic sequence and synthetic job identity",
            "Snapshot identifies dropped diagnostic events"
          ],
          "implementationNotes": [
            "Do not record job payloads, thread stack memory, or unbounded labels."
          ],
          "verification": [
            "Reconstruct a normal claim-to-completion path from the ring.",
            "Overflow the ring during the forced deadlock trace and retain an explicit loss marker."
          ],
          "deliverables": [
            "Bounded trace recorder and stall diagnostic"
          ],
          "rollout": "Enable the recorder only for the local harness until overhead is measured.",
          "skills": [
            "Diagnostics",
            "Ring buffers",
            "Privacy"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Site reliability",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "b40b5dbb-c01e-46b6-ab37-04516954d6b6",
          "key": "SCONCUR-110",
          "title": "Publish the worker-pool contract and benchmark limits",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SCONCUR-105",
            "SCONCUR-108",
            "SCONCUR-109"
          ],
          "scenario": "A build tool and a request server both plan to reuse the pool despite different fairness, blocking, and shutdown requirements.",
          "acceptanceCriteria": [
            "Document supported job behavior and prohibited blocking assumptions",
            "Report throughput, queue wait, memory, and shutdown duration for declared workloads",
            "List cases where a runtime-native executor is preferable"
          ],
          "implementationNotes": [
            "Do not generalize results beyond the recorded machine and workload profiles."
          ],
          "verification": [
            "Reproduce one CPU-bound and one mixed-duration benchmark from a clean checkout.",
            "Run the unsupported permanently blocking job and confirm the guide predicts the outcome."
          ],
          "deliverables": [
            "Contract, benchmark manifest, and adoption checklist"
          ],
          "rollout": "Require each adopter to select and verify a workload profile.",
          "skills": [
            "Benchmarking",
            "Documentation",
            "Capacity planning"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "26536d74-4837-4bde-ab64-3f13e1b2f2f8"
    },
    {
      "key": "SIPC",
      "title": "Supervise local worker processes without losing their output",
      "field": "Systems programming",
      "summary": "Build framed IPC, bounded buffering, process lifecycle control and restart-safe request identity.",
      "context": "A fictional document converter launches local sandbox substitutes as child processes. Its prototype parses newline-delimited output, leaks descriptors, and retries requests after ambiguous worker exits. Create a Rust supervisor and deterministic worker fixtures; no document content or production sandbox is supplied.",
      "stack": [
        "Rust",
        "Child processes",
        "Unix sockets or named pipes",
        "Vitest or cargo test"
      ],
      "prerequisites": [
        "File descriptors",
        "Framing",
        "Process signals"
      ],
      "developerValue": "Practice IPC contracts, resource inheritance, process supervision and ambiguous completion.",
      "companyValue": "Review a local worker boundary that contains crashes and preserves request outcomes before connecting an isolated execution provider.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "36749fbb-c8fc-48cd-a96a-b504b7b7c0ed",
          "key": "SIPC-101",
          "title": "Frame worker messages without treating newlines as boundaries",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A diagnostic string contains a newline and splits one response into two apparent messages.",
          "acceptanceCriteria": [
            "Frame declares version, type, request identity, and bounded payload length",
            "Reader handles partial headers and payloads",
            "Unknown versions fail without consuming the next frame"
          ],
          "implementationNotes": [
            "Cap frame size before allocating its payload buffer."
          ],
          "verification": [
            "Read several frames split across every header boundary.",
            "Advertise an oversized or truncated payload and verify bounded rejection."
          ],
          "deliverables": [
            "Versioned frame codec and fragmentation tests"
          ],
          "rollout": "Keep the line protocol available only for old local fixtures during migration.",
          "skills": [
            "Binary protocols",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "64ff2e43-105b-4cd5-9cd2-881d56087400",
          "key": "SIPC-102",
          "title": "Close inherited descriptors before executing the worker",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A child inherits the supervisor listener and keeps it open after the parent exits, preventing clean restart.",
          "acceptanceCriteria": [
            "Child receives only declared stdin, stdout, stderr, and control handles",
            "Supervisor closes duplicate ends after spawn",
            "Restart can bind the same local endpoint"
          ],
          "implementationNotes": [
            "Do not depend on a global close-all scan that races other threads opening handles."
          ],
          "verification": [
            "Spawn, complete, and restart a worker while checking descriptor counts.",
            "Add an undeclared inheritable handle and confirm the fixture detects it."
          ],
          "deliverables": [
            "Spawn handle policy and leak regression"
          ],
          "rollout": "Audit handle inheritance before enabling multiple workers.",
          "skills": [
            "Process spawning",
            "Resource cleanup"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "9c0d3081-a6bd-4512-a3cf-a68db6b9567f",
          "key": "SIPC-103",
          "title": "Correlate out-of-order worker replies to the right caller",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SIPC-101"
          ],
          "scenario": "Two conversions finish in reverse order and the supervisor resolves the first waiter with the second result.",
          "acceptanceCriteria": [
            "Every accepted request has a unique operation identity",
            "Replies resolve only the matching pending request",
            "Duplicate and unknown replies are recorded without completing another caller"
          ],
          "implementationNotes": [
            "Keep the pending map bounded by admission capacity and deadlines."
          ],
          "verification": [
            "Complete three requests in reverse order and verify each result.",
            "Send a duplicate and an unknown identity and confirm pending callers remain unchanged."
          ],
          "deliverables": [
            "Correlation table and ordering tests"
          ],
          "rollout": "Enable concurrent requests only after correlation checks pass.",
          "skills": [
            "Correlation IDs",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4fb92f59-13b2-463f-ba7f-7a5feb290b0d",
          "key": "SIPC-104",
          "title": "Separate protocol output from worker diagnostics",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "SIPC-101",
            "SIPC-102"
          ],
          "scenario": "A library warning written to stdout is parsed as a reply and closes the worker connection.",
          "acceptanceCriteria": [
            "Protocol frames use one declared channel",
            "Diagnostics use stderr with bounded capture",
            "Malformed protocol bytes fail the request without hiding diagnostics"
          ],
          "implementationNotes": [
            "Sanitize diagnostics and cap retained bytes per worker."
          ],
          "verification": [
            "Return a valid response while writing warnings to stderr.",
            "Write nonprotocol bytes on the protocol channel and verify isolated failure."
          ],
          "deliverables": [
            "Channel contract and mixed-output fixtures"
          ],
          "rollout": "Treat unexpected stdout as a worker defect during local migration.",
          "skills": [
            "Process I/O",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "22ae357c-b779-4cb2-af5d-b885dc64e6b6",
          "key": "SIPC-105",
          "title": "Apply backpressure when a worker stops reading",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SIPC-103",
            "SIPC-104"
          ],
          "scenario": "A stalled child leaves the supervisor buffering every request body until memory is exhausted.",
          "acceptanceCriteria": [
            "Per-worker and global pending byte limits are enforced",
            "Admission reports overload before consuming the body",
            "Healthy workers can continue within their own capacity"
          ],
          "implementationNotes": [
            "Do not solve the stall with an unbounded retry queue."
          ],
          "verification": [
            "Drive balanced workers to their declared capacity.",
            "Pause one reader and prove buffers remain bounded while another worker progresses."
          ],
          "deliverables": [
            "IPC admission controller and stalled-reader test"
          ],
          "rollout": "Start with small limits and expose overload to callers.",
          "skills": [
            "Backpressure",
            "Resource isolation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": [
            {
              "pattern": "bulkhead",
              "activity": "APPLY",
              "focus": "Isolate each child process buffer and preserve global capacity so one stopped reader cannot consume every supervisor resource."
            }
          ]
        },
        {
          "id": "6995a556-fce5-42e4-b007-06bed5fd4f4a",
          "key": "SIPC-106",
          "title": "Classify worker exit before deciding whether to retry",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SIPC-103"
          ],
          "scenario": "The worker exits after writing its output but before the acknowledgement frame; automatic retry may produce a second external artifact.",
          "acceptanceCriteria": [
            "Outcome distinguishes not-started, running, acknowledged, failed, and unknown",
            "Unknown completion requires status lookup or explicit review",
            "Retry reuses the stable operation identity"
          ],
          "implementationNotes": [
            "Do not infer failure solely from pipe closure or process exit code."
          ],
          "verification": [
            "Exercise exits before start and after acknowledged completion.",
            "Exit after effect but before acknowledgement and preserve UNKNOWN without blind retry."
          ],
          "deliverables": [
            "Exit classification state machine and ambiguity fixtures"
          ],
          "rollout": "Disable automatic retry for unknown outcomes until the worker supports reconciliation.",
          "skills": [
            "Distributed failure",
            "Idempotency",
            "State machines"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "99f143fa-585f-47c0-af09-c74cc2255eb8",
          "key": "SIPC-107",
          "title": "Terminate a process tree without signaling unrelated work",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SIPC-102",
            "SIPC-106"
          ],
          "scenario": "A timed-out worker launches a helper. Killing only the parent leaks the helper; reusing a process-group identifier risks signaling a newer process.",
          "acceptanceCriteria": [
            "Each operation owns a fresh supervised process group or platform job object",
            "Termination verifies the group identity before signaling",
            "Cleanup observes all declared descendants or reports unresolved members"
          ],
          "implementationNotes": [
            "Tests use inert local helpers and never enumerate or signal arbitrary host processes."
          ],
          "verification": [
            "Terminate a fixture parent and its two waiting children.",
            "Reuse a synthetic numeric identifier and prove identity validation blocks the stale cleanup."
          ],
          "deliverables": [
            "Process-tree lifecycle adapter and safe termination tests"
          ],
          "rollout": "Keep worker concurrency at one until descendant cleanup is reliable.",
          "skills": [
            "Process groups",
            "Identity fencing",
            "Cleanup"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "c7702989-e5a3-4afa-b275-bf5af95f87a9",
          "key": "SIPC-108",
          "title": "Restart crashed workers without retry storms",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SIPC-105",
            "SIPC-106"
          ],
          "scenario": "A corrupt fixture crashes every replacement worker, and immediate restart loops consume the supervisor CPU.",
          "acceptanceCriteria": [
            "Restart budget uses bounded attempts and backoff",
            "Stable runtime resets the failure window",
            "Exhaustion opens a visible unavailable state"
          ],
          "implementationNotes": [
            "Use injected time and deterministic jitter; do not sleep in tests."
          ],
          "verification": [
            "Crash twice, recover, and verify the budget clears after stability.",
            "Crash every replacement and confirm restart attempts stop at the bound."
          ],
          "deliverables": [
            "Restart policy and crash-loop test"
          ],
          "rollout": "Fail new requests fast while a worker class is unavailable.",
          "skills": [
            "Supervision",
            "Backoff",
            "Failure isolation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "circuit-breaker",
              "activity": "APPLY",
              "focus": "Open a bounded unavailable state after repeated worker crashes so replacement attempts stop until the declared recovery probe."
            }
          ]
        },
        {
          "id": "2b2c45a8-78da-429f-b580-cbe94eac9a12",
          "key": "SIPC-109",
          "title": "Reconcile pending operations after supervisor restart",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SIPC-103",
            "SIPC-106",
            "SIPC-108"
          ],
          "scenario": "The supervisor restarts with requests marked running but no in-memory correlation table and no proof whether workers completed them.",
          "acceptanceCriteria": [
            "Persist stable operation identity and last acknowledged state before dispatch",
            "Recovery queries a deterministic worker ledger when supported",
            "Unresolved operations remain visible and are never silently marked failed"
          ],
          "implementationNotes": [
            "The local ledger contains synthetic identities and bounded metadata, not document bodies."
          ],
          "verification": [
            "Restart after acknowledgement and restore the completed result.",
            "Restart during an unqueryable effect and retain UNKNOWN for review."
          ],
          "deliverables": [
            "Pending-operation journal and restart drill"
          ],
          "rollout": "Require reconciliation support before enabling autonomous retry.",
          "skills": [
            "Crash recovery",
            "Journaling",
            "Idempotency"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "2a7e116d-a6c6-4d14-913d-61b6b8ea8dad",
          "key": "SIPC-110",
          "title": "Document the IPC boundary for a future isolated provider",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SIPC-107",
            "SIPC-108",
            "SIPC-109"
          ],
          "scenario": "The local child-process harness is about to be mistaken for a production candidate-code sandbox.",
          "acceptanceCriteria": [
            "Document framing, resource limits, process identity, shutdown, and unresolved outcomes",
            "State which isolation guarantees the local supervisor does not provide",
            "Define the provider contract a hardened external executor must satisfy"
          ],
          "implementationNotes": [
            "Do not claim namespace, secret, network, or host isolation from ordinary child processes."
          ],
          "verification": [
            "Reproduce the local crash and restart drill from the guide.",
            "Attempt to select the local adapter under a production configuration and require fail-closed behavior."
          ],
          "deliverables": [
            "IPC contract and explicit production boundary note"
          ],
          "rollout": "Keep the local supervisor restricted to synthetic development fixtures.",
          "skills": [
            "Provider interfaces",
            "Security boundaries",
            "Documentation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "a40a56f5-00da-4afb-b1fb-38fe8499c4be"
    },
    {
      "key": "SRUNTIME",
      "title": "Evolve a bounded bytecode runtime without executing host code",
      "field": "Systems programming",
      "summary": "Implement decoding, stack safety, resource budgets and compatible bytecode revisions.",
      "context": "A fictional rules engine executes a tiny arithmetic bytecode over synthetic integers. Its interpreter trusts jump offsets and can run forever. Build a local Rust runtime; it has no filesystem, network, dynamic loading, host calls, or candidate-source execution.",
      "stack": [
        "Rust",
        "Bytecode fixtures",
        "Property tests",
        "Fuzzing"
      ],
      "prerequisites": [
        "Stacks",
        "Instruction decoding",
        "Control flow"
      ],
      "developerValue": "Practice runtime invariants, validation, resource accounting and compatibility.",
      "companyValue": "Review a constrained execution component whose malformed programs fail deterministically without gaining host capabilities.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "dded49ac-11a5-4f77-980b-98a1e72fe2ca",
          "key": "SRUNTIME-101",
          "title": "Decode instructions without reading past the bytecode buffer",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A truncated PUSH instruction reads its operand from bytes beyond the supplied program.",
          "acceptanceCriteria": [
            "Decoder checks opcode and operand length before advancing",
            "Unknown opcodes return a stable offset and code",
            "Failure exposes no partially decoded instruction"
          ],
          "implementationNotes": [
            "Keep bytecode length bounded before parsing."
          ],
          "verification": [
            "Decode a program containing every documented instruction.",
            "Truncate at every byte and confirm deterministic errors without panic."
          ],
          "deliverables": [
            "Checked decoder and truncation matrix"
          ],
          "rollout": "Reject programs not validated by the new decoder.",
          "skills": [
            "Binary parsing",
            "Bounds checking"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "417fa830-641c-4a0f-83e3-a022f5fda1ee",
          "key": "SRUNTIME-102",
          "title": "Validate stack depth across both sides of a branch",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [
            "SRUNTIME-101"
          ],
          "scenario": "One branch pushes a value and the other does not, so the merge point underflows only for certain inputs.",
          "acceptanceCriteria": [
            "Validator computes required and resulting depth per instruction",
            "Control-flow merges require compatible stack shape",
            "Maximum stack depth is bounded before execution"
          ],
          "implementationNotes": [
            "Validation must terminate on loops through a visited-state worklist."
          ],
          "verification": [
            "Validate a diamond control flow with matching stack shapes.",
            "Change one branch to omit a push and reject the merge."
          ],
          "deliverables": [
            "Stack-shape validator and branch fixtures"
          ],
          "rollout": "Keep runtime stack checks even after static validation.",
          "skills": [
            "Data-flow analysis",
            "Stacks"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "5a6d05ea-d97f-4080-acf8-e772edc2d9c2",
          "key": "SRUNTIME-103",
          "title": "Reject jumps that land inside instruction operands",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SRUNTIME-101",
            "SRUNTIME-102"
          ],
          "scenario": "A crafted jump targets the second byte of a literal and reinterprets it as an opcode.",
          "acceptanceCriteria": [
            "Decoder records every legal instruction boundary",
            "Jump targets must reference a boundary in the same program",
            "Backward jumps remain permitted within the execution budget"
          ],
          "implementationNotes": [
            "Do not normalize invalid offsets to the nearest instruction."
          ],
          "verification": [
            "Execute forward and backward jumps to valid boundaries.",
            "Target each byte inside a multi-byte operand and reject validation."
          ],
          "deliverables": [
            "Boundary-indexed control-flow validation"
          ],
          "rollout": "Invalidate cached programs when the instruction format version changes.",
          "skills": [
            "Control flow",
            "Validation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a1bcff17-ab03-4369-b58f-034b0f88cdd2",
          "key": "SRUNTIME-104",
          "title": "Report integer overflow instead of changing arithmetic by build mode",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "SRUNTIME-101"
          ],
          "scenario": "Debug builds trap on addition overflow while optimized builds wrap, producing different rule outcomes.",
          "acceptanceCriteria": [
            "Arithmetic semantics are identical across build profiles",
            "Overflow returns a typed runtime fault with instruction offset",
            "Division defines zero and minimum-value edge cases"
          ],
          "implementationNotes": [
            "Use checked operations; do not expose floating-point values in this bytecode revision."
          ],
          "verification": [
            "Evaluate boundary-safe addition, subtraction, multiplication, and division.",
            "Exercise every overflow boundary and division by zero in both profiles."
          ],
          "deliverables": [
            "Arithmetic contract and profile-parity tests"
          ],
          "rollout": "Version any intentional arithmetic semantic change.",
          "skills": [
            "Integer arithmetic",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0507f331-7700-462c-a48c-7390b8ce2a95",
          "key": "SRUNTIME-105",
          "title": "Stop infinite programs with a deterministic instruction budget",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SRUNTIME-103",
            "SRUNTIME-104"
          ],
          "scenario": "A backward jump with an always-true condition consumes a worker indefinitely.",
          "acceptanceCriteria": [
            "Caller supplies a positive maximum instruction count",
            "Every executed instruction consumes budget",
            "Exhaustion returns current offset and no successful result"
          ],
          "implementationNotes": [
            "Wall-clock timeout can be defense in depth but is not the deterministic oracle."
          ],
          "verification": [
            "Run a terminating loop at exactly the declared budget.",
            "Run an infinite loop and verify failure at the same step in repeated executions."
          ],
          "deliverables": [
            "Instruction metering and loop-bound tests"
          ],
          "rollout": "Begin with a conservative budget and expose exhaustion separately from invalid bytecode.",
          "skills": [
            "Resource metering",
            "Determinism"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "b11d5fb5-74e6-402b-96df-7ea4b373ed91",
          "key": "SRUNTIME-106",
          "title": "Bound heap-like values without adding a garbage collector",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SRUNTIME-102",
            "SRUNTIME-105"
          ],
          "scenario": "A proposed LIST instruction allocates on every loop iteration and the prototype retains all intermediate values.",
          "acceptanceCriteria": [
            "Compare arena reset, reference counting, and no-list alternatives for the bounded language",
            "Chosen design defines maximum live bytes and value count",
            "Budget failure releases all runtime-owned allocations"
          ],
          "implementationNotes": [
            "Do not introduce tracing collection without a workload and cycle requirement that needs it."
          ],
          "verification": [
            "Evaluate a bounded list program and reconcile peak live bytes.",
            "Allocate until the value budget and confirm clean failure without leaks."
          ],
          "deliverables": [
            "Memory strategy decision and bounded-value prototype"
          ],
          "rollout": "Keep LIST disabled until the memory contract is accepted.",
          "skills": [
            "Runtime memory",
            "Tradeoff analysis",
            "Leak testing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "52c9e232-7a46-4068-a102-65e8ab8ffc84",
          "key": "SRUNTIME-107",
          "title": "Cache validated programs without confusing bytecode revisions",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SRUNTIME-103",
            "SRUNTIME-105"
          ],
          "scenario": "A cached validation result for version one is reused after an opcode gains a wider operand in version two.",
          "acceptanceCriteria": [
            "Cache identity binds exact bytes, bytecode version, validator version, and limits",
            "Validation failure is not cached across a newer validator",
            "Hash collision handling cannot return another program"
          ],
          "implementationNotes": [
            "Cache entries contain immutable validated metadata and bounded program bytes only."
          ],
          "verification": [
            "Reuse one validated program under identical authority.",
            "Change each identity dimension and require a miss; inject a key collision and compare bytes."
          ],
          "deliverables": [
            "Versioned validation cache and collision tests"
          ],
          "rollout": "Enable read-through caching after hit/miss telemetry reconciles with validation calls.",
          "skills": [
            "Cache correctness",
            "Versioning",
            "Hashing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Compiler and language tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "505583a3-2b61-4b78-a236-88d876b31589",
          "key": "SRUNTIME-108",
          "title": "Make runtime faults useful without leaking input values",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SRUNTIME-104",
            "SRUNTIME-105"
          ],
          "scenario": "Fault logs dump the full operand stack, which may later contain customer-derived values, while omitting the bytecode revision needed for diagnosis.",
          "acceptanceCriteria": [
            "Fault records contain code, instruction offset, runtime version, and bounded trace identity",
            "Operand values and full program bytes are excluded",
            "Repeated identical faults aggregate under bounded dimensions"
          ],
          "implementationNotes": [
            "Use synthetic values in the exercise and keep generic analytics content-free."
          ],
          "verification": [
            "Produce each fault class and reconcile its diagnostic fields.",
            "Push a sentinel value and confirm it appears in no log or metric."
          ],
          "deliverables": [
            "Redacted runtime fault schema and tests"
          ],
          "rollout": "Replace verbose stack dumps before adding any non-synthetic inputs.",
          "skills": [
            "Observability",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Privacy engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7f50584a-5d7c-4655-8029-7d694831deee",
          "key": "SRUNTIME-109",
          "title": "Load a new runtime revision without changing in-flight programs",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SRUNTIME-107",
            "SRUNTIME-108"
          ],
          "scenario": "Reloading the opcode table mutates a global registry while workers execute programs validated under the old table.",
          "acceptanceCriteria": [
            "Each execution binds one immutable runtime revision",
            "New programs select only fully initialized revisions",
            "Retirement waits for in-flight references without blocking unrelated execution"
          ],
          "implementationNotes": [
            "Avoid a mutable Singleton registry; publish immutable snapshots through explicit ownership."
          ],
          "verification": [
            "Run old and new program revisions concurrently and verify their semantics.",
            "Attempt a partial revision load and confirm no execution can select it."
          ],
          "deliverables": [
            "Revision registry, concurrent load test, and retirement protocol"
          ],
          "rollout": "Publish one synthetic revision behind an explicit selector and retain rollback to the prior snapshot.",
          "skills": [
            "Versioned runtime",
            "Concurrency",
            "Immutability"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": [
            {
              "pattern": "singleton",
              "activity": "REMOVE",
              "focus": "Replace the mutable process-wide opcode registry with immutable runtime revision snapshots bound explicitly to each execution."
            }
          ]
        },
        {
          "id": "47a65cd7-89ea-4bd4-993e-3dcbfa293738",
          "key": "SRUNTIME-110",
          "title": "Fuzz the runtime under fixed memory and step limits",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SRUNTIME-105",
            "SRUNTIME-106",
            "SRUNTIME-108"
          ],
          "scenario": "Random bytecode tests occasionally hang or consume the test host, so the suite is disabled in continuous integration.",
          "acceptanceCriteria": [
            "Harness caps input bytes, instructions, value memory, and wall-clock defense",
            "Every failure records a minimized reproducible seed",
            "Crash, panic, timeout, and semantic disagreement are distinct outcomes"
          ],
          "implementationNotes": [
            "Run only the capability-free local runtime; never execute generated host code."
          ],
          "verification": [
            "Replay the checked-in seed corpus with deterministic results.",
            "Seed malformed loops and oversized allocations and confirm bounded termination."
          ],
          "deliverables": [
            "Bounded fuzz harness and minimized regression corpus"
          ],
          "rollout": "Start with a short deterministic CI corpus and schedule longer local runs separately.",
          "skills": [
            "Fuzzing",
            "Resource limits",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "fcf41c09-df30-436e-b87a-6fd8bb78ab02"
    },
    {
      "key": "SFFI",
      "title": "Stabilize a native compression boundary before wider adoption",
      "field": "Systems programming",
      "summary": "Design a safe FFI contract with explicit ownership, error mapping and compatibility.",
      "context": "A fictional desktop backup tool calls a small Rust compression library from Node.js. The binding leaks buffers on exceptions and treats ABI mismatches as corrupted input. Build against generated byte arrays and a local native library; no production archive format or user files are supplied.",
      "stack": [
        "Rust",
        "C ABI",
        "Node-API",
        "Sanitizers"
      ],
      "prerequisites": [
        "FFI ownership",
        "Binary compatibility",
        "Error handling"
      ],
      "developerValue": "Practice language-boundary contracts, native resource safety and version negotiation.",
      "companyValue": "Review a binding that fails safely and can be rolled back before native code enters additional application paths.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "29836321-c28f-4edc-953d-d714bfc57ed7",
          "key": "SFFI-101",
          "title": "Write the buffer ownership table before exposing the binding",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "JavaScript and Rust both believe the other side frees an output buffer when conversion throws.",
          "acceptanceCriteria": [
            "Document owner for every input, output, error, and callback value",
            "Each transfer has one release operation and allowed thread",
            "Borrowed memory cannot outlive its originating call"
          ],
          "implementationNotes": [
            "Do not infer ownership from constness or language garbage collection."
          ],
          "verification": [
            "Trace success and error paths through the ownership table.",
            "Inject failure after native allocation and verify exactly one release."
          ],
          "deliverables": [
            "FFI ownership contract and allocation counter test"
          ],
          "rollout": "Keep the pure-language fallback until every path has an owner.",
          "skills": [
            "FFI",
            "Ownership",
            "Resource cleanup"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3a048c85-03f3-4afc-91d9-ee3132f6b96b",
          "key": "SFFI-102",
          "title": "Validate lengths before converting JavaScript buffers",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A signed length crosses the C boundary and becomes a very large unsigned value.",
          "acceptanceCriteria": [
            "Binding rejects lengths outside the actual buffer and native type range",
            "Zero-length input follows a documented contract",
            "Conversion failure calls no compression function"
          ],
          "implementationNotes": [
            "Perform validation on the boundary side that has both pointer and buffer length."
          ],
          "verification": [
            "Compress empty, small, and maximum-fixture buffers.",
            "Pass negative-equivalent, oversized, and detached buffers and verify rejection."
          ],
          "deliverables": [
            "Length checks and boundary corpus"
          ],
          "rollout": "Reject unsupported buffers before enabling the native path.",
          "skills": [
            "Integer conversion",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5b585a37-bb44-45bd-88a3-319c45e55124",
          "key": "SFFI-103",
          "title": "Map native errors without losing machine-readable causes",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SFFI-101",
            "SFFI-102"
          ],
          "scenario": "Every nonzero native status becomes 'compression failed', hiding whether the caller supplied bad input or the allocator exhausted its cap.",
          "acceptanceCriteria": [
            "Stable public codes distinguish input, capacity, version, cancellation, and internal faults",
            "Native diagnostic text is bounded and treated as untrusted",
            "Unknown statuses map to one safe internal category"
          ],
          "implementationNotes": [
            "Do not include raw input bytes or native addresses in errors."
          ],
          "verification": [
            "Trigger and map each declared native status.",
            "Return an unknown status with oversized text and verify bounded safe mapping."
          ],
          "deliverables": [
            "Versioned error map and contract tests"
          ],
          "rollout": "Callers must stop branching on old free-form messages before migration.",
          "skills": [
            "Error contracts",
            "Boundary validation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "API design",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4b7c64ca-603f-4dcc-a608-61d08e41aac1",
          "key": "SFFI-104",
          "title": "Release native output after JavaScript cancellation",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "SFFI-101",
            "SFFI-103"
          ],
          "scenario": "The caller abandons a promise while native work finishes later; its output buffer has no remaining JavaScript consumer and is leaked.",
          "acceptanceCriteria": [
            "Operation state records whether a result still has a consumer",
            "Late output is released on the native allocation thread or declared safe path",
            "Cancellation and completion races release once"
          ],
          "implementationNotes": [
            "Cancellation is cooperative; do not unload code while a native call is running."
          ],
          "verification": [
            "Cancel before start and after successful delivery.",
            "Race cancellation with native completion across repeated deterministic schedules."
          ],
          "deliverables": [
            "Cancellation cleanup protocol and race tests"
          ],
          "rollout": "Keep native concurrency at one until release counts reconcile.",
          "skills": [
            "Cancellation",
            "FFI cleanup",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "eec7179e-19df-4467-9b41-1fad48d4e812",
          "key": "SFFI-105",
          "title": "Move blocking compression off the JavaScript event loop",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SFFI-102",
            "SFFI-104"
          ],
          "scenario": "A 50 MB synthetic buffer blocks timers and health checks because the binding invokes native compression synchronously.",
          "acceptanceCriteria": [
            "Large work runs in a bounded worker pool",
            "Completion returns on the expected runtime thread",
            "Queue saturation rejects before copying the full input"
          ],
          "implementationNotes": [
            "Measure copy cost separately from compression time and cap fixture size."
          ],
          "verification": [
            "Compress concurrent small and large buffers while measuring timer delay.",
            "Saturate the pool and confirm bounded memory with a typed overload result."
          ],
          "deliverables": [
            "Asynchronous binding and event-loop latency report"
          ],
          "rollout": "Route buffers above a measured threshold first and retain synchronous fallback for small fixtures.",
          "skills": [
            "Async runtimes",
            "Performance",
            "Backpressure"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Performance engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "396819f7-5b29-4ebd-a397-fb9c5528458a",
          "key": "SFFI-106",
          "title": "Negotiate ABI capability before the first compression call",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SFFI-103"
          ],
          "scenario": "A newer binding calls an option function missing from the loaded native library and the process terminates during symbol resolution.",
          "acceptanceCriteria": [
            "Initialization reads ABI version and explicit capability bits",
            "Unsupported required capabilities fail before accepting work",
            "Optional capabilities have documented fallback behavior"
          ],
          "implementationNotes": [
            "Do not infer ABI compatibility from package version or filename alone."
          ],
          "verification": [
            "Load current and compatible older fixture libraries.",
            "Load a library missing a required symbol and fail closed before dispatch."
          ],
          "deliverables": [
            "ABI handshake and compatibility matrix"
          ],
          "rollout": "Probe in startup readiness while the pure-language provider remains selectable.",
          "skills": [
            "ABI versioning",
            "Feature negotiation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "87030659-88f7-4949-b29d-d66a46121f58",
          "key": "SFFI-107",
          "title": "Contain a native panic without pretending the process is safe",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SFFI-103",
            "SFFI-106"
          ],
          "scenario": "Malformed options trigger a Rust panic that crosses the C ABI and aborts the Node process.",
          "acceptanceCriteria": [
            "FFI entry points catch supported unwind cases before the ABI boundary",
            "Panic maps to an internal fault with operation identity",
            "Abort-configured builds are identified and isolated out of process"
          ],
          "implementationNotes": [
            "Do not claim catch_unwind protects memory after arbitrary native corruption."
          ],
          "verification": [
            "Trigger a controlled recoverable panic and map its result.",
            "Select an aborting fixture provider and require process-isolation policy instead of in-process execution."
          ],
          "deliverables": [
            "Panic-boundary policy and controlled failure fixtures"
          ],
          "rollout": "Keep risky codecs behind an external process provider until their failure mode is qualified.",
          "skills": [
            "Panic safety",
            "Isolation boundaries",
            "FFI"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "42d20473-5374-4d91-8310-aa483334b13f",
          "key": "SFFI-108",
          "title": "Compare native output against the compatibility oracle",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SFFI-105",
            "SFFI-106"
          ],
          "scenario": "The native path is faster but emits archives the existing decompressor accepts differently around empty blocks.",
          "acceptanceCriteria": [
            "Golden corpus defines byte compatibility or declared semantic compatibility",
            "Both providers round-trip every supported case",
            "Differences are classified before rollout"
          ],
          "implementationNotes": [
            "Use generated non-sensitive bytes and pin provider versions in the report."
          ],
          "verification": [
            "Compare providers across corpus sizes and option combinations.",
            "Inject a one-byte divergence and show the gate blocks promotion."
          ],
          "deliverables": [
            "Differential harness and compatibility report"
          ],
          "rollout": "Canary only corpus classes with reconciled outputs.",
          "skills": [
            "Differential testing",
            "Compatibility"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "13e8f702-7568-48d6-a393-595f2461f97b",
          "key": "SFFI-109",
          "title": "Unload a retired native revision only after callbacks drain",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SFFI-104",
            "SFFI-106"
          ],
          "scenario": "Hot replacement unloads the old library while an asynchronous completion callback still points into its code.",
          "acceptanceCriteria": [
            "Each operation pins one library revision through callback completion",
            "Retirement blocks new calls and observes active reference count",
            "Deadline reports unresolved references without forced unload"
          ],
          "implementationNotes": [
            "Prefer process restart for platforms that cannot guarantee safe dynamic unloading."
          ],
          "verification": [
            "Run old and new revisions concurrently, then retire the old after drain.",
            "Hold one completion callback and verify unload does not occur at the deadline."
          ],
          "deliverables": [
            "Revision lifetime protocol and delayed-callback test"
          ],
          "rollout": "Use process replacement as the default until in-process retirement is proven for the target platform.",
          "skills": [
            "Dynamic libraries",
            "Reference lifetimes",
            "Safe rollout"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "4337ba99-6c9a-4940-bc4f-6ed2ea1218a4",
          "key": "SFFI-110",
          "title": "Package the native binding with a reversible compatibility gate",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SFFI-107",
            "SFFI-108",
            "SFFI-109"
          ],
          "scenario": "A package publish selects the native binary by platform name but ignores CPU features and libc compatibility.",
          "acceptanceCriteria": [
            "Artifact metadata binds OS, architecture, ABI, runtime, and required CPU features",
            "Installer rejects an incompatible binary before load",
            "Pure-language fallback selection is explicit and observable"
          ],
          "implementationNotes": [
            "Do not download or execute binaries outside the generated local fixture set."
          ],
          "verification": [
            "Select each compatible fixture artifact and report its identity.",
            "Present wrong architecture, ABI, and feature metadata and verify safe fallback."
          ],
          "deliverables": [
            "Artifact selector, compatibility cases, and rollback note"
          ],
          "rollout": "Publish metadata and fallback behavior before enabling native-by-default selection.",
          "skills": [
            "Packaging",
            "Compatibility",
            "Release engineering"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "DevOps",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "00ad18d5-9ac5-4716-888c-62e97c908b90"
    },
    {
      "key": "SKERNEL",
      "title": "Build an operating-system boundary that fails predictably",
      "field": "Systems programming",
      "summary": "Wrap files, timers and readiness notifications with explicit partial-result and portability behavior.",
      "context": "A fictional local agent watches generated inbox files and schedules bounded processing. Direct system calls are scattered across the code, mishandle interrupted operations, and make tests platform-dependent. Build a Rust OS adapter with temporary fixture directories; no kernel module, elevated privilege, or production host modification is required.",
      "stack": [
        "Rust",
        "Filesystem APIs",
        "Polling adapter",
        "Temporary directories"
      ],
      "prerequisites": [
        "System calls",
        "File descriptors",
        "Monotonic clocks"
      ],
      "developerValue": "Practice OS error semantics, partial I/O, portability and deterministic abstraction boundaries.",
      "companyValue": "Review host-facing code whose retries, resource limits, and platform differences are explicit before packaging it as a local agent.",
      "delivery": "Ten linked tickets across three phases. Use synthetic inputs and a local harness; provide source, focused tests, measurements where requested, and a recovery note.",
      "phases": [
        {
          "id": "model",
          "title": "Establish the machine contract",
          "goal": "Make representation, ownership and failure boundaries explicit."
        },
        {
          "id": "control",
          "title": "Control resources and concurrency",
          "goal": "Implement bounded behavior under realistic interleavings."
        },
        {
          "id": "operate",
          "title": "Prove recovery and handoff",
          "goal": "Measure, diagnose and safely replace the component."
        }
      ],
      "tickets": [
        {
          "id": "151c3e66-8557-4dc3-a4d3-05856c347d91",
          "key": "SKERNEL-101",
          "title": "Read a file completely across short system calls",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "The adapter assumes one read fills the requested buffer and silently truncates a generated manifest after an injected short read.",
          "acceptanceCriteria": [
            "Loop until EOF, declared length, or typed error",
            "Return bytes already read only when the contract permits partial results",
            "Zero-progress reads cannot spin forever"
          ],
          "implementationNotes": [
            "Use a controllable local read adapter; never require privileged system-call interception."
          ],
          "verification": [
            "Read the same manifest through one-byte and irregular chunk schedules.",
            "Return zero progress before EOF and confirm bounded failure."
          ],
          "deliverables": [
            "Complete-read primitive and short-read tests"
          ],
          "rollout": "Route manifest reads through the helper before larger files.",
          "skills": [
            "System calls",
            "Partial I/O"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "421f63ac-b16f-4489-a9aa-005d9fb8c1f2",
          "key": "SKERNEL-102",
          "title": "Write a durable replacement without exposing a half file",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "model",
          "dependsOn": [],
          "scenario": "A crash between truncation and write leaves the agent configuration empty.",
          "acceptanceCriteria": [
            "Write to a unique file in the destination directory",
            "Flush file content before atomic replacement where the platform supports it",
            "Document directory durability and unsupported-platform behavior"
          ],
          "implementationNotes": [
            "Preserve permissions intentionally and reject symlink destination surprises."
          ],
          "verification": [
            "Replace an existing fixture and observe either old or complete new content.",
            "Interrupt before rename and confirm the destination remains unchanged."
          ],
          "deliverables": [
            "Atomic-replace adapter and interruption cases"
          ],
          "rollout": "Retain backups only under an explicit bounded retention policy.",
          "skills": [
            "Filesystem durability",
            "Atomic replacement"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0c01553a-b00d-40eb-a862-6026bd1828c6",
          "key": "SKERNEL-103",
          "title": "Retry interrupted calls without hiding cancellation",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "model",
          "dependsOn": [
            "SKERNEL-101"
          ],
          "scenario": "Every interrupted call is retried automatically, so a cancelled operation keeps waiting after shutdown begins.",
          "acceptanceCriteria": [
            "Retry only declared interrupt errors",
            "Check cancellation and deadline between attempts",
            "Preserve noninterrupt error identity"
          ],
          "implementationNotes": [
            "Retry policy belongs beside the operation contract, not in a catch-all error loop."
          ],
          "verification": [
            "Inject two interrupts followed by success before deadline.",
            "Cancel between interrupts and verify no further system call is attempted."
          ],
          "deliverables": [
            "Interrupt-aware retry helper and cancellation tests"
          ],
          "rollout": "Adopt per operation after its retry safety is reviewed.",
          "skills": [
            "Error handling",
            "Cancellation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "98330fc6-80e8-44e1-8ae6-d9014865a065",
          "key": "SKERNEL-104",
          "title": "Keep wall-clock changes out of elapsed-time deadlines",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [],
          "scenario": "An NTP correction moves wall time backwards and extends a file-processing deadline by several minutes.",
          "acceptanceCriteria": [
            "Elapsed deadlines use an injected monotonic clock",
            "User-facing timestamps remain UTC wall time",
            "Conversion between the two clock domains is prohibited"
          ],
          "implementationNotes": [
            "Tests advance fake clocks; they do not alter the host clock."
          ],
          "verification": [
            "Expire a deadline through monotonic advancement.",
            "Move wall time forward and backward and prove elapsed behavior is unchanged."
          ],
          "deliverables": [
            "Clock boundary and time-jump tests"
          ],
          "rollout": "Migrate deadline call sites before changing displayed timestamps.",
          "skills": [
            "Clocks",
            "Time modeling"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Real-time systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "78ac8352-98b8-4f0c-b718-823fae29f5fc",
          "key": "SKERNEL-105",
          "title": "Normalize watcher bursts into a bounded rescan request",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SKERNEL-102",
            "SKERNEL-104"
          ],
          "scenario": "One editor save produces create, rename, and modify events; the agent processes the same file three times and misses changes after queue overflow.",
          "acceptanceCriteria": [
            "Events trigger idempotent directory reconciliation rather than direct truth",
            "Burst coalescing has a maximum delay",
            "Overflow schedules a full bounded rescan and remains visible"
          ],
          "implementationNotes": [
            "Do not promise identical watcher events across operating systems."
          ],
          "verification": [
            "Replay create-via-rename and direct-write event sequences with one final reconciliation.",
            "Overflow the event buffer and confirm a rescan restores the fixture state."
          ],
          "deliverables": [
            "Watcher reconciliation loop and platform event fixtures"
          ],
          "rollout": "Keep periodic scans as a fallback during watcher rollout.",
          "skills": [
            "Filesystem watchers",
            "Reconciliation",
            "Portability"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 60
            },
            {
              "field": "Platform engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "caccf725-e955-4cff-a109-f66448a660f8",
          "key": "SKERNEL-106",
          "title": "Bound open descriptors while scanning a deep inbox",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "SKERNEL-101",
            "SKERNEL-105"
          ],
          "scenario": "Recursive scanning opens every subdirectory before closing any, exhausting the process descriptor limit.",
          "acceptanceCriteria": [
            "Traversal has an explicit descriptor and work-queue bound",
            "Directory handles close on success, skip, and error",
            "Unreadable entries are reported without aborting unrelated roots"
          ],
          "implementationNotes": [
            "Use a generated tree and configured low limit; do not change host-wide limits."
          ],
          "verification": [
            "Scan a deep and wide tree while measuring peak open handles.",
            "Inject an unreadable directory and repeated short reads, then check cleanup."
          ],
          "deliverables": [
            "Bounded scanner and descriptor accounting test"
          ],
          "rollout": "Start with one configured root and expose incomplete scans.",
          "skills": [
            "Resource bounds",
            "Directory traversal",
            "Cleanup"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5fce6797-7c0f-451b-84b8-ee5e2ff1ab9d",
          "key": "SKERNEL-107",
          "title": "Prevent path traversal through a watched-root handle",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "SKERNEL-102",
            "SKERNEL-106"
          ],
          "scenario": "A path is validated under the inbox, then a directory is replaced with a symlink before open, escaping the allowed root.",
          "acceptanceCriteria": [
            "Operations resolve relative to an already opened trusted root",
            "Traversal rejects symlinks or verifies each component under declared policy",
            "Validation and use cannot be separated by an attacker-controlled rename"
          ],
          "implementationNotes": [
            "Use temporary synthetic directories and no elevated privileges."
          ],
          "verification": [
            "Open and replace normal nested fixture files through the root handle.",
            "Race a directory-to-symlink swap and confirm no outside file is read or changed."
          ],
          "deliverables": [
            "Root-relative filesystem adapter and race regression"
          ],
          "rollout": "Fail closed on platforms where the required safe primitive is unavailable.",
          "skills": [
            "Filesystem security",
            "TOCTOU",
            "Path handling"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 65
            },
            {
              "field": "Security",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "e34489e6-9281-463d-a64d-613056a4f8cd",
          "key": "SKERNEL-108",
          "title": "Expose platform capability instead of silently changing semantics",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "operate",
          "dependsOn": [
            "SKERNEL-102",
            "SKERNEL-105"
          ],
          "scenario": "The Windows fixture cannot provide the same directory-flush guarantee as the Unix adapter, but both report durable replacement.",
          "acceptanceCriteria": [
            "Adapter reports exact supported capabilities",
            "Callers can require a capability and fail before mutation",
            "Fallback semantics have distinct result codes and documentation"
          ],
          "implementationNotes": [
            "Do not erase platform differences behind a boolean success value."
          ],
          "verification": [
            "Run the shared contract against two declared capability fixtures.",
            "Require directory durability from an unsupported fixture and confirm no replacement starts."
          ],
          "deliverables": [
            "OS capability model and cross-adapter contract suite"
          ],
          "rollout": "Gate each deployment profile on its required capability set.",
          "skills": [
            "Portability",
            "Capability modeling",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "09c90ea3-c784-4dac-b27d-082534c5dbe3",
          "key": "SKERNEL-109",
          "title": "Recover an orphaned temporary replacement after restart",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "operate",
          "dependsOn": [
            "SKERNEL-102",
            "SKERNEL-107",
            "SKERNEL-108"
          ],
          "scenario": "A crash leaves temporary files beside the destination; startup cannot tell whether they are incomplete writes or a replacement ready to finish.",
          "acceptanceCriteria": [
            "Temporary name binds operation identity and expected content hash",
            "Recovery verifies destination and temporary content before action",
            "Ambiguous or foreign files remain untouched and visible"
          ],
          "implementationNotes": [
            "Cleanup is scoped to the opened trusted root and never follows links."
          ],
          "verification": [
            "Recover before-rename and after-rename crash fixtures idempotently.",
            "Place a foreign matching-looking file and confirm the agent records but does not delete it."
          ],
          "deliverables": [
            "Replacement journal and startup reconciliation drill"
          ],
          "rollout": "Run recovery in report-only mode before enabling scoped cleanup.",
          "skills": [
            "Crash consistency",
            "Reconciliation",
            "Filesystem safety"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2ecab357-7137-4aa9-a3ae-991a3b30a03e",
          "key": "SKERNEL-110",
          "title": "Package the OS adapter without requesting unnecessary privilege",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "operate",
          "dependsOn": [
            "SKERNEL-107",
            "SKERNEL-108",
            "SKERNEL-109"
          ],
          "scenario": "An installer manifest requests administrator access even though the agent operates only inside a user-selected directory.",
          "acceptanceCriteria": [
            "Document required paths, handles, notifications, and permissions",
            "Default installation runs as an unprivileged user",
            "Unavailable optional watcher capability falls back visibly to polling"
          ],
          "implementationNotes": [
            "Do not install services, modify the registry, or request real privilege in the exercise."
          ],
          "verification": [
            "Run the packaged local fixture under a restricted temporary account profile.",
            "Remove watcher capability and verify bounded polling without elevated fallback."
          ],
          "deliverables": [
            "Privilege inventory, packaging manifest, and fallback test"
          ],
          "rollout": "Keep installation local and reversible until platform review is complete.",
          "skills": [
            "Least privilege",
            "Packaging",
            "Operational documentation"
          ],
          "fieldMix": [
            {
              "field": "Systems programming",
              "percentage": 70
            },
            {
              "field": "DevOps",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "4b77692b-e1a3-4649-874d-e84670d9a8ce"
    },
    {
      "key": "DCI",
      "title": "Make pull-request CI trustworthy under load",
      "field": "DevOps",
      "summary": "Repair cache identity, cancellation, flaky checks, and feedback latency in a multi-package pipeline.",
      "context": "A fictional TypeScript monorepo has twelve packages and a local CI simulator. Pull requests wait for redundant work, stale caches occasionally pass broken changes, and superseded runs continue consuming executors. Create synthetic package graphs and fake check APIs; no hosted CI credentials or production repositories are supplied.",
      "stack": [
        "TypeScript",
        "pnpm",
        "Git",
        "CI simulator"
      ],
      "prerequisites": [
        "Dependency graphs",
        "Process exit codes",
        "Test isolation"
      ],
      "developerValue": "Practice treating CI as a versioned delivery system with correctness, latency, and recovery constraints.",
      "companyValue": "Review a pipeline that reduces wasted compute without allowing stale or skipped checks to approve changes.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "188f2761-111f-4302-9665-2e7202fae287",
          "key": "DCI-101",
          "title": "Pin the required-check contract before optimizing the pipeline",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Branch protection expects names that differ from the workflow after a recent rename, leaving one required check permanently pending.",
          "acceptanceCriteria": [
            "Declare stable check identities and their owning commands",
            "Map every protected check to exactly one terminal report",
            "Unknown or duplicated check names fail workflow validation"
          ],
          "implementationNotes": [
            "The local simulator must not call a real repository or modify branch protection."
          ],
          "verification": [
            "Complete every declared check and reconcile its final status.",
            "Rename and duplicate a check, then confirm validation blocks the workflow."
          ],
          "deliverables": [
            "Required-check manifest and consistency test"
          ],
          "rollout": "Publish the manifest before changing job topology.",
          "skills": [
            "CI contracts",
            "Configuration validation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "4e632cae-be6f-45aa-8985-685b2b272332",
          "key": "DCI-102",
          "title": "Fail the pipeline when a command exits through a hidden pipe",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Test output is piped through a formatter; the formatter succeeds after the test process fails, so the job reports green.",
          "acceptanceCriteria": [
            "Job status reflects every command in the pipeline",
            "Original stdout and stderr remain available",
            "Signal termination and ordinary nonzero exit are distinguished"
          ],
          "implementationNotes": [
            "Do not parse human-readable output to determine success."
          ],
          "verification": [
            "Run successful tests through the formatter and retain readable logs.",
            "Fail the upstream process and verify the job reports its exact failure."
          ],
          "deliverables": [
            "Exit-status wrapper and pipeline regression"
          ],
          "rollout": "Apply first to test jobs, then audit every piped command.",
          "skills": [
            "Shell behavior",
            "Process status"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "297f79c8-d71d-4857-8ae4-2d1ce68a638e",
          "key": "DCI-103",
          "title": "Compute affected packages from both dependency directions",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DCI-101"
          ],
          "scenario": "Changing a shared type package runs its own tests but skips three consumers that compile against the changed contract.",
          "acceptanceCriteria": [
            "Changed packages and transitive consumers enter the affected set",
            "Deleted and renamed files map to their owning package",
            "Global configuration changes select the declared full set"
          ],
          "implementationNotes": [
            "Use the synthetic graph and explicit ownership rules; filename substring guesses are insufficient."
          ],
          "verification": [
            "Change a leaf, shared library, and root configuration and compare selected packages.",
            "Create a dependency cycle fixture and fail analysis without silently dropping nodes."
          ],
          "deliverables": [
            "Affected-graph selector and graph fixtures"
          ],
          "rollout": "Run selection in report-only mode beside the current full pipeline.",
          "skills": [
            "Dependency graphs",
            "Change analysis"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0f5ef932-2051-4f2b-a4e9-9e04cf4ba76b",
          "key": "DCI-104",
          "title": "Key build caches from every semantic input",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DCI-103"
          ],
          "scenario": "A cache hit reuses generated clients after the schema changed because only source-directory files contribute to the key.",
          "acceptanceCriteria": [
            "Cache identity includes command, toolchain, environment contract, direct inputs, and dependency outputs",
            "Secrets and absolute workspace paths are excluded",
            "Restore verifies metadata before using outputs"
          ],
          "implementationNotes": [
            "A cache hit may improve speed but cannot waive required checks."
          ],
          "verification": [
            "Repeat an identical build and verify a safe hit.",
            "Change schema, compiler version, and an upstream output independently and require misses."
          ],
          "deliverables": [
            "Canonical cache manifest and invalidation tests"
          ],
          "rollout": "Enable read-only restore before allowing new cache writes.",
          "skills": [
            "Build caching",
            "Hashing",
            "Reproducibility"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "bb098876-2ae1-4714-907d-0ad95b9ca0e8",
          "key": "DCI-105",
          "title": "Cancel superseded pull-request runs without erasing evidence",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DCI-101",
            "DCI-102"
          ],
          "scenario": "A force-push starts a new run while the old run still publishes late check results under the branch name.",
          "acceptanceCriteria": [
            "Concurrency identity binds repository, pull request, and immutable revision",
            "New revision requests cancellation of older active runs",
            "Late results remain tied to their original revision and cannot satisfy the new one"
          ],
          "implementationNotes": [
            "Cancellation is cooperative and must not mark unfinished checks successful."
          ],
          "verification": [
            "Start two revisions and verify only the new one remains eligible.",
            "Deliver a late success from the old run and prove it cannot update the new revision."
          ],
          "deliverables": [
            "Revision-scoped concurrency controller and race test"
          ],
          "rollout": "Canary on the local simulator while recording saved executor time.",
          "skills": [
            "Concurrency control",
            "Immutable revisions"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ff85dddf-ed40-42da-8d24-5270d223c7da",
          "key": "DCI-106",
          "title": "Quarantine a flaky test without making it optional forever",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DCI-101"
          ],
          "scenario": "A timing-sensitive test is retried until it passes, hiding a rising failure rate and extending every pull request.",
          "acceptanceCriteria": [
            "First-attempt and retry outcomes remain separate",
            "Quarantine has owner, reason, expiry, and tracking reference",
            "Expired quarantine fails the policy check"
          ],
          "implementationNotes": [
            "Do not classify a test as flaky from one failure; use the supplied deterministic failure history."
          ],
          "verification": [
            "Quarantine the documented test and keep its outcomes visible.",
            "Expire or omit ownership and confirm the pipeline blocks rather than silently skips."
          ],
          "deliverables": [
            "Quarantine registry, policy check, and trend fixture"
          ],
          "rollout": "Limit quarantine to named tests and review before expiry.",
          "skills": [
            "Flake management",
            "Policy as code",
            "Test analytics"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Quality engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "1c7ec037-fade-4156-94de-4e005839fa9b",
          "key": "DCI-107",
          "title": "Prevent untrusted pull requests from receiving release secrets",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DCI-101",
            "DCI-103"
          ],
          "scenario": "The same reusable workflow handles internal branches and external pull requests, and a broad token is present before trust is evaluated.",
          "acceptanceCriteria": [
            "Trust context is resolved before selecting credentials or privileged jobs",
            "Untrusted revisions receive read-only checkout and no protected environment",
            "Privileged continuation binds the reviewed immutable revision"
          ],
          "implementationNotes": [
            "Use fake secret handles and repository events; never place a credential value in fixtures or logs."
          ],
          "verification": [
            "Run trusted and untrusted event fixtures and compare granted capabilities.",
            "Change the revision after approval and confirm privileged jobs refuse to start."
          ],
          "deliverables": [
            "CI trust-boundary policy and event matrix"
          ],
          "rollout": "Fail closed for ambiguous event provenance.",
          "skills": [
            "CI security",
            "Least privilege",
            "Supply chain"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3d29f13f-2f66-4bac-8cf2-9e62e0073c36",
          "key": "DCI-108",
          "title": "Measure queue and execution delay separately",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DCI-103",
            "DCI-104",
            "DCI-105"
          ],
          "scenario": "The team calls CI slow from total duration, but most delay occurs before an executor starts during the morning burst.",
          "acceptanceCriteria": [
            "Record created, queued, started, and completed timestamps",
            "Report queue, setup, execution, and artifact phases separately",
            "Percentiles retain workload and executor-class dimensions only"
          ],
          "implementationNotes": [
            "Use bounded synthetic dimensions and state the observation window."
          ],
          "verification": [
            "Reconcile phase durations for a mixed local workload.",
            "Omit a timestamp and confirm the run is marked incomplete rather than assigned zero delay."
          ],
          "deliverables": [
            "CI latency model and workload report"
          ],
          "rollout": "Use the baseline before changing runner count or job structure.",
          "skills": [
            "Observability",
            "Latency analysis"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Performance engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "78f78167-a5b2-4761-97d8-b9e4b72bf857",
          "key": "DCI-109",
          "title": "Resume reporting after the checks API loses a response",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DCI-105",
            "DCI-108"
          ],
          "scenario": "The fake checks API accepts a final status and drops the response; the reporter retries by creating a second check with conflicting output.",
          "acceptanceCriteria": [
            "One deterministic external-check identity exists per run and check",
            "Retry reconciles remote state before creating anything",
            "Conflicting terminal state becomes visible and stops automation"
          ],
          "implementationNotes": [
            "Provider calls occur outside database transactions and use the local controllable adapter."
          ],
          "verification": [
            "Publish each terminal status once and replay reporting safely.",
            "Drop the response after acceptance and verify reconciliation finds the existing result."
          ],
          "deliverables": [
            "Idempotent check reporter and lost-response drill"
          ],
          "rollout": "Enable for one check family while retaining the prior reporter for rollback.",
          "skills": [
            "Idempotency",
            "API reconciliation",
            "Distributed failure"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "0de0c979-9785-4ffb-8199-7d200463f5d8",
          "key": "DCI-110",
          "title": "Hand off CI ownership with a safe degraded mode",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DCI-106",
            "DCI-107",
            "DCI-108",
            "DCI-109"
          ],
          "scenario": "When the cache or check provider is unavailable, maintainers do not know which failures can fall back and which must block merging.",
          "acceptanceCriteria": [
            "Runbook names owners, dependencies, alerts, and escalation conditions",
            "Cache outage falls back to uncached required checks",
            "Check-reporting uncertainty blocks eligibility while preserving local results"
          ],
          "implementationNotes": [
            "Do not claim merge protection changes; the exercise documents the intended integration contract."
          ],
          "verification": [
            "Rehearse cache loss and complete an uncached run.",
            "Lose final check acknowledgement and follow the block-and-reconcile path."
          ],
          "deliverables": [
            "CI runbook and two recovery rehearsals"
          ],
          "rollout": "Review the runbook with a second engineer before adopting the workflow.",
          "skills": [
            "Runbooks",
            "Degraded operation",
            "Ownership handoff"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "e29698dd-99c6-4977-a933-bae9330a03d6"
    },
    {
      "key": "DREL",
      "title": "Promote one immutable release through every environment",
      "field": "DevOps",
      "summary": "Replace rebuild-per-environment delivery with verified artifact promotion and reversible rollout.",
      "context": "A fictional scheduling API is rebuilt separately for test, staging, and production-like local environments. The resulting images differ, release notes list the branch instead of the artifact, and rollback rebuilds old source with new dependencies. Use a local registry simulator and synthetic deployments; no cluster or customer traffic is supplied.",
      "stack": [
        "TypeScript",
        "OCI metadata",
        "Git",
        "Deployment simulator"
      ],
      "prerequisites": [
        "Artifact digests",
        "Release states",
        "Health checks"
      ],
      "developerValue": "Practice immutable promotion, release authority, compatibility gates, canaries, and rollback.",
      "companyValue": "Review a delivery flow that can identify exactly what is running and restore a known artifact without rebuilding it.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "6d153361-5f16-43bd-b0d7-8798363d84eb",
          "key": "DREL-101",
          "title": "Bind release identity to an artifact digest",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "The deployment record stores image:latest and commit branch, so two releases display the same identity after the tag moves.",
          "acceptanceCriteria": [
            "Release stores immutable artifact digest, source revision, and build manifest hash",
            "Mutable tags resolve to a digest before approval",
            "Display distinguishes requested tag from deployed digest"
          ],
          "implementationNotes": [
            "Use the local registry simulator and never pull public images."
          ],
          "verification": [
            "Resolve and deploy one fixture tag while retaining its digest.",
            "Move the tag and confirm the approved release identity does not change."
          ],
          "deliverables": [
            "Immutable release record and moved-tag test"
          ],
          "rollout": "Require digest resolution before any environment accepts a new release.",
          "skills": [
            "Artifact identity",
            "Release metadata"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7d8aafd3-11b6-4368-bb95-4372cfc5b61b",
          "key": "DREL-102",
          "title": "Generate release notes from the promoted revision range",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "DREL-101"
          ],
          "scenario": "Notes include commits merged after the artifact was built because they query the current branch head.",
          "acceptanceCriteria": [
            "Notes bind previous and current immutable source revisions",
            "Each change links to its synthetic pull-request identity",
            "Empty, missing, and nonancestor ranges have explicit outcomes"
          ],
          "implementationNotes": [
            "Do not use current branch state after release creation."
          ],
          "verification": [
            "Generate notes for a declared three-change revision range.",
            "Advance the branch and confirm the existing notes remain unchanged."
          ],
          "deliverables": [
            "Revision-bound notes generator and history fixtures"
          ],
          "rollout": "Publish notes as draft until artifact and range reconciliation pass.",
          "skills": [
            "Git history",
            "Release communication"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "eb3f4d08-f1c5-4c5b-8a56-4c7d7fbd8e5b",
          "key": "DREL-103",
          "title": "Promote the built artifact instead of rebuilding it",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DREL-101"
          ],
          "scenario": "Staging and production-like environments run images compiled at different times from the same source label.",
          "acceptanceCriteria": [
            "Build creates one content-addressed artifact",
            "Promotion changes environment references without changing bytes",
            "Environment record retains promotion actor, time, and source environment"
          ],
          "implementationNotes": [
            "Configuration remains external and versioned; it is not baked differently into each image."
          ],
          "verification": [
            "Promote one digest through two fixture environments and compare bytes.",
            "Attempt promotion with a mismatching manifest and block the transition."
          ],
          "deliverables": [
            "Promotion command and byte-identity tests"
          ],
          "rollout": "Adopt from test to staging before changing the final environment.",
          "skills": [
            "Artifact promotion",
            "Immutability"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a353edb1-9ede-4d47-b034-85a0d7751dc1",
          "key": "DREL-104",
          "title": "Gate promotion on database compatibility",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DREL-103"
          ],
          "scenario": "A release expects a renamed column while rollback still expects the old one, making the nominal rollback artifact unusable.",
          "acceptanceCriteria": [
            "Manifest declares required and provided schema compatibility window",
            "Promotion checks current environment schema before deployment",
            "Rollback target is validated against post-migration schema"
          ],
          "implementationNotes": [
            "Use fixture schema versions; do not execute migrations against a real database."
          ],
          "verification": [
            "Promote an expand-compatible release and validate its rollback target.",
            "Attempt a contract-first release and show the gate identifies the incompatible direction."
          ],
          "deliverables": [
            "Schema compatibility gate and rollout matrix"
          ],
          "rollout": "Require expand, migrate, contract phases for destructive changes.",
          "skills": [
            "Database migrations",
            "Compatibility",
            "Rollback planning"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "23cfe1d5-b2bc-49c8-a618-9ef36e17940c",
          "key": "DREL-105",
          "title": "Canary one cohort with a measurable abort rule",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DREL-103",
            "DREL-104"
          ],
          "scenario": "A canary is called healthy because no one watched it for long, despite a synthetic error spike in one endpoint.",
          "acceptanceCriteria": [
            "Canary binds cohort, duration, traffic minimum, and comparison baseline",
            "Abort evaluates declared error and latency thresholds",
            "Insufficient observations remain inconclusive"
          ],
          "implementationNotes": [
            "Use deterministic synthetic traffic; thresholds apply only to this exercise."
          ],
          "verification": [
            "Run a healthy canary through the full observation window.",
            "Inject an endpoint-specific regression and confirm automatic halt before wider rollout."
          ],
          "deliverables": [
            "Canary policy, evaluator, and regression fixtures"
          ],
          "rollout": "Expand only after a conclusive passing result.",
          "skills": [
            "Progressive delivery",
            "Release analysis"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f95388c5-7823-4bd0-9c23-9b3d54c0e678",
          "key": "DREL-106",
          "title": "Pause a release when deployment state drifts",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DREL-103"
          ],
          "scenario": "A manual fixture change replaces one replica image, but the release controller continues and records the target digest as complete.",
          "acceptanceCriteria": [
            "Reconciliation compares desired and observed digest per instance",
            "Unexpected drift pauses rollout and identifies affected instances",
            "Repair requires an explicit decision to restore desired state or adopt a new release"
          ],
          "implementationNotes": [
            "Do not overwrite drift before recording it."
          ],
          "verification": [
            "Complete a rollout whose observations match the release.",
            "Change one instance out of band and confirm the controller pauses without erasing evidence."
          ],
          "deliverables": [
            "Drift detector and paused-release flow"
          ],
          "rollout": "Begin with report-only drift detection in the simulator.",
          "skills": [
            "Reconciliation",
            "Configuration drift"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "af9474f3-ffe4-4f1d-a560-d1143b6f58a8",
          "key": "DREL-107",
          "title": "Authorize release approval for the exact artifact",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DREL-101",
            "DREL-105"
          ],
          "scenario": "An approval made for one digest remains valid after the release record is edited to point at another artifact.",
          "acceptanceCriteria": [
            "Approval binds artifact digest, environment, policy version, and expiry",
            "Any bound-field change invalidates approval",
            "Requester cannot satisfy a required independent approval role"
          ],
          "implementationNotes": [
            "Use synthetic identities and permissions; this is workflow authorization, not proof of code authorship."
          ],
          "verification": [
            "Approve and promote the exact eligible release.",
            "Change digest and replay the approval token, then verify denial and audit."
          ],
          "deliverables": [
            "Release approval boundary and replay tests"
          ],
          "rollout": "Require explicit approval for the final simulated environment first.",
          "skills": [
            "Authorization",
            "Release governance",
            "Audit"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f4b2bfa9-4da7-4896-86e6-9c8f99554548",
          "key": "DREL-108",
          "title": "Rollback to a known artifact without rebuilding source",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DREL-104",
            "DREL-105",
            "DREL-106"
          ],
          "scenario": "The rollback command checks out an old tag and rebuilds it with current dependencies, producing bytes never previously tested.",
          "acceptanceCriteria": [
            "Rollback selects a previously promoted immutable digest",
            "Compatibility gate evaluates current schema and configuration",
            "Release history records the failed and restored identities"
          ],
          "implementationNotes": [
            "Rollback does not delete the failed artifact or rewrite its record."
          ],
          "verification": [
            "Roll forward, trigger the abort rule, and restore the exact prior digest.",
            "Remove the prior artifact from the registry fixture and block rollback with a recovery instruction."
          ],
          "deliverables": [
            "Digest-based rollback command and rehearsal"
          ],
          "rollout": "Maintain at least one verified compatible rollback target per environment.",
          "skills": [
            "Rollback",
            "Artifact retention",
            "Incident response"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "c1ba6b1b-9de4-4ae3-a869-01afe8558711",
          "key": "DREL-109",
          "title": "Resume promotion after the registry response disappears",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DREL-103",
            "DREL-108"
          ],
          "scenario": "The registry accepts a promotion tag and drops the response; retry sees the tag but cannot tell whether it was created by this operation.",
          "acceptanceCriteria": [
            "Promotion uses deterministic operation identity",
            "Retry reads digest and operation metadata before mutation",
            "Conflicting existing tag becomes visible and blocks automatic continuation"
          ],
          "implementationNotes": [
            "The registry adapter is local and provider responses are treated as untrusted input."
          ],
          "verification": [
            "Promote and replay one operation with the same result.",
            "Drop the acceptance response and separately precreate a conflicting tag."
          ],
          "deliverables": [
            "Idempotent promotion adapter and ambiguity tests"
          ],
          "rollout": "Enable one registry namespace while retaining digest-only deployment.",
          "skills": [
            "Idempotency",
            "Registry APIs",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Integrations",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8f4e8668-22ec-4080-af14-1aea48e1da60",
          "key": "DREL-110",
          "title": "Publish a release ledger that answers what is running",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DREL-102",
            "DREL-106",
            "DREL-108",
            "DREL-109"
          ],
          "scenario": "During a rehearsal, responders compare commit hashes from logs because there is no single view of release, artifact, configuration, and schema identity.",
          "acceptanceCriteria": [
            "Ledger shows desired and observed artifact per environment",
            "Entries include configuration and schema compatibility identities",
            "Failed, paused, rolled-back, and superseded releases remain inspectable"
          ],
          "implementationNotes": [
            "The ledger is append-oriented planning and operational data; it is not candidate evidence."
          ],
          "verification": [
            "Trace a promotion, pause, and rollback from ledger entries.",
            "Remove an observation and confirm the view displays uncertainty rather than inferred state."
          ],
          "deliverables": [
            "Release ledger projection and responder guide"
          ],
          "rollout": "Use the ledger during a full local rollback rehearsal before handoff.",
          "skills": [
            "Release observability",
            "Audit trails",
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "92ac7bad-92e7-478c-b25e-6cd40d07548c"
    },
    {
      "key": "DENV",
      "title": "Keep environment configuration explicit and recoverable",
      "field": "DevOps",
      "summary": "Validate configuration, secret references, feature changes, and drift without copying sensitive values.",
      "context": "A fictional notification service uses environment files assembled by shell scripts. Defaults differ by machine, secret values appear in diagnostics, and emergency flags have no expiry. Build a typed local configuration compiler with fake secret references and synthetic environments; no real credentials or notification providers are supplied.",
      "stack": [
        "TypeScript",
        "JSON Schema",
        "Secret adapter",
        "Vitest"
      ],
      "prerequisites": [
        "Configuration precedence",
        "Schema validation",
        "Least privilege"
      ],
      "developerValue": "Practice configuration as a reviewed contract with safe diagnostics, provenance, and rollback.",
      "companyValue": "Review environment changes before deployment and reduce outages caused by missing, stale, or silently defaulted settings.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "50ae3a4a-f042-4401-b70e-448207316740",
          "key": "DENV-101",
          "title": "Define precedence without depending on process order",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Local, environment, and command-line values are merged in object iteration order, so the same inputs produce different ports in two scripts.",
          "acceptanceCriteria": [
            "Declare precedence for base, environment, and explicit override layers",
            "Each resolved value retains its source layer",
            "Duplicate keys within one layer fail parsing"
          ],
          "implementationNotes": [
            "Do not read the host process environment directly in domain tests."
          ],
          "verification": [
            "Resolve the same layers in shuffled input order and compare output.",
            "Provide duplicate keys and confirm no partial configuration is returned."
          ],
          "deliverables": [
            "Layered configuration resolver and precedence tests"
          ],
          "rollout": "Generate a report beside the current scripts before switching consumers.",
          "skills": [
            "Configuration modeling",
            "Determinism"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "fd85c697-6042-43c2-9517-e680ad0218fe",
          "key": "DENV-102",
          "title": "Reject missing required values before service startup",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "DENV-101"
          ],
          "scenario": "The service starts with an empty callback base URL and fails only when the first delivery completes.",
          "acceptanceCriteria": [
            "Schema distinguishes required, optional, and defaulted values",
            "Validation reports all safe field errors together",
            "Invalid configuration prevents provider initialization"
          ],
          "implementationNotes": [
            "Defaults must be explicit in the versioned schema and safe for every environment that uses them."
          ],
          "verification": [
            "Validate complete development and production-like fixture configurations.",
            "Remove several required fields and confirm providers are never constructed."
          ],
          "deliverables": [
            "Typed configuration schema and startup tests"
          ],
          "rollout": "Run validation as a pre-deployment gate before enforcing it at startup.",
          "skills": [
            "Schema validation",
            "Fail-closed startup"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Quality engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "cc79eaf8-c3d3-4af7-8a0e-09941862f440",
          "key": "DENV-103",
          "title": "Keep secret values out of configuration diffs",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DENV-102"
          ],
          "scenario": "A deployment preview serializes the fully resolved configuration, including a fake API token value, into the job log.",
          "acceptanceCriteria": [
            "Configuration stores secret references separately from ordinary values",
            "Diffs show reference identity and version without secret content",
            "Errors and snapshots redact values even when resolution fails"
          ],
          "implementationNotes": [
            "Use sentinel fake secrets and assert they never appear in output."
          ],
          "verification": [
            "Diff two configurations with changed secret references.",
            "Make resolution fail with a sentinel value in the provider error and verify redaction."
          ],
          "deliverables": [
            "Secret-reference model and log-leak tests"
          ],
          "rollout": "Remove full resolved-config logging before connecting any nonfixture provider.",
          "skills": [
            "Secret handling",
            "Redaction",
            "Data minimization"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "a22eb550-482f-4483-ba88-095fb3c617dd",
          "key": "DENV-104",
          "title": "Validate cross-field configuration invariants",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DENV-102"
          ],
          "scenario": "Retries are enabled while the idempotency store is disabled, creating duplicate notification attempts after timeouts.",
          "acceptanceCriteria": [
            "Cross-field rules run after individual field validation",
            "Retry requires a compatible idempotency mode and positive deadline",
            "Errors identify involved settings without exposing values"
          ],
          "implementationNotes": [
            "Keep invariants centralized and versioned rather than scattered among service constructors."
          ],
          "verification": [
            "Validate supported retry and store combinations.",
            "Enable retry with no store and with a shorter operation deadline than backoff."
          ],
          "deliverables": [
            "Configuration invariant set and combination matrix"
          ],
          "rollout": "Evaluate current environment fixtures and resolve all violations before enforcement.",
          "skills": [
            "Invariant design",
            "Configuration testing"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "e32acfa6-f854-48c9-838f-0a07a42325d0",
          "key": "DENV-105",
          "title": "Require expiry and ownership for emergency feature overrides",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DENV-101",
            "DENV-103"
          ],
          "scenario": "A disable-delivery flag added during a rehearsal remains set for weeks because its reason and owner exist only in chat.",
          "acceptanceCriteria": [
            "Override records owner, reason, scope, creation, and expiry",
            "Expired override fails compilation instead of remaining active",
            "Normal configuration remains visible beneath the override"
          ],
          "implementationNotes": [
            "Use synthetic operator identities; flags do not bypass authorization or audit."
          ],
          "verification": [
            "Apply an active scoped override and show its provenance.",
            "Compile expired and ownerless overrides and confirm blocking errors."
          ],
          "deliverables": [
            "Expiring override registry and policy tests"
          ],
          "rollout": "Introduce reporting before rejecting legacy unowned fixture flags.",
          "skills": [
            "Feature flags",
            "Operational governance",
            "Time modeling"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "7a53d86d-61aa-4611-acd4-d51cd73b3028",
          "key": "DENV-106",
          "title": "Promote configuration by immutable revision",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DENV-103",
            "DENV-104"
          ],
          "scenario": "A mutable environment file changes after approval but before deployment, so the applied settings were never reviewed.",
          "acceptanceCriteria": [
            "Compilation produces canonical content and immutable revision hash",
            "Approval and deployment bind the exact revision",
            "Any source-layer change produces a new revision"
          ],
          "implementationNotes": [
            "Exclude secret values while binding secret reference identities and schema version."
          ],
          "verification": [
            "Approve and deploy one unchanged revision.",
            "Edit a source layer after approval and verify deployment refuses the stale authorization."
          ],
          "deliverables": [
            "Immutable configuration revision and approval-binding tests"
          ],
          "rollout": "Use revision identities in the local deployment simulator before removing mutable file reads.",
          "skills": [
            "Content hashing",
            "Immutable configuration",
            "Authorization"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "0f479a4a-f9ef-4f79-bac3-b24fc8210b37",
          "key": "DENV-107",
          "title": "Resolve secret rotation without restarting into a mixed revision",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DENV-103",
            "DENV-106"
          ],
          "scenario": "Two secret references rotate independently while workers reload, leaving some requests signed with mismatched key and certificate versions.",
          "acceptanceCriteria": [
            "Dependent secret references resolve as one declared bundle revision",
            "Reload publishes only a fully validated immutable snapshot",
            "In-flight work retains its starting snapshot until completion"
          ],
          "implementationNotes": [
            "Fake secret material stays inside the local adapter and is never included in generic configuration hashes."
          ],
          "verification": [
            "Rotate a complete bundle while old and new operations overlap.",
            "Withhold one member and confirm no worker selects the partial revision."
          ],
          "deliverables": [
            "Secret-bundle reload protocol and overlap test"
          ],
          "rollout": "Keep restart-based rotation available until snapshot reload is proven.",
          "skills": [
            "Secret rotation",
            "Atomic publication",
            "Concurrency"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 65
            },
            {
              "field": "Security",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "d18f6f9d-bb43-4a43-8eb2-b1b9106a65fa",
          "key": "DENV-108",
          "title": "Detect environment drift without copying secret data",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DENV-106"
          ],
          "scenario": "A local environment's retry count is changed outside the compiler, but drift reports are disabled because teams fear dumping secrets.",
          "acceptanceCriteria": [
            "Compare ordinary canonical values and secret reference identities",
            "Report missing, extra, and changed paths with provenance",
            "Secret values and provider error bodies are never serialized"
          ],
          "implementationNotes": [
            "Observed configuration comes from a bounded fake runtime projection."
          ],
          "verification": [
            "Detect changes in an ordinary value and a secret reference version.",
            "Return a sentinel secret in observed input and prove it cannot enter the report."
          ],
          "deliverables": [
            "Redacted drift detector and fixture report"
          ],
          "rollout": "Begin in read-only mode and resolve unexplained differences before automation.",
          "skills": [
            "Drift detection",
            "Redaction",
            "Reconciliation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3484f07b-c47f-49d6-bb40-ed42bb62829e",
          "key": "DENV-109",
          "title": "Roll back configuration without rolling back application code",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DENV-106",
            "DENV-107",
            "DENV-108"
          ],
          "scenario": "A new timeout revision overloads the fake provider, but the only recovery script redeploys the entire previous application artifact.",
          "acceptanceCriteria": [
            "Rollback selects a prior compatible configuration revision",
            "Compatibility is checked against the current application contract",
            "History retains failed and restored revisions plus observed outcome"
          ],
          "implementationNotes": [
            "Rollback never mutates a historical revision or reuses its approval for another environment."
          ],
          "verification": [
            "Deploy a bad timeout revision and restore the prior compatible configuration.",
            "Choose a revision requiring an older schema and block rollback with an actionable result."
          ],
          "deliverables": [
            "Configuration rollback command and recovery rehearsal"
          ],
          "rollout": "Maintain one known-compatible revision for each simulated environment.",
          "skills": [
            "Configuration rollback",
            "Compatibility",
            "Incident recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9a0fc31a-43b5-49bb-b19c-c7a37c31d4c4",
          "key": "DENV-110",
          "title": "Publish the environment contract for service owners",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DENV-105",
            "DENV-108",
            "DENV-109"
          ],
          "scenario": "New owners know variable names but not which settings can change independently, which require restart, or how failure appears.",
          "acceptanceCriteria": [
            "Reference lists type, source, default, sensitivity, reload behavior, and owner",
            "Cross-field invariants and rollback compatibility are linked",
            "Examples use synthetic values and secret references only"
          ],
          "implementationNotes": [
            "Generated reference comes from the same schema used by validation."
          ],
          "verification": [
            "Generate and review documentation for every current field.",
            "Add an undocumented schema field and make the consistency test fail."
          ],
          "deliverables": [
            "Generated environment reference and owner runbook"
          ],
          "rollout": "Require schema and documentation consistency in CI.",
          "skills": [
            "Documentation generation",
            "Service ownership"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "ba88d4b3-eed6-4979-9779-616d422eccc6"
    },
    {
      "key": "DART",
      "title": "Build an artifact path that can defend what it publishes",
      "field": "DevOps",
      "summary": "Create reproducible packages, provenance, signing boundaries, retention, and compromise recovery.",
      "context": "A fictional command-line product publishes local package archives. Builds contain timestamps, checksums are copied without provenance, and cleanup can delete the only rollback artifact. Use generated source trees, ephemeral development signing keys, and local object storage; no public registry or production key is supplied.",
      "stack": [
        "TypeScript",
        "Tar",
        "S3-compatible adapter",
        "Ephemeral signing provider"
      ],
      "prerequisites": [
        "Content hashing",
        "Archive formats",
        "Release metadata"
      ],
      "developerValue": "Practice reproducible artifacts, provenance validation, signing-key isolation and retention safety.",
      "companyValue": "Review a supply path that can trace, verify, retain, and revoke artifacts without relying on mutable names.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "7c67f02e-cf7b-4b02-a19c-bb49324a9095",
          "key": "DART-101",
          "title": "Make archive bytes reproducible from the same source manifest",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Two builds from identical fixtures differ because archive order, timestamps, ownership, and path separators come from the host.",
          "acceptanceCriteria": [
            "Sort entries by canonical relative path",
            "Normalize declared timestamps, ownership, permissions, and separators",
            "Reject paths escaping or colliding after normalization"
          ],
          "implementationNotes": [
            "Use generated files only and do not archive the repository working tree."
          ],
          "verification": [
            "Build twice in different temporary roots and compare byte digests.",
            "Add traversal and normalization-collision paths and confirm rejection."
          ],
          "deliverables": [
            "Deterministic archive writer and reproducibility tests"
          ],
          "rollout": "Publish reproducibility metadata before replacing the current archive path.",
          "skills": [
            "Reproducible builds",
            "Archive safety"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "96fab8e1-c129-4fda-a909-d2b0b2d8f696",
          "key": "DART-102",
          "title": "Generate a dependency inventory from resolved inputs",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "DART-101"
          ],
          "scenario": "The package manifest lists declared ranges, not the exact dependency versions bundled into the archive.",
          "acceptanceCriteria": [
            "Inventory records exact package, version, integrity, and relationship",
            "Generation uses the resolved lock and packaged output",
            "Unknown or duplicate identities fail the release gate"
          ],
          "implementationNotes": [
            "Do not contact public vulnerability or package services in the exercise."
          ],
          "verification": [
            "Generate a stable inventory for the fixture lockfile.",
            "Remove an integrity entry and add a duplicate package identity, then block publication."
          ],
          "deliverables": [
            "Dependency inventory generator and malformed-lock tests"
          ],
          "rollout": "Attach inventory to local artifacts before enforcing completeness.",
          "skills": [
            "SBOM",
            "Dependency management"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "29da159f-1060-42f8-8cc0-cf38252d1023",
          "key": "DART-103",
          "title": "Bind provenance to source, builder, and exact artifact",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DART-101",
            "DART-102"
          ],
          "scenario": "A provenance file names a commit but is copied beside a different archive without detection.",
          "acceptanceCriteria": [
            "Statement binds artifact digest, source revision, build recipe, and builder identity",
            "Verification recomputes the artifact digest",
            "Unknown statement fields are preserved or rejected by version policy"
          ],
          "implementationNotes": [
            "Builder identity is a synthetic workload identity, not a person or authorship claim."
          ],
          "verification": [
            "Verify the matching artifact and statement.",
            "Swap artifact and source identities independently and confirm failure."
          ],
          "deliverables": [
            "Versioned provenance statement and verifier"
          ],
          "rollout": "Require verified provenance for a single fixture channel first.",
          "skills": [
            "Provenance",
            "Supply-chain security"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "80244ca5-fdf1-439d-bef2-05603cf4ec64",
          "key": "DART-104",
          "title": "Keep signing keys outside the build workspace",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DART-103"
          ],
          "scenario": "The build job receives an exportable private key file that any build script could read or include in the archive.",
          "acceptanceCriteria": [
            "Build produces an unsigned digest and signing request",
            "Signing provider accepts only authorized artifact metadata",
            "Private key bytes never enter workspace, logs, or artifacts"
          ],
          "implementationNotes": [
            "Use ephemeral local keys behind a provider interface; production key management remains unprovisioned."
          ],
          "verification": [
            "Sign and verify an authorized fixture artifact.",
            "Search outputs for a sentinel key and reject an unauthorized digest request."
          ],
          "deliverables": [
            "Signing-provider boundary and leak tests"
          ],
          "rollout": "Keep unsigned artifacts nonpromotable while the development signer is enabled.",
          "skills": [
            "Key isolation",
            "Provider interfaces",
            "Signing"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Security",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b384a822-d3ec-400e-b76c-d39519209983",
          "key": "DART-105",
          "title": "Promote only artifacts whose evidence set reconciles",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DART-102",
            "DART-103",
            "DART-104"
          ],
          "scenario": "A package is promoted after signature verification even though its inventory belongs to an earlier build.",
          "acceptanceCriteria": [
            "Gate binds artifact, provenance, inventory, signature, and policy versions",
            "Every component references the same artifact digest",
            "Missing or conflicting metadata blocks promotion with exact reasons"
          ],
          "implementationNotes": [
            "This verifies release metadata, not candidate Outcome Evidence or ownership."
          ],
          "verification": [
            "Promote one complete matching fixture set.",
            "Mix inventory, signature, and provenance from neighboring builds and reject each case."
          ],
          "deliverables": [
            "Artifact evidence-set gate and mismatch matrix"
          ],
          "rollout": "Run the gate in report-only mode before making it mandatory.",
          "skills": [
            "Release gates",
            "Integrity",
            "Policy validation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "43defb43-7152-401a-83f3-5e2ecf61fd64",
          "key": "DART-106",
          "title": "Prevent a mutable channel from changing an approved artifact",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DART-105"
          ],
          "scenario": "The beta channel is approved while pointing to one digest, then its mutable object is overwritten before clients resolve it.",
          "acceptanceCriteria": [
            "Approval binds channel, digest, and revision",
            "Channel update uses compare-and-set against observed revision",
            "Clients can resolve historical channel revisions"
          ],
          "implementationNotes": [
            "Channel is discovery metadata; the artifact remains content addressed and immutable."
          ],
          "verification": [
            "Advance beta from one approved digest to another.",
            "Race two channel updates and verify only one wins without overwriting history."
          ],
          "deliverables": [
            "Versioned channel pointer and concurrency test"
          ],
          "rollout": "Enable one nondefault fixture channel before broader use.",
          "skills": [
            "Optimistic concurrency",
            "Artifact channels"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Distributed systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "a645ef65-9999-462f-82a4-fef5060abe99",
          "key": "DART-107",
          "title": "Revoke a compromised signing identity without deleting history",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DART-104",
            "DART-105"
          ],
          "scenario": "A development signing key is declared compromised, and the cleanup proposal deletes every artifact it signed, including investigation records.",
          "acceptanceCriteria": [
            "Revocation records key identity, effective scope, time, and reason",
            "Verification distinguishes signed-before, signed-after, and explicitly revoked artifacts",
            "Historical metadata remains inspectable and immutable"
          ],
          "implementationNotes": [
            "Use ephemeral fixture keys; do not claim real-world trust without a provisioned signer and policy."
          ],
          "verification": [
            "Verify artifacts on both sides of a declared rotation under policy.",
            "Present an artifact signed after compromise and confirm promotion denial without deletion."
          ],
          "deliverables": [
            "Signing revocation policy and temporal tests"
          ],
          "rollout": "Block new promotion first, then review already promoted fixture artifacts.",
          "skills": [
            "Key revocation",
            "Temporal policy",
            "Audit"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 65
            },
            {
              "field": "Security",
              "percentage": 35
            }
          ],
          "patterns": []
        },
        {
          "id": "f6faa569-728e-4161-9b8f-990aced24191",
          "key": "DART-108",
          "title": "Retain rollback artifacts while bounding storage growth",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DART-105",
            "DART-106"
          ],
          "scenario": "Age-only cleanup removes the last compatible rollback artifact for a supported release line.",
          "acceptanceCriteria": [
            "Retention protects active, rollback, held, and investigation-referenced digests",
            "Deletion plan is deterministic and reviewable before mutation",
            "Partial deletion resumes by immutable digest"
          ],
          "implementationNotes": [
            "Use local object storage and synthetic artifact bytes; never delete undeclared objects."
          ],
          "verification": [
            "Plan and execute cleanup while retaining every protected digest.",
            "Interrupt halfway and replay; add an unknown reference and keep it unresolved."
          ],
          "deliverables": [
            "Artifact retention planner and interrupted cleanup drill"
          ],
          "rollout": "Run plan-only mode before enabling scoped fixture deletion.",
          "skills": [
            "Retention",
            "Object storage",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Storage systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "151556f6-1594-4f48-bb78-0a50300eb470",
          "key": "DART-109",
          "title": "Recover publication after object storage acknowledges late",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DART-103",
            "DART-105",
            "DART-108"
          ],
          "scenario": "The object store commits an archive but the upload times out; retry creates a differently named duplicate and publishes only one metadata set.",
          "acceptanceCriteria": [
            "Object key derives from verified content digest",
            "Retry reconciles size, digest, and metadata before upload",
            "Conflicting existing content is quarantined and never overwritten"
          ],
          "implementationNotes": [
            "Treat storage metadata as untrusted until content identity is verified."
          ],
          "verification": [
            "Upload and replay an identical artifact idempotently.",
            "Lose the response after commit and preplace conflicting bytes under the expected key."
          ],
          "deliverables": [
            "Content-addressed publisher and ambiguous-upload tests"
          ],
          "rollout": "Enable for one artifact class while retaining the prior publisher for rollback.",
          "skills": [
            "Object storage",
            "Idempotency",
            "Integrity"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Storage systems",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "f6f08239-1f6a-48de-af61-93fee1ca5387",
          "key": "DART-110",
          "title": "Rehearse artifact compromise from block to recovery",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DART-107",
            "DART-108",
            "DART-109"
          ],
          "scenario": "The response plan says rotate and rebuild but does not identify affected channels, compatible rollback artifacts, or how clients learn the block.",
          "acceptanceCriteria": [
            "Runbook traces key, artifact, channel, environment, and consumer relationships",
            "Rehearsal blocks promotion and selects a verified compatible artifact",
            "Recovery publishes a new identity without rewriting compromised history"
          ],
          "implementationNotes": [
            "The scenario uses fictional artifacts and ephemeral keys only."
          ],
          "verification": [
            "Complete a synthetic compromise and restore a safe channel.",
            "Remove the expected rollback artifact and follow the documented blocked path."
          ],
          "deliverables": [
            "Artifact incident runbook and tabletop transcript"
          ],
          "rollout": "Review findings before treating the workflow as ready for an external registry.",
          "skills": [
            "Incident response",
            "Supply-chain recovery",
            "Runbooks"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "c842c7e6-cc1c-4fda-93b0-ef2c10224911"
    },
    {
      "key": "DDEV",
      "title": "Make local development reproducible without hiding dependencies",
      "field": "DevOps",
      "summary": "Define bootstrap, service readiness, data reset, offline behavior, and cross-platform parity.",
      "context": "A fictional support portal requires a database, cache, object store, and mail catcher. Setup lives in personal notes, reset scripts sometimes target shared resources, and offline work fails after package caches are cleared. Build a local-only development contract with synthetic data; no shared staging system or production credentials are supplied.",
      "stack": [
        "TypeScript",
        "Containers",
        "PowerShell and POSIX shell",
        "Local services"
      ],
      "prerequisites": [
        "Environment variables",
        "Service health",
        "Database migrations"
      ],
      "developerValue": "Practice developer-environment automation, safe reset boundaries, portability, and diagnostic quality.",
      "companyValue": "Reduce onboarding and support cost while making local dependencies and destructive operations explicit.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "276ce689-0acd-40be-9e86-e91372146730",
          "key": "DDEV-101",
          "title": "Turn the setup notes into one preflight report",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "A new developer follows six documents and reaches application startup before learning that the required runtime version is unsupported.",
          "acceptanceCriteria": [
            "Preflight checks runtime, package manager, container engine, ports, and required files",
            "Each result says detected, required, and remediation",
            "Checks are read-only and return one aggregate status"
          ],
          "implementationNotes": [
            "Do not install software or change host settings from preflight."
          ],
          "verification": [
            "Run against a complete declared fixture environment.",
            "Simulate multiple missing dependencies and report all of them in one pass."
          ],
          "deliverables": [
            "Read-only preflight command and environment fixtures"
          ],
          "rollout": "Link preflight from the existing setup guide before removing manual checks.",
          "skills": [
            "Developer experience",
            "Environment diagnostics"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "87b6076f-72a1-4f53-95ec-5d62edbd3668",
          "key": "DDEV-102",
          "title": "Start local services only after validating port ownership",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "DDEV-101"
          ],
          "scenario": "Bootstrap sees a port in use and assumes the expected database is running, but the listener belongs to another application.",
          "acceptanceCriteria": [
            "Readiness validates protocol and fixture service identity",
            "Port collision names the port without terminating the owner",
            "Bootstrap records which processes or containers it started"
          ],
          "implementationNotes": [
            "Never kill an unknown process or bind beyond loopback in this exercise."
          ],
          "verification": [
            "Reuse a healthy owned fixture service and start a missing one.",
            "Place an unrelated listener on the port and fail with remediation."
          ],
          "deliverables": [
            "Service identity probes and collision tests"
          ],
          "rollout": "Require identity checks before automated startup.",
          "skills": [
            "Service discovery",
            "Safe automation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Platform engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "78afbe4a-e67c-4f3c-8bbd-61f0930a59c4",
          "key": "DDEV-103",
          "title": "Apply migrations exactly once during concurrent bootstrap",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DDEV-102"
          ],
          "scenario": "Two local application processes start together and both run the same migration, leaving one failed and the schema state unclear.",
          "acceptanceCriteria": [
            "Migration ownership uses the database-supported lock",
            "Waiters observe the final applied version",
            "Failure leaves the migration retryable and visible"
          ],
          "implementationNotes": [
            "Use migrations; do not replace the workflow with schema push."
          ],
          "verification": [
            "Start two bootstrap processes against an empty fixture database.",
            "Interrupt the migration owner and verify a later run can safely resolve state."
          ],
          "deliverables": [
            "Migration coordination and concurrent-start test"
          ],
          "rollout": "Keep manual migration available until the bootstrap path is repeatable.",
          "skills": [
            "Database migrations",
            "Concurrency",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Database engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9df80cc5-bf65-480d-9568-d0244b940f80",
          "key": "DDEV-104",
          "title": "Seed deterministic accounts without creating duplicates",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DDEV-103"
          ],
          "scenario": "Every bootstrap appends another demo organization and screenshots depend on whichever duplicate is returned first.",
          "acceptanceCriteria": [
            "Seed identities are stable and unique",
            "Repeated seed reconciles declared values idempotently",
            "User-owned local additions remain untouched"
          ],
          "implementationNotes": [
            "Synthetic fixtures must be clearly labeled and never selected outside local Demo mode."
          ],
          "verification": [
            "Seed twice and compare identities, counts, and relations.",
            "Change one fixture revision and verify an intentional update without duplicate rows."
          ],
          "deliverables": [
            "Versioned seed reconciler and repeat-run tests"
          ],
          "rollout": "Require explicit local Demo mode before seeding.",
          "skills": [
            "Test data",
            "Idempotency",
            "Data safety"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Database engineering",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "2da31ae9-f161-4f65-9892-e29e68e50210",
          "key": "DDEV-105",
          "title": "Reset only resources created by this workspace",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DDEV-102",
            "DDEV-104"
          ],
          "scenario": "A cleanup command deletes every container with a generic project label, including another checkout's database.",
          "acceptanceCriteria": [
            "Workspace identity is stable, explicit, and included on owned resources",
            "Reset previews exact absolute targets and service identities",
            "Foreign and ambiguous resources are refused"
          ],
          "implementationNotes": [
            "The command operates only on generated local fixtures and requires an explicit reset flag."
          ],
          "verification": [
            "Preview and reset one isolated fixture workspace.",
            "Add a second workspace and an ambiguous unlabeled resource, then prove both survive."
          ],
          "deliverables": [
            "Scoped reset command and cross-workspace safety tests"
          ],
          "rollout": "Ship preview-only first and document recovery limits.",
          "skills": [
            "Safe automation",
            "Resource ownership",
            "Destructive-operation design"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "9956e319-b6b2-416e-887d-298ef86f950e",
          "key": "DDEV-106",
          "title": "Report readiness by dependency instead of waiting blindly",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DDEV-102",
            "DDEV-103"
          ],
          "scenario": "Bootstrap sleeps thirty seconds, then starts the application even if object storage is still initializing or the database failed permanently.",
          "acceptanceCriteria": [
            "Each dependency has a bounded identity-aware readiness probe",
            "Transient and terminal failures have separate retry behavior",
            "Overall report shows ready, waiting, failed, and skipped dependencies"
          ],
          "implementationNotes": [
            "Use injected time and local probes; fixed sleep is not readiness."
          ],
          "verification": [
            "Start dependencies with staggered readiness and complete when all required services pass.",
            "Return a permanent schema error and stop retrying with an actionable report."
          ],
          "deliverables": [
            "Dependency readiness graph and timing tests"
          ],
          "rollout": "Display reports beside the existing startup path before enforcing them.",
          "skills": [
            "Readiness",
            "Retry policy",
            "Diagnostics"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "5df6ec4f-1102-4d82-aa29-60254eff94e7",
          "key": "DDEV-107",
          "title": "Support an offline bootstrap from a verified local cache",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DDEV-101",
            "DDEV-106"
          ],
          "scenario": "Developers lose network access during an incident rehearsal and bootstrap cannot tell which packages and service images are already available locally.",
          "acceptanceCriteria": [
            "Offline manifest lists exact package and image digests",
            "Bootstrap verifies every cached artifact before use",
            "Missing items produce a complete acquisition list without partial startup"
          ],
          "implementationNotes": [
            "Do not bypass integrity checks or contact a network when offline mode is selected."
          ],
          "verification": [
            "Bootstrap from a complete verified cache with network access denied.",
            "Remove and corrupt separate artifacts and report both before starting services."
          ],
          "deliverables": [
            "Offline manifest, verifier, and disconnected tests"
          ],
          "rollout": "Treat offline support as explicit mode with a generated cache preparation step.",
          "skills": [
            "Offline workflows",
            "Artifact integrity",
            "Dependency management"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Developer tooling",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "3634dd46-7515-46f3-835e-eb309f928173",
          "key": "DDEV-108",
          "title": "Keep Windows and POSIX commands behaviorally equivalent",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DDEV-101",
            "DDEV-105",
            "DDEV-106"
          ],
          "scenario": "The PowerShell reset resolves symlinks differently from the POSIX script and deletes a fixture path the other implementation refuses.",
          "acceptanceCriteria": [
            "Both entry points call one typed cross-platform core",
            "Path, quoting, exit status, and signal differences have contract tests",
            "Unsupported platform behavior fails visibly"
          ],
          "implementationNotes": [
            "Tests use temporary directories and do not invoke destructive commands through another shell."
          ],
          "verification": [
            "Run the shared fixture matrix through both thin entry points.",
            "Use paths with spaces, links, and metacharacters and compare safe outcomes."
          ],
          "deliverables": [
            "Cross-platform command core and parity report"
          ],
          "rollout": "Keep platform scripts as wrappers and review every behavioral difference.",
          "skills": [
            "Cross-platform tooling",
            "Shell safety",
            "Contract testing"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "1cd0f27b-4f89-423f-bff9-324e605eb440",
          "key": "DDEV-109",
          "title": "Diagnose local startup without collecting source or secrets",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DDEV-106",
            "DDEV-108"
          ],
          "scenario": "A support bundle recursively archives the workspace to explain startup failures, capturing source files and environment secrets.",
          "acceptanceCriteria": [
            "Bundle allowlist contains tool versions, bounded health results, safe config identities, and recent bootstrap events",
            "Source, environment values, tokens, database rows, and payload logs are excluded",
            "User previews exact included files and fields"
          ],
          "implementationNotes": [
            "Use sentinel secrets and synthetic source fixtures to prove exclusion."
          ],
          "verification": [
            "Generate a useful bundle for a failed readiness probe.",
            "Place sentinels in every prohibited source and confirm none appear in archive bytes."
          ],
          "deliverables": [
            "Redacted support bundle and leak regression suite"
          ],
          "rollout": "Keep bundle generation local and user initiated.",
          "skills": [
            "Diagnostics",
            "Privacy",
            "Redaction"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "f547310a-897a-4313-a750-385fb9666051",
          "key": "DDEV-110",
          "title": "Prove onboarding from a clean machine profile",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DDEV-104",
            "DDEV-107",
            "DDEV-108",
            "DDEV-109"
          ],
          "scenario": "The setup succeeds only on long-lived developer machines that already contain undeclared packages and cached service state.",
          "acceptanceCriteria": [
            "Test starts from a declared clean profile with empty workspace-owned state",
            "Online and prepared-offline paths produce the same fixture application behavior",
            "Duration report separates downloads, builds, migrations, seeds, and readiness"
          ],
          "implementationNotes": [
            "The profile is a local disposable fixture, not a production host image."
          ],
          "verification": [
            "Complete onboarding twice from clean profiles and compare outcomes.",
            "Remove one declared prerequisite and verify preflight fails before mutation."
          ],
          "deliverables": [
            "Clean-profile onboarding rehearsal and timing report"
          ],
          "rollout": "Use the rehearsal in documentation review before changing team onboarding policy.",
          "skills": [
            "Onboarding automation",
            "Reproducibility",
            "Performance analysis"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Developer tooling",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "52784e0d-6b6f-43a1-967c-d9b7736f422b"
    },
    {
      "key": "DPREVIEW",
      "title": "Create review environments that clean themselves up",
      "field": "DevOps",
      "summary": "Provision isolated previews with bounded cost, tenant-safe data, verified readiness, and deletion recovery.",
      "context": "A fictional product team creates local preview environments for pull requests. Names collide, fixtures copy more data than needed, failed provisioning leaks resources, and merged changes leave previews running. Build an infrastructure simulator with fake DNS, storage, and deployment providers; no cloud account or live domain is supplied.",
      "stack": [
        "TypeScript",
        "Infrastructure model",
        "Fake DNS",
        "Queue adapter"
      ],
      "prerequisites": [
        "Resource graphs",
        "Idempotency",
        "Tenant isolation"
      ],
      "developerValue": "Practice ephemeral environment lifecycle, scoped configuration, cleanup, quotas, and provider reconciliation.",
      "companyValue": "Review changes in isolated representative environments while controlling leakage, resource growth, and abandoned infrastructure.",
      "delivery": "Ten linked tickets across three phases. Use a local repository and fake providers; deliver workflow code, failure tests, a rollback rehearsal, and a concise runbook.",
      "phases": [
        {
          "id": "baseline",
          "title": "Make the delivery contract visible",
          "goal": "Replace implicit workflow assumptions with reviewable inputs and outcomes."
        },
        {
          "id": "control",
          "title": "Control change and failure",
          "goal": "Add bounded concurrency, authority checks, and restart-safe transitions."
        },
        {
          "id": "handoff",
          "title": "Operate and improve",
          "goal": "Measure the workflow, rehearse recovery, and document ownership."
        }
      ],
      "tickets": [
        {
          "id": "ffbb8ae1-5f3a-4164-928b-167ff2b74868",
          "key": "DPREVIEW-101",
          "title": "Derive a collision-resistant preview identity",
          "type": "TASK",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [],
          "scenario": "Two repositories both open pull request 42 and receive the same environment name, causing one preview to replace the other.",
          "acceptanceCriteria": [
            "Identity binds repository, immutable revision, and pull-request identity",
            "Human-readable alias maps to one immutable environment ID",
            "Length and character limits are enforced before provider calls"
          ],
          "implementationNotes": [
            "Do not use branch text as the sole authority or resource identity."
          ],
          "verification": [
            "Create previews for same-number requests in two repositories.",
            "Use oversized and normalization-colliding names and confirm no resource mutation."
          ],
          "deliverables": [
            "Preview identity contract and collision tests"
          ],
          "rollout": "Adopt IDs in state first while retaining old aliases for display.",
          "skills": [
            "Resource identity",
            "Input validation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "348fa0d8-3ceb-40a7-8b0a-5e83ea22e178",
          "key": "DPREVIEW-102",
          "title": "Compile a minimal preview configuration",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "FOUNDATIONAL",
          "estimateMinutes": 90,
          "phaseId": "baseline",
          "dependsOn": [
            "DPREVIEW-101"
          ],
          "scenario": "Preview inherits production-like integrations and tries to send fixture events to undeclared external endpoints.",
          "acceptanceCriteria": [
            "Preview configuration selects only fake or explicitly allowed providers",
            "Network policy defaults to deny and lists required local dependencies",
            "Secrets are references to preview-scoped fixtures"
          ],
          "implementationNotes": [
            "No production credential, customer data, or public callback is permitted."
          ],
          "verification": [
            "Compile a preview using only declared fake providers.",
            "Reference an external endpoint and a production-like secret scope, then block compilation."
          ],
          "deliverables": [
            "Preview configuration policy and denial tests"
          ],
          "rollout": "Require policy compilation before any resource plan.",
          "skills": [
            "Environment isolation",
            "Configuration policy",
            "Security"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Security",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d508bc1b-c8f5-47c4-912e-ceaf794954cc",
          "key": "DPREVIEW-103",
          "title": "Plan the resource graph before creating anything",
          "type": "STORY",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "baseline",
          "dependsOn": [
            "DPREVIEW-101",
            "DPREVIEW-102"
          ],
          "scenario": "Provisioning creates storage before discovering the requested database class exceeds the preview quota, leaving an orphan.",
          "acceptanceCriteria": [
            "Plan resolves complete dependency graph and quota cost",
            "Validation lists every blocking reason before mutation",
            "Plan has immutable revision used by apply"
          ],
          "implementationNotes": [
            "Fake provider discovery is read-only and bounded."
          ],
          "verification": [
            "Plan a valid preview and reconcile its declared resource order.",
            "Exceed compute and storage quotas together and confirm zero creates."
          ],
          "deliverables": [
            "Preview planner and multi-error quota tests"
          ],
          "rollout": "Expose plan-only operation before apply is enabled.",
          "skills": [
            "Infrastructure planning",
            "Quotas",
            "Dependency graphs"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "d39c3f8d-3f57-4b9e-a471-fda575a9fd26",
          "key": "DPREVIEW-104",
          "title": "Apply preview resources idempotently after interruption",
          "type": "CHORE",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "control",
          "dependsOn": [
            "DPREVIEW-103"
          ],
          "scenario": "Provisioning stops after database creation. Retry creates a second database because local state was not saved before the provider call.",
          "acceptanceCriteria": [
            "Each resource has deterministic operation identity",
            "Apply reconciles provider state before create",
            "Completed resources resume without recreating or skipping dependencies"
          ],
          "implementationNotes": [
            "Provider calls execute outside state transactions and return untrusted observations."
          ],
          "verification": [
            "Apply a complete plan and replay it without changes.",
            "Interrupt after one accepted create and confirm retry adopts the matching resource."
          ],
          "deliverables": [
            "Idempotent preview applier and interruption drill"
          ],
          "rollout": "Limit concurrent previews while reconciliation behavior is observed.",
          "skills": [
            "Idempotency",
            "Infrastructure automation",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "8d72454d-8fbf-4102-bb09-b8e3b02e52ef",
          "key": "DPREVIEW-105",
          "title": "Seed representative data without copying customer records",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DPREVIEW-102",
            "DPREVIEW-104"
          ],
          "scenario": "A convenient preview script proposes copying a small slice of the production-like database, including free-text notes.",
          "acceptanceCriteria": [
            "Seed generator produces synthetic entities matching declared schema constraints",
            "Relationships and edge cases are deterministic from a versioned seed",
            "No source connector for customer data exists in preview composition"
          ],
          "implementationNotes": [
            "Do not claim synthetic distributions reproduce real customer behavior."
          ],
          "verification": [
            "Seed two previews with the same revision and compare logical fixtures.",
            "Attempt to configure an undeclared source connector and fail before data access."
          ],
          "deliverables": [
            "Synthetic preview seeder and schema-edge fixtures"
          ],
          "rollout": "Review fixture usefulness separately from data-safety enforcement.",
          "skills": [
            "Synthetic data",
            "Privacy",
            "Database seeding"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Privacy engineering",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "e2ba3ba7-9b0a-4f07-a908-64746947ecb1",
          "key": "DPREVIEW-106",
          "title": "Publish the preview URL only after identity-aware readiness",
          "type": "BUG",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "control",
          "dependsOn": [
            "DPREVIEW-104",
            "DPREVIEW-105"
          ],
          "scenario": "The bot posts a URL when the load balancer responds, but it points to an older preview that still owns the recycled alias.",
          "acceptanceCriteria": [
            "Readiness proves environment ID, revision, schema, and seed version",
            "URL publication compares alias ownership immediately before update",
            "Failure remains pending or failed with exact dependency status"
          ],
          "implementationNotes": [
            "Use fake DNS and loopback probes; no public record is created."
          ],
          "verification": [
            "Publish a ready matching preview alias.",
            "Return healthy content from an older environment and block publication."
          ],
          "deliverables": [
            "Identity-aware readiness gate and stale-alias test"
          ],
          "rollout": "Show URLs only after the new gate succeeds.",
          "skills": [
            "Readiness",
            "DNS",
            "Identity validation"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Networking",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "3bb23150-9669-4b46-aa5d-6f3f4636fa5d",
          "key": "DPREVIEW-107",
          "title": "Enforce preview quotas across concurrent requests",
          "type": "STORY",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "control",
          "dependsOn": [
            "DPREVIEW-103",
            "DPREVIEW-104"
          ],
          "scenario": "Two valid plans each fit the remaining quota, then apply concurrently and exceed the team limit together.",
          "acceptanceCriteria": [
            "Quota reservation and environment admission are atomic",
            "Expired reservations are reclaimed through identity-checked leases",
            "Provider failure releases or reconciles reservation deterministically"
          ],
          "implementationNotes": [
            "Do not hold a database transaction open across provider operations."
          ],
          "verification": [
            "Admit concurrent plans whose combined cost fits exactly.",
            "Race two plans over the limit and verify only one obtains authority to apply."
          ],
          "deliverables": [
            "Quota reservation protocol and concurrency tests"
          ],
          "rollout": "Start with conservative team quotas and visible denials.",
          "skills": [
            "Concurrency",
            "Leases",
            "Quota enforcement"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Distributed systems",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "da238bc2-ff17-4d1f-b0ae-e05b156263ad",
          "key": "DPREVIEW-108",
          "title": "Expire previews without deleting an active replacement",
          "type": "CHORE",
          "priority": "HIGH",
          "difficulty": "ADVANCED",
          "estimateMinutes": 240,
          "phaseId": "handoff",
          "dependsOn": [
            "DPREVIEW-101",
            "DPREVIEW-104"
          ],
          "scenario": "A delayed cleanup job for an old preview alias deletes storage now owned by a newer environment.",
          "acceptanceCriteria": [
            "Cleanup binds immutable environment and resource identities",
            "Deletion compares current provider ownership before action",
            "Alias reuse cannot transfer cleanup authority"
          ],
          "implementationNotes": [
            "Use fake providers and delete only resources returned by the scoped plan."
          ],
          "verification": [
            "Expire one environment and remove exactly its resource graph.",
            "Reuse its alias for a new environment before delayed cleanup and confirm new resources survive."
          ],
          "deliverables": [
            "Fenced expiry job and alias-reuse regression"
          ],
          "rollout": "Run cleanup in report-only mode before enabling deletions.",
          "skills": [
            "Cleanup",
            "Fencing",
            "Resource ownership"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Cloud infrastructure",
              "percentage": 30
            }
          ],
          "patterns": []
        },
        {
          "id": "b2e31a8b-87a8-47b7-a867-8e68519ed649",
          "key": "DPREVIEW-109",
          "title": "Resume partial preview deletion without losing unresolved resources",
          "type": "TASK",
          "priority": "HIGH",
          "difficulty": "EXPERT",
          "estimateMinutes": 360,
          "phaseId": "handoff",
          "dependsOn": [
            "DPREVIEW-108"
          ],
          "scenario": "DNS deletion succeeds, storage deletion times out after acceptance, and the environment is marked deleted despite an unknown storage outcome.",
          "acceptanceCriteria": [
            "Deletion tracks each resource as pending, deleted, absent, failed, or unknown",
            "Retry reconciles unknown provider state before mutation",
            "Environment closes only when every resource reaches a resolved terminal state"
          ],
          "implementationNotes": [
            "Unknown does not equal absent; provider responses remain untrusted until identity reconciliation."
          ],
          "verification": [
            "Delete a full graph and replay the job idempotently.",
            "Lose a storage-delete response and confirm the environment remains visibly unresolved."
          ],
          "deliverables": [
            "Deletion state machine and partial-failure drill"
          ],
          "rollout": "Alert on aged unresolved cleanup rather than hiding it.",
          "skills": [
            "Lifecycle state",
            "Provider reconciliation",
            "Recovery"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 60
            },
            {
              "field": "Site reliability",
              "percentage": 40
            }
          ],
          "patterns": []
        },
        {
          "id": "ce70d63e-a047-4ac2-a86e-4c5d61552824",
          "key": "DPREVIEW-110",
          "title": "Report preview value and cost without vanity counts",
          "type": "BUG",
          "priority": "MEDIUM",
          "difficulty": "INTERMEDIATE",
          "estimateMinutes": 150,
          "phaseId": "handoff",
          "dependsOn": [
            "DPREVIEW-106",
            "DPREVIEW-107",
            "DPREVIEW-109"
          ],
          "scenario": "A dashboard celebrates total previews created while ignoring failed readiness, time-to-review, idle duration, and leaked resources.",
          "acceptanceCriteria": [
            "Report creation-to-ready time, ready duration, cleanup latency, failures, and declared resource cost",
            "Metrics use bounded repository and outcome dimensions",
            "Unresolved deletion remains included until reconciled"
          ],
          "implementationNotes": [
            "Do not infer developer productivity or individual performance from preview usage."
          ],
          "verification": [
            "Reconcile a mixed fixture cohort from request through deletion.",
            "Omit cleanup observations and confirm the report shows incomplete cost and lifecycle data."
          ],
          "deliverables": [
            "Preview lifecycle report and interpretation guide"
          ],
          "rollout": "Use the report to tune lifecycle policy, not rank people.",
          "skills": [
            "Operational metrics",
            "Cost attribution",
            "Responsible analytics"
          ],
          "fieldMix": [
            {
              "field": "DevOps",
              "percentage": 70
            },
            {
              "field": "Site reliability",
              "percentage": 30
            }
          ],
          "patterns": []
        }
      ],
      "id": "92882874-daf4-419f-b640-f607fe581727"
    }
  ]
}
