A website generator can produce a successful build and still deliver an awkward page. It can also show a good screenshot, change the source afterward, and accidentally approve a version nobody actually reviewed.

WebsitePitcher's local generation loop treats technical evidence and visual review as separate inputs. A version becomes ready only when both refer to the same source.

Give the controller a narrow job

The agent develops the website structure, content, styling, and any generated imagery. The controller orchestrates the process and enforces evidence, state, and resource limits.

The loop is:

generate source
→ isolated build and browser checks
→ desktop and mobile screenshots
→ agent review with optional corrections
→ rebuild if source changed
→ publish an immutable ready artifact when all gates pass

This keeps design decisions with the agent while making acceptance criteria enforceable outside its narrative response.

A review is structured data

The visual review contains an approval decision, a numeric score, a bounded issue list, and a summary. The controller validates that structure instead of searching a paragraph for an encouraging phrase.

The current gate requires a passing technical report, both screenshot attachments, approval, a score of at least eight, and no remaining issues.

An automated score is the agent's assessment. It is not a measured conversion rate, accessibility certification, or substitute for human design acceptance.

Corrections invalidate old screenshots

The controller fingerprints the source manifest with paths in a deterministic order. After the review turn, it compares the reviewed source with the source used to build the screenshots.

If the agent changed a file, an approval in that same response cannot release the new source. Another build and review are required.

This avoids a subtle failure: the agent sees a layout problem, fixes it, and says the page is now ready, even though the corrected layout has never been rendered.

A screenshot proves something about one artifact. The source fingerprint keeps that artifact relationship explicit.

Bound retries and preserve work

The implementation allows at most three visual rounds inside a shared deadline. It also accumulates output-token usage across turns rather than resetting the budget after each correction.

Before and after important stages, checkpoints preserve the draft and available evidence. Reaching a limit produces a failed job with retained work, rather than an unreviewed ready version.

That makes retry behavior more useful: a later improvement can start from a known draft instead of pretending the previous attempt never happened.

Separate a demonstrated run from a finished product

The local project documents a successful restaurant demonstration with generated imagery, build checks, and desktop/mobile review. It does not establish that every industry or every correction pattern works equally well.

The next useful evidence is a range of briefings, deliberately difficult layouts, and real correction rounds. The architecture already enforces the central rule: a positive review belongs to the exact source that produced the reviewed images.