Laravel API + Next.js Marketplace Migration Plan and Copilot Prompt

Act as a senior software architect. Analyze the project report below and produce (1) a phased migration plan from the current prototype to a Laravel API backend with a Next.js frontend, and (2) an implementation prompt I can give to a coding assistant such as GitHub Copilot, one phase at a time. Base every decision on the report and requirements; where they are silent, state the assumption.

## Inputs
Project summary and market: [PROJECT]
Current state report (stack, folders, implemented and mocked features, known gaps): [CURRENT_REPORT]
Target backend: Laravel [LARAVEL_VERSION] with [BACKEND_PACKAGES] (for example Sanctum, Horizon, Filament, Scout)
Target frontend: Next.js [NEXTJS_VERSION] App Router
Capacity targets supported by evidence (current users, expected peak requests per second, catalog size): [CAPACITY_TARGETS]
Market-specific requirements (currencies, payment methods, offline use, messaging channels): [MARKET_REQUIREMENTS]
Design constraints (existing UI style that must be preserved): [DESIGN_CONSTRAINTS]
Team size and timeline: [TEAM_AND_TIMELINE]

## Instructions
1. Summarize the current state and the gaps that block production (no backend, local-only data, simulated login, no payments, missing tests, no RBAC, no monitoring, no i18n).
2. Propose phases with exit criteria, starting with the data model, authentication and RBAC, and the core order flow before growth features (referrals, coupons, loyalty).
3. Backend: domain model and migrations, REST API resources, Sanctum (first-party SPA/mobile tokens) or Passport (if third parties need OAuth), queues with Horizon on Redis, admin and merchant panels with Filament, search through Scout with the chosen engine. Verify each package's support for [LARAVEL_VERSION] in its official docs.
4. Frontend: migrate existing components without changing their look; choose rendering per page (static with revalidation for product pages, dynamic for cart, checkout and dashboards); per-merchant theming through configuration, not forks.
5. Money and currencies: store amounts as integer minor units with a currency code; store the exchange-rate source, rate and timestamp used for every order; define who updates rates and how often. List every required currency and regional rate explicitly and resolve inconsistencies in [MARKET_REQUIREMENTS].
6. Offline merchant work: define which operations work offline, the local store (IndexedDB), the sync protocol, idempotency keys and conflict resolution (for example stock edited offline and online).
7. Messaging commerce: use the official business messaging API, with customer opt-in and pre-approved message templates where the provider requires them.
8. Security and compliance: CSRF for cookie sessions, rate limiting, validated requests and parameterized queries, encryption of sensitive fields, audit logs for payments and admin actions, privacy policy and data-retention rules for [MARKET_REQUIREMENTS] jurisdictions.
9. Infrastructure: object storage and CDN for images, environments, backups, monitoring and error tracking, CI/CD. Size it from [CAPACITY_TARGETS] and include a load-test step before launch instead of assuming a user count.

## Return
1. Current-state assessment.
2. Target architecture diagram (text) and component list.
3. Phased roadmap with exit criteria and dependencies.
4. Data model outline (users, roles, merchants, stores, products, variants, inventory, carts, orders, payments, currencies and rates, coupons, referrals, loyalty, sync events).
5. The coding-assistant prompt, split by phase, each part naming the files to create, conventions to follow and tests to write.
6. Risks, open questions and assumptions.

## Acceptance checks
- No scale, speed or search-ranking outcome is promised; capacity work is tied to [CAPACITY_TARGETS] and a load test.
- Versions and package compatibility are stated as items to verify, not assumed.
- Currency handling never uses floating point and records the rate used per order.
- The existing visual design is preserved in every frontend phase.