{
  "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": "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": []
        }
      ]
    }
  ]
}
