HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

Unknown

Conceptio › Archive › arXiv CS

arXiv CSopen access

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

Unknown · 2026 · arxiv_cs

arXiv CS · Papers · License: Open Access · 2026

Open Source ↗Direct PDF ↓

softwarearchitecture softwareengineering testing

software engineering, software architecture, testing

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

arXiv:2605.26807v1 [cs.SE] 26 May 2026

Jiajun Wu1 , Jian Yang1 , Tuney Zheng2 , Wei Zhang1 Haowen Wang2 , Yihang Lou3 , Xianglong Liu1 1 Beihang University 2 IQuest Research 3 Peking University

Abstract LLMs can now produce full HTML pages, but many of those pages are only superficially correct: they render once, then fail under scroll, hover, click, resize, or gameplay. Evaluation from screenshots can miss these failures, and filtering discards many pages that are still repairable. We introduce HTMLC URE, a browser experience framework that evaluates HTML after the system has interacted with it. The evaluator executes the page across viewports and interaction states, records deterministic browser evidence, and gives the VLM curated keyframes from the executed trajectory rather than isolated screenshots. The same state signal drives a closed loop repair engine: HTMLC URE diagnoses the current page, chooses a state specific repair family, runs each candidate again, and exports quality cleared pages for SFT. On a 97K prompt corpus, this expands the directly usable seed into a candidate pool of 63,703 quality cleared pages, from which we construct the final refined SFT set of 40K pages. Under the same backbone and training recipe, HTMLCure-27B-Refined reaches 50.6 on HTMLB ENCH-400 with 45.2% deterministic test case pass, placing it in the same performance band as strong reference rows such as Kimi-K2.6 and GPT-5.4. On the released MiniAppBench validation split, it reaches 81.2 average, improving raw 27B SFT by 15.3 points and approaching the level of strong reference systems. Quality Result

Game Before Multi-Layer Experience

Game After Evidence-Gated Repair

HTMLCure Static Observation

Score 3 JS errors

Broken HUD

No rendering

No interact

Structured Evidence VLM Judge

Score Zero errors

Full gameplay

Keyboard OK

Responsive

Figure 1: Problem setting and full pipeline objective. HTMLC URE evaluates interactive HTML through browser traces, routes repair by current page state, and exports only quality cleared pages into the refined SFT candidate pool.

Introduction

LLMs can write frontend code at scale, but the generated HTML often looks acceptable in the first screenshot and then fails under use. In our 97K prompt corpus across six semantic task families, only about 15% of Kimi-K2.5 pages are directly usable under the browser gate. The rest fail through inert controls, stalled game logic, broken responsive layouts, missing content, or export gate violations. Preprint.

Filtering removes these pages before testing whether they are recoverable. For data construction, this is a state estimation problem rather than only a scoring problem: a static screenshot or sparse visual trace can hide failures that appear only after hover, click, scroll, resize, or gameplay, leaving the repair loop with a weak basis for choosing among rewrite, local repair, and preservation. Table 1 shows the practical consequence: Low pages usually need broad replacement, Mid pages are better served by diagnosis guided local repair, and High pages should mostly be preserved.

Table 1: Repair action depends on current page state. “Local fix” groups diagnosis guided actions that do not rewrite the page. Success means ∆ ≥ 5; catastrophe means ∆ ≤ −10.

Local fix Rewrite Policy We propose HTMLC URE, a state aware repair and State data construction framework built around this sig- Low (< 40) 92%, +9.1 90%, +14.2 Rewrite nal. HTMLC URE first experiences an HTML page Mid (40–79) 95%, +11.3 92%, +8.3 Diagnose through the browser by rendering it, changing view- High (≥ 80) 0%, −0.2 17% cat., −2.7 Refine ports, exercising controls, and probing deeper states when needed. The VLM judges curated keyframes from that trajectory. The novelty is not browser evaluation alone; prior benchmarks already use browser interaction. The contribution is to make the executed trace operational: the controller diagnoses the current page, selects a state specific repair family, runs each candidate again, and keeps candidates that pass the same quality gate. Figure 2 shows the full loop. HTMLB ENCH in section 4 exposes the deterministic browser execution slice for reproducible comparison, while accepted repair traces become the refined SFT pool. Section 5 tests this data route under the same backbone and training recipe, with the released MiniAppBench validation split as an external check.

This leads to three contributions: (1) Browser experience as a repair state signal. HTMLC URE turns browser evidence into a structured page state that bounds VLM visual judgment and drives repair decisions. (2) State aware interactive repair. The experienced state determines the repair family: rewrite weak pages, diagnose partially working pages, and preserve pages that are already strong. The controller runs candidates again and screens out repairs that regress under the quality gate. (3) Repair as data construction. Accepted repairs expand the original High subset into a larger refined SFT corpus. Under the matched SFT recipe, the final 27B model reaches 50.6 on HTMLB ENCH-400 with 45.2% deterministic test case pass, putting it in the same range as Kimi-K2.6 and GPT-5.4, and reaches 81.2 average on the released MiniAppBench validation split, 15.3 points above raw 27B SFT.

Multi Dimensional Experiential Evaluation Pipeline

HTMLC URE evaluates an HTML page as an artifact that must run in a browser. The evaluator loads the page, changes the viewing context, exercises common interactions, and records the resulting evidence before any visual judgment is made. Figure 2 places this evaluator at the front of the pipeline. The output is not only a scalar score: it is an ordered experience trace that exposes the current page state and later drives repair routing. 2.1

Design Philosophy

A screenshot based view reduces the page to single step visual observation, ŷ = f I(s1 ), . . . , I(sk ) ,

(1)

where s1 , . . . , sk are sampled browser states, I(si ) is the rendered frame at state si , and f is typically a visual judge. This view is useful for screenshot fidelity, but it leaves out failures that appear only after use. A page can render cleanly while click handlers fail, mobile layout breaks, animations stall, or console errors appear after a state change. We instead evaluate the page by executing an action sequence before visual scoring. Let h denote an HTML artifact and let π = (a1 , . . . , aT ) denote a sequence of viewing and interaction actions. The evaluator produces E(h, π) = {et }Tt=1 , et = (vt , bt ), (2)

Input

User Prompt Static Analysis

Refinement Rewrite

Diagnosis & Triage

fail

Keyframe Selector

Evidence Gate Feedback Loop

LLM Repair Generation

Best HTML Output 97k

L4: Responsive 8-12 annotated keyframes

pass

HTML Extract

L1: Visual Observe L2: Active Interact L3: Deep Gameplay

Deterministic Probes Test Runner

Output

Patch

seed plan

LLM Code Generation

Evidence-Gated Repair Loop

Experiential Evaluation

Annotated Keyframes

Quality Filtering

Scoring & Evidence Aggregation

4-Layer Experience Protocol

fuse signals

Observer Auditor Scorer VLM Multi-Agent Scoring

Multi-Dimensional Score Report

40k

Evidence Pool

Training Dataset

Figure 2: HTMLC URE pipeline. The evaluator gathers browser evidence and curated keyframes, the controller chooses a state specific repair family, and the export stage adds quality cleared pages to the refined SFT candidate pool before the final training export. where vt records visual evidence such as rendered frames, viewport snapshots, and frame differences, and bt records behavioral evidence such as probe outcomes, DOM state, latency, and console state. The output is an ordered trace, not a small screenshot set. The visual component is judged from curated states after execution, while the deterministic probes keep the behavioral record explicit. The same trace supports repair because it localizes where the page failed, whether a later edit regressed, and what state the controller should act on in Section 3. 2.2

Four Layer Experience Protocol

The protocol has four layers. Layers 1 and 2 cover ordinary use first: loading behavior, motion, layout under different device views, content below the fold, prominent controls, hover states, keyboard bindings, and scroll triggered behavior. These checks answer the question that matters before aesthetics: does the page render and respond under normal use? When early evidence suggests deeper interactivity, Layer 3 runs a short task driven rollout so game states, counters, canvas changes, and multi step UI transitions remain visible to the evaluator. Layer 4 selects representative keyframes from the same run and attaches event context. The visual scorer sees the page through this executed trajectory rather than through unrelated still images. 2.3

Five Component Scoring

We assign each page a five component score: X sd (h) = gd E(h, π) , S(h) = sd (h),

D = {rend, vis, func, inter, code}.

(3)

d∈D

Table 2 gives the public HTMLB ENCH scoring profile used in the final experiments. The mapping gd specifies how each dimension reads the trace. Coverage is recorded only as execution metadata; it is not a score dimension. Most points come from browser execution, deterministic test cases, or static checks; the VLM is reserved for visual design over curated states. Equation (3) makes this split explicit. Rendering, Table 2: HTMLB ENCH scoring profile. Coverfunctionality, interactivity, and code quality are age is metadata, not score. computed from browser execution or static analDimension Inter. Non-int. Evidence ysis; visual design is the only component assigned 10 10 Browser health through the VLM path. This path is bounded. An Rendering 20 20 VLM keyframes Analyst observes screenshots and probe evidence, Visual Design 55 65 Frozen TC pass while a separate Scorer receives no screenshots and Functionality 10 0 Browser probes assigns the visual component from the structured Interactivity Code Quality 5 5 Static pass report plus objective metrics under deterministic 100 100 Hybrid decoding. Implementation guardrails reduce visual Total credit for horizontal overflow, missing viewport support, broken mobile layout, or absent styling. For noninteractive prompts, the interaction budget moves into functionality, so a static dashboard is not penalized for lacking controls it was never asked to provide. The scalar S(h) sets the page state for repair, and the vector (sd (h))d∈D points to the dimension that limits the page. Leaderboard rows are therefore interpreted through the full evidence bundle: total score, deterministic test case pass rate, component scores, and the external MiniAppBench result. 3

2.4

Cost Control and Tiered Gating

HTMLC URE does not run every expensive probe on every page. A static pass removes malformed or trivial pages and collects code quality evidence. Layers 1–2 run on all remaining pages. Layer 3 runs only when earlier evidence indicates deeper interaction, and the visual scorer receives curated keyframes from Layer 4. Mid pages receive a diagnostic branch because routing decisions are hardest in that band. This keeps evaluation affordable while preserving state information needed by repair.

State Aware Interactive Repair Engine

