AgendaPro/docs/superpowers/specs/2026-07-27-demo-email-domain-design.md

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: [email protected] and [email protected]. 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 '[email protected]' THEN '[email protected]' WHEN '[email protected]' THEN '[email protected]' END WHERE (email = '[email protected]' AND role = 'admin') OR (email = '[email protected]' 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 [email protected] and [email protected].
• 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.