# Scenario E2E framework triage context

This is a curated operational summary of `skills/use-scenario-e2e-framework/`.
It intentionally excludes repository inventories, credentials, generated
artifacts, and full scenario files.

## Execution boundary

- Scenario YAML is loaded by the APITestGen scenario runner during the configured
  GitHub Actions scenario step.
- A scenario contains ordered API operations. Runtime values can be captured
  from earlier responses and referenced by later requests.
- Product or case classification is only possible when the failing evidence
  belongs to the scenario execution step. Workflow setup and teardown remain
  infrastructure failures.

## Useful evidence relationships

- `scenario_yaml`, `case_id`, `operation`, and `order` locate the failing case.
- Request method, URL, body, expected expression/status, actual status, response
  body, and trace ID explain the API-contract mismatch.
- The first failed operation is normally more diagnostic than cascading cleanup
  failures.
- A response proves product behavior only when the request is sufficiently
  complete and valid for the intended API contract.

## Component grouping guidance

- Use one stable component slug for the product or framework boundary actually
  implicated by evidence.
- Do not use workflow names, scenario paths, job names, clusters, traces, run
  numbers, case IDs, or people as components.
- Use the same component for failures that would be investigated by the same
  subsystem owner, even when their surface symptoms differ.
- Use `api-testgen` for runner/parser/placeholder semantics inside an otherwise
  valid scenario execution. Use `ci-infrastructure` or a more precise CI
  component for failures outside the scenario boundary.

## Problem fingerprint guidance

- `problem_key` describes a reusable symptom or root problem in kebab case.
- Exclude run-specific values and IDs.
- Two failures may share a problem key even when observed in different product
  components, when evidence indicates the same dependency or framework issue.
- Prefer a concrete fingerprint such as `cluster-stuck-creating`,
  `unexpected-create-500`, or `missing-runtime-placeholder` over generic labels
  such as `api-error` or `test-failed`.