The repair stage is where the experience trace becomes an intervention policy. A trace contains rendered states, interaction outcomes, console and probe evidence, device views, and curated keyframes. HTMLC URE feeds this record to a repair controller before any generation call. The controller is not a generic regeneration prompt over source code or a screenshot. It first decides how much of the current page should be trusted, chooses a state specific edit family, and runs each candidate again before an accepted checkpoint can enter the refined pool. Figure 2 shows this controller branch between evaluation and export. The first decision is how much of the current implementation to trust. A low scoring page often has no reliable local target and is better handled by replacement. A mid scoring page usually contains usable structure mixed with broken behavior, which makes diagnosis guided patching viable. A high scoring page is treated conservatively because broad rewriting can destroy working interaction. The VLM contributes contrastive before/after evidence, but the controller grounds each action in the full browser trace: probes, test failures, console state, device views, and curated visual evidence. 3.1

Experienced State → Strategy Selection

Let s = S(h) be the current score of page h, let s(h) = (sd (h))d∈D be the component score vector, and let D(h) be the structured diagnosis produced from the executed trace. The routing function σ maps this experienced state to a repair family:  s < 40, HolisticRewrite, σ(D, s) = Rewrite or InteractionTargetedFix(D), 40 ≤ s < 80, (4)  Preserve or TargetedRefine(D), s ≥ 80. D(h) is a structured controller input rather than a free form rationale. It contains failed test case identifiers, requirement statuses, component scores, render and console failures, responsive keys, button and form probe outcomes, gameplay or canvas evidence when present, keyframe annotations, and repair history. The controller used in our experiments is a fixed rule system over this record, not a learned policy. The 40 and 80 thresholds define the Low/Mid/High operating states used throughout the data funnel, and the 97 threshold is an export oriented early stop target. Within each band, observed failures bind the route to an admissible operator family. The score bands turn the trust decision into a routing rule. Low pages are routed toward replacement because local edits rarely have a stable target. Mid pages keep access to both rewriting and diagnosis guided repair, since they often combine usable layout or logic with broken interactions. High pages are preservation cases: the default action is to keep the current checkpoint after rerunning the page, and small additive refinement is allowed only for a localized low risk defect. Thus, the trace is not passive evaluation output; it is the control state that determines which edits are allowed. 3.2

Closed Loop Repair and Contrastive Feedback

Repair proceeds in short rounds. At round t, the system executes the current page ht , forms the state summary (S(ht ), s(ht ), D(ht )), selects an admissible operator family, and prompts the LLM to produce up to two candidates Ct . The small candidate budget keeps repair as a controlled edit process, not a search over many samples. The next state is chosen by ht+1 = arg ′ max Scomp (h′ , ht ), (5) h ∈Ct ∪{ht }

where the inclusion of ht lets the controller keep the current page when all proposals score worse. The composite score Scomp (Equation 7) penalizes regressions across dimensions instead of accepting a 4

candidate only because one component improved. Candidate acceptance requires another browser run under the same protocol. Each round also uses Contrastive Visual Feedback: the VLM compares curated keyframes from ht and h′ , then reports improved regions, regressions, and unchanged regions. The next prompt receives this visual diff together with deterministic browser evidence, so the LLM sees the concrete before/after trajectory that its previous edit produced. 3.3

Constrained Strategy Space

The admissible operator sets differ by state: ΩLow = {HolisticRewrite, FeatureCompletion, GameRepair}, ΩMid = {Rewrite, BugFix, PlayabilityRepair, InteractionTargetedFix, GameRepair, VisualEnrichment}, ΩHigh = {NoOpVerify, VisualPolish, InteractionEnhance, FunctionalityRefine, CodeCleanup}.

(6)

Within each set, D(h) binds observed failures to specific operator families. Console or probe failures activate bug fixing; broken keyboard or mouse bindings activate playability repair; stable logic with weak presentation activates visual enrichment. Game repair is used when the trace shows that the interactive scaffold is worth preserving. The High state set is narrow because strong pages are more likely to be harmed by broad edits than helped by them; in this band, verification without editing is a valid controller output. 3.4

Regression Aware Acceptance and Termination

Interactive repair can improve one dimension while damaging another. HTMLC URE ranks candidates with a regression aware objective rather than raw total score: X wd · max 0, sd (h) − sd (h′ ) , (7) Scomp (h′ , h) = S(h′ ) − d∈D ′

where h is the current page and h is a repaired candidate. Functionality and interactivity receive larger regression weights because failures in these dimensions are most visible during actual use. This objective is used in Equation 5, so an edit must survive another execution rather than win through a one sided gain in visual quality. A trace stops when the page reaches a high target score (s ≥ 97), when recent iterations show small or negative gains under the patience rule, or when the eight round budget is exhausted. Crossing 80 changes the admissible family from repair to refinement, but it does not stop the loop. High scoring pages stay under operators that preserve the working implementation.

HTMLB ENCH: Deterministic Browser Executable Evaluation

Table 3: HTMLB ENCH task family composition. HTMLB ENCH is a standalone benchmark for single file interactive HTML generation. It is built to measure whether Task family Items TCs Subtypes a generated page renders, satisfies prompt grounded re- Apps & Tools 105 1,688 18 quirements, responds to user actions, adapts across view- Content & Marketing 110 1,660 16 ports, and maintains visual quality. The frozen release Data Visualization 35 588 7 55 682 9 contains 400 item ids with category metadata, scored test Games & Simulations 20 328 4 cases, weights, and browser action sequences. Table 3 3D/WebGL Scenes 75 1,054 11 gives the six user facing task families. The items cover 65 Visual Art & Animation 400 6,000 65 subtypes, 122 easy, 156 medium, and 122 hard prompts; Total 338 tasks require interaction because the benchmark is designed for pages that must respond under use, not only for static screenshot fidelity. Each scored test case is a deterministic browser program built from actions such as click, type, hover, key press, resize, screenshot change check, JavaScript assertion, and visibility check. Test cases are prompt grounded and avoid selectors, class names, frameworks, hidden source code assumptions, real credentials, payments, and private services that are specific to one implementation. A page’s functionality score is the weighted pass rate over the frozen 6,000 test pool; coverage is kept only as execution

Table 4: Main results on HTMLB ENCH and the released MiniAppBench validation split. MoE sizes report total and active parameters when disclosed; equal size SFT controls appear only in Table 6. Model

Size

HTMLB ENCH-400

MiniAppBench-Val

Score TC Pass (%) Rend. Vis. TC/Func. Inter. Code Intent Static Dyn. Avg. Open source models Kimi-K2.6 1TA32B 49.8 43.7 8.7 10.8 24.8 1.2 4.1 92.2 85.6 78.9 85.5 Kimi-K2.5 1TA32B 49.4 42.5 9.1 11.2 24.1 1.1 4.0 89.6 82.9 76.2 82.9 GLM-5 744BA40B 49.2 41.9 8.9 11.2 23.7 1.3 4.0 90.9 81.0 74.2 82.0 DeepSeek-V3.2 685BA37B 48.8 42.8 8.5 10.5 24.3 1.4 4.1 89.8 81.2 75.1 82.0 GLM-5.1 754BA40B 48.6 39.6 9.2 11.7 22.5 1.2 4.0 92.8 87.0 83.6 87.8 GLM-4.7 358BA32B 47.7 40.7 8.9 10.6 23.1 1.1 4.1 88.8 82.2 73.0 81.3 Qwen3.6-27B 27B 47.1 38.1 9.3 11.0 21.6 1.1 4.0 91.7 84.5 76.8 84.3 Qwen3.6-35B-A3B 35BA3B 46.3 37.4 9.3 10.8 21.2 1.0 4.0 90.0 83.1 72.2 81.8 Qwen3.5-122B-A10B 122BA10B 45.6 38.0 9.0 10.0 21.5 1.0 4.1 87.2 80.7 77.8 81.9 Qwen3.5-397B-A17B 397BA17B 45.6 37.3 9.2 10.1 21.1 1.1 4.1 84.4 77.3 61.7 74.5 Qwen3.5-27B 27B 45.5 38.4 8.7 9.8 21.8 1.1 4.0 87.6 73.7 68.3 76.5 Qwen3.5-35B-A3B 35BA3B 45.2 37.7 9.0 9.8 21.3 1.0 4.1 82.9 74.3 59.0 72.1 DeepSeek-V4-Flash 284BA13B 44.5 35.7 8.5 10.7 20.3 1.1 3.9 90.1 82.0 83.1 85.1 MiniMax-M2.5 229BA10B 44.5 36.9 8.9 9.8 20.9 0.9 4.0 90.0 83.2 76.3 83.2 Qwen3.5-9B 9B 42.9 35.1 8.9 9.1 19.9 0.9 4.0 73.3 63.2 30.7 55.7 Qwen3.5-4B 4B 41.7 35.4 8.7 8.5 19.6 0.9 4.0 67.2 57.2 20.3 48.2 Closed source models GPT-5.4 49.2 42.7 8.8 11.0 24.2 1.0 4.2 90.8 86.5 85.6 87.7 Claude-Opus-4.7 47.8 39.8 9.2 11.1 22.6 1.0 3.9 89.7 83.3 85.9 86.3 Claude-Opus-4.6 47.5 39.3 9.2 11.0 22.3 0.9 4.1 87.3 81.8 81.9 83.7 Claude-Sonnet-4.6 46.6 37.2 9.4 11.1 21.1 1.0 3.9 87.9 83.4 80.8 84.0 Gemini-3.1-Pro 45.4 37.0 8.9 10.5 21.0 0.9 4.0 84.3 78.8 78.3 80.5 Claude-Opus-4.5-20251101 43.9 38.5 8.8 8.9 21.8 1.0 3.3 88.0 82.2 77.8 82.7 HTMLCure SFT models HTMLCure-4B-Raw 4B 42.8 39.5 8.2 9.1 20.7 1.0 3.8 66.2 58.4 29.3 51.3 HTMLCure-4B-Filtered 4B 45.1 37.5 9.1 9.6 21.3 1.0 4.1 69.8 60.0 27.2 52.3 HTMLCure-4B-Refined 4B 46.5 40.9 8.9 9.7 22.7 1.2 4.0 72.5 63.4 29.0 55.0 HTMLCure-9B-Raw 9B 43.0 41.4 8.0 8.9 21.3 1.0 3.8 72.1 59.3 20.3 50.6 HTMLCure-9B-Filtered 9B 45.8 40.3 8.7 9.6 22.4 1.1 4.0 73.7 63.9 27.1 54.9 HTMLCure-9B-Refined 9B 48.5 42.1 9.2 10.2 23.9 1.1 4.1 76.5 65.0 28.1 56.5 HTMLCure-27B-Raw 27B 45.8 42.6 8.4 10.0 22.7 0.9 3.8 76.0 64.8 56.7 65.9 HTMLCure-27B-Filtered 27B 48.1 40.8 9.3 10.5 23.1 1.1 4.1 78.6 69.7 61.2 69.9 HTMLCure-27B-Refined 27B 50.6 45.2 9.1 10.7 25.6 1.1 4.1 87.8 81.1 74.6 81.2

