fix agent loop detected rewriting the same broken form label

fix agent loop detected rewriting the same broken form label - how to fix it

TL;DR

Break the loop by changing strategy after two failed attempts: if rewiring htmlFor does not stick, the label is probably generated by a component the agent cannot see, and the fix moves up a level to the component or its props. One line of why: rewriting the same DOM node repeatedly means the agent is fighting the renderer, and the renderer always wins.

The error, verbatim

RemediationAgentError: loop detected rewriting form label 9 times
    label: "Email" for input#email (association lost on each rerender)
    patch: set htmlFor (overwritten by component on rerender)

Fix it step by step

Step 1: Reproduce the loop

node agent/remediate.js --rule label | rg -i 'loop|rewrit' | head -5

Expected: The agent rewrites the same label every pass.

Step 2: Confirm the renderer overwrites

node -e "console.log('component rerenders input with new id each time, htmlFor points at stale id')"

Expected: The component regenerates the input id on rerender.

Step 3: Escalate to the component

rg -n 'htmlFor|label' agent/patches/label.js | head -10

Expected: Add: after 2 failed DOM patches, patch the component source (stable id via useId) instead of the DOM.

Step 4: Re-run remediation

node agent/remediate.js --rule label | tail -4

Expected: Component-level fix sticks across rerenders.

Step 5: Add a regression probe

node agent/run-audit.js --smoke | tail -3

Expected: Smoke run passes; schedule it so the breakdown is caught if it ever regresses.

When to use this skill

• You run an agent that scans UIs for accessibility and it hits this breakdown
• The agent's scan loop stalls, crashes, or loops on this exact failure
• You are hardening an audit agent's error handling for production scans

When NOT to use this skill

• A human runs the scan manually and it works, this is agent-harness failure handling
• The scan completes and only reports violations, use the rule-specific skills

Compatibility

Remediation agent with DOM and source patch primitives. Component frameworks regenerate DOM, so DOM patches are fragile. Pin the tool version in the lockfile so scans stay reproducible across machines.

Variant phrasings

agent label rewrite loop

Same loop, same escalation.

fix agent fighting rerender

Practitioner phrasing for DOM patches vs components.

the breakdown hits other routes too

Agent failure modes are systemic; apply the hardening to every route the agent covers, not just the one that failed.

Why it happens

In component frameworks the DOM is a render output, and DOM-level patches get overwritten on the next render. An agent that patches htmlFor on the DOM node watches the component regenerate the input with a fresh id and loops forever. The escalation rule is: after a small number of failed DOM patches, patch the source (give the component a stable id, wire the label there). DOM patching is for static pages; component source patching is for apps. Agent breakdowns are systemic: the same failure mode will hit every route, page, or run the agent touches. Harden the harness once (timeouts, loop detection, verification gates) instead of patching per page, and keep breakdown telemetry separate from violation counts.

Edge cases

• Cap DOM patch retries at 2, then escalate, the loop detector is the backstop, not the strategy.
• Stable ids from useId or equivalent survive rerenders, hardcoded ids collide, generated-per-render ids churn.
• If the component is third-party, the fix is a wrapper or a vendor ticket, not more DOM patching.
• Log breakdowns separately from violations in agent telemetry; mixing them hides whether the agent itself is getting more reliable.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_sO0OVsAtahfneicI49iNfA