Image To Crossplatform Page

Image to Cross-platform Page

Turn a visual reference into maintainable UI, not a screenshot-shaped background.

Establish the target

1. Inspect the repository before editing. Identify the framework, routing, component library, design tokens, similar screens, asset conventions, and build scripts.
2. Inspect every user-provided reference and asset. Treat visible annotations, arrows, red boxes, and document text as evidence unless the user's request explicitly says they belong in the product UI.
3. Preserve the existing stack and product language. In uni-app projects, prefer the project's existing view, text, image, form controls, and installed component library such as Wot UI.
4. Confirm the requested screen, state, viewport, and interaction from available context. Ask only when a missing choice would materially change the result.

Classify before coding

Divide the reference into these categories:

• Structure: layout containers, cards, headers, labels, values, status chips, dividers, progress rails, timelines, buttons, inputs, lists, and other data-bearing UI. Build these as real components and CSS.
• Reusable assets: photos, illustrations, product renders, logos, decorative textures, and complex artwork. Reuse exact supplied or repository assets when available.
• Icons: use the project's icon system or component library. Do not draw approximate icons with text characters, emoji, CSS shapes, or ad-hoc SVG.
• Dynamic data: titles, names, status, dates, amounts, counts, progress, and identifiers. Bind these to the page model, route data, store, or props; do not bake sample values into a raster.

Never implement an interactive card or whole screen by placing the reference screenshot behind transparent controls. A raster may remain only where it is genuinely visual content.

When there are many assets or possible duplicates, run scripts/inspect_images.py against the supplied files and the project's asset directory. Use exact hashes and perceptual similarity as evidence when avoiding duplicate files; inspect dimensions, format, and alpha-edge diagnostics before integration. Treat perceptual matches and fringe indicators as review candidates, not automatic deletion decisions.

Implement

Read references/implementation.md before writing cross-platform page code.

Work from the outside in:

1. Reproduce the page geometry and responsive container behavior.
2. Build semantic sections and components.
3. Bind existing business data and states. Use isolated fixtures or mocks only when the repository has no suitable preview state; do not invent APIs, persisted records, workflow states, or navigation to make the screenshot render.
4. Place real visual assets with the correct crop and density.
5. Restore visible interactions and existing navigation or form behavior.
6. Check narrow and wide mobile widths without changing the requested design direction.

Preserve unrelated user changes. Reuse existing styles and components before introducing new abstractions. Keep the implementation scoped to the requested page or regions.

Validate

Read references/qa.md before handing off.

At minimum, for the platforms and tooling that the repository actually configures:

• Run the repository's type and lint checks for changed files.
• Build or run H5 and each target mini-program platform relevant to the request. An unconfigured platform is not a failure; record it as not applicable.
• Open the H5 page in an available browser at the reference state and mobile viewport. If H5 or browser execution is unavailable, validate the configured target runtime and report the missing visual evidence explicitly.
• Check console errors, failed images, clipping, overflow, safe-area behavior, and primary controls.
• Run scripts/compare_screenshots.py when Pillow is available, or create equivalent normalized side-by-side, overlay, and difference evidence. Inspect the combined comparison, not two screenshots in isolation.
• Record the result in design-qa.md when visual matching is part of the task. Do not claim completion while a P0, P1, or P2 mismatch remains.

Completion criteria

The task is complete only when:

• UI text and business values are selectable, accessible page content rather than pixels.
• Layout responds without horizontal overflow or broken overlap.
• Required interactions still work.
• Visual assets load cleanly and are not unnecessarily duplicated.
• Every relevant, repository-configured target build passes, or a genuine external blocker is reported with evidence. Targets the repository does not configure are marked not applicable.
• The visual comparison has no unresolved high- or medium-severity differences.