feat: route-based demo lab + Playwright setup for Copilot cloud agent

[Copilot]

examples/react-web had no routing, no per-component demo pages, no stable test selectors, no Playwright config, and no cloud agent bootstrap. This PR converts it into a complete, Playwright-compatible demo lab.

Routing (examples/react-web)

• App.tsx → React Router shell; original OverrideShowcase content preserved at /theme-overrides
• / — index with link grid to all routes
• /components/:name — per-primitive demo pages, scoped to verified components from packages/ui/src/components/ only: Card, GlowCard, Drawer, TokenAmount
• /widget/claim — ClaimWidget demo with tab-based isolation (Default / Cobalt / Teal); only one widget instance is active at a time
• /theme-overrides — 5-tab OverrideShowcase unchanged in behavior

Components still in packages/ui/src/components-test/ (Button, Input, Alert, Badge, etc.) do not have dedicated demo pages until they are promoted to components/.

Route screenshots (verified working)

Route	Screenshot
/ (index)
/components/card
/components/glowcard
/components/drawer
/components/tokenamount
/widget/claim — Default tab
/widget/claim — Cobalt tab
/widget/claim — Teal tab

Known issues / TODO

• Drawer: React console warning Function components cannot be given refs — the Drawer component itself triggers this warning; it does not break rendering but should be fixed when Drawer is reviewed.

Wagmi mock connector

The /widget/claim page uses a lightweight mock EIP-1193 provider scoped to that route — no browser wallet required. The mock provider is passed as the provider prop to each ClaimWidget (which owns its own GoodWidgetProvider boundary), so every tab renders in a connected state showing the "Claim" button:

// src/mock/mockEip1193.ts
export const MOCK_ADDRESS = '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045'
export const MOCK_CHAIN_ID = 42220 // Celo mainnet

// Each tab mounts exactly one ClaimWidget with its own provider boundary
<ClaimWidget provider={mockProvider} />                               // Default tab
<ClaimWidget key="cobalt" provider={mockProvider} themeOverrides={cobaltOverrides} />  // Cobalt tab
<ClaimWidget key="teal"   provider={mockProvider} themeOverrides={tealOverrides} />    // Teal tab

ClaimWidget tab isolation

Tamagui resolves theme tokens at mount time. Rendering multiple GoodWidgetProvider trees with different themeOverrides simultaneously causes the last-mounted provider to win for shared theme keys. The tab-based layout (mirroring /theme-overrides) ensures only one ClaimWidget is mounted at a time, giving each instance a clean, isolated Tamagui theme context with no style bleed between overrides.

Stable selectors

data-testid on key elements following ComponentName-variant convention (e.g. Card-default, GlowCard-default, tab-default, nav-Card, tab-cobalt, tab-teal).

Playwright

• playwright.config.ts at repo root — Chromium, baseURL: http://localhost:3000, screenshot always, trace on first retry, video on failure, reuseExistingServer: true
• tests/demo/smoke.spec.ts — smoke test per verified component route + tab cycling for /theme-overrides + three separate tab tests for /widget/claim (default, cobalt, teal)
• Root package.json: "test:demo": "playwright test tests/demo" + @playwright/test dev dep

Cloud agent bootstrap

.github/workflows/copilot-setup-steps.yml — corepack enable, pnpm install, pnpm build, playwright install chromium --with-deps

Docs

• docs/demo-environment.md — route map, testid convention, mock wallet rationale, cloud agent quick-start, and guidance on when to add new component demo pages
• AGENTS.md / ARCHITECTURE.md — updated with demo environment section and monorepo layout

No changes to packages/ui, packages/core, packages/claim-widget, or packages/embed.

[L03TJ3]

@copilot please revert all demo-able flows which are based on components that are in components-test
the only verified components can be found in components

[Copilot]

@copilot please revert all demo-able flows which are based on components that are in components-test
the only verified components can be found in components

Done in commit 056d8d4. Removed all 16 demo pages for components still in components-test/ (Button, Input, Alert, Badge, Spinner, Select, Checkbox, Switch, Separator, Heading, Text, WalletInfo, AddressDisplay, ChainBadge, Toast, ActionSheet). The /components/:name route now only serves the four verified components from packages/ui/src/components/: Card, GlowCard, Drawer, TokenAmount. The index page, App router, smoke tests, and docs were updated to match.

[L03TJ3]

@copilot okay, can we test the flow and you sharing screenshots of the different routes.
if things are not working or breaking, try and fix them or document them in the pull-request description as 'todo' items

[L03TJ3]

@copilot, can you fix the mocked wagmi flow so we can also test and take screenshots from the claim-widget example and include them in the pull-request description?

[Copilot]

@copilot, can you fix the mocked wagmi flow so we can also test and take screenshots from the claim-widget example and include them in the pull-request description?

Fixed in commit 7c11fd7. The root cause was that each ClaimWidget creates its own internal GoodWidgetProvider, so the outer page-level mock provider wasn't visible to useWallet() inside the widget. The fix passes provider={mockProvider} directly to each <ClaimWidget> instance, so all three now render in the connected state with the "Claim" button.

All three instances (Default, Cobalt override, Teal override) now show "Claim":

[L03TJ3]

@copilot The claimwidget page demo is not truly showcasing isolation, rather, it shows a limitiation of how tamagui handles different providers on the same page and clashing styling assigment. (all widget examples show only the last assigned themeOverrides, in this case, teal)

The better way to showcase the isolation of components with different themeOverrides is to follow the themeOverrides pages setup and put them behind different tabs (render upon tab active)

[Copilot]

