Create staking migration widget with Fuse approval flow, unified migration journey states, coverage, and demo app integration

[Copilot]

Implements the staking migration widget now that the issue is in executable [PLAN] state (draft removed), replacing the previous governance-only block.

What was added

• New package: @goodwidget/staking-migration-widget
  • Standard widget package shape with index, element, and register exports
  • Runtime contract/types for host config, statuses, steps, events, and adapter actions
  • React widget UI and state-driven rendering
  • Feature-local components for summary, timeline, step row, and status notices
• Adapter flow using provider-first architecture (GoodWidgetProvider + useWallet()):
  • Reads user Fuse sG$ staking balance
  • Validates required config (migrationApiBaseUrl, migrationOperator, optional token)
  • Validates network (Fuse / chain id 122)
  • Executes approval on Fuse before any migration API call
  • Submits approval tx hash to migration API and polls progress
  • Renders unstake → bridge sent → bridge received → stake with one active spinner
  • Preserves completed steps when later steps fail
  • Handles approval-failed and backend error with retry paths
• UX refinement to unify state experience into a single migration journey card:
  • Keeps summary, progress timeline, and state messaging in one consistent card layout
  • Treats wrong-network, approval pending/failed, migrating, success, and error as stages of the same journey
  • Adds clearer visual hierarchy with status badges and explicit step state indicators (completed / in progress / failed), including approval as the first journey step
• Follow-up UX refinements from PR feedback:
  • Implemented state-driven CTA progression:
    • Wrong network → Switch to Fuse
    • Ready → Approve and Migrate
    • Approval pending / migrating → disabled CTA
    • Success → Refresh balance
    • Error / approval-failed → Retry migration
  • Added wallet action wiring for Fuse network switching (wallet_switchEthereumChain) in adapter actions/runtime contract
  • Empty-balance state no longer shows an enabled migration CTA; it now avoids actionable migrate button until balance exists
  • Restored the summary card’s original visual emphasis (removed the “Migration Journey dominant” visual-weight adjustment) based on latest PR feedback
  • Added a persistent Current action block inside the migration journey so the active step/action remains visible without scrolling
  • Increased active step prominence in the stepper (highlighted active row + stronger active state marker)
  • Removed duplicated terminal success/error messaging outside the journey by surfacing outcome details directly in the timeline
• Demo app integration:
  • Added @goodwidget/staking-migration-widget to examples/react-web dependencies
  • Rendered StakingMigrationWidget in examples/react-web/src/App.tsx (default demo view) alongside the existing claim widget showcase
• Storybook coverage added under widget-specific folder:
  • examples/storybook/src/stories/staking-migration-widget/StakingMigrationWidget.stories.tsx
  • States: empty balance, wrong-network, approval-pending, migrating, success, error
• Playwright widget smoke coverage added:
  • tests/widgets/staking-migration-widget/states.spec.ts
  • Includes CTA/state assertions for empty balance, wrong network, approval pending, success, and error
  • Updated terminal-state assertions to match guided flow labels and timeline-driven outcome messaging
• Storybook workspace wiring updated to include the new widget package dependency.

Domain/source alignment

• Fuse staking contract source is aligned to GoodProtocol deployment mapping (production.FuseStaking), with Fuse/Celo migration context implemented in the widget’s adapter and state machine behavior.

Validation performed

• pnpm --filter @goodwidget/staking-migration-widget run lint ✅
• pnpm --filter @goodwidget/staking-migration-widget run build ✅
• pnpm --filter @goodwidget/storybook run build-storybook ✅
• pnpm --filter @goodwidget/example-react-web run lint ✅ (with existing warning)
• pnpm --filter @goodwidget/example-react-web run build ✅
• pnpm run build ✅
• pnpm exec playwright test tests/widgets/staking-migration-widget/states.spec.ts --list ✅

Note: full Playwright execution in this environment is currently blocked by missing Chromium headless-shell binary installation (playwright install hangs), so screenshot-producing runs could not complete here.

[blueogin]

@copilot I removed [DRAFT] from issue
please make code changes

[Copilot]

@copilot I removed [DRAFT] from issue
please make code changes

Implemented in commit 25ae9bc.

This adds the new @goodwidget/staking-migration-widget package (adapter + widget + element/register/index), Storybook state stories under examples/storybook/src/stories/staking-migration-widget/, and Playwright smoke coverage under tests/widgets/staking-migration-widget/states.spec.ts.

[blueogin]

• The migration flow covers the main states (wrong network, approval pending, migrating, success, and failed), which is good.
• However, the overall experience feels fragmented. Each state appears as a separate card rather than different stages of a single migration journey.
• The "Wrong Network" card feels isolated from the migration flow. It looks more like a standalone alert than the first step of the migration process.
• The "Migration Complete" and "Migration Failed" states also feel disconnected. They appear as separate notifications rather than a natural continuation of the migration progress state.
• I would expect the migration card to evolve through the different states (wrong network → approval pending → migrating → success/failure) while keeping a consistent layout and context.
• The migration progress screen is the strongest part of the design because it clearly shows what is happening. I would make that progress view the primary focus and have all other states build on top of it.
• The UI is also quite text-heavy. Users should be able to understand the current status immediately through stronger visual indicators, progress states, and clearer hierarchy.

[blueogin]

@copilot The migration flow covers the main states (wrong network, approval pending, migrating, success, and failed), which is good.
However, the overall experience feels fragmented. Each state appears as a separate card rather than different stages of a single migration journey.
The "Wrong Network" card feels isolated from the migration flow. It looks more like a standalone alert than the first step of the migration process.
The "Migration Complete" and "Migration Failed" states also feel disconnected. They appear as separate notifications rather than a natural continuation of the migration progress state.
I would expect the migration card to evolve through the different states (wrong network → approval pending → migrating → success/failure) while keeping a consistent layout and context.
The migration progress screen is the strongest part of the design because it clearly shows what is happening. I would make that progress view the primary focus and have all other states build on top of it.
The UI is also quite text-heavy. Users should be able to understand the current status immediately through stronger visual indicators, progress states, and clearer hierarchy.

[Copilot]

@copilot The migration flow covers the main states (wrong network, approval pending, migrating, success, and failed), which is good.
However, the overall experience feels fragmented. Each state appear...

Addressed in commit ce66e76.

The widget now stays as a single evolving migration journey card across wrong-network, approval-pending/failed, migrating, success, and failure. I moved summary + progress + state feedback into one consistent layout, added stronger status/progress indicators (badge + step states), and kept recovery actions inline with the same journey context.

[blueogin]

@copilot The top card ("Migrate Fuse staking to Celo savings") becomes somewhat redundant once migration starts.
During Approval Pending, Migrating, Success, and Error states, I'd consider reducing its visual weight.
The Migration Journey section should become the dominant element since it contains the most important information for the user.
The CTA button should evolve with the current state:
Wrong Network → "Switch to Fuse"
Ready → "Approve and Migrate"
Approval Pending → Disabled / Loading
Migrating → Disabled
Success → "Refresh Balance" or "View Savings"
Error → "Retry Migration"
In the Success and Error states, the colored status section feels slightly duplicated.
The Migration Journey already communicates the outcome.
Consider merging the sections or making the bottom status area more compact.
For the Empty Balance state:
I wouldn't show an enabled-looking "Approve and Migrate" button.
The button should either be hidden or clearly disabled with an explanation.

[blueogin]

@copilot Can you add the staking migration widget to the demo app?

[Copilot]

@copilot Can you add the staking migration widget to the demo app?

Implemented in commit 0dbdfc1.

I added the staking migration widget to the React demo app (examples/react-web) by wiring the workspace dependency and rendering StakingMigrationWidget in the default demo view.

[blueogin]

@copilot please refer this design(first image)
the main 'hero' card can easily be replicated by following the second image
Avoid duplicated success/error messaging if the stepper already communicates the outcome
Keep the overall widget structure, but make the migration journey feel like a guided step-based flow
The active step should be visually prominent so users immediately understand where they are
The active step/action should remain visible without requiring the user to scroll

[Copilot]

@copilot please refer this design(first image)
the main 'hero' card can easily be replicated by following the second image
Avoid duplicated success/error messaging if the stepper already communicates ...

Implemented in commit b61df67.

Updated the journey to feel more guided while keeping the existing widget structure: added a prominent "Current action" block near the top of the journey, strengthened active-step visual emphasis in the stepper, and removed duplicate success/error notice sections by surfacing terminal outcome details directly in the journey timeline.

[blueogin]

@copilot first screenshot is what you should chage
second secreenshot is stepper reference

[Copilot]

@copilot first screenshot is what you should chage
second secreenshot is stepper reference

Can you point me to the exact element/state from the first screenshot that should change (for example: hero card header, CTA area, status block, or step row styling), and which state(s) it applies to? If you can add one annotated screenshot, I’ll apply it precisely in the next commit.