metadata. The full leaderboard score remains hybrid because visual design uses the bounded VLM path from section 2, while TC pass reports the deterministic browser test slice. The benchmark files pass a strict schema validator and a benchmark quality audit for duplicate evidence, shallow visual checks, and cross template leftovers. An exact normalized prompt check finds no HTMLB ENCH prompt duplicated in the 91,484 traced repair records used for the SFT data analysis. Compared with agent based evaluation [24], HTMLB ENCH provides reproducible, multi dimensional HTML quality measurement with localized browser level failure records.

Experiments

5.1

Experimental Setup

The experiments test whether repair from Table 5: Refined pool. browser experience creates better supervi- State Traces Reject Partial Export Share sion for SFT, rather than only higher page Low (< 40) 15,686 5 (0.0%) 7,205 (45.9%) 8,476 (54.0%) 13.3% scores after repair. We use one browser Mid (40–79) 62,012 10 (0.0%) 11,121 (17.9%) 50,881 (82.1%) 79.9% 0 (0.0%) 4,346 (31.5%) 6.8% crawled prompt corpus and construct three High (≥ 80) 13,786 9,440 (68.5%) SFT routes from it. Raw keeps valid gen- Filter baseline 13,786 High pages 63,703 pages (+49,917); 40K train export erated pages, Filtered keeps the original Refined pool High subset, and Refined uses the final 40K export accepted after browser experienced repair. The routes use the same prompt response format and are evaluated with the same HTMLB ENCH runner and the released MiniAppBench validation split; the changing factor is how the HTML supervision is constructed. Table 5 gives the refined pool funnel, while Appendix D.1 gives the extraction counts, state definitions, MiniAppBench protocol, and training configuration. The funnel rules out a simple filtering story: most exported pages come from repaired Low and Mid states, while High pages mainly serve as a preservation check. Figure 3 gives the corresponding distributional view, showing that repair shifts the corpus upward rather than only selecting already good pages.

mean 58.9 -> 82.4

High

3D/WebGL Data Viz

Density

High Mid

Content Visual/Anim. Games/Sim.

Mid Low

Low 0

Score

100

Original

Final

Apps/Tools 0

Avg score lift by task family

Figure 3: Corpus level repair effect. Panel A compares the score density before and after repair, Panel B shows how traces migrate across the Low/Mid/High state bands, and Panel C reports mean lift by semantic task family. Taken together, the three views show a broad upward redistribution rather than a thin threshold effect. 5.2

Main Results

Table 4 is the main downstream test. We fine tune Qwen3.5 4B, 9B, and 27B checkpoints [13] with the same LlamaFactory recipe and prompt response format; Raw, Filtered, and Refined differ only in the source of HTML supervision, with Refined using the final 40K export cleared by the repair gate. On HTMLB ENCH-400, Refined leads the Raw/Filtered/Refined comparison at every scale, and HTMLCure-27B-Refined reaches 50.6 with 45.2% deterministic test case pass. These two numbers should be read together: the total score includes the bounded visual component, while TC pass is the deterministic browser slice. On the released MiniAppBench validation split [24], the same model reaches 81.2 average, 15.3 points above raw 27B SFT. The main result is therefore the controlled route comparison: repair from browser experience turns weak and partial pages into verified supervision that improves the same backbone under the same training recipe. The reference rows provide model family context, not the causal evidence for the method. 5.3

Ablation Study

We next separate the amount of supervision Table 6: Equal size controlled ablation with 12,392 from the kind of supervision produced by re- examples per route. pair. Raw, Filtered, and Refined are matched to Run Scale Data Score TC Pass (%) MiniApp the same training count and retrained with the 9B Raw 41.9 37.8 53.7 same recipe at 9B and 27B. Table 6 reports this A1 A2 9B Filtered 45.1 37.0 55.2 matrix; A1–A6 are only compact run identifiers. A3 9B Refined 47.5 40.9 55.1 The matched comparison keeps the data count A4 27B Raw 45.0 41.2 62.5 41.0 71.8 fixed and leaves the repair route as the changing A5 27B Filtered 48.2 43.7 75.1 factor. At 9B, Refined leads the matched routes A6 27B Refined 49.9 on HTMLB ENCH score and pass rate, while MiniAppBench remains essentially tied with Filtered. At 27B, Refined leads the matched routes on both benchmarks under the same training count. This shows that browser experienced traces carry stronger supervision, not only more examples: pages interacted with, repaired under state specific control, and verified again still train the higher scoring model at matched corpus size.

Analysis

6.1

State Controls Repair Choice

We analyze 592,830 repair attempts over 91,484 pages to isolate how browser experience guides routing. A page with no stable structure, a page with broken controls, and a page that already passes most checks expose different repair risks. Table 7 shows the consequence: the useful action family changes with the state observed by the browser trace. Table 7: State aware repair utility. “Best route” reports the highest lift action family in each state before repair; the rewrite columns show what happens when rewrite is used outside its useful regime. State

Best route

Low (< 40) Mid (40–79) High (≥ 80)

Holistic rewrite Interaction fix Targeted fix

∆

Success

Cat.

Rewrite ∆

Rewrite cat.

+14.2 +11.3 -0.2

90.0% 95.4% 0.0%

0.6% 0.1% 0.0%

+14.2 +8.3 -2.7

0.6% 0.4% 17.0%

35,822 324,880 232,128

Policy Rewrite weak pages Diagnose then repair Conservative refine only

State x Family

Policy Frontier

Task-Family Lift 3D/WebGL

Rewrite

cat 100%

cat 0.5%

Expected lift

cat 0.5%

Interaction fix

cat 1.4%

cat 0.1%

cat 0%

Data Viz

Content

4 Visual/Anim.

3 2

Targeted fix

cat 0.9%

cat 0.4%

cat 0%

Low

Mid

High

State before repair

Games/Sim.

Rewrite

+0.88 | 39.4%

0.1%

0.2%

Catastrophe rate

0.3%

Apps/Tools

0.4%

Mean lift

Figure 4: Policy diagnostic for state aware repair. The figure compares action utility, fixed policies, and state aware routing across page states and task families. Low pages are usually too incomplete for local patches, so broad rewriting has room to help. Mid pages already contain usable structure, and interaction repair gives a larger and safer local correction than rewriting the whole page. High pages are the preservation regime: their main risk is regression, not missing recovery. This is the first reason the controller cannot be reduced to a single generic repair prompt. Figure 4 turns the operator table into a policy diagnostic. Fixed targeted repair is safe but leaves many weak pages unrecovered. Fixed rewrite captures weak page recovery but pays for it on pages that should not be rewritten. State aware routing keeps the recovery side of rewrite while avoiding the high risk region for already working pages. Panel C is a useful sanity check rather than a separate claim: the lift varies by task family, but the preferred routing pattern remains stable enough to support one state conditioned controller. 6.2

Interactive Value and Checkpoint Retention

State choice is only part of the mechanism. The repair loop also has to decide which candidate to keep. Figure 5 shows why HTMLC URE exports the best verified checkpoint rather than the last candidate produced by the editor. 82.4

60% 40% 20% 0% Input R1

+2.5

68.5

Current score Peak score

58.9 60 R2

R3 Low

R5 Mid

R7 High

Repair Round

bars: cumulative lift line: High-state rate

80%

High-state rate

80%

Cumulative score lift

80%

79.8

Mean score

Share of samples

100%

60%

40% 10

20%

5 0

Repair Round

Figure 5: Iteration level repair value. The figure shows how retained checkpoints improve over rounds, why best checkpoint export matters, and where repair gains saturate. Panel A shows the population moving from Low and Mid toward High once the controller finds a useful path. Panel B is the main export diagnostic: after the early rounds, the current candidate can lag behind the retained checkpoint, so a "take the final edit" rule would discard verified gains. Panel C explains the stopping behavior. Most usable lift arrives early, but weaker pages still need a short tail of search. This keeps the claim calibrated: the value is not that every edit helps, but that browser re-execution lets the system reject regressions and export only cleared checkpoints. Figure 6 is a scope check. The task families fail in different ways, so the useful diagnostic is not a single mean lift. The figure shows that repair is not confined to one family, while also making clear that higher score does not automatically imply export. The score band accounting behind this view is defined in Table 8; the SFT export gate remains the one reported in Table 5. Together with the data funnel in Table 5 and the corpus shift in Figure 3, these diagnostics give a compact mechanism story. Browser experience identifies the page state, state determines the repair family, and repeated execution protects the best recovered candidate. The main evidence for the method is the coupling between state aware routing, checkpointed export, and the downstream SFT

Mean lift Success % Eligible %

Data Viz

+28.0

Content

+25.9

Visual/Anim.

+23.6

Games/Sim.

+22.7

Before After

Apps/Tools 40

+13.6 60

Mean score before/after repair

Score improvement

+34.4

3D/WebGL

95%

37%

Data Viz

89%

74%

Content

84%

72%

Visual/Anim.

86%

73%

Games/Sim.

89%

72%

Apps/Tools

73%

71%

20 10

. ntent GL Viz Tools Sim. AnimC o Data3D/Web Apps/ Games/Visual/

Figure 6: Repair scope across semantic task families. The figure summarizes score gains, lift distributions, and final SFT eligibility by task family. gains in Tables 4 and 6; the family level patterns serve as coverage checks rather than a separate causal claim.

Related Work

Web Agents and Browser Interaction. Language agent work studies how models interleave reasoning, actions, and feedback in external environments. ReAct introduces reasoning action traces, WebShop evaluates agents in a shopping website environment, and Reflexion uses trial feedback for later attempts [23, 22, 15]. Browser oriented benchmarks extend this line to realistic websites and multimodal browsing: Mind2Web, WebArena, and WebVoyager ask agents to complete tasks through web pages rather than answer from text alone [3, 25, 5]. HTMLC URE also treats the browser as an evidence source, but for a different objective. The trace is not the final trajectory of a web agent; it is the diagnostic state for routing HTML repair and selecting pages for supervised training. HTML Generation and Frontend Evaluation. Code intelligence has moved from foundation models toward agents and applications, as summarized in recent surveys and code model reports [20, 21]. Frontend benchmarks measure complementary parts of HTML quality. Design2Code [16] and Image2Struct [14] emphasize visual or structural fidelity, while MiniAppBench, WebGen-Bench, Vibe Code Bench, FullFront, Vision2Web, and WebCoderBench move toward generated interactive applications [24, 9, 18, 17, 6, 8]. These benchmarks show why static screenshots or code similarity are insufficient for interactive pages. HTMLC URE does not claim browser evaluation alone as the novelty. It uses the executed trace as a control signal: deterministic probes score most dimensions, the VLM judges bounded visual states from the trace, and the resulting state routes repair and export. Feedback Driven Repair and Synthetic Supervision. Self-Refine, Self-Debugging, CodeRL, and self-repair studies revise outputs from feedback or execution signals [10, 2, 7, 11]; DesignBench and VIBEPASS study frontend repair and diagnosis in related settings [19, 1]. Separately, selected synthetic data can improve smaller models [4], and web agent pipelines such as Explorer use exploration to synthesize or filter trajectories [12]. HTMLC URE connects these directions for interactive HTML. A page may render yet fail under hover, canvas updates, button state changes, or mobile layout checks. Rather than only keeping or discarding it, browser experience classifies the current state, restricts the repair family, re-executes each candidate, and exports the best verified checkpoint as SFT supervision.

