eks_relay/docs/TODO.md

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

Dostępne są dwa bezpieczne tryby podglądu:

• panel read-only: GET /ops,
• /admin/events — audyt decyzji bramki,
• /admin/jobs — kolejka i dead jobs,
• /admin/messages — przetworzone wiadomości/idempotencja,
• /admin/tickets — utworzone/adoptowane tickety,
• /admin/meta — słowniki filtrów i liczniki,
• npm run events — CLI podglądu audytu,
• Prisma Studio — tylko przez SSH tunnel, nie przez publiczny Traefik.

Panel /ops jest przeznaczony do codziennego podglądu i wymaga ADMIN_TOKEN po stronie przeglądarki. Prisma Studio ma pełny dostęp read/write do bazy i zostaje wyłącznie narzędziem technicznego debugowania przez SSH.