Run your first Markdown test#

Start with the maintained sample site's fixed-save scenario. The runner validates and coordinates the work; your active agent/runtime coordinator performs actions and captures real evidence.

Verify prerequisites#

1. Complete workspace setup and build supported entries.
2. Start the sample site in an owned worktree. Keep its process running and record the exact printed URL, including any prefix.
3. Configure an adopting project's runtime using the canonical runtime configuration and installed capability checks.
4. Establish a fresh-agent mechanism, a new isolated context per attempt, available screenshot/video capabilities, and reviewed export policy. The sample requires screenshots; video defaults are overridden by its root section except where a leaf strengthens them.

Do not declare newBrowserContexts: true for tabs sharing storage. Current T3 preview alone cannot satisfy product browser-test isolation. API/CLI tests need fresh agents and durable diagnostics but no browser context.

Inspect and select#

These commands run from the SnagBadger checkout. Replace runtime/output paths with your project's real configuration and a new directory:

node tooling/testing/plan.mts inspect --catalog examples/test-plans/sample-site
node tooling/testing/plan.mts start --catalog examples/test-plans/sample-site --output <new-run-directory> --runtime <project>/testing-runtime.json --ids catalog:profile/persistence/fixed/sample-profile-persistence-fixed-save-roundtrip

Keep start in a persistent terminal session. The output directory must be new. The inherited hooks open the agreed sample URL and set the correct mode; communicate the URL to the coordinator rather than guessing a port.

Service the bridge#

Use the run-test-plan skill with the configured runtime. The coordinator obtains pending work with next, delegates a fresh worker for the attempt, targets the owned isolated context, saves evidence, and sends validated progress/complete responses. Bridge request/response contracts describe this exchange.

The filesystem bridge is not a standalone unattended browser runner. If the coordinator is absent, the command waits for responses. A runtime capability failure or unreachable host should be recorded as blocked/incomplete, not treated as a passed test.

Observe and review#

The fixed scenario should retain Morgan Lee across Overview → Profile. Record actual values, actions and the required screenshot; simulated prototype evidence cannot substitute for that proof. The checkpoint retains the attempt before the next test starts.

After text and attachments have been reviewed, open the generated HTML run report. If policy is missing, results remain structured and reporting is needs-review; configure policy and run:

node tooling/testing/plan.mts report --output <run-directory> --runtime <project>/testing-runtime.json

Continue with result review. When ready to demonstrate a known failure, select a buggy-mode test deliberately; failure is the expected product observation, not a reason to erase evidence.