Add secure GoodWidget integration boundary

[Copilot]

Prepares GoodWallet to host reviewed GoodWidgets through authenticated bottom-sheet routes while keeping wallet authority behind a restricted runtime provider boundary.

• Registry and routing

  • Added typed registry validation for exact versions, IDs/routes, chains, methods, and integration mode.
  • Added registered-widget-only bottom-sheet route resolution.

• Secure provider boundary

  • Exposes a restricted EIP-1193 facade only.
  • Enforces per-widget methods, chains, active account, typed-data chain, and transaction chain.
  • Defaults signing and transactions to denied without Wallet-owned approval.

await provider.request({
  method: "personal_sign",
  params: [message, activeAccount],
})

• Widget hosts

  • Added lazy client-side Web Component and React hosts.
  • Web Components receive provider, themeOverrides, and config as object properties and clear them on unmount.
  • Web Components remain the default; React requires explicit registry selection.

• Dashboard

  • Integrated registry-driven widget actions without changing the six core action order or More-drawer behavior.
  • Added reusable local/system icon support.

• Coverage

  • Added focused registry, provider-policy, host cleanup, and React resolution tests.
  • Added desktop and mobile dashboard layout assertions.

• Fixes [PLAN] Prepare GoodWallet for GoodWidget integration #53

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
good-wallet-v2	Ready	Preview	Jul 31, 2026 3:48pm

[blueogin]

@copilot
review this pr

[L03TJ3]

@blueogin
Can you confirm first because I think some review points were specifically introduced by you.
So maybe it made sense to have. Why for example are we replacing session state?
that means if I have a logged in regular wallet I also have to sign in?

delegate to copilot or fix yourself whatever still needs to be done:

---

Please simplify and tighten this PR before it is merged.

1. Revert the session-persistence changes from this PR

Restore the existing session behavior in:

• src/login/context/SessionContext/storage.ts
• src/login/context/SessionContext/storage.test.ts
• src/login/hooks/context.ts
• src/sections/Options/OptionsView.tsx

PR #54 currently deletes SIGNER_SESSION during module initialization and stops restoring or persisting sessions (storage.ts:6-14,38-48). This is a breaking login/session change that is outside the scope of the widget integration work.

If persisted seeds are considered unsafe when widgets run on the wallet origin, handle that as a separate security task with an explicit product decision, migration plan, and user-facing acceptance criteria. Do not silently change session persistence as part of PR #54.

2. Remove unused backward-compatibility code

Simplify src/components/Form/RoundButton/RoundButton.tsx to the API used by its only caller:

• Keep icon, iconElement, text, and indicator.
• Remove RoundButtonType, buttonType, buttonIcons, fill, and the legacy fallback branches at RoundButton.tsx:7-47,62-74.

The only current caller is src/sections/Home/components/WalletSection.tsx:250-255, and it already uses the new API. There is no repository consumer requiring the old API.

Also remove unused widget API that exists only for anticipated compatibility, unless a real consumer is added:

• DEFAULT_WIDGET_INTEGRATION_MODE and resolveWidgetIntegrationMode in src/widgets/registry.ts:10-13,59-62
• Unused chainId, supportedMethods, and isRevoked getters in src/widgets/provider/RestrictedEip1193Provider.ts:159-169

3. Start with the minimum provider capability set

Reduce src/widgets/provider/policy.ts:14-61 and RestrictedEip1193Provider.ts to the methods and chains required by the first concrete widget or test fixture.

Keep the provider extensible so a later reviewed registry change can add a method or chain when an actual widget needs it. Do not pre-support 25 methods, 10 chains, and transaction variants without a demonstrated consumer.

Retain the security-critical behavior:

• Global and per-widget method allowlists
• Per-widget chain allowlists
• Active-account and active-chain validation
• Wallet-owned approval before signing or sending transactions
• Provider revocation and Web Component property cleanup
• No signer, seed, unrestricted provider, or session object in widget props

Avoid adding generalized transaction normalization, concurrency handling, or compatibility behavior until a concrete flow and test require it.

4. Prove the actual widget flow

src/widgets/registry.ts:147 currently leaves WIDGETS empty, while tests-playwright/wallet-flows.e2e.ts:70-110 tests only the original six wallet actions.

Add a minimal test-only widget fixture and desktop/mobile coverage that proves:

1. A registered widget opens from the dashboard.
2. It opens from the expanded More drawer on the constrained layout.
3. It mounts inside the authenticated bottom sheet through [widgetRoute]/page.tsx.
4. An unregistered widget route is rejected.

[blueogin]

@L03TJ3 Confirmed - that was intentional from my side.

I removed session persistence because widgets share origin and could read SIGNER_SESSION / masterSeed from localStorage, bypassing the restricted provider.

You’re right that this also forces normal wallets to sign in again after refresh. I’ll revert storage.ts and keep the existing session behavior.

[blueogin]

@L03TJ3 Done - addressed your points:

Restored session persistence
Removed unused RoundButton / widget helpers
Reduced provider allowlist to the minimum fixture set
Added a Playwright-only test fixture with desktop/mobile coverage for open / More / mount / unregistered rejection