@copilot The claimwidget page demo is not truly showcasing isolation, rather, it shows a limitiation of how tamagui handles different providers on the same page and clashing styling assigment. (all wi...

Fixed in commit 985295b. The page now uses the same tab pattern as ThemeOverridesPage — only the active tab's ClaimWidget is mounted, so there's never more than one GoodWidgetProvider with themeOverrides in the tree at a time. This eliminates the Tamagui theme-clash (last-mounted provider winning).

Each tab renders its widget cleanly in isolation:

Default tab — preset baseline, no overrides:

Cobalt tab — cobalt brand themeOverrides:

Teal tab — teal brand themeOverrides:

The smoke tests were updated to match: each tab is now tested independently by clicking tab-cobalt / tab-teal before asserting the widget testid.

[L03TJ3]

@copilot Goal:
Convert the current route-based demo lab iteration into a Storybook-based demo system for GoodWidget.
Update and make the changes in a new pull-request branched out from copilot/feat-route-based-demo-lab-playwright-setup.

Context:
This PR proved that the repo can support:

• local browser demo execution
• Playwright in Copilot cloud agent
• deterministic widget demos
• mock wallet/provider setup
• screenshots, traces, and video artifacts
• stable selectors for automated validation

Do not treat the existing route-based examples/react-web approach as something that must be preserved.
It was a useful test iteration. The new target is Storybook-first.

GoodWidget needs a demo/docs environment because it is:

• a component library
• a design system
• a widget framework
• an ecosystem widget platform where integrators can choose protocol features to expose

The environment should let developers and external contributors:

• browse primitives
• inspect widgets
• play with args/controls
• test token overrides
• test component theme overrides
• test host/integrator themeOverrides
• understand the design-system contract through clear examples
• use generated docs instead of relying only on README guidance
• run visual and interaction checks consistently

Task:
Refactor PR #6 toward Storybook.

Implementation direction:

1. Add Storybook for React + Vite.
2. Prefer a dedicated Storybook package/location, for example:
   • examples/storybook
     or another clean monorepo package if better.
3. Move the useful demo concepts from examples/react-web into Storybook stories.
4. Do not maintain duplicate route-based demo pages.
5. Keep Playwright/cloud-agent compatibility, but point it at Storybook instead of the route app where practical.

Storybook must support:

• component stories
• widget stories
• args/controls
• autodocs
• interaction tests with play functions
• visual/screenshot testing through Playwright or Storybook-compatible test tooling
• deterministic mock wallet/provider stories
• theme/token/brand-kit override exploration

Initial representative stories:

• Card
• GlowCard
• Drawer
• TokenAmount
• ClaimWidget
• Theme override / brand-kit playground

Theme playground requirements:
Create at least one Storybook story or story group where users can switch or experiment with:

• default GoodWalletV2 preset
• token overrides
• component theme overrides
• host themeOverrides-style runtime overrides

The story/docs copy must clearly explain:

• token overrides are broad design-system inputs
• component themes are targeted visual overrides
• host themeOverrides are runtime integrator overrides
• named component parts are API-like and should not be exposed accidentally

Playwright/cloud-agent requirements:

• Update Playwright config so automated tests can target Storybook.
• Keep screenshots enabled.
• Keep traces enabled.
• Keep video-on-failure or equivalent.
• Ensure tests run in Copilot cloud agent.
• Update .github/workflows/copilot-setup-steps.yml if needed.
• Ensure Storybook can run on localhost in the cloud-agent environment.
• Add or update scripts so an agent can run:
  • install/build
  • start Storybook
  • run Storybook smoke/interaction/visual checks

Suggested scripts:

• pnpm storybook
• pnpm build-storybook
• pnpm test:storybook
• optionally keep pnpm test:demo only if still meaningful

Repository cleanup:

• If examples/react-web is no longer the canonical demo surface, update docs to say so.
• Remove route-demo documentation that no longer applies.
• Do not leave misleading docs that describe examples/react-web as the canonical demo lab.
• Reuse mock wallet/provider utilities from PR feat: route-based demo lab + Playwright setup for Copilot cloud agent #6 if useful, but move them to a shared demo/test fixture location so that Storybook can use it.

Documentation requirements:
Update or create docs explaining:

• Storybook is the canonical GoodWidget demo/docs environment
• how to run Storybook locally
• how to run it in Copilot cloud agent
• how to add a new primitive story
• how to add a new widget story
• how to write args/controls
• how to add theme override examples
• how to add interaction tests
• how to generate screenshots/traces/videos
• expectations for outside contributors adding demos

Acceptance criteria:

• Storybook runs locally.
• Storybook builds successfully.
• Representative stories exist.
• Autodocs are enabled and visible.
• Args/controls are useful for at least the representative primitives.
• Theme/brand-kit override playground exists.
• ClaimWidget renders in Storybook with deterministic mock wallet/provider state.
• At least one interaction test exists.
• Automated tests target Storybook and produce useful artifacts.
• Copilot cloud-agent setup works with the new Storybook flow.
• Documentation reflects Storybook as the primary demo system.
• The previous route-based app is removed.

Validation commands:
Run the relevant commands and report results:

• pnpm install
• pnpm build
• pnpm build-storybook
• pnpm test:storybook
• any remaining demo/test commands if kept
• Run playwright and recreate screenshots.

Important:
This should be a Storybook-first conversion of PR #6, not an additive “support both” setup.
Only document if there is a concrete technical reason that Storybook cannot cover a specific flow and why its not included (yet).

[Copilot]

@L03TJ3 I've opened a new pull request, #8, to work on those changes. Once the pull request is ready, I'll request review from you.

[L03TJ3]

Closing this in favor of #8 where we introduce storybook