# Scenario framework failure patterns

Use these patterns only when supported by supplied evidence. They are diagnostic
guidance, not facts about a particular failure.

## Likely case or framework problems

- Missing or ambiguous request/response evidence inside the scenario execution
  boundary defaults to the configured case owner rather than infrastructure.
- An unresolved placeholder, missing captured value, or a reference to a value
  before its producing operation usually indicates scenario authoring or runner
  semantics rather than a product regression.
- An invalid path, unsupported field, malformed body, or expected status that
  conflicts with the current API contract is a case error.
- Ordering errors often appear as a valid later request using absent or stale
  state. Identify the first operation that failed to establish the state.
- Retry configuration must be bounded and use a non-zero delay. Immediate or
  unbounded polling can create misleading rate-limit or timeout symptoms.
- Cleanup failures after a primary case failure should not replace the primary
  diagnosis unless cleanup is the only failure.

## Likely product problems

- A valid request returns an unexpected 5xx with a product trace ID.
- A successful mutation never reaches its documented stable state within the
  scenario's valid bounded wait.
- A response is syntactically successful but violates a required contract field
  or state transition.

## Likely infrastructure problems

- Checkout, dependency setup, authentication, cloud login, runner, artifact,
  notification, or workflow-summary failures.
- Network transport errors, GitHub runner termination, credential failures, and
  service rate limits outside the scenario execution boundary.