UI Test Visual Report

Provider-owned Codex pool UI before / after

This comparison uses two real local GoClaw dashboards seeded with the same fixture data. The only difference is the code revision: main@b38a078e versus fix@faf98c73. The screenshots below isolate the two regressions fixed by the PR: hidden saved pool membership on provider pages, and sticky custom routing state on agent pages.

Before Revision
b38a078e
origin/main
After Revision
faf98c73
PR branch
Fixture
codex-owner owns pool membership
codex-disabled is saved as a disabled member
solo-agent uses codex-solo with no saved pool defaults
Capture Method
Real local UI via Playwright
SQLite-backed gateways on separate ports

Scenario 1: provider page hides saved non-ready members

The provider page should show saved pool membership even when an extra account is disabled or not ready. Before the fix, the page derived membership only from quota-fetched ready accounts, so the saved member disappeared entirely.

What was broken on main

The pool owner codex-owner had a saved extra member codex-disabled, but the UI rendered 0 in pool, an empty account list, and no selectable extra account.

What the patch changes

The page now renders membership from the saved provider settings, while still limiting quota lookups to ready accounts only. The disabled member remains visible and clearly labeled as blocked.

Provider Detail
Before
Before fix: provider detail hides the saved disabled pool member.
Main branch behavior:
  • Available Extra Accounts is effectively empty.
  • Accounts in Pool shows 0 in pool.
  • The saved disabled member is invisible, so the provider-owned pool looks unsaved.
Provider Detail
After
After fix: provider detail shows the saved disabled pool member and pool count.
Fixed branch behavior:
  • Codex Disabled is visible in Available Extra Accounts.
  • Accounts in Pool correctly shows 2 in pool.
  • The disabled member is still shown as saved, with blocked state clearly surfaced.

Scenario 2: agent page manufactured a sticky custom override

When an agent had no explicit routing override and the provider had no saved pool yet, the UI should have represented that state as inherit / use provider defaults. Before the fix, the draft model incorrectly materialized it as a saved custom primary_first + [] state.

What was broken on main

The agent page defaulted to Custom For This Agent and framed the agent as if it had its own routing policy, even though there was no provider-owned pool and no explicit agent override saved.

What the patch changes

The draft state now preserves a true inherit mode. The UI shows Use Provider Defaults and clarifies that the agent stays on its primary account until provider-owned pool members are later added.

Agent Codex Pool
Before
Before fix: agent page defaults to Custom For This Agent even with no provider-owned pool.
Main branch behavior:
  • Custom For This Agent is selected by default.
  • The copy tells the user to configure provider members first before enabling pooled routing.
  • This makes the implicit default state look like an explicit agent override.
Agent Codex Pool
After
After fix: agent page defaults to Use Provider Defaults and explains the temporary primary-only behavior.
Fixed branch behavior:
  • Use Provider Defaults is selected.
  • The helper copy explains the temporary primary-only behavior without inventing a custom override.
  • The agent can stay in inherit mode now and automatically pick up provider pool members later.
Generated from a real local browser session using two SQLite-backed GoClaw instances. The frontends were served from separate Vite dev servers, authenticated with system + a local owner token, and seeded through the HTTP API with the same provider / agent records before capture.