# EKSRelay — TODO / known follow-ups

## 1. Produkcyjna skrzynka e-mail w Chatwoot: uniknąć importu całej historii

**Status:** do rozpoznania przed podpięciem `info@easyklima.com` jako produkcyjnej skrzynki w Chatwoot.

### Problem

Jeśli do Chatwoot zostanie podpięta obecna produkcyjna skrzynka z dużą historią maili, Chatwoot może zacząć pobierać i tworzyć konwersacje dla tysięcy starych wiadomości. To grozi:

- zaśmieceniem Chatwoot historycznymi konwersacjami,
- uruchomieniem webhooków/bota dla starych maili,
- kosztami Flowise/OpenAI,
- błędnym odpowiadaniem na dawne wiadomości,
- trudnym do odwrócenia bałaganem operacyjnym.

### Cel

Do Chatwoot mają trafić tylko wiadomości przychodzące **od momentu wdrożenia / cutover**, a nie cała historia skrzynki.

### Hipotezy i opcje do sprawdzenia

1. **Nowa pusta skrzynka produkcyjna + forwarding od daty wdrożenia**
   - Utworzyć nowy mailbox/alias docelowy dla Chatwoot.
   - Od momentu cutover przekierować nowe wiadomości z `info@easyklima.com` do tej skrzynki.
   - Najbezpieczniejsza opcja, bo Chatwoot widzi pustą historię.

2. **Reguła po stronie Amazon WorkMail / mail gateway**
   - Sprawdzić, czy da się ustawić regułę forwardowania/kopii tylko dla nowych maili.
   - Nie importować istniejących wiadomości przez IMAP.

3. **IMAP folder cutover**
   - Stworzyć nowy pusty folder, np. `Chatwoot-Inbox`.
   - Od momentu wdrożenia reguła przenosi/kopiuje nowe maile do tego folderu.
   - Chatwoot podpina się tylko do tego folderu, jeśli jego integracja IMAP pozwala wskazać folder.

4. **Archiwizacja/przeniesienie historii przed podpięciem**
   - Przenieść stare wiadomości poza folder `Inbox` przed uruchomieniem synchronizacji Chatwoot.
   - Ryzykowne operacyjnie, wymaga backupu i ostrożności.

5. **Sprawdzenie mechanizmu Chatwoot IMAP**
   - Ustalić, czy Chatwoot ma ustawienie typu `since`, UID start, import only new, albo ograniczenie zakresu synchronizacji.
   - Jeśli nie ma — nie polegać na samym Chatwoot jako zabezpieczeniu.

### Wymagana decyzja przed produkcją

Nie podpinać produkcyjnego `info@easyklima.com` bez wcześniejszego testu na kopii/nowej skrzynce i jednoznacznego potwierdzenia, że stare wiadomości nie zostaną zaimportowane.

### Minimalny plan bezpiecznego cutover

1. Zrobić backup/eksport listy obecnych folderów i liczników wiadomości na skrzynce.
2. Przetestować zachowanie Chatwoot na testowej skrzynce z kontrolowaną historią.
3. Wybrać jeden wariant: preferowany **nowy pusty mailbox/alias + forwarding od cutover**.
4. Na czas pierwszego testu produkcyjnego ustawić w EKSRelay dodatkowy bezpiecznik:
   - `WORKER_ENABLED=false` albo
   - tymczasowo ograniczyć przetwarzanie tylko do testowego inbox/conversation,
   żeby ewentualny import historii nie odpalił masowo Flowise.
5. Po potwierdzeniu, że Chatwoot widzi tylko nowe wiadomości, włączyć worker i wykonać smoke test.

## 2. WordPress Store API auth

Stary plugin `wp-plugins/eksrelay_api.php` nadal ma otwarte `permission_callback => __return_true`.

EKSRelay potrafi już wysyłać `Authorization: Bearer <WP_STORE_API_SECRET>`, ale WordPress musi zacząć ten sekret wymuszać po stronie endpointów.

## 3. Rotacja sekretów po wdrożeniu

Po sesji wdrożeniowej zrotować:

- token Cloudflare użyty do konfiguracji DNS/WAF,
- `relay_shared_secret` w Flowise i EKSRelay,
- ewentualnie odpowiadający sekret w fallbackowym PHP relayu, jeśli ma zostać aktywny jako rollback.

## 4. Podgląd bramki / operacje

Aktualnie dostępne:

- `/admin/events` — audyt decyzji bramki,
- `/admin/jobs` — kolejka i dead jobs,
- `/admin/messages` — przetworzone wiadomości/idempotencja,
- `npm run events` — CLI podglądu audytu,
- Prisma Studio — tylko przez SSH tunnel, nie przez publiczny Traefik.

Do rozważenia później: mały read-only panel operacyjny nad `/admin/*`, bez pełnego dostępu zapisu do bazy jak Prisma Studio.