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