Visual Verification

When the agent changes something in your project, the most reliable way to confirm it actually worked is to look at the editor viewport. ClaudusBridge gives the agent image-capture tools so it can see its own work, but a good result still comes from a tight loop of small changes and frequent looking — exactly how a human would verify in the editor.

The small-change / look / decide / repeat loop

Don't have the agent make a large batch of edits and check once at the end. Instead:

1. Make one small change. Spawn a single actor, set one material parameter, nudge one widget.
2. Look. Capture the viewport (or the relevant asset/editor image) and inspect the result.
3. Decide. Did it land where expected? Right size, right color, right place? If not, why?
4. Repeat. Apply the next small change, or correct the last one.

This keeps every change cheap to verify and cheap to undo. A wrong assumption is caught after one step instead of ten, and the capture you take is unambiguous because only one thing changed.

Capture quirks to know

The bridge's image tools behave differently depending on what they render:

• Viewport and asset captures render offscreen and work even when the editor is in the background. Prefer these for unattended verification.
• Editor-window captures need the editor foregrounded — they grab what's actually on screen, so bring the editor to the front first.
• Viewport captures want an explicit camera/transform and annotations. Even though those parameters read as "optional," provide them — an unframed capture often points nowhere useful, and annotations make before/after comparisons legible.

Durable editor quirks

These are editor behaviors that trip people (and agents) up regardless of what's being verified. Knowing them prevents "I changed it but nothing happened" confusion.

Materials: the Apply button

Editing a material's graph or parameters does not update what you see in the level until you Apply (or Save) the material. If a material change "didn't take," the change is real but unapplied — apply it, then re-capture. Verify the material after applying, not before.

Viewport realtime mode

A level viewport that is not in realtime mode won't continuously redraw, so animated or time-dependent changes (and sometimes freshly-applied material updates) can look stale in a capture. Enable realtime on the viewport before verifying anything that animates or depends on continuous rendering, or you may be looking at a frozen frame.

UMG: ProgressBar Percent

A ProgressBar's fill is driven by its Percent property (a normalized 0..1 value), not by its size. If a progress bar looks empty or full "wrong," check Percent rather than the widget's dimensions. Setting it to, say, 0.5 is what produces a half-filled bar.

UMG: CanvasPanelSlot LayoutData

When a widget lives inside a Canvas Panel, its position, size, anchors, and alignment are held in the slot's LayoutData (the CanvasPanelSlot), not on the widget itself. To move or resize it, edit the slot's layout — changing the widget directly won't reposition it. If a widget "won't move," confirm you're editing the CanvasPanelSlot LayoutData and not just the widget's own properties.

A good verification habit

Treat each capture as evidence, not decoration:

• Frame the capture on the thing you changed, and annotate it.
• Apply/save before looking when materials are involved.
• Make sure the viewport is in realtime mode for anything dynamic.
• For UMG, look at the driving property (Percent) or the slot (LayoutData), not just the widget.

Small change, look, decide, repeat — with these quirks in mind, the viewport tells you the truth about whether the work landed.