docs: harden demo email migration checks

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

@@ -8,22 +8,25 @@ data, and the deployed Coolify instance.
 
 ## Scope
 
-- Replace active `@agendapro.demo` references in application code, tests,
-  README, and operational documentation with `@agendamax.demo`; retain the old
-  domain only where this specification documents the migration itself.
+- 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 admin and owner accounts
-  with a targeted SQL change, preserving all other data.
+- 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 `users.email` values whose domain is `agendapro.demo`.
+updating only these two exact rows: `admin@agendapro.demo` 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
@@ -34,8 +37,11 @@ does not expose password values through the API.
 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. Run a targeted SQLite update inside the persistent production app volume:
-   `UPDATE users SET email = REPLACE(email, '@agendapro.demo', '@agendamax.demo') WHERE email LIKE '%@agendapro.demo';`
+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
@@ -43,11 +49,25 @@ deployment first and use the existing Coolify rollback procedure.
 
 ## Acceptance Criteria
 
-- `rg "agendapro\\.demo"` returns no active application, test, or README
-  references (historical notes may be explicitly excluded if any are retained).
+- `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.