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 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.