discover

Explore the running app and record verified selectors in discovery.md.

Usage

/verefi:discover [--name <run-name>] [--url <base-url>]

What this does

Read test-plan.md, drive the real app with agent-browser to confirm the elements each test case relies on actually exist, and write what you found to discovery.md. This closes the gap testplan can't close on its own — testplan never looks at the live app, so its Implementation Notes selectors are educated guesses, not verified ones. In one real run, skipping this step produced a 15-test suite that failed 14/15 on a selector that was never real; running discovery first and using its output brought the same test cases to 6/6 passing. That's the entire point of this skill — don't let it be optional in spirit even when it's optional in the pipeline.

Run name

<name> defaults to the sanitized current git branch (same rule as every other stage), with --name as an explicit override:

name=$(git branch --show-current 2>/dev/null | sed 's/[^a-zA-Z0-9._-]/-/g')
if ! [[ "$name" =~ ^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$ ]]; then name=default; fi

If --name is supplied, reject it unless it exactly matches ^[A-Za-z0-9][A-Za-z0-9._-]{0,63}$. Do not sanitize an explicit value. Validate it before reading or writing any .verefi/<name>/ path and use it only as a session name after validation.

Inputs

• Required: .verefi/<name>/test-plan.md — read the Test Cases section for elements to verify, and Implementation Notes for the default Base URL
• Optional: .verefi/<name>/audit.md — static selector inventory from /verefi:audit. When present, discovery becomes targeted verification, not blind exploration: confirm audit's inventory rows for the elements the test plan needs first (fast — you already know what to look for), then spend the remaining effort on what only a live run can show — multi-step flows, per-role behavior, elements audit found no evidence for.
• Optional: --url overrides the Base URL from the test plan (e.g. if the app is running on a different port right now)