Repository navigation
Description
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 inWalletSection.tsx, the reusable icon support inRoundButton.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.tsas 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.tsxregistry-driven so widgets reuse the existing grid and More drawer. - Use
src/widgets/AuthenticatedWidgetRoute.tsxfor the authenticated bottom-sheet boundary. - Use
src/widgets/WidgetRenderer.tsxto select the Web Component host by default or the React host when explicitly configured. - Pass the same small
{ provider, themeOverrides, config }contract throughsrc/widgets/hosts/WebComponentWidgetHost.tsxandsrc/widgets/hosts/ReactWidgetHost.tsx. - Use
src/widgets/provider/WidgetProvider.tsxandsrc/widgets/provider/RestrictedEip1193Provider.tsas 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.tsxsrc/widgets/registry.tssrc/sections/Home/components/WalletSection.tsxsrc/widgets/AuthenticatedWidgetRoute.tsxsrc/widgets/WidgetRenderer.tsxsrc/widgets/hostTypes.tssrc/widgets/hostProperties.tssrc/widgets/resolveReactWidget.tssrc/widgets/hosts/ReactWidgetHost.tsxsrc/widgets/hosts/WebComponentWidgetHost.tsxsrc/widgets/provider/WidgetProvider.tsxsrc/widgets/provider/RestrictedEip1193Provider.tssrc/widgets/provider/policy.tssrc/widgets/registry.test.tssrc/widgets/hostProperties.test.tssrc/widgets/resolveReactWidget.test.tssrc/widgets/provider/RestrictedEip1193Provider.test.tstests-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
Labels
Type
Projects
- StatusShow more project fieldsIn Review
Activity