Conclusion

We introduce HTMLC URE, a browser experience framework for evaluating and repairing LLM generated interactive HTML. The central idea is that execution should not be used only after generation as a pass or fail judge. Once a page has been rendered, interacted with, and viewed across states, the browser trace becomes a repair state signal: it separates missing structure from broken interaction and low risk refinement, selects the corresponding repair family, re-executes candidates, and exports the best verified checkpoint as SFT supervision. This turns repair into data construction rather than polishing after the fact. In our experiments, the refined pool trains a 27B model that reaches 50.6 on HTMLB ENCH-400 and 81.2 on the released MiniAppBench validation split, comparable to strong reference systems while preserving the controlled Raw/Filtered/Refined gains. The remaining limits are concrete. The VLM still judges the bounded visual design component, browser probes cannot cover every possible interaction, and complex games expose coupled timing and state failures. A next step is to learn routing and stopping from the repair traces themselves, while extending this approach beyond single file HTML.

References [1] Srijan Bansal, Jiao Fangkai, Yilun Zhou, Austin Xu, Shafiq Joty, and Semih Yavuz. VIBEPASS: Can vibe coders really pass the vibe check?, 2026. arXiv preprint arXiv:2603.15921. [2] Xinyun Chen, Maxwell Lin, Nathanael Schärli, and Denny Zhou. Teaching large language models to self-debug, 2023. arXiv preprint arXiv:2304.05128. [3] Xiang Deng, Yu Gu, Boyuan Zheng, Shijie Chen, Samuel Stevens, Boshi Wang, Huan Sun, and Yu Su. Mind2Web: Towards a generalist agent for the web. In Advances in Neural Information Processing Systems 36, Datasets and Benchmarks Track, 2023. NeurIPS 2023 Spotlight; arXiv preprint arXiv:2306.06070. [4] Suriya Gunasekar, Yi Zhang, Jyoti Aneja, Caio César Teodoro Mendes, Allie Del Giorno, Sivakanth Gopi, Mojan Javaheripi, Piero Kauffmann, Gustavo de Rosa, Olli Saarikivi, Adil Salim, Shital Shah, Harkirat Singh Behl, Xin Wang, Sébastien Bubeck, Ronen Eldan, Adam Tauman Kalai, Yin Tat Lee, and Yuanzhi Li. Textbooks are all you need, 2023. arXiv preprint arXiv:2306.11644. [5] Hongliang He, Wenlin Yao, Kaixin Ma, Wenhao Yu, Yong Dai, Hongming Zhang, Zhenzhong Lan, and Dong Yu. WebVoyager: Building an end-to-end web agent with large multimodal models. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, pages 6864–6890, Bangkok, Thailand, 2024. Association for Computational Linguistics. arXiv preprint arXiv:2401.13919. [6] Zehai He, Wenyi Hong, Zhen Yang, Ziyang Pan, Mingdao Liu, Xiaotao Gu, and Jie Tang. Vision2Web: A hierarchical benchmark for visual website development with agent verification, 2026. arXiv preprint arXiv:2603.26648. [7] Hung Le, Yue Wang, Akhilesh Deepak Gotmare, Silvio Savarese, and Steven Chu Hong Hoi. CodeRL: Mastering code generation through pretrained models and deep reinforcement learning. In Advances in Neural Information Processing Systems 35, 2022. NeurIPS 2022; arXiv preprint arXiv:2207.01780. [8] Chenxu Liu, Yingjie Fu, Wei Yang, Ying Zhang, and Tao Xie. WebCoderBench: Benchmarking web application generation with comprehensive and interpretable evaluation metrics, 2026. arXiv preprint arXiv:2601.02430. [9] Zimu Lu, Yunqiao Yang, Houxing Ren, Haotian Hou, Han Xiao, Ke Wang, Weikang Shi, Aojun Zhou, Mingjie Zhan, and Hongsheng Li. WebGen-Bench: Evaluating LLMs on generating interactive and functional websites from scratch, 2025. arXiv preprint arXiv:2505.03733. [10] Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. Selfrefine: Iterative refinement with self-feedback. In Advances in Neural Information Processing Systems 36, 2023. [11] Theo X. Olausson, Jeevana Priya Inala, Chenglong Wang, Jianfeng Gao, and Armando SolarLezama. Is self-repair a silver bullet for code generation? In The Twelfth International Conference on Learning Representations, 2024. ICLR 2024; arXiv preprint arXiv:2306.09896. [12] Vardaan Pahuja, Yadong Lu, Corby Rosset, Boyu Gou, Arindam Mitra, Spencer Whitehead, Yu Su, and Ahmed Hassan Awadallah. Explorer: Scaling exploration-driven web trajectory synthesis for multimodal web agents. In Findings of the Association for Computational Linguistics: ACL 2025, pages 6300–6323, Vienna, Austria, 2025. Association for Computational Linguistics. arXiv preprint arXiv:2502.11357. [13] Qwen. Qwen3.5. https://huggingface.co/collections/Qwen/qwen35, 2026. Official Qwen3.5 model collection. [14] Josselin Somerville Roberts, Tony Lee, Chi Heem Wong, Michihiro Yasunaga, Yifan Mai, and Percy Liang. Image2Struct: Benchmarking structure extraction for vision-language models. In Advances in Neural Information Processing Systems 37, Datasets and Benchmarks Track, 2024. 10

[15] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning. In Advances in Neural Information Processing Systems 36, 2023. NeurIPS 2023; arXiv preprint arXiv:2303.11366. [16] Chenglei Si, Yanzhe Zhang, Ryan Li, Zhengyuan Yang, Ruibo Liu, and Diyi Yang. Design2Code: Benchmarking multimodal code generation for automated front-end engineering. In Proceedings of the 2025 Conference of the Nations of the Americas Chapter of the Association for Computational Linguistics: Human Language Technologies (Volume 1: Long Papers), pages 3956–3974. Association for Computational Linguistics, 2025. NAACL 2025; arXiv preprint arXiv:2403.03163. [17] Haoyu Sun, Huichen Will Wang, Jiawei Gu, Linjie Li, and Yu Cheng. FullFront: Benchmarking MLLMs across the full front-end engineering workflow, 2025. arXiv preprint arXiv:2505.17399. [18] Hung Tran, Langston Nashold, Rayan Krishnan, Antoine Bigeard, and Alex Gu. Vibe code bench: Evaluating AI models on end-to-end web application development, 2026. arXiv preprint arXiv:2603.04601. [19] Jingyu Xiao, Ming Wang, Man Ho Lam, Yuxuan Wan, Junliang Liu, Yintong Huo, and Michael R. Lyu. DesignBench: A comprehensive benchmark for MLLM-based front-end code generation, 2025. arXiv preprint arXiv:2506.06251. [20] Jian Yang, Xianglong Liu, Weifeng Lv, Ken Deng, Shawn Guo, Lin Jing, Yizhi Li, Shark Liu, Xianzhen Luo, Yuyu Luo, Changzai Pan, Ensheng Shi, Yingshui Tan, Renshuai Tao, Jiajun Wu, Xianjie Wu, Zhenhe Wu, Daoguang Zan, Chenchen Zhang, Wei Zhang, He Zhu, Terry Yue Zhuo, Kerui Cao, Xianfu Cheng, Jun Dong, Shengjie Fang, Zhiwei Fei, Xiangyuan Guan, Qipeng Guo, Zhiguang Han, Joseph James, Tianqi Luo, Renyuan Li, Yuhang Li, Yiming Liang, Congnan Liu, Jiaheng Liu, Qian Liu, Ruitong Liu, Tyler Loakman, Xiangxin Meng, Chuang Peng, Tianhao Peng, Jiajun Shi, Mingjie Tang, Boyang Wang, Haowen Wang, Yunli Wang, Fanglin Xu, Zihan Xu, Fei Yuan, Ge Zhang, Jiayi Zhang, Xinhao Zhang, Wangchunshu Zhou, Hualei Zhu, King Zhu, Bryan Dai, Aishan Liu, Zhoujun Li, Chenghua Lin, Tianyu Liu, Chao Peng, Kai Shen, Libo Qin, Shuangyong Song, Zizheng Zhan, Jiajun Zhang, Jie Zhang, Zhaoxiang Zhang, and Bo Zheng. From code foundation models to agents and applications: A comprehensive survey and practical guide to code intelligence, 2025. [21] Jian Yang, Wei Zhang, Shawn Guo, Zhengmao Ye, Lin Jing, Shark Liu, Yizhi Li, Jiajun Wu, Cening Liu, X. Ma, Yuyang Song, Siwei Wu, Yuwen Li, L. Liao, T. Zheng, Ziling Huang, Zelong Huang, Che Liu, Yan Xing, Renyuan Li, Qingsong Cai, Hanxu Yan, Siyue Wang, Shikai Li, Jason Klein Liu, An Huang, Yongsheng Kang, Jinxing Zhang, Chuan Hao, Haowen Wang, Weicheng Gu, Ran Tao, Mingjie Tang, Peihao Wu, Jianzhou Wang, Xianglong Liu, Weifeng Lv, and Bryan Dai. Iquest-coder-v1 technical report, 2026. [22] Shunyu Yao, Howard Chen, John Yang, and Karthik Narasimhan. WebShop: Towards scalable real-world web interaction with grounded language agents. In Advances in Neural Information Processing Systems 35, 2022. NeurIPS 2022; arXiv preprint arXiv:2207.01206. [23] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik R. Narasimhan, and Yuan Cao. ReAct: Synergizing reasoning and acting in language models. In The Eleventh International Conference on Learning Representations, 2023. ICLR 2023; arXiv preprint arXiv:2210.03629. [24] Zuhao Zhang, Chengyue Yu, Yuante Li, Chenyi Zhuang, Linjian Mo, and Shuai Li. MiniAppBench: Evaluating the shift from text to interactive HTML responses in LLM-powered assistants, 2026. arXiv preprint arXiv:2603.09652. [25] Shuyan Zhou, Frank F. Xu, Hao Zhu, Xuhui Zhou, Robert Lo, Abishek Sridhar, Xianyi Cheng, Tianyue Ou, Yonatan Bisk, Daniel Fried, Uri Alon, and Graham Neubig. WebArena: A realistic web environment for building autonomous agents. In The Twelfth International Conference on Learning Representations, 2024. ICLR 2024; arXiv preprint arXiv:2307.13854.

Limitations and Release Safeguards

The main evidence is the same backbone route comparison: Raw, Filtered, and Refined use the same base checkpoints, training recipe, and evaluation runners, so the changing factor is how the HTML supervision is constructed. This is the central axis of HTMLC URE. The browser does not only score a page; it creates the state signal that decides whether the system should rewrite, diagnose and patch, or preserve the current implementation. The wider leaderboard provides context across model families, while the SFT block and the equal size controls isolate the repair data effect under matched training conditions. HTMLB ENCH provides a frozen, comprehensive evaluation suite for interactive HTML quality, and MiniAppBench supplies an external validation split. The visual design component is bounded, scored from structured evidence, and reported together with deterministic test case pass rate and MiniAppBench, so the main conclusion is tied to executed behavior rather than visual judgment alone. The release is organized around reproducible artifacts. The artifact includes item JSONL files, frozen test cases, browser runner, scoring code, validation commands, configuration templates, aggregate trace tables, SFT manifests, and scripts for reconstruction. These files expose the benchmark, the execution based scoring path, the repair data funnel, and the aggregate evidence used by the figures and tables. For responsible release, benchmark prompts and generated examples avoid real credentials, payments, private services, and personal data; safety sensitive prompts are treated as UI only demos with synthetic placeholders. The main dual use risk is misuse of generated HTML for deceptive login, payment, or dashboard interfaces, so release documentation includes usage restrictions, filters for credential collection patterns, and license notices for Qwen, LlamaFactory, MiniAppBench, and provider generated outputs.

Data and Code Availability

We provide the HTMLCure code and release materials at https://github.com/wuyuVerse/H TMLCure. The release contains the HTMLCure evaluation and repair code, the HTMLBench-400 benchmark files, the frozen 6,000 test case selection file, browser runner and scoring utilities, example configuration files, benchmark audit scripts, smoke tests, documentation for the evaluation protocol and architecture, aggregate trace tables, SFT manifests, provenance notes, reconstruction scripts, and an MIT license for the released HTMLCure code. For SFT data, the public release exposes route manifests and reconstruction scripts; release of the full generated and refined HTML corpus is handled under the applicable source and provider redistribution terms. External benchmarks, model APIs, Qwen checkpoints, MiniAppBench, LlamaFactory, and provider generated outputs remain governed by their original licenses and provider terms.

Supplementary Analysis

The main paper reports the aggregate effect of repair and moves the iteration level value curve into Section 6.2. This appendix keeps the lower level diagnostics: whether one strong repair prompt would be enough, and whether a fixed stopping rule would be safe. Both checks use the same browser traces that determine export into the refined SFT pool, so the evidence remains tied to observed rendering, interaction behavior, and regression risk. C.1

State Transition Accounting

The state transition view is a score band diagnostic, not an export table. Rows in Table 8 use the original evaluator score before repair, and columns use the final retained score band after repair. Entries are percentages within each original state, with counts in parentheses. This table therefore asks whether repair moves pages across score bands under the browser evaluator. It does not say that every page in a final High band is exported into SFT; export also requires the quality gate and sampling step summarized in Table 5. This distinction matters most for original High pages: remaining in the High band is a preservation check, while Table 5 reports how many of those pages are actually included in the refined pool.

Table 8: State transition before and after repair. Rows are original score bands; columns are final retained score bands. Entries are within row percentages with counts.

C.2

Orig.

Low

Mid

High

Low Mid High

1.8% (278) 0.0% (0) 0.0% (0)

44.2% (6,932) 17.9% (11,129) 0.0% (0)

54.0% (8,476) 82.1% (50,883) 100.0% (13,786)

Strategy Profiles

Figure 7 is a fixed policy diagnostic. If repair were generic self refinement, one action family should dominate return, reliability, and coverage at the same time. Panel A shows a different structure. Interaction repair gives the strongest local correction when the executed trace exposes a broken control, stalled transition, or failed playability path, but it covers a narrower part of the repairable population. Rewrite covers many structurally weak pages and contributes large recovery, but it is not the most reliable family once the page already has usable structure. Other targeted fixes absorb a broad set of local defects, yet their average lift is smaller. This is why the controller is useful: the objectives do not collapse into one ranking. Panels B and C expose the same dependency at the individual strategy level. The highest value actions are not mainly visual polish operations; they are interaction, playability, and holistic rewrite actions whose usefulness depends on what the browser trace revealed. This matters for the main claim. A screenshot only judge would see the surface state but would not reliably distinguish a missing click response from a broken game loop or from a page that needs replacement. The state aware controller uses the executed trace to choose among these repair families: replace when there is no stable local target, diagnose when partial structure remains, and preserve when further broad editing is more likely to damage than recover the page.

Rewrite

Interaction fix

+9.7

92%

Other targeted fix 100%

49%

Fix interaction Fix playability Holistic rewrite

Interaction fix

+11.2

95%

100%

Other targeted fix

+7.3

92%

100%

42%

Return

Success

Safety

Support

Fix game Bug fix Feature complete Visual enrichment

Family Profile

Avg score lift

85%

90%

Success

95%

100%

Figure 7: Strategy profile for repairable pages. Panel A compares action families over return, success, safety, and support. Panels B and C rank concrete strategies by lift and success, showing that the useful action depends on the page state exposed by browser execution. C.3

Convergence and Stopping

Figure 5 in the main analysis shows that more rounds alone do not explain the improvement. The population moves sharply once a useful repair path is found, and the current candidate can regress after a better checkpoint has already appeared. This is why HTMLC URE runs every candidate again and exports the best cleared checkpoint, not the final candidate in the loop. Figure 8 explains why stopping must also depend on state. Low pages often need several rounds because the first successful action must reconstruct missing structure before local defects become visible. Mid pages reach their best checkpoint earlier, which matches the diagnosis repair route in the main policy. High pages behave differently: many are already best at input or peak in the first few rounds. Continuing to edit them creates little additional value and mainly opens a regression channel. The figure therefore supports preservation as an active policy choice, not as a failure to improve high scoring pages. Taken together with Figure 5, the appendix figures give the mechanism level evidence behind the corpus and SFT results. The benefit of HTMLC URE is not that it edits more. It edits after experiencing the page, uses that experience to choose the repair family, verifies each candidate through a fresh 13

execution pass, and stops or preserves when the evidence indicates that further edits are more likely to revisit or damage an already usable page. These controls make repair suitable for data construction: the refined pool grows because weak and partial pages are recovered under a measurable quality gate, while strong pages are protected from unnecessary rewriting. 0%

23% 14% 12% 11% 10% 11% 16%

448

3.5K

Mid

15% 25% 16% 12% 10%

9.5K

4.8K

4.3K

5.1K

High

15.3K

2.3K

9.8K

1.9K

7.4K

1.7K

5.9K

1.6K

28% 20% 27%

3.9K

2.7K

3.7K

1.1K

892

769

703

Input R1

1.7K

2.5K

80% captured

Share captured

Original state

100%

Low

High

80% 60%

Mid

40%

Low Mid High

20%

Best observed checkpoint

<=R3 best input best R8+ needed

Low

0% InputR1 R2 R3 R4 R5 R6 R7 R8

25%

50%

75%

Stopping profile share

Repair checkpoint

100%

Figure 8: State dependent stopping behavior. Panel A locates the first best checkpoint for each original state. Panel B shows how quickly each state captures its best candidate. Panel C summarizes early peaks, input best cases, and late recoveries, motivating preservation for High pages and longer search for weaker pages. C.4

Representative Case Studies

Figures 9–14 follow the same semantic family order as Table 3 and show case cards rendered in a browser from selected repair traces. These are qualitative examples rather than additional aggregate evidence; the measured claims come from the trace analyses above. Each card places the original render beside the retained checkpoint, reports the verified score path, and lists the repair action used at every round. The point is to expose what the controller is optimizing: not just a better screenshot, but executable structure, interaction feedback, rendering stability, and visual coherence over a page trajectory.

Games & Simulations

verified score path

46 -> 89.9

Base defender game

+43.9 verified lift

A keyboard-and-mouse base defense game with enemies, a protected zone, …

Before

Original game

Best R8

TRACE

Best R8 selected after browser/VLM evidence checks across the repair trace.

Playable R8 state

BASE DEFENDER

base hp

score

92%

24,860

COLLISION VERIFIED

TRACE

AIM LOCK

wave

08 / 12

PICKUP CHAIN

COMBO

RED x4 ZONE SAFE PERFECT WAVE

Playable loop is incomplete: controls, obstacle checks, and score state are not verified.

MOUSE SPACE

R8 restores responsive controls, enemy waves, protectedzone checks, score state, and stable feedback.

SOURCE PROMPT

Create a singlepage base defense game. The playe…

+9.5

+2.2

+1.3

+0.6

+0.9

+1.0

+0.1

rebuild str…

game mech…

interaction …

visual polish

complete f…

bug fix

VERIFIED EDIT

BEST RETAINED

Figure 9: Real repair trace for Games & Simulations. The card contrasts the original broken gameplay state with a playable retained checkpoint and shows the verified repair actions that recover the game loop.

Apps & Tools

verified score path

46 -> 87.9

Overseas moving planner

+41.9 verified lift

A relocation planner with date reminders, checklist tracking, document stat…

Before

Unlinked planner

Best R8

TRACE

MoveDraft

Documents

Moving plan

Overview

origin -- destination

Documents

WORKFLOW -MISSING

Housing

Checklist placeholder

Timeline

Dates, documents, -reminders, and destination state Document placeholder -are disconnected. Reminder placeholder

Budget

Progress placeholder

45% ready

Documents

10/22

Checklist, dates, and documents are linked

Reminders Housing

TRACE

Search tasks, documents, dates

Singapore relocation

Overview

Unbound modules Documents

Workflow planner

MoveWise

draft

Best R8 selected after browser/VLM evidence checks across the repair trace.

Reminders

Jun 28

4 active

Confirm Singapore lease

May 12

Budget used

Upload visa documents

May 18

Book sea-freight pickup

Jun 02

Shanghai -> Singapore

Timeline Budget used

Budget

Destination brief

Notify bank + school Jun 10

The interface is visible, but workflow state, reminders, and action affordances are incomplete.

$4.8k

Destination brief

SG / EP pass

R8 turns the task into a usable planner with modules, status, reminders, and workflow controls.

SOURCE PROMPT

Build an overseas moving planner with checklist…

+6.9

+6.1

+2.8

+0.8

+0.1

+0.3

+1.0

+0.1

rebuild str…

visual polish

VERIFIED EDIT

BEST RETAINED

Figure 10: Real repair trace for Apps & Tools. The card shows how an early off target application state is repaired into a usable planner with task state and workflow affordances.

Data Visualization

verified score path

52 -> 90.6

Traffic analytics dashboard

+38.6 verified lift

A responsive SVG traffic analytics dashboard with trend lines, categories, su…

Before

Broken dashboard

Traffic Analytics Direct

Social

Referral

Best R8

TRACE

Best R8 selected after browser/VLM evidence checks across the repair trace.

Repaired dashboard

Traffic Analytics

offline Organic

Direct

Social

Referral

TRACE

live Organic

DATA NOT ENCODED Jan

Mar

Series, legend toggles, prediction bands, and May Jul are Sep summary cards missing.

Nov

Jan

Mar

May

Jul Sep Nov forecast band + anomaly checks

Correlation

Growth

Anomalies

Correlation

Growth

Anomalies

0.82

+2.4%

The dashboard lacks encoded series, legends, prediction cues, and summary cards.

R8 restores multi-series SVG trends, anomaly markers, forecast cues, and summary panels.

SOURCE PROMPT

Create a responsive SVG traffic analytics…

+12.7

+10.8

+0.1

+0.7

+0.3

+1.3

+0.4

rebuild str…

visual polish

VERIFIED EDIT

BEST RETAINED

Figure 11: Real repair trace for Data Visualization. The card contrasts a missing analytic structure with a retained checkpoint that restores encoded series, legend controls, and summary panels.

Visual Art & Animation

verified score path

47 -> 93.8

Particle clock animation

+46.8 verified lift

A pure-SVG clock whose particles morph smoothly as the displayed time cha…

Before

Broken particle clock

Best R8

TRACE

no morph timing

Repaired particle clock

PA R T I C L E C L O C K

digit map unstable

missing segments

Best R8 selected after browser/VLM evidence checks across the repair trace.

weak clock state

stable digit spacing

The visual shell appears, but morph timing and stable particle geometry are not established.

TRACE

morph path locked

smooth particle morph

live SVG state

R8 aligns the visual style and stabilizes particle morphing across observed frames.

SOURCE PROMPT

Create a pure-SVG particle clock. Each digit is mad…

+10.8

+1.9

+0.1

+0.3

+0.6

+0.7

+0.2

rebuild str…

visual polish

complete f…

bug fix

VERIFIED EDIT

BEST RETAINED

Figure 12: Real repair trace for Visual Art & Animation. The card shows how browser evidence guides the repair from off target motion toward a coherent particle clock animation.

3D/WebGL Scenes

verified score path

47 -> 94.2

Tidal orbit explorer

+47.2 verified lift

A pseudo-3D orbit explorer with Earth, Moon, Sun, tidal bulges, force vector…

Before

Broken orbit state

Best R8

TRACE

Best R8 selected after browser/VLM evidence checks across the repair trace.

Tidal orbit explorer

TRACE

Hover focus

tide contrast

0.87

Moon/Sun vectors, tide bulges, and labels stay visible in one scene.

scrub orbit phase toggle vectors force vectors

The scene contains the right orbit objects, but depth, tide state, force labels, and focus behavior are incomplete.

tide bulges

depth rings

inspect tide zone

R8 preserves the orbit task while adding tide bulges, force vectors, labels, depth cues, and focus controls.

SOURCE PROMPT

Create an interactive pseudo-3D tidal…

+12.4

+13.7

+0.4

+0.6

+0.1

+0.2

+1.1

+0.8

rebuild str…

playability …

visual polish

VERIFIED EDIT

BEST RETAINED

Figure 13: Real repair trace for 3D/WebGL Scenes. The card keeps the radial map task and shows how repair adds neon regions, depth rings, labels, and interaction ready SVG structure.

Content & Marketing

verified score path

60 -> 86.7

Teacher content manager

+26.7 verified lift

A content manager for teachers to organize teaching materials, lesson draft…

Before

Collapsed content shell

Best R8

TRACE

Best R8 selected after browser/VLM evidence checks across the repair trace.

Linked lesson workspace

TeachFlow Studio MATERIAL LIBRARY Slides: Water Cycle

Reading: Ecosystems

Quiz: Exit Ticket

saved lesson

LESSON OUTLINE

Ecosystems Lesson Grade 6

TRACE

45 min

ready

Warm-up: ecosystem vocabulary from Review Slides Q3

Activity: food-web group task inserted from material library

Exit ticket: claim + evidence Lab: Food Web

ready to publish

reuse block

The content shell lacks hierarchy, reusable material blocks, and task-specific editing controls.

preview lesson

publish

R8 converts the loose shell into a linked lesson workspace with reusable materials, outline state, and publish actions.

SOURCE PROMPT

Make a singlepage content manager for…

+13.4

+9.4

+10.4

+9.4

+0.2

+0.4

+1.0

+0.3

interaction …

complete f…

rebuild str…

visual polish

VERIFIED EDIT

BEST RETAINED

Figure 14: Real repair trace for Content & Marketing. The card shows how repair turns a coarse content shell into a clearer lesson building workspace with reusable materials and scanable hierarchy.

Additional Details

This appendix records the benchmark specification, reproducibility boundary, and compact prompt templates used by the evaluation and repair system. D.1

SFT Data Construction and Training Routes

The SFT data are derived from 97,115 HTML generation prompts collected from browser crawled web tasks and mapped to the same six semantic families used by HTMLB ENCH. Kimi-K2.5 generates one HTML page per prompt. Format extraction and browser initialization produce 92,418 valid Raw rows with evaluator scores. Of these, 91,484 also have completed repair traces; the remaining 934 valid Raw rows are retained only for Raw SFT because they do not have a completed repair trajectory. The repair controller assigns each traced page to the Low, Mid, or High state used throughout the paper. Low pages usually require structural reconstruction, Mid pages have enough usable structure for diagnosis guided repair, and High pages are primarily preservation cases. A repaired page enters the quality cleared candidate pool only after the retained version is executed again and passes the final gate. This process yields the 63,703 page refined candidate pool in Table 5; the final Refined SFT route uses a 40K page export sampled from that pool. The natural size comparison uses the amount of data each route actually provides. Raw uses the valid generation pool, Filtered uses the original High subset, and Refined uses the 40K repair cleared export. The equal size ablation in Table 6 fixes the count at 12,392 examples per route, which separates data quality from sample count. All route comparisons keep the prompt response template fixed, so a training example always contains the same user prompt field and one complete HTML response. All SFT runs use LlamaFactory with full parameter SFT of Qwen3.5 checkpoints. We use the qwen3_5_text template, packing, maximum sequence length 32,768, cosine learning rate schedule, warmup ratio 0.05, and 3 epochs. The default learning rates are scale specific: 1×10−5 for 4B, 8×10−6 for 9B, and 5×10−6 for 27B. The 4B and 9B routes use 32 GPUs, while the 27B route uses 128 GPUs with ZeRO style full parameter training configuration. These settings are held fixed within each scale; Raw, Filtered, and Refined differ only in their supervision source. 17

D.2

Data Provenance, Licensing, and Compute

The 97,115 generation prompts are browser crawled task descriptions collected from publicly reachable web pages under an allowlist collection policy. The crawler keeps the task request and task family metadata rather than copying source page assets, account gated content, credentials, payment flows, private services, or personal data. Prompts that require real login, payment, private backend access, or collection disallowed by the source policy are excluded before generation. Kimi-K2.5 is then used to generate one synthetic single file HTML response for each accepted prompt. These provider generated responses are used as synthetic supervision for Qwen SFT under the project provider terms; redistribution is handled separately from internal training. The public artifact therefore releases benchmark files, aggregate trace tables, SFT manifests, sampling scripts, and reconstruction code. Release of the full generated or refined HTML corpus is governed by the corresponding source and provider redistribution terms. Compute reporting is split by stage in Table 9. Initial generation and repair are API based; request logs retain provider and model identifiers, retry status, timestamps, and token usage when available, but API keys, private endpoints, account identifiers, and billing rates are not released. Local model evaluation uses NVIDIA H20 GPU workers for vLLM serving and a Chromium based browser runner for executable tests. HTMLB ENCH evaluation of local SFT checkpoints uses tensor parallel size 8, maximum model length 32,768, temperature 0, generation concurrency 4, timeout 600 seconds, and maximum generation length 30,000 tokens; browser tests run in full mode over the frozen 400 item benchmark. MiniAppBench evaluation uses Chromium through Playwright on the released validation split with parallel worker count 3 and the same maximum generation length. Table 10 reports the SFT wall clock and H20 card hour accounting from archived LlamaFactory logs. Table 9: Pipeline compute and reporting. Local GPU stages use NVIDIA H20 cards; API credentials and private billing metadata are excluded from the release. Stage

Compute

Reported settings

Initial generation

Provider API

Repair

Provider API + browser runner

HTMLB ENCH eval.

8 H20 GPUs + browser runner

MiniAppBench eval.

8 H20 GPUs + Playwright

SFT

32 or 128 H20 GPUs

One Kimi-K2.5 call per accepted prompt; logs retain model, timestamp, retry status, and token usage when available. Up to 8 rounds and at most 2 candidates per round; every candidate is re-executed before acceptance; logs retain state band, strategy, scores, gate decision, and retained checkpoint. vLLM tensor parallel 8, max length 32,768, temperature 0, generation concurrency 4, timeout 600s, max output 30,000 tokens, full 400-item browser evaluation. vLLM tensor parallel 8 for local checkpoints, validation file query_validation_100.json, Chromium browser, 3 parallel workers, max output 30,000 tokens. LlamaFactory full parameter SFT, packing, sequence length 32,768, 3 epochs, per-device batch 1, gradient accumulation 1, cosine schedule, warmup 0.05.

Table 10: SFT compute from archived training logs. All routes use NVIDIA H20 GPUs; card h is wall clock multiplied by the recorded card count. Route

Scale

Cards

Wall h

Card h

Raw Filtered Refined Raw Filtered Refined Raw Filtered Refined

