Skip to content

Feature Request: Prepare GoodWallet for GoodWidget Integration #52

Description

@L03TJ3

Assume GoodWallet PR #51 is not merged. Use its widget runtime work as the reference, but do not merge or reproduce its release-to-Copilot automation.

Feature summary

Add one reusable, authenticated path for integrating reviewed @goodwidget/* packages into GoodWallet.

A widget should be added through a typed registry and a small bottom-sheet route. It should receive only a restricted EIP-1193 provider and optional theme/public configuration.

Problem or opportunity

Without a shared integration boundary, every widget would need custom dashboard, routing, session, package-loading, and wallet-provider code.

GoodWallet instead needs a single reviewed foundation so a later widget integration is normally limited to an exact dependency update, one registry entry, one route, an icon, and focused tests.

Proposed solution

  • Selectively replicate the runtime work from GoodWallet PR #51: src/widgets/**, the registry-driven dashboard changes in WalletSection.tsx, the reusable icon support in RoundButton.tsx, and their focused tests. Do not copy its workflows, custom agent, dispatch processor, release scripts, CODEOWNERS changes, or automation documentation.
  • Use src/widgets/registry.ts as the reviewed source for widget package identity, exact version, literal entry imports, integration mode, route, label/icon, chains, and provider methods.
  • Keep src/sections/Home/components/WalletSection.tsx registry-driven so widgets reuse the existing grid and More drawer.
  • Use src/widgets/AuthenticatedWidgetRoute.tsx for the authenticated bottom-sheet boundary.
  • Use src/widgets/WidgetRenderer.tsx to select the Web Component host by default or the React host when explicitly configured.
  • Pass the same small { provider, themeOverrides, config } contract through src/widgets/hosts/WebComponentWidgetHost.tsx and src/widgets/hosts/ReactWidgetHost.tsx.
  • Use src/widgets/provider/WidgetProvider.tsx and src/widgets/provider/RestrictedEip1193Provider.ts as the only bridge to the active Wallet session. Never expose the signer, seed, or session internals.
  • Keep the global security boundary in src/widgets/provider/policy.ts. A widget's approved method list must restrict its requests at runtime, not merely validate that GoodWallet supports those methods.
  • Require a Wallet-owned user approval step for signing and transaction requests. Until that exists, signing-capable widgets must remain disabled.

Acceptance criteria

  • The typed registry rejects duplicate widget IDs/routes, unsupported chains/methods, and non-exact package versions.
  • Web Component mode is the default and React mode can be selected in one reviewed registry entry.
  • Registry actions reuse the existing dashboard grid and responsive More drawer without changing the six core actions.
  • An authenticated bottom-sheet route can mount a registered widget without widget-specific session code.
  • Both hosts lazy-load on the client and pass the same small host contract.
  • Web Component object properties are assigned without HTML serialization and cleared on unmount.
  • Each widget can call only its reviewed EIP-1193 method subset on its reviewed chains.
  • Every signing request validates the active account and chain and passes through explicit Wallet-owned approval.
  • Widget code never receives the underlying signer, seed, unrestricted RPC provider, or session internals.
  • Unit tests cover registry validation, integration-mode selection, property handoff/cleanup, method restriction, chain/account validation, and provider errors.
  • Desktop and mobile Playwright tests cover authenticated opening through the dashboard/More drawer and preserve the existing layout behavior.
  • Type checking, unit tests, the production build, and Playwright tests pass.

Additional context

Primary references:

  • GoodWallet PR #51, only for the runtime/dashboard/provider portions described above
  • src/components/Form/RoundButton/RoundButton.tsx
  • src/widgets/registry.ts
  • src/sections/Home/components/WalletSection.tsx
  • src/widgets/AuthenticatedWidgetRoute.tsx
  • src/widgets/WidgetRenderer.tsx
  • src/widgets/hostTypes.ts
  • src/widgets/hostProperties.ts
  • src/widgets/resolveReactWidget.ts
  • src/widgets/hosts/ReactWidgetHost.tsx
  • src/widgets/hosts/WebComponentWidgetHost.tsx
  • src/widgets/provider/WidgetProvider.tsx
  • src/widgets/provider/RestrictedEip1193Provider.ts
  • src/widgets/provider/policy.ts
  • src/widgets/registry.test.ts
  • src/widgets/hostProperties.test.ts
  • src/widgets/resolveReactWidget.test.ts
  • src/widgets/provider/RestrictedEip1193Provider.test.ts
  • tests-playwright/wallet-flows.e2e.ts

New widget routes should follow:

src/app/[locale]/@home/(home)/(bottomsheet)/<route-slug>/page.tsx

Out of scope:

  • implementing or publishing a GoodWidget package
  • widget-owned UI, actions, transaction state, success state, or errors
  • .github/workflows/goodwidget-released.yml, .github/agents/widget-integrator.agent.md, scripts/widget-release/**, repository dispatch, Copilot tasks, and other CI/CD automation from PR Setup support and ci/cd handling updating and integrating verified production released widgets #51
  • autonomous approval or merging
  • installing AI Credits itself; that should be a small follow-up after both repository preparation tasks are complete

Create the plan

Create an execution plan in a new sub-issue and leave this feature request unchanged. Do not implement it until instructed.

  • Title: [DRAFT][PLAN] Prepare GoodWallet for GoodWidget integration
  • Type: Task
  • Start the description with the sub-issue title.
  • Link the sub-issue to this feature request.
  • Start from the exact reference paths and the limited PR Setup support and ci/cd handling updating and integrating verified production released widgets #51 diff above.
  • Separate reusable Wallet foundation work from a later widget-specific dependency, registry, route, icon, and test change.
  • Include only required behavior, execution steps, acceptance criteria, and a human-reviewer checklist.
  • Do not plan changes in the GoodWidget repository.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions