remediation agent stuck in loop fixing heading order
Fixes remediation agent loops on heading order by renumbering the whole outline in one pass. Use it when the agent fixes one heading and another violation appears. Not for single skipped headings, which any patch clears.
remediation agent stuck in loop fixing heading order - how to fix it
TL;DR
Fix the outline in one pass from a single scan: collect every heading violation, compute the corrected levels for the whole tree, and apply them together. Agents that fix one heading, re-scan, and fix the next loop because renumbering shifts the outline. One line of why: heading levels are relative to each other, so local fixes invalidate each other.
The error, verbatim
RemediationAgentError: heading order loop, 15 iterations
pattern: fix h4 to h3, rescan finds new skip at h5, repeat
page: docs with component-injected headings
Fix it step by step
Step 1: Reproduce the loop
node agent/remediate.js --rule heading-order | rg -i 'loop|iteration' | head -5Expected: The agent renumbers headings one at a time forever.
Step 2: Dump the full outline
npx @axe-core/cli https://example.com/docs --rules heading-order --save axe-ho.json | tail -2Expected: One scan shows every offending heading at once.
Step 3: Renumber in one pass
rg -n 'heading' agent/patches/heading-order.js | head -10Expected: Change the patch: compute all corrected levels from one outline, apply together.
Step 4: Re-run remediation
node agent/remediate.js --rule heading-order | tail -4Expected: Single pass produces a valid outline, verification passes.
Step 5: Add a regression probe
node agent/run-audit.js --smoke | tail -3Expected: 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 patch primitives. One axe scan provides the full heading outline. Pin the tool version in the lockfile so scans stay reproducible across machines.
Variant phrasings
agent heading renumber loop
Same loop, same single-pass fix.
fix agent heading order infinite
Practitioner phrasing.
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
Heading levels are globally relative: changing one heading's level changes what its neighbors should be. An agent fixing violations one at a time chases a shifting outline, especially when components inject headings at render. The correct patch takes the whole outline from one scan, computes a valid leveling (each increase steps by one), and applies all changes atomically. Component-injected headings may need the component fixed instead, if the outline shifts per render. 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
- Components that render headings need a level prop, otherwise the outline depends on page context.
- Decreases can skip levels freely, only increases must step by one, the algorithm should know this.
- Verify the outline after, not just the rule: a valid outline is the real goal.
- 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_ewqNRS4h1Z5-8D-gHm-nIA