verify-form-validation

A rejected form still looks fine on screen

Validation code is written once, glanced at in the browser with one obviously-bad value, and never driven again. The bug that ships is never the value you tried. It's the one you didn't: a submit button that isn't disabled until the field blurs, a button that's disabled only by CSS and still clickable, or a handler that fires the request before the check finishes.

Reticle can drive the real form and check all three failure points at once. Not set up? Follow the reticle skill: it installs Reticle, asks the user before init changes the app's files, and proves one flow.

Read this before you start: the browser's own validation can mask the app's

required, pattern, type="email" and friends stop the browser at the constraint-validation bubble before your app's JS ever runs. If you assert on that native tooltip, you've verified the browser, not the code you're supposed to be testing. Confirm the error you're checking is the app's own element (a testid, a role, a rendered string), not a :invalid pseudo-state, before you trust the verdict. If the form relies on native validation alone with no app-level check behind it, that's the finding: say so, don't paper over it with a predicate that happens to pass.

Trigger the rejection

Name the consequence before you act, same as any Reticle drive:

reticle_look({ action: "page", sessionId, mode: "interactive" })   // get refs for the field and submit control

reticle_act_and_wait({ sessionId, ref, action: "fill", args: { value: "<invalid>" }, until: { kind: "allOf", predicates: [
  { kind: "element", query: { testid: "field-error" } },
  { kind: "element", query: { role: "button", name: "Submit" }, state: "disabled" },
]}})

If the check runs on blur rather than on keystroke, move focus to a different control as its own step before asserting: reticle_act({ sessionId, ref: otherRef, action: "focus" }) on the submit button or the next field, since focusing anything else is what fires the blur you need. If it's debounced instead, don't sleep for it. Use reticle_run({ tool: "reticle_clock", args: { sessionId, advanceMs } }) to advance past the debounce window exactly as in test-error-states. A fixed sleep passes on your machine and flakes in CI.

Prove nothing fired

The button looking disabled is not the same claim as the request never leaving. Don't just trust the disabled state you already asserted. Try the submit anyway, so a fake-disabled control (CSS-only, still clickable) gets caught instead of waved through:

reticle_act({ sessionId, ref: submitRef, action: "click" })

Then assert the negative. Checking count: 0 the instant after the click proves nothing on its own: the request may simply not have been sent yet. Give the app a real window to have tried before you trust the absence, settling first and then checking the count, in one call:

reticle_assert({ sessionId, since, timeout_ms: 3000, predicate: { kind: "allOf", predicates: [
  { kind: "settled" },
  { kind: "net", method: "POST", urlContains: "/api/...", count: 0 },
]}})

The timeout_ms is what makes this a wait instead of a snapshot: reticle_assert defaults to timeout_ms: 0, one evaluation at the instant you call it, so without it settled is just checked once right after the click and proves nothing about whether the app was actually idle. With timeout_ms: 3000, the call keeps polling for up to three seconds until the page genuinely goes quiet. Only once it has settled does a count: 0 reading mean anything. Use since from the click's own result, not from the earlier fill, so you're scoped to requests after the submit attempt specifically.

Clear the error

Correct the value and confirm the rejection was conditional, not permanent:

reticle_act_and_wait({ sessionId, ref, action: "fill", args: { value: "<valid>" }, until: { kind: "allOf", predicates: [
  { kind: "element", query: { testid: "field-error" }, absent: true },
  { kind: "element", query: { role: "button", name: "Submit" }, state: "enabled" },
]}})

A form that never re-enables once it has rejected something once is a second bug wearing the first one's clothes.

What to assert

Only verified: "yes" is a pass. "no" is a real finding, "unknown" means Reticle couldn't tell and needs a better capture, and "no-fault" means nothing was disproven but nothing was declared either. None of the three are evidence the form rejects bad input.

1. The error is the app's own, not the browser's native bubble.
2. The submit control's disabled state is real, not opacity/cursor styling that only looks inert. This is the same distinction design-system-compliance draws between disabled-looking and disabled.
3. Zero matching requests fired, counted, not inferred from "no error was thrown."
4. The rejection is conditional: a valid value clears the error and re-enables submit.

Honesty

A verdict here is about this field and this invalid value, not the whole form. A required-field check tells you nothing about a pattern check on a different field. If you only drove one input, say which one, and say the rest of the form is unverified rather than letting a single pass read as "the form validates."

---

Capability reference: curl https://docs.reticle.sh/capabilities.md. Everything else: curl https://docs.reticle.sh/llms.txt.