Verifying Ui

Verifying UI

Your human partner decides whether UI work is right, by looking at what the running app actually shows next to what they approved. Your own check — a browser measurement, a passing test, a glance at a screenshot, the project's own app-checking skill — is not the verdict. The work is done when every verify group on the page is passed.

REQUIRED BACKGROUND: ryugi:artifacts — its artboard.md covers image and video boards, verify groups and reading verdicts.

Work with no visible change skips this skill: logic already proven by tests, CLI or terminal output, a tweak your human partner watched you make live.

Before fixing a visible bug

Capture the broken state from the running app now, while you reproduce it. After the fix there is no honest "before".

The verify page

1. Where. The artboard that holds the approved design gets a page verify (name "Verify"). No such artboard (a bug, work that skipped brainstorming, or a design approved on a claude.ai canvas): a new artboard verify-<topic>, with the canvas link in each group's sticky.
2. One group per module or per bug, "verify": true, titled with the module or bug:
   • Built from a spec: the approved board (a board with the same file) on the left, a screenshot of the real app on the right. A module with interaction also gets a short recording of it. No approved board: the screenshot alone, titled with the spec's requirement.
   • A bug: before on the left, after on the right; add a recording when the bug is about behaviour.
3. Evidence is real. Screenshots and recordings come from the running app, with whatever tool this environment has — a project skill that drives the app is a fine source. Never an HTML board standing in for "actual". Copy evidence under pages/verify/; keep each video under 8MB and the artboard under 20MB. Over 20MB the cloud copy stops updating: say so and shrink or drop the largest recordings.
4. Set focus to the first group, check that warnings and pending are empty, give the link (the cloud link when there is one), say what each group shows, and ask them to tell you here when they have decided. End your turn; don't poll.

Running the checks

Before the first run, read how the project says to verify (its agent instructions, acceptance or verification docs) and follow its commands and output conventions over your own habits.

Each check has one output location. A retry or rerun writes over the previous result; never create numbered copies (-1, -2, -final) of the same check. Keep two runs side by side only when the point is comparing two builds, and name them for the builds. Delete scratch output you created once the evidence you need is copied to the verify page.

Prepare each recording

Add the original recording normally; Artifacts prepares Verify videos automatically. Replay the video on the Verify page: every action, loading or error state, and final result must remain visible. When original timing or narration is itself evidence (performance, timeouts), set "trim": false on that video board.

When verdicts come back

On their next message, run comment list and read groups.

• pass: done for that group. Leave its files alone.
• reject: read the reason and any pins on its boards, and fix it inside that group:
  • Behaviour or state (wrong content, a disabled control, a broken flow): under ryugi:test-driven-development.
  • Look only (layout, spacing, color, type): the rejected screenshot is the failing reproduction and the new screenshot is the check.
  • One commit per fix; exploratory work stays uncommitted, as ryugi:executing-specs says.
  • Replace the evidence (same file, or add a board to the group), reply on the reject thread with what changed and the commit, and leave the thread open.
  • The fix changes what a passed group shows: replace that group's evidence too — it goes back to pending — and say so in your reply.
• pending: waiting on your human partner. Say so; don't call it done.

Your final message is "done" only when every verify group has passed. Until then it carries the link and what is waiting on whom.

A new round is for new work on the same page — a later spec, another bug — not for a reject. Put it below the last round with new groups. Passed groups of earlier rounds drop "verify": true; groups that have not passed keep it.

Red Flags