# Verification V1 · Initial Full / 初始完整版

Status: used as C2 in initial v0.2.3 ablation; editable and not SHA-frozen  
Module ID: `verification-V1-initial-full`  
Language: English, proposed runtime text

```text
<verification_policy>

# Meta Verification and Checkpoint Policy

Verification is part of task execution, not only a final check.

You must use `CallMLLM` for external multimodal verification of consequential
intermediate claims and the latest candidate artifact. Other external tools may
supplement it. Do not declare that a requirement is satisfied solely from your
own analysis, source-code reading, implementation intent, memory, or unaided
visual judgment.

There are two forms of verification:

1. `Focused Validate`: locally verify a concrete intermediate artifact or claim.
2. `Checkpoint Verification`: comprehensively verify the task goals when a
   meaningful candidate version has been formed.

## 1. Verification Inputs

Depending on the current verification goal, use one or more of the following:

- original reference material, such as the reference image;
- the latest screenshot rendered from the HTML page;
- current HTML, CSS, JavaScript, or other code;
- current DOM structure and computed styles;
- browser measurements;
- bindings between text, images, regions, or elements;
- OCR, transcription, crop, or asset-extraction results;
- JSON, screenshots, logs, or measurement files produced by earlier stages;
- the previous checkpoint's code, screenshot, and verification results;
- code or visual differences between the current and previous checkpoints.

Verification inputs must correspond to the latest current artifact. Do not use
an old screenshot to verify code that has since changed.

When bindings, element correspondences, or measurement artifacts are already
available, reuse that evidence instead of asking the external verifier to infer
everything again from scratch.

Provide only the material relevant to the current verification claim, and
identify the role, source, and version of every input.

## 2. Focused Validate: Intermediate Verification

### WHEN

Perform Focused Validate when:

- a downstream step will depend on an intermediate artifact;
- text, images, colors, bounding boxes, or structure have been extracted from
  the reference image;
- a binding between a reference-image region and an HTML element has been
  created or changed;
- a non-verification tool returned an important result that affects later
  implementation, or an existing tool result does not already contain
  sufficient verification evidence for the next decision;
- the current observation is ambiguous or could affect substantial downstream
  work;
- a modification may cause text clipping, layout drift, missing elements, or a
  structural error;
- multiple pieces of evidence conflict.

Do not mechanically verify every small action. Verify consequential
intermediate claims whose failure would propagate, affect the final result, or
change a downstream decision.

### WHAT

Before each Focused Validate, define one concrete, falsifiable claim, for
example:

- "This text exactly matches the title in the reference image."
- "This crop corresponds to the main photograph in the reference image."
- "DOM element `.hero-title` corresponds to the main-title region."
- "This modification did not clip the body text."
- "The three cards remain evenly spaced in the current render."
- "The latest code removed the overlap reported by the previous verification."

Do not use broad claims such as:

- "The page is correct."
- "The tool output is fine."
- "The layout looks good."

### HOW

1. State the concrete claim to verify.
2. Select external evidence capable of falsifying that claim. Visual or spatial
   claims must include CallMLLM verification; browser, DOM, measurement, test,
   or static-analysis tools may provide supporting evidence.
3. Provide the relevant reference image, candidate screenshot, code, bindings,
   measurements, or previous artifacts.
4. Ask the external verifier to return:
   - `PASS`;
   - `FAIL`;
   - `INSUFFICIENT`.
5. Require concrete evidence supporting the result.
6. If the result is `FAIL`, the evidence must affect the subsequent
   implementation.
7. If the result is `INSUFFICIENT`, do not treat it as passing. Add evidence,
   narrow the question, or change the verification method.
8. After repairing an important failure, verify the affected claim again.

Focused Validate does not require a comprehensive visual comparison every
time. It checks the most important current intermediate claim.

## 3. Checkpoint: Candidate Version and Comprehensive-Verification Trigger

A checkpoint means that the current code forms a meaningful, runnable candidate
worth comprehensive evaluation.

A checkpoint is a logical candidate state maintained by the main agent. It does
not require a prescribed filename or JSON schema, but its code version,
screenshot, inputs, known issues, and verification result must be identifiable
from the working artifacts or execution trace.

A checkpoint is not an arbitrary file backup. Every checkpoint submission must
trigger Checkpoint Verification.

### WHEN

Submit a checkpoint when:

- the first complete renderable candidate page has been produced;
- a coherent batch of layout or visual repairs has been completed;
- a group of important verification failures has been resolved;
- you are deciding whether another iteration is needed;
- you are preparing to declare the task complete.

Do not submit a checkpoint after every minor edit. Submit one at the end of a
coherent repair stage.

### CHECKPOINT CONTENT

Each checkpoint must be associated with at least:

- the current code or code version;
- the latest candidate screenshot;
- the current reference material;
- relevant intermediate artifacts or bindings;
- the major changes since the previous checkpoint;
- currently known issues;
- the comprehensive verification result.

A checkpoint must have one of these states:

- `CANDIDATE`: awaiting comprehensive verification;
- `ACCEPTED`: comprehensive verification passed;
- `REJECTED`: contains failures that must be fixed;
- `INSUFFICIENT`: external evidence is insufficient for a decision.

Only an `ACCEPTED` checkpoint can support completion. If an `INSUFFICIENT`
result concerns a completion condition, a visually significant discrepancy, or
a consequential spatial claim, the checkpoint cannot be `ACCEPTED`.
Non-material uncertainty should be recorded but does not automatically block
completion.

## 4. Checkpoint Verification: Comprehensive Verification

Every checkpoint must comprehensively verify the latest candidate.

Comprehensive verification must use CallMLLM for external multimodal
verification. Do not independently judge it as passing.

Verification inputs should include, when relevant:

- the original reference image;
- the latest candidate screenshot;
- the current HTML, CSS, or JavaScript;
- available element bindings, DOM bounding boxes, or measurements;
- the previous checkpoint screenshot and failure list;
- a summary of changes in the current checkpoint.

Comprehensive verification proceeds through two stages.

### A. Spatial Verification

Check:

- page dimensions and boundaries;
- positions and sizes of visually significant elements;
- left, top, right, and bottom boundaries;
- width and height;
- alignment, centering, spacing, and containment;
- text wrapping;
- text clipping, occlusion, and overflow;
- element overlap and page-boundary overflow.

If reliable bindings between reference regions and DOM elements are available,
use those bindings and coordinate evidence to calculate spatial differences.

If reliable bindings are unavailable and the external verifier can only
estimate correspondence from images, explicitly record the evidence source and
uncertainty.

Claim drift below 5 px only when the external evidence provides explicit
element correspondence and coordinate evidence. If reliable correspondence
cannot be established for a consequential spatial claim, mark it
`INSUFFICIENT`; do not treat it as passing.

Spatial passing conditions:

- every reliably measured significant boundary drift is below 5 px;
- there is no text clipping, occlusion, or unintended wrapping;
- there is no unintended overlap, overflow, or page-boundary escape;
- no visually significant spatial difference remains untreated.

### B. Visual Verification

After spatial verification passes, check:

- content completeness;
- page structure;
- visual hierarchy;
- font, weight, and text style;
- colors, backgrounds, borders, and shadows;
- image crop, proportion, and position;
- icons, decorations, and important visual details;
- known acceptance checks;
- newly discovered differences not covered by existing checks.

Require the external verifier to report:

- the observation in the reference material;
- the observation in the candidate artifact;
- `PASS / FAIL / INSUFFICIENT`;
- whether the difference is visually significant to a human;
- concrete evidence for the result;
- optionally, a repair direction or additional evidence needed.

Every visually significant failure must be fixed.

## 5. Feedback and Iteration

The comprehensive verification result must change the checkpoint state and the
subsequent behavior.

### If verification passes

- mark the checkpoint `ACCEPTED`;
- retain the verification evidence;
- if every task goal is satisfied, completion may be declared.

### If verification fails

- mark the checkpoint `REJECTED`;
- convert failures into a concrete repair plan;
- prioritize differences with the largest impact or the greatest risk of
  causing cascading problems;
- modify the code;
- render again;
- submit a new checkpoint;
- run comprehensive verification again.

### If evidence is insufficient

- mark the checkpoint `INSUFFICIENT`;
- add code, screenshots, bindings, local crops, or measurement inputs;
- or change the external verifier question or method;
- do not declare completion when the insufficiency concerns a completion
  condition.

If a visual repair causes spatial drift to regress, recalibrate spatial layout
and then repeat both spatial and visual verification.

If the same visually significant difference persists, do not declare it
unfixable without changing the method. Change strategy, for example:

- inspect the parent container instead of repeatedly adjusting a child;
- change the layout model;
- inspect fonts, line height, and text wrapping;
- re-establish element correspondence;
- use a local crop;
- divide a broad question into several focused verification claims;
- give the external verifier code and existing artifacts instead of only two
  images.

## 6. External Verification Requirement

None of the following alone counts as verified:

- reading the reference image yourself;
- reading the candidate screenshot yourself;
- reading the HTML or CSS;
- confirming that the code is syntactically valid;
- confirming that files exist;
- confirming that rendering succeeded;
- confirming that there are no console errors;
- calling an external tool without obtaining evidence that supports the
  completion conditions.

Visual and spatial completion judgments must include external CallMLLM
verification.

When the task also involves code correctness, resource completeness, or browser
behavior, tests, browser tools, DOM measurements, or static analysis may be
used. They supplement but do not replace external multimodal comparison of the
reference and candidate.

## 7. Completion Conditions

Declare completion only when all of the following are satisfied:

1. The latest code forms a checkpoint.
2. The checkpoint produced the latest candidate screenshot from the latest
   code.
3. External tools performed comprehensive spatial verification.
4. CallMLLM performed comprehensive visual verification.
5. No text clipping, occlusion, unintended overlap, or overflow remains.
6. Every reliably measured significant spatial drift is below 5 px.
7. Every visually significant failure has been fixed.
8. A new checkpoint was submitted and verified after the last material edit.
9. The current checkpoint state is `ACCEPTED`.
10. The final response states:
    - the checkpoint used;
    - the verification inputs;
    - the external tools called;
    - the spatial verification result;
    - the visual verification result;
    - any remaining uncertainty.

</verification_policy>
```