# Observed test support

Use this reference when approved scenarios need authentication, fixtures, lifecycle
hooks, worker actions, fixture lookup, environment access or cleanup. Read
[the test-support integration guide](../../../../docs/integration/test-support.md)
for the repository-local helper contracts and approved verification adapter.

1. Map each approved scenario and revision to its required support. Keep existing
   run/section resource setup distinct from authentication in `beforeEach`, after
   the attempt's fresh context exists. Include an actual worker API/CLI/tool and
   fixture lookup mechanism; the lifecycle function registry and `HookContext.shared`
   provide local runner state only.
2. Call `inspectTestSupport` through `tooling/onboarding/test-support.mts` with
   current application/environment/revision, approved catalog scenarios, bindings
   and selected runtime. Discovery inspects metadata only. Importing host modules
   requires separate explicit approved verification scope; inspect actual approved
   exports once loaded. Complete when every required binding has a visible status.
3. For missing custom support, obtain the runtime user's consent for that specific
   integration before starting host changes. Preserve authored configuration,
   show the concrete final diff, and obtain final approval. Keep declined or pending
   integrations blocked. Account provisioning, deployment and production mutation
   remain separately authorized host workflows.
4. Review disposable verification operations, selected environment/runtime and
   affected scenarios. After approval, call `verifyTestSupport` with the current
   review ID, approval evidence and each integration's consent/final approval.
   The host's probe must exercise actual worker access using existing run/attempt
   identifiers and confirm authentication in the exact packet session. Complete
   when operations, lookup, failure handling and cleanup have observed results.
5. Record only reviewed nonsecret identifiers and evidence pointers in the existing
   onboarding scratchpad. Keep credentials, endpoint secrets, operation responses,
   session handles and errors in the authorized host environment. Record environment
   limitations separately; disposable fixture proof does not prove native runtime
   behavior that was unavailable.
6. Offer execution of approved `observed-ready` scenarios through the existing
   runner. Leave missing/pending/blocked scenarios visibly blocked and continue
   ready API/CLI work if browser isolation is unsupported. Preserve the selected
   runtime; a new tab is not a fresh context. Refresh verification after relevant
   scope/revision changes. Support failures are setup failures; only scenario
   execution establishes an application bug.