Configure hooks and isolated attempts#

Hooks prepare fixtures around execution. Browser isolation prevents one attempt's cookies/storage from contaminating another; hooks restore application/backend state that browser isolation cannot reset.

Choose the correct lifecycle#

Hook phase	Scope	Suitable use
beforeRun / afterRun	Root section only	Start/stop a shared disposable environment
beforeSection / afterSection	Selected section entry/exit	Allocate/remove section fixtures
beforeEach / afterEach	Each attempt	Authenticate its own context and reset test data

Setup proceeds root-to-leaf; cleanup reverses order and is attempted after setup/test errors. Context creation precedes per-test hooks; supported video starts before those hooks. Cleanup must tolerate partial initialization and a null browser when creation failed.

Declare trusted work#

Each hook has a unique ID and exactly one function registry name or instruction. Function names are references, not inline executable YAML. For example:

hooks:
  beforeEach:
    - { id: authenticate, function: authenticateUser }
  afterEach:
    - { id: cleanup, function: removeFixture }

Resolve those names in a trusted project module. It receives run/test/section/session context, shared fixture state, and browser actions when available. Credentials stay in the executing environment. Canonical hook guidance includes bindings, overrides and review-policy configuration.

Verify isolation#

The runtime must create a unique isolated browser context per attempt and target every action/capture to it. New tabs in one profile share cookies/local storage and are insufficient. Probe with disposable same-origin markers and clean them up before claiming support.

A section login does not carry into new per-attempt contexts. Re-authenticate each attempt or install project-owned state through an explicit hook. Release owned pages/contexts honestly; page closure is not always full context disposal.

Current T3 preview tabs share storage. Use them to observe repository implementation, not to assert product-runtime isolation. Runtime mappings explains supported adapter responsibilities and live-tool verification.

See configuration reference for the division between catalog settings, runtime capabilities and report-review policy.