# Demo Accesses and Email Domain

## Goal

Make the demo credentials easy to use and standardize the platform demo accounts
from `@agendapro.demo` to `@agendamax.demo` in source data, documentation, local
data, and the deployed Coolify instance.

## Scope

- Replace active positive `@agendapro.demo` references in application code,
  tests, README, and operational documentation with `@agendamax.demo`; retain
  the old domain only in migration-history documentation or explicit
  negative-login assertions.
- Keep the existing demo password `demo1234` and expose it clearly beside each
  demo account in `README.md`.
- Update the local SQLite demo users without deleting businesses, appointments,
  or other seeded records.
- Deploy the code to the existing AgendaMax Coolify application.
- Update the persistent production SQLite users for the exact admin and owner
  accounts with a targeted SQL change, preserving all other data.

## Data Flow

Fresh databases receive the new admin and owner emails from `server/scripts/seed.ts`
and `server/index.ts`. Existing local and production databases are migrated by
updating only these two exact rows: `admin@agendapro.demo` and
`owner@agendapro.demo`. If the active database is fresh and already contains the
new emails, the SQL update is a no-op and is skipped.

The employee accounts already use their business domains and are not changed.
Login verification uses `POST /api/auth/login` with the documented password and
does not expose password values through the API.

## Production Procedure

1. Run the local checks and build.
2. Push the change to the AgendaMax source mirror used by Coolify.
3. Trigger and monitor a Coolify deployment.
4. Inspect the exact old/new admin and owner rows. If an old row and its matching
   new row both exist, stop and resolve the unique-email collision. If no old
   rows exist and the new rows are present, record a safe no-op. Otherwise run a
   targeted SQLite update inside the persistent production app volume:
   `UPDATE users SET email = CASE email WHEN 'admin@agendapro.demo' THEN 'admin@agendamax.demo' WHEN 'owner@agendapro.demo' THEN 'owner@agendamax.demo' END WHERE (email = 'admin@agendapro.demo' AND role = 'admin') OR (email = 'owner@agendapro.demo' AND role = 'owner');`
5. Verify health, login for admin and owner, and the production page.

If deployment fails, do not run the production SQL migration; inspect the
deployment first and use the existing Coolify rollback procedure.

## Acceptance Criteria

- `rg "agendapro\\.demo"` returns no active positive application, test, or
  README references; only explicit negative-login assertions and
  migration-history documentation may retain the old domain.
- README lists every demo account with email and `demo1234`.
- Fresh seed creates `admin@agendamax.demo` and `owner@agendamax.demo`.
- Existing local data contains the new emails and retains its records.
- Coolify deployment finishes successfully.
- Production `/api/health` returns `ok: true`.
- Production admin and owner logins succeed with `demo1234`.
- Production admin and owner logins using the old domain return `401`.
- README employee emails exactly match the accent-preserving emails generated by the seed.
- The targeted SQL pairs each old email with its matching role and never rewrites
  another old-domain user.

## Known Verification Limitation

The already-migrated local database has null `businesses.working_hours` and
employee `working_hours` values. As a result, the slot-dependent `test:e2e` and
`test:booking` assertions can fail before booking, including their existing
downstream dereference. This is a pre-existing scheduling-data limitation,
unrelated to the email-domain change; do not change working-hours data for this
task.