4B 4B 4B 9B 9B 9B 27B 27B 27B

32 32 32 32 32 32 128 128 128

62.9 7.5 47.4 63.6 7.7 24.4 46.6 5.8 18.1

2,014 241 1,516 2,035 246 781 5,962 740 2,320

A1 Raw A2 Filtered A3 Refined A4 Raw A5 Filtered A6 Refined

9B 9B 9B 27B 27B 27B

32 32 32 128 128 128

8.5 7.6 11.7 6.3 5.8 8.7

272 245 375 801 741 1,110

D.3

External MiniAppBench Protocol

MiniAppBench is used as an external transfer check rather than as part of the repair loop. It is never used for routing, export gating, threshold selection, or checkpoint selection. The full benchmark contains 500 tasks over six domains, but the public test set withholds evaluation references for leaderboard integrity. We therefore report all paper numbers on the released validation file, query_validation_100.json, which includes the user queries, difficulty levels, domain labels, and evaluation references needed for local reproduction. The split is fixed before model comparison, external to HTMLB ENCH and the SFT corpus, and evaluated with the same MiniAppEval runner for every row in Tables 4 and 6. We use it as evidence of transfer beyond HTMLB ENCH-400, not as a replacement for a hidden benchmark submission. Table 11: MiniAppBench external evaluation split. Full counts are from the benchmark release; validation counts are the fixed released split used in this paper.

D.4

Domain

Full

Val.

Description

Science Games Tools Visualization Humanities Lifestyle

187 121 57 56 47 32

31 23 28 4 12 2

Simulators and virtual laboratories Puzzles, simulations, and casual games Schedulers, editors, and utilities Charts and interactive generative art Skill learning and cultural study Trackers, toys, and roleplay applications

Total

500

100

Six-domain external validation split

HTMLB ENCH Specification and Reproducibility

HTMLB ENCH is frozen as a benchmark for single file HTML generation that can be executed in a browser. The release contains 400 item identifiers, task family metadata, test case identifiers, test case weights, and browser action sequences. A benchmark item is the atomic public unit shown in Table 12: models receive only the prompt, while the test cases, weights, and execution traces remain on the benchmark side. The six public families are collapsed from ten source buckets (apps, UI pages, games, data visualization, creative pages, SVG art, 3D/WebGL, content pages, landing pages, and portfolios), which prevents the benchmark from inheriting narrow collection names as evaluation labels. Table 12: HTMLB ENCH item and test case schema. Field

Purpose

id category, sub_type difficulty prompt has_interaction test_cases steps

Stable benchmark item identifier. Six family taxonomy plus finer subtype metadata. Easy, medium, or hard benchmark stratum. User facing request for one self contained HTML page. Whether the task expects active browser behavior. Weighted deterministic browser checks with ordered steps. Actions such as click, hover, key press, resize, JavaScript assertion, and screenshot change checks.

The frozen scored pool contains 6,000 test cases. The runner executes 16,120 steps across those cases, with the largest groups coming from JavaScript assertions, waits, screenshot change checks, screenshots, clicks, text clicks, JavaScript evaluation, resize, key press, and text assertions. These actions are intentionally mixed: some check visible page health, some check semantic DOM state, and others force interaction or responsive layout transitions. Coverage is recorded as metadata and is not a score dimension.

Table 13: HTMLB ENCH construction and independence controls. Control

Implementation in the released benchmark

Prompt source

Six semantic families with 65 subtypes and balanced easy, medium, and hard strata. The benchmark keeps source bucket metadata for audit, but models are evaluated only from the user facing prompt. Checks must be prompt grounded and observable in the browser: content, controls, state changes, responsive behavior, rendering health, and semantic structure. Tests must not depend on class names, variable names, frameworks, hidden DOM layout, real credentials, payments, or private services. The scored pool is a fixed 6,000 test selection. Runtime scoring depends on the current page execution and weighted test case pass rate, not on model identity or repair history. The public files pass the strict benchmark validator with 400 items and no schema or logic errors. The benchmark quality audit reports no duplicate evidence, shallow visual, or cross template risk types in the released files. An exact normalized prompt match audit between the 400 benchmark prompts and the 91,484 traced repair records used for the SFT data analysis finds zero overlaps.

Test case rule

Frozen scoring pool Quality control

Train/test separation

The 400 item size is a deliberate benchmark design choice rather than a claim that the open web is exhausted by 400 prompts. Each item is expensive because it carries multiple tests that execute in a browser and because full evaluation includes rendering, probes, keyframes, and optional visual judgment. The interaction heavy mix is also deliberate: static pages can be judged reasonably well by screenshot and layout checks, while the target failure mode of this paper appears when generated pages must respond to user actions. Noninteractive prompts remain in the benchmark and use the scoring profile in Table 2, where the interaction budget is not counted against tasks that do not ask for controls. Table 14: HTMLB ENCH evaluation protocol. Stage

Benchmark side operation

Generation Extraction Static pass Browser pass Frozen TCs Visual pass Aggregation

Model returns one complete HTML document from the prompt. Runner extracts valid HTML and records malformed or truncated outputs. HTML/CSS/JS hygiene, metadata, dependency, and semantic structure checks. Render, console state, interaction probes, viewport changes, and keyframes. Weighted deterministic test cases compute the functionality component. VLM judges visual design from curated executed keyframes in full mode. Dimensions are summed directly to a 100 point score; no normalization after scoring.

The visual component is controlled separately from the deterministic browser tests and is not the only basis for interpreting results. In full mode, the Analyst sees screenshots and browser evidence but cannot assign scores. The Scorer receives no screenshots and must score from the Analyst JSON plus objective metrics. The VLM call uses deterministic decoding, and the final composite scorer applies deterministic guardrails before scaling visual design to its 20 point budget. Fast mode skips the VLM phase for low cost regression checks; leaderboard results use full mode. This keeps the visual signal available for design quality while grounding the main interpretation in test case pass rate, component scores, same backbone route comparisons, and MiniAppBench. Reproducibility is organized around two artifacts. The benchmark artifact consists of the item JSONL files, the frozen test case selection file, the browser runner, the scoring code, validation commands, and configuration templates. The paper artifact additionally reports the aggregate trace tables used for the figures and SFT comparisons, including the state bands, repair outcomes, and iteration level summaries. Together, these files make the benchmark execution path, the repair funnel, and the route comparisons inspectable. Open weight model runs can be reproduced from the released prompts, runner, configs, and independently generated responses, while closed API reference rows should be interpreted with the provider version used at evaluation time. D.5

Repair Controller Implementation Details

The repair controller is intentionally a fixed rule system in this paper. It is not trained on HTMLB ENCH, and it does not query a learned policy to choose actions. Its input is the structured diagnosis D(h) described in Table 15; this record is built from browser execution, deterministic tests, visual analysis, and repair history before the LLM receives a prompt.

Table 15: Structured diagnosis used by the repair controller. Field group

Controller evidence

Score state Test failures

Total score, five component scores, Low/Mid/High band, and distance to the export target. Failed test case identifiers, assertion messages, missing requirement items, and pass rate changes from previous rounds. Render success, console errors, JavaScript exceptions, overlays, FPS or frozen motion evidence, and responsive layout failures. Responsive buttons, keyboard bindings, form submission behavior, hover response, drag response, gameplay state changes, and latency. Analyst observations, distinctive or generic design signals, mobile and desktop keyframe notes, and contrastive before/after feedback. Previous strategies, accepted and rejected candidates, best verified checkpoint, regressions, and preservation list.

Runtime state Interaction state Visual state History

The operating thresholds have specific roles. Scores below 40 are treated as Low because the implementation often lacks a stable local target; scores from 40 to 79 are treated as Mid because enough structure exists for diagnosis guided repair; scores at or above 80 are treated as High and routed through conservative refinement. The target 97 is an early stop condition for pages that are already strong enough for export. The controller can request at most two candidates per round and always compares them with the current checkpoint. This design prevents uncontrolled edit sampling, keeps regression checks cheap enough to run at corpus scale, and makes the exported page the best checkpoint verified by execution rather than the last generated candidate. D.6

Prompt Templates

This appendix provides the complete fixed prompt templates used by the benchmark generation, evaluation, browser testing, and repair agents. Braced fields are populated at runtime with task specific evidence, generated HTML, keyframe annotations, probe summaries, previous iterations, or output mode settings; the surrounding instructions, output contracts, and state dependent control logic are shown in full. D.6.1

Benchmark Generation

The generation prompt is intentionally minimal so that HTMLB ENCH measures first pass HTML generation under a uniform interface. It enforces a single self contained HTML artifact and forbids explanations or markdown wrappers. Prompt template. For benchmark model evaluation, each model receives the original task as the user message and a minimal system instruction that forces a single self contained HTML response. The generator rejects empty, truncated, or non HTML outputs and retries safety sensitive tasks with a UI only demo suffix when required by the provider. Benchmark HTML Generation System Prompt You generate benchmark solutions as a single self-contained HTML document. Return only the final HTML. Do not include analysis, explanations, markdown fences, or any text before/after the HTML. Start with <!DOCTYPE html> when applicable and ensure the document is complete and closed. Optional retry suffix for provider-safety blocks: Build a harmless, front-end-only demo. Use fake placeholder data only. Do not process, transmit, store, or validate real credentials or payment data; if payment fields are requested, implement UI-only demo formatting/validation with synthetic examples.

D.6.2

Experience Evaluation Agents

The evaluation stage separates visual observation from scoring. The Analyst receives screenshots and browser evidence but does not assign scores. The Scorer receives no screenshots and must justify each dimension from structured evidence.

Experience Analyst prompt template. The Analyst is the only evaluation agent that sees screenshots. It receives the task, static code facts, render and console evidence, interaction probes, keyframe annotations, responsive views, DOM inventory, visible text, and selected screenshots. It returns both visual observations and a requirement checklist; it does not assign scores. Experience Analyst Prompt You are a meticulous HTML page analyst. You will describe EXACTLY what you see in the screenshots, report objective facts from probe data, AND verify each task requirement. Do NOT score. Only observe and audit. ## Task Description {query} ## Static Analysis - HTML size: {html_size}; Canvas: {has_canvas}; JS: {has_script}; CSS: {has_style}; SVG: {has_svg}; rAF: {has_raf} - Input types detected: {input_types} - External resources: {ext_list} - Static issues: {static_issues} ## Render and Runtime Evidence - Rendered: {rendered}; Title: {page_title} - Serious console errors: {console_list} - JS exceptions: {page_err_list} ## Browser Interaction Evidence - Agent phase: {agent_ran}; steps: {agent_steps}; actions: {agent_actions} - Confirmed responsive keys: {discovered_keys} - Keyboard probe: {keyboard_probed}; responsive: {keyboard_responsive} - Button census: {buttons_responsive}/{buttons_tested} responsive - Form, drag, gameplay, canvas, animation, audio, and latency evidence: {dynamic_experience_fields} ## Screenshots Each image is a keyframe from automated testing. Review them IN ORDER. {frame_annotations} Compare consecutive frames carefully: - Identical frames after interaction = interaction BROKEN - Progressive change = interaction WORKING ## Your Task Part 1: Observation. Describe the page factually. Cite specific evidence such as frame deltas, latency, button response rate, keyboard response, canvas fill, and console state. List distinct visual elements, generic/template-like signals, distinctive design signals, working features, broken features, interaction quality, and layout notes. Part 2: Requirement Audit. Break the task description into prompt-grounded requirements. For each requirement, return status = done, broken, or missing with evidence. Ignore packaging constraints such as "single HTML file" unless they cause a user-facing failure. Do not count optional extras as requirements. Reply ONLY with valid JSON: { "page_type": "...", "visual_state": "...", "visual_elements": ["..."], "template_like_signals": ["..."], "distinctive_design_signals": ["..."], "design_specificity": "...", "working": ["..."], "broken": ["..."], "interaction_quality": "...", "layout_notes": "...", "requirements": [ {"requirement": "...", "status": "done|broken|missing", "evidence": "..."} ], "summary": {"total": 0, "done": 0, "broken": 0, "missing": 0} }

Evidence only scorer prompt template. The Scorer receives no screenshots. It reads the Analyst JSON and objective metrics, then assigns the five component score. This separates visual perception from scoring and lets the implementation clamp scores when objective probes contradict the model’s text report.

Evidence-Only Scorer Prompt You are a strict HTML quality scorer. You receive structured evidence from a prior analysis stage plus objective metrics. You have NO screenshots. Score based ONLY on the evidence provided. ## Task Description {query} ## Analyst Report {observer_report_json} ## Requirement Checklist {task_auditor_report_json} ## Objective Metrics Summary - Keyboard: probed={keyboard_probed}; responsive={keyboard_responsive}; keys={keys_responded} - Button response rate: {button_response_rate_str} - Canvas: type={canvas_type}; content={canvas_has_content}; fill={canvas_fill_ratio} - Animation: detected={animation_detected}; fps={fps_quality}; frame changes={frame_change_rate} - Latency: avg={avg_latency}; max={max_latency}; timed out={interactions_timed_out} - Console and JS exceptions: {console_count}; {page_err_count} - Form, drag, gameplay, structural, and agent evidence: {objective_metric_fields} ## Scoring Rules 1. Evidence only. If a feature is not supported by the Analyst report or probe data, do not assume it exists. 2. Functionality is driven by the requirement checklist. Done items raise the score; broken items penalize more than missing items because they indicate a failed implementation. 3. Interaction is constrained by objective probes. Unresponsive buttons, keyboard failure, gameplay with no state change, or timed-out actions cap interaction. 4. Visual design is judged from the Analyst's visual evidence. Polished but reusable templates should not receive top visual scores without prompt-specific design signals. 5. Code quality is independent of visual quality and depends on runtime cleanliness, maintainability, event wiring, and implementation organization. 6. Score conservatively and cite evidence in every reason. Return JSON with the five dimensions and total: { "rendering": {"score": 0, "reason": "..."}, "visual_design": {"score": 0, "reason": "..."}, "functionality": {"score": 0, "reason": "..."}, "interaction": {"score": 0, "reason": "..."}, "code_quality": {"score": 0, "reason": "..."}, "total_score": 0, "bugs": ["specific observed bug"], "missing_features": ["missing prompt-grounded feature"], "highlights": ["working feature to preserve"], "improvement_hints": ["actionable repair hint"], "summary": "..." }

Browser use interaction tester prompt template. When the optional agent test phase is enabled, the browser agent receives a task specific interaction protocol. The prompt is augmented with detected input modes and, for games, keys that were already verified by the key scan.

Automated Interaction Tester Prompt You are an automated HTML page quality tester. Thoroughly test the page and produce a detailed report. Visit this URL: {page_url} ## What this page should do {query} ## Testing procedure 1. Load the page and observe initial rendering. 2. Activate entry points such as Start, Submit, Play, Enter, or OK. 3. Test every feature mentioned in the task: - click buttons and interactive elements - fill and submit forms - test navigation, menus, tabs, pagination, and modes - observe and interact with animated or canvas-based content - navigate through multiple states or views 4. Complete at least one full user workflow. 5. Report unresponsive elements, visual glitches, broken layout, on-page errors, and missing content. {interaction_guide} ## Report 1. Rendering: initial page state and visible failures. 2. Feature status: working, partial, broken, or missing. 3. Bug list: what happened versus what should have happened. 4. Missing features. 5. Overall quality: Excellent, Good, Fair, Poor, or Broken.

D.6.3

State Aware Repair Agents

The repair stage receives structured browser evidence collected from the current page. The controller selects the strategy, while the prompt exposes the current score, evidence, prior attempts, and preservation constraints to the code generating model. State aware repair prompt template. All repair strategies share the same prompt structure: current state, scores, previous attempts, objective probe evidence, Analyst evidence, requirement checklist, preservation list, and the current HTML. The controller changes the strategy specific instruction block according to page state and diagnosis. Low pages use rewrite oriented prompts, Mid pages use diagnosis guided repair prompts, and High pages use conservative refinement prompts.

State-Aware Repair Prompt Template You are an expert HTML/CSS/JavaScript developer. Improve the current page under the strategy selected by the repair controller: {strategy_name}. ## Task {query} ## Current page state Total score: {score}/100 Dimension scores: rendering={rendering}, visual_design={visual_design}, functionality={functionality}, interaction={interaction}, code_quality={code_quality} ## Previous repair attempts {prev_iterations} ## Objective probe evidence {probe_evidence} ## Visual and requirement evidence {observer_evidence} {requirement_checklist} {visual_context} {contrastive_feedback} ## Problems to fix {issues_or_missing_features} ## Features that must be preserved {preservation_list} ## Strategy-specific instruction {strategy_instruction} Examples: - Holistic rewrite: rebuild a complete implementation when the page lacks a stable local target, while preserving any verified useful structure. - Feature completion: implement all broken or missing requirements without removing working features. - Interaction repair: fix event wiring, input handling, latency, feedback, and state transitions without changing unrelated visuals. - Game repair: target the diagnosed layer such as input, game loop, canvas rendering, overlay state, or gameplay logic. - Visual enrichment: improve typography, layout, palette, depth, animation, and responsive polish without breaking verified behavior. - High-state refinement: make small additive patches and avoid broad rewrites. ## Current HTML ```html {html} ``` ## Output rule If the selected mode is patch mode, return JSON patches: {"patches": [{"old_str": "exact substring", "new_str": "replacement"}]} If the selected mode is rewrite mode, return only the complete HTML file.

Probe driven game repair prompt template. Game pages receive a more specific prompt when probes isolate the failed layer. This prompt is used only when the controller detects game like structure and objective evidence such as keyboard response, requestAnimationFrame calls, canvas content, overlays, or game state changes.

Probe-Driven Game Repair Prompt You are an expert HTML/CSS/JavaScript game developer. Automated probes identified the failing layer: {game_layer}. Fix that layer without rewriting unrelated systems. ## Task {query} ## Current state Total score: {score}/100 Probe evidence: {probe_evidence} Working features to preserve: {preservation_list} ## Root-cause checklist If {game_layer}=input: 1. canvas is not focusable or lacks tabindex 2. keydown/keyup listeners are attached to the wrong element 3. preventDefault is missing for arrow keys 4. key state is not read inside the game loop If {game_layer}=loop: 1. requestAnimationFrame is never called 2. loop starts only after a user action 3. update or draw throws and stops the loop If {game_layer}=canvas: 1. canvas width or height is zero 2. getContext is missing or called before the DOM is ready 3. clearRect runs without redraw 4. overlay or CSS hides the canvas If {game_layer}=overlay: 1. game-over or modal screen is visible on load 2. start screen cannot be dismissed 3. initial score, lives, or state incorrectly trigger a terminal state If {game_layer}=gameplay: 1. collision, scoring, state machine, timer, level progression, or physics is wrong 2. input works but game state does not change correctly ## Current HTML ```html {html} ``` Return the requested patch or full HTML according to {output_mode}.

Contrastive visual feedback prompt template. After a candidate is run again, HTMLC URE can compare before/after keyframes and inject the result into the next repair prompt. This turns the loop from blind retry into visual, state aware correction. Contrastive Visual Feedback Prompt You are a visual quality analyst comparing two versions of an HTML page. The page was modified between BEFORE and AFTER. Identify what improved, what regressed, and what remained unchanged. ## Task {query} ## Score change {score_before} -> {score_after} ({delta}) Dimension deltas: {dim_deltas_str} ## Frame pairs {pair_count} paired screenshots are provided below. For each pair, BEFORE is the old version and AFTER is the new version at the same interaction state. Classify each visible difference: - IMPROVED: broken, missing, or ugly before; fixed, present, or better after - REGRESSED: working or good before; broken, worse, or missing after - UNCHANGED: same problem visible in both versions Focus on functional and visual differences, not minor pixel shifts. Reply ONLY with JSON: { "improved": ["..."], "regressed": ["..."], "unchanged_issues": ["..."], "priority_fix": "single most important thing to fix next" }

Visual diagnosis and verification prompt templates. For high scoring pages, HTMLC URE can request a targeted visual diagnosis and then verify whether a visual enrichment candidate improves the page without breaking behavior. Visual Diagnosis and Verification Prompts Diagnosis: You are a visual quality expert. Examine this HTML page screenshot and identify specific visual issues preventing it from reaching professional quality. Task: {query} Current score: {score}; visual_design={visual_design}; rendering={rendering} Focus on color palette, typography, spacing, layout, visual depth, polish, responsive quality, hover states, transitions, and micro-animations. Do NOT suggest functionality changes. Return JSON: {"issues": ["..."], "suggestions": ["..."], "css_focus_areas": ["..."]} Verification: You are a visual quality analyst comparing BEFORE and AFTER versions of an HTML page modified for visual quality. Task: {query} Before score: {score_before}; After score: {score_after} Compare polish, layout integrity, content completeness, and whether interactive controls remain visible and properly styled. Return JSON: {"improved": true, "functional_regression": false, "improvements": ["..."], "regressions": ["..."]}

HTMLCure: Turning Browser Experience into State Guided Repair for Interactive HTML

Related documents