# Verification and cutover boundaries

## What this package is

A fresh-install Laravel 13 / PHP 8.4 / MySQL application with compiled browser
assets and production Composer dependencies. It does not require a Node server,
Replit runtime, Redis, Supervisor, Docker, or a permanent worker in production.

The rebuild includes public pages, booking/tracking/private invoices, customer
portal and feedback, local accounts and permissions, repair/customer/store/
inventory administration, payments and receipts, wallet and loyalty effects,
employee operations, appointments/reports, CSV/XLSX/PDF inventory imports,
the public shop, warranty claims, and configurable provider integrations.

This is a staging-installation deliverable, not a claim that every original
screen, external integration, and historical record has been reconciled.

## Checks performed

- Automated PHP checks cover pricing/deposits, order/payment/status/loyalty
  effects, customer ownership, store scoping, employee permissions, feedback,
  shop stock and pricing, import validation, provider signatures/idempotency,
  stale-payment reconciliation, and installer safety.
- The domain schema was exercised on isolated MariaDB databases.
- A separate MySQL proof verified explicit installer-admin relocation during
  legacy import, preserving legacy IDs and leaving imported accounts inactive.
- An extracted ZIP was served through its optional public_html wrapper. Real
  HTTP forms completed setup-code verification, requirements, database testing,
  configuration, administrator creation, all migrations, permanent locking,
  and login. Public/admin pages and compiled CSS loaded successfully.
- The installer was visually checked in the development preview.

All test data was synthetic. Existing production records were not imported,
modified, or deleted.

## Before replacing a live site

1. Back up the existing website and databases.
2. Confirm PHP 8.4 and every extension listed by the installer on the actual
   cPanel account. Select the matching PHP version for both web and optional CLI.
3. Install on a staging domain or separate directory first. Do not overwrite an
   existing public_html directory without an intentional, backed-up cutover.
4. Configure the real business details, catalog, email sender and required
   provider credentials. No live email, SMS, WhatsApp, AI, Stripe payment or
   refund calls were made during development.
5. Verify the business's critical journeys on that host. In particular, test
   actual email delivery and Stripe's signed webhook callback in provider test
   mode before enabling live payments.
6. Reconcile historical data separately using docs/LEGACY_DATA_MIGRATION.md.
   Public registration never claims historical customers by matching email.
7. Change DNS only after staging acceptance and data reconciliation.

## Deliberate limitations

- AI voice handling is explicitly unavailable; a voice-provider workflow has
  not been verified. Configured text chat and saved handoffs are separate.
- PDF inventory parsing requires configured OpenAI and extractable PDF text.
  Image-only/scanned invoices are rejected rather than silently guessed; use
  the CSV/XLSX route or manually enter the inventory.
- Public registration requires working verification-email delivery. The
  installer administrator can configure email before inviting users.
- Stale successful Stripe charges are held for an administrator's reconciliation
  or real refund; they are never silently discarded or allocated as fake repair
  payments.
- No actual Namecheap installation, live-provider acceptance, complete visual
  parity audit, production-data export/import, or DNS cutover has been performed.