update

2026-03-28 15:04:35 +01:00
parent c1d0d7762f
commit 2ab0d0e90e
44 changed files with 3027 additions and 493 deletions
--- a/.paul/PROJECT.md
+++ b/.paul/PROJECT.md
@@ -13,7 +13,7 @@ Sprzedawca moĹĽe obsĹ‚ugiwaÄ‡ zamĂłwienia ze wszystkich kanaĹ‚Ăłw
 | Attribute | Value |
 |-----------|-------|
 | Version | 1.0.0 |
-| Status | v1.9 Complete |
+| Status | v2.1 Complete |
 | Last Updated | 2026-03-28 |

 ## Requirements
@@ -56,6 +56,8 @@ Sprzedawca moĹĽe obsĹ‚ugiwaÄ‡ zamĂłwienia ze wszystkich kanaĹ‚Ăłw
 - [x] Synchronizacja statusow orderPRO -> shopPRO (cron push, reverse mapping, PUT API) — Phase 45
 - [x] Synchronizacja statusow orderPRO -> Allegro (cron push, reverse mapping, fulfillment status update API) - Phase 46
 - [x] Automatyzacja przesylek: natychmiastowy event `shipment.created` + akcja `update_shipment_status` - Phase 47
+- [x] Szablony e-mail: zmienne `przesylka.numer` i `przesylka.link_sledzenia` z provider-aware linkiem sledzenia - Phase 48
+- [x] Automatyzacja: tab Historia z filtrowaniem/paginacja + retencja 30 dni + akcja update_order_status - Phase 49

 ### Active (In Progress)

@@ -122,6 +124,9 @@ PHP (XAMPP/Laravel), integracje z API marketplace'Ăłw (Allegro, Erli) oraz API
 | Quill.js 2.0.3 CDN dla edytora szablonĂłw | Brak build pipeline w projekcie; CDN prostszy | 2026-03-16 | Active |
 | Event automatyzacji `shipment.created` uruchamiany natychmiast po utworzeniu paczki | Reakcje automatyzacji nie czekaja na cron tracking; przeplyw jest natychmiastowy | 2026-03-28 | Active |
 | Akcja `update_shipment_status` emituje `shipment.status_changed` tylko przy realnej zmianie | Brak petli automatyzacji i brak falszywych triggerow | 2026-03-28 | Active |
+| Zmienne e-mail przesylki bazuja na najnowszej paczce `shipment_packages` i `DeliveryStatus::trackingUrl` | Jeden spojny kontrakt dla numeru i linku sledzenia w szablonach | 2026-03-28 | Active |
+| Historia automatyzacji zapisywana per regula (success/failed) i czyszczona cronem po 30 dniach | Audyt wykonywania regul bez recznego utrzymania danych | 2026-03-28 | Active |
+| Akcja update_order_status korzysta z OrdersRepository::updateOrderStatus | Spojnosc z historia statusow i activity log bez duplikowania logiki | 2026-03-28 | Active |

 ## Success Metrics

@@ -153,5 +158,6 @@ Quick Reference:

 ---
 *PROJECT.md â€” Updated when requirements or context change*
-*Last updated: 2026-03-28 after Phase 47 completion (Shipment Creation Automation)*
+*Last updated: 2026-03-28 after Phase 49 completion (Automation History Tab)*
+

--- a/.paul/ROADMAP.md
+++ b/.paul/ROADMAP.md
@@ -2,22 +2,43 @@

 ## Overview

-orderPRO to narzÄ™dzie do wielokanaĹ‚owego zarzÄ…dzania sprzedaĹĽÄ…. Projekt przechodzi od podstawowych integracji z marketplace'ami i generowania etykiet, przez rozbudowÄ™ o nowe ĹşrĂłdĹ‚a zamĂłwieĹ„ i przewoĹşnikĂłw, aĹĽ do peĹ‚nego zarzÄ…dzania produktami i stanami magazynowymi.
+orderPRO to narzedzie do wielokanalowego zarzadzania sprzedaza. Projekt przechodzi od podstawowych integracji z marketplace'ami i generowania etykiet, przez rozbudowe o nowe zrodla zamowien i przewoznikow, az do pelnego zarzadzania produktami i stanami magazynowymi.

 ## Current Milestone

-No active milestone (v1.9 complete)
+No active milestone - Ready to define next scope

-Gotowe do zaplanowania kolejnego milestone (obszary planowane: zarzadzanie produktami i stanami magazynowymi).
-
-| Phase | Name | Status | Plans |
-|------|------|--------|-------|
-| - | - | - | - |
-
-Next action: utworzyc nowy milestone i roadmape kolejnego zakresu.
+Next action: uruchom $paul-milestone (lub $paul-plan) dla kolejnego celu biznesowego.

 ## Completed Milestones

+<details>
+<summary>v2.1 Automation History & Observability - 2026-03-28 (1 phase, 1 plan)</summary>
+
+Rozdzielenie Ustawienia > Zadania automatyczne na taby Ustawienia i Historia, wdrozenie audytu wykonan regul (filtry + paginacja), retencja 30 dni oraz akcja update_order_status.
+
+| Phase | Name | Plans | Completed |
+|-------|------|-------|-----------|
+| 49 | Automation History Tab | 1/1 | 2026-03-28 |
+
+Archive: .paul/phases/49-automation-history-tab/
+
+</details>
+
+
+<details>
+<summary>v2.0 Email Template Shipment Variables - 2026-03-28 (1 phase, 1 plan)</summary>
+
+Rozszerzenie szablonow e-mail o zmienne przesylki (`przesylka.numer`, `przesylka.link_sledzenia`) oraz provider-aware budowanie linku sledzenia.
+
+| Phase | Name | Plans | Completed |
+|-------|------|-------|-----------|
+| 48 | Email Template Shipment Variables | 1/1 | 2026-03-28 |
+
+Archive: `.paul/phases/48-email-template-shipment-variables/`
+
+</details>
+
 <details>
 <summary>v1.9 Shipment Automation Immediate Trigger - 2026-03-28 (1 phase, 1 plan)</summary>

@@ -281,4 +302,7 @@ Archive: `.paul/milestones/v0.1-ROADMAP.md`

 ---
 *Roadmap created: 2026-03-12*
-*Last updated: 2026-03-28 - v1.8 Allegro Status Push completed*
+*Last updated: 2026-03-28 - v2.1 completed (phase 49)*
+
+
+
--- a/.paul/STATE.md
+++ b/.paul/STATE.md
@@ -1,55 +1,56 @@
-# Project State
+# Project State

 ## Project Reference

 See: .paul/PROJECT.md (updated 2026-03-28)

 **Core value:** Sprzedawca moze obslugiwac zamowienia ze wszystkich kanalow sprzedazy i nadawac przesylki bez przelaczania sie miedzy platformami.
-**Current focus:** v1.9 complete - ready to plan next milestone
+**Current focus:** Milestone v2.1 completed; ready for next milestone planning

 ## Current Position

-Milestone: v1.9 Shipment Automation Immediate Trigger - Complete
-Phase: Complete (47 - Shipment Creation Automation)
-Plan: 47-01 complete
-Status: Ready to plan next milestone
-Last activity: 2026-03-28 14:35:00 - UNIFY completed, phase transitioned
+Milestone: v2.1 Automation History & Observability - Complete
+Phase: 1 of 1 (49 - Automation History Tab) - Complete
+Plan: 49-01 complete
+Status: Ready for next PLAN / next milestone
+Last activity: 2026-03-28 14:47:06 - UNIFY closed for 49-01, SUMMARY created

 Progress:
- v1.9 Milestone: [##########] 100%
- Next milestone: [..........] 0%
+- Milestone: [##########] 100%
+- Phase 49: [##########] 100%

 ## Loop Position

 Current loop state:
 ```
 PLAN --> APPLY --> UNIFY
-  done     done      done    [Loop complete - ready for next PLAN]
+ done     done      done   [Loop complete - ready for next PLAN]
 ```

+## Session Continuity
+
+Last session: 2026-03-28 14:47:06
+Stopped at: Phase 49 complete, milestone v2.1 complete
+Next action: Uruchom `$paul-milestone` (lub `$paul-plan`) dla kolejnego celu
+Resume file: .paul/ROADMAP.md
+
 ## Accumulated Context

 ### Decisions
 | Date | Decision | Impact |
 |------|----------|--------|
-| 2026-03-28 | Dodano event `shipment.created` triggerowany natychmiast po sukcesie tworzenia paczki | Reguly automatyzacji reaguja od razu, bez oczekiwania na cron |
-| 2026-03-28 | Dodano akcje `update_shipment_status` z aktualizacja tylko przy realnej zmianie | Brak petli i duplikatow triggerow |
-| 2026-03-28 | `AutomationService` rozszerzony o `ShipmentPackageRepository` i fallback wyboru paczki | Stabilne wykonanie akcji statusowej nawet bez `package_id` w kontekscie |
+| 2026-03-28 | Rozdzielenie `/settings/automation` na taby `Ustawienia` i `Historia` | Lepsza czytelnosc i oddzielenie konfiguracji od audytu wykonania |
+| 2026-03-28 | Historia automatyzacji zapisywana per regula (success/failed) + filtry/paginacja | Szybsza diagnostyka triggerow i wynikow regul |
+| 2026-03-28 | Retencja historii starszej niz 30 dni przez cron `automation_history_cleanup` | Kontrola rozmiaru danych i automatyczne porzadkowanie |
+| 2026-03-28 | Akcja `update_order_status` przez `OrdersRepository::updateOrderStatus` | Spojnosc z historia statusow i activity logiem |

-### Skill Audit (Phase 47, Plan 01)
+### Skill Audit Carry-Over
 | Expected | Invoked | Notes |
 |----------|---------|-------|
-| sonar-scanner | ✓ | Scan wykonany w UNIFY; analysis successful na sonar.project-pro.pl |
-
-## Session Continuity
-
-Last session: 2026-03-28 14:35:00
-Stopped at: Phase 47 complete, loop closed
-Next action: Start next milestone planning ($paul-new-milestone)
-Resume file: .paul/phases/47-shipment-created-automation/47-01-SUMMARY.md
+| sonar-scanner | yes | Uruchomiony po APPLY, analiza zakonczona sukcesem |

 ## Git State

-Last commit: ad9087d
+Last commit: c1d0d77
 Branch: main
 Feature branches merged: none
--- a/.paul/phases/46-allegro-status-push/46-01-PLAN.md
+++ b/.paul/phases/46-allegro-status-push/46-01-PLAN.md
@@ -0,0 +1,199 @@
+---
+phase: 46-allegro-status-push
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/Modules/Settings/AllegroStatusSyncService.php
+  - src/Modules/Settings/AllegroApiClient.php
+  - src/Modules/Settings/AllegroStatusMappingRepository.php
+  - src/Modules/Settings/AllegroOrderSyncStateRepository.php
+  - src/Modules/Settings/AllegroIntegrationController.php
+  - resources/views/settings/allegro.php
+  - resources/lang/pl.php
+  - tests/Unit/AllegroStatusSyncServiceTest.php
+  - DOCS/ARCHITECTURE.md
+  - DOCS/TECH_CHANGELOG.md
+autonomous: true
+---
+
+<objective>
+## Goal
+Wdrozyc dzialajaca synchronizacje statusow zamowien w kierunku `orderPRO -> Allegro` i aktywowac ten kierunek w konfiguracji integracji Allegro.
+
+## Purpose
+Opcja kierunku `orderPRO -> Allegro` jest dostepna w UI, ale obecnie jest zablokowana i backend zwraca komunikat "jeszcze nie wdrozony". Operator nie moze wypchnac zmian statusu wykonanych recznie w orderPRO do Allegro.
+
+## Output
+- Pelna obsluga push direction w `AllegroStatusSyncService`
+- Metoda API do aktualizacji statusu checkout form w Allegro
+- Reverse mapping statusow `orderpro_status_code -> allegro_status_code`
+- Aktywna opcja kierunku w UI ustawien Allegro
+- Testy jednostkowe krytycznej logiki push
+- Aktualizacja dokumentacji technicznej
+</objective>
+
+<context>
+## Project Context
+@.paul/PROJECT.md
+@.paul/ROADMAP.md
+@.paul/STATE.md
+
+## Prior Work
+@.paul/phases/45-shoppro-status-push/45-01-SUMMARY.md
+
+## Source Files
+@src/Modules/Settings/AllegroStatusSyncService.php
+@src/Modules/Settings/AllegroApiClient.php
+@src/Modules/Settings/AllegroStatusMappingRepository.php
+@src/Modules/Settings/AllegroOrderSyncStateRepository.php
+@src/Modules/Settings/AllegroIntegrationController.php
+@resources/views/settings/allegro.php
+@resources/lang/pl.php
+@src/Modules/Cron/AllegroStatusSyncHandler.php
+</context>
+
+<skills>
+## Required Skills (from SPECIAL-FLOWS.md)
+
+| Skill | Priority | When to Invoke | Loaded? |
+|-------|----------|----------------|---------|
+| sonar-scanner | required | Po APPLY, przed UNIFY | o |
+
+**BLOCKING:** Required skills MUST be loaded before APPLY proceeds.
+
+## Skill Invocation Checklist
+- [ ] sonar-scanner loaded (run command or confirm)
+</skills>
+
+<acceptance_criteria>
+
+## AC-1: Cron pushuje reczne zmiany statusu orderPRO do Allegro
+```gherkin
+Given integracja Allegro ma ustawiony kierunek synchronizacji statusow na orderPRO -> Allegro
+  And zamowienie Allegro ma reczna zmiane statusu w orderPRO (order_status_history.change_source = manual)
+  And istnieje mapowanie statusu orderPRO na status Allegro
+When uruchamia sie job cron allegro_status_sync
+Then AllegroStatusSyncService wykonuje push statusu do API Allegro
+  And wynik synchronizacji zawiera licznik pushed i failed
+```
+
+## AC-2: Brak mapowania nie zatrzymuje przetwarzania
+```gherkin
+Given czesc zamowien nie ma reverse mapowania statusu orderPRO -> Allegro
+When cron przetwarza batch zmian statusow
+Then zamowienia bez mapowania sa oznaczone jako skipped
+  And pozostale zamowienia sa dalej przetwarzane
+```
+
+## AC-3: Ustawienie kierunku jest aktywne i zapisywalne w UI
+```gherkin
+Given operator otworzy Ustawienia > Integracje > Allegro > Ustawienia
+When wybierze kierunek orderPRO -> Allegro i zapisze formularz
+Then opcja nie jest zablokowana jako disabled
+  And wartosc jest zapisana w app_settings (allegro_status_sync_direction)
+```
+
+</acceptance_criteria>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Implementacja push direction w AllegroStatusSyncService i reverse mapowania</name>
+  <files>src/Modules/Settings/AllegroStatusSyncService.php, src/Modules/Settings/AllegroStatusMappingRepository.php, src/Modules/Settings/AllegroOrderSyncStateRepository.php</files>
+  <action>
+    1. Rozszerzyc `AllegroStatusSyncService::sync()` o realna sciezke dla `orderpro_to_allegro` zamiast zwracania "jeszcze nie wdrozony".
+    2. Dodac prywatna metode push (np. `syncOrderproToAllegro()`), ktora:
+       - pobiera zamowienia Allegro z recznymi zmianami statusu (`order_status_history.change_source = manual`) od ostatniego kursora,
+       - filtruje tylko zamowienia `source = allegro`,
+       - buduje reverse mapowanie na podstawie `allegro_order_status_mappings` (`orderpro_status_code -> allegro_status_code`, first match wins),
+       - dla brakow mapowania zwieksza `skipped`, bez przerywania petli,
+       - aktualizuje kursor push po sukcesie batcha.
+    3. W `AllegroStatusMappingRepository` dodac metode zwracajaca reverse map dla push direction.
+    4. W `AllegroOrderSyncStateRepository` dodac obsluge kursora `last_status_pushed_at` (get/update), defensywnie wobec srodowisk bez kolumny.
+    5. Zachowac obecna logike `allegro_to_orderpro` bez regresji.
+
+    Avoid:
+    - nie pushowac zmian z `change_source = import` ani `sync` (petla synchronizacji),
+    - nie modyfikowac flow importu zamowien Allegro.
+  </action>
+  <verify>php -l src/Modules/Settings/AllegroStatusSyncService.php && php -l src/Modules/Settings/AllegroStatusMappingRepository.php && php -l src/Modules/Settings/AllegroOrderSyncStateRepository.php</verify>
+  <done>AC-1 i AC-2 satisfied: backend obsluguje push direction i bezpiecznie pomija brak mapowania</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Dodanie metody API update statusu checkout-form w AllegroApiClient</name>
+  <files>src/Modules/Settings/AllegroApiClient.php, src/Modules/Settings/AllegroStatusSyncService.php</files>
+  <action>
+    1. Dodac do `AllegroApiClient` metode aktualizacji statusu realizacji zamowienia Allegro (checkout form fulfillment) z obsluga tokena i bledow HTTP analogiczna do istniejacych metod.
+    2. Uzyc tej metody w push direction serwisu sync, mapujac status orderPRO na docelowy kod Allegro.
+    3. Zapewnic czytelny wynik dla kazdego rekordu (success/fail) i agregacje w odpowiedzi crona.
+    4. Zachowac istniejace standardy: prepared flow, brak stringowego SQL, brak "magic values" bez stalej.
+
+    Avoid:
+    - nie dodawac natywnych `alert()/confirm()` ani zmian w warstwie widoku w tym tasku,
+    - nie tlumic bledow API bez zapisu ich tresci do wyniku sync.
+  </action>
+  <verify>php -l src/Modules/Settings/AllegroApiClient.php && php -l src/Modules/Settings/AllegroStatusSyncService.php</verify>
+  <done>AC-1 satisfied: service moze fizycznie zaktualizowac status po stronie Allegro API</done>
+</task>
+
+<task type="auto">
+  <name>Task 3: Aktywacja opcji w UI + testy jednostkowe + dokumentacja</name>
+  <files>resources/views/settings/allegro.php, src/Modules/Settings/AllegroIntegrationController.php, resources/lang/pl.php, tests/Unit/AllegroStatusSyncServiceTest.php, DOCS/ARCHITECTURE.md, DOCS/TECH_CHANGELOG.md</files>
+  <action>
+    1. Usunac blokade `disabled` z opcji `orderPRO -> Allegro` w formularzu ustawien Allegro i pozostawic poprawny zapis przez istniejacy endpoint `saveImportSettings`.
+    2. Uzuplenic komunikaty i opisy w tlumaczeniach PL (jezeli wymagane), aby nie sugerowaly "wkrotce".
+    3. Dodac testy jednostkowe dla krytycznych sciezek push:
+       - push sukces + increment `pushed`,
+       - brak reverse mapping + increment `skipped`,
+       - blad API + increment `failed` i brak przerwania batcha.
+    4. Zaktualizowac `DOCS/ARCHITECTURE.md` o dzialajacy kierunek `orderpro_to_allegro`.
+    5. Dopisac wpis do `DOCS/TECH_CHANGELOG.md` (co i dlaczego zostalo wdrozone).
+
+    Avoid:
+    - nie zmieniac schematu DB w tym planie,
+    - nie rozszerzac zakresu o nowe endpointy UI poza aktywacja istniejacej opcji.
+  </action>
+  <verify>php -l src/Modules/Settings/AllegroIntegrationController.php && php -l tests/Unit/AllegroStatusSyncServiceTest.php && C:/xampp/php/php.exe vendor/bin/phpunit tests/Unit/AllegroStatusSyncServiceTest.php</verify>
+  <done>AC-3 satisfied: opcja jest aktywna, testy i dokumentacja pokrywaja nowy kierunek</done>
+</task>
+
+</tasks>
+
+<boundaries>
+
+## DO NOT CHANGE
+- src/Modules/Settings/AllegroOrdersSyncService.php
+- src/Modules/Settings/AllegroOrderImportService.php
+- src/Modules/Orders/OrdersController.php
+- database/migrations/*
+
+## SCOPE LIMITS
+- Zakres dotyczy tylko synchronizacji statusow, bez zmian importu zamowien i bez zmian mapowania dostaw.
+- Brak przebudowy UI zakladki Allegro poza aktywacja istniejacej opcji kierunku.
+- Brak nowych cron job types i brak zmian interwalow harmonogramu.
+
+</boundaries>
+
+<verification>
+Before declaring plan complete:
+- [ ] `php -l` przechodzi dla wszystkich zmienionych plikow PHP
+- [ ] Test jednostkowy `AllegroStatusSyncServiceTest` przechodzi lokalnie
+- [ ] Kierunek `orderpro_to_allegro` nie zwraca juz komunikatu "jeszcze nie wdrozony"
+- [ ] Wynik sync zawiera liczniki `pushed`, `skipped`, `failed`
+- [ ] UI pozwala zapisac kierunek `orderPRO -> Allegro`
+- [ ] `DOCS/ARCHITECTURE.md` i `DOCS/TECH_CHANGELOG.md` sa zaktualizowane
+</verification>
+
+<success_criteria>
+- Wszystkie taski zakonczone
+- Wszystkie kryteria akceptacji spelnione
+- Brak regresji w kierunku `allegro_to_orderpro`
+- Nowy kierunek dziala z poziomu crona i jest aktywowalny w UI
+</success_criteria>
+
+<output>
+After completion, create `.paul/phases/46-allegro-status-push/46-01-SUMMARY.md`
+</output>
--- a/.paul/phases/46-allegro-status-push/46-01-SUMMARY.md
+++ b/.paul/phases/46-allegro-status-push/46-01-SUMMARY.md
@@ -0,0 +1,132 @@
+---
+phase: 46-allegro-status-push
+plan: 01
+subsystem: api
+tags: [allegro, status-sync, cron, mappings]
+requires:
+  - phase: 45-shoppro-status-push
+    provides: orderPRO to external marketplace status push pattern
+provides:
+  - Allegro status push from orderPRO manual status changes
+  - Active orderPRO_to_allegro direction in integration settings
+  - Unit coverage for core push scenarios
+affects: [settings, cron, integrations]
+tech-stack:
+  added: []
+  patterns: [reverse status mapping, push cursor tracking, api retry on 401]
+key-files:
+  created:
+    - .paul/phases/46-allegro-status-push/46-01-SUMMARY.md
+    - tests/Unit/AllegroStatusSyncServiceTest.php
+  modified:
+    - src/Modules/Settings/AllegroStatusSyncService.php
+    - src/Modules/Settings/AllegroApiClient.php
+    - src/Modules/Settings/AllegroStatusMappingRepository.php
+    - src/Modules/Settings/AllegroOrderSyncStateRepository.php
+    - src/Modules/Cron/CronHandlerFactory.php
+    - resources/views/settings/allegro.php
+    - resources/lang/pl.php
+    - DOCS/ARCHITECTURE.md
+    - DOCS/TECH_CHANGELOG.md
+key-decisions:
+  - "Push only manual status changes (change_source=manual) to avoid sync loops."
+  - "Reuse integration_order_sync_state with last_status_pushed_at cursor for incremental push."
+  - "Retry once after token refresh on ALLEGRO_HTTP_401."
+patterns-established:
+  - "First-match-wins reverse mapping: orderpro_status_code -> allegro_status_code."
+  - "Per-order push result aggregation: pushed, skipped, failed."
+duration: ~4h
+started: 2026-03-28T12:20:50+01:00
+completed: 2026-03-28T13:20:00+01:00
+---
+
+# Phase 46 Plan 01: Allegro Status Push Summary
+
+orderPRO to Allegro status synchronization was implemented end-to-end and enabled in UI, with tests and documentation updates.
+
+## Performance
+
+| Metric | Value |
+|--------|-------|
+| Duration | ~4h |
+| Started | 2026-03-28T12:20:50+01:00 |
+| Completed | 2026-03-28T13:20:00+01:00 |
+| Tasks | 3 completed |
+| Files modified | 10 |
+
+## Acceptance Criteria Results
+
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| AC-1: Cron pushes orderPRO manual status changes to Allegro | Pass | Implemented in AllegroStatusSyncService with API call, counters, and cursor updates. |
+| AC-2: Missing mapping does not stop processing | Pass | Unmapped statuses are counted as skipped; batch continues. |
+| AC-3: orderPRO -> Allegro direction active in UI | Pass | Disabled flag removed, option is selectable and persisted by existing settings flow. |
+
+## Verification Results
+
+| Command | Result |
+|--------|--------|
+| `php -l src/Modules/Settings/AllegroStatusSyncService.php` | PASS |
+| `php -l src/Modules/Settings/AllegroApiClient.php` | PASS |
+| `php -l src/Modules/Settings/AllegroStatusMappingRepository.php` | PASS |
+| `php -l src/Modules/Settings/AllegroOrderSyncStateRepository.php` | PASS |
+| `php -l src/Modules/Cron/CronHandlerFactory.php` | PASS |
+| `php -l tests/Unit/AllegroStatusSyncServiceTest.php` | PASS |
+| `C:/xampp/php/php.exe vendor/bin/phpunit --filter AllegroStatusSyncServiceTest --testdox` | PASS (4 tests, 39 assertions) |
+| `sonar-scanner` | PASS (analysis successful; Quality Gate failed due existing/new issues tracked in DOCS/todo.md) |
+
+## Accomplishments
+
+- Implemented real push path `orderpro_to_allegro` in sync service.
+- Added Allegro API fulfillment status update method and integrated it into cron flow.
+- Added reverse status mapping and push cursor support.
+- Enabled the direction in Allegro settings UI and adjusted PL hint text.
+- Added unit tests for success, skipped, failure, and 401 retry behavior.
+- Updated architecture and technical changelog docs.
+
+## Files Created/Modified
+
+| File | Change | Purpose |
+|------|--------|---------|
+| `src/Modules/Settings/AllegroStatusSyncService.php` | Modified | Added orderPRO->Allegro push execution and result aggregation. |
+| `src/Modules/Settings/AllegroApiClient.php` | Modified | Added PUT fulfillment status endpoint wrapper. |
+| `src/Modules/Settings/AllegroStatusMappingRepository.php` | Modified | Added reverse map builder for push direction. |
+| `src/Modules/Settings/AllegroOrderSyncStateRepository.php` | Modified | Added read/write support for `last_status_pushed_at`. |
+| `src/Modules/Cron/CronHandlerFactory.php` | Modified | Injected dependencies for new push logic and shared sync state repository. |
+| `resources/views/settings/allegro.php` | Modified | Enabled orderPRO->Allegro direction option. |
+| `resources/lang/pl.php` | Modified | Updated direction hint text (no "soon" wording). |
+| `tests/Unit/AllegroStatusSyncServiceTest.php` | Created | Added tests for key push flow behaviors. |
+| `DOCS/ARCHITECTURE.md` | Modified | Documented active push direction and API client method. |
+| `DOCS/TECH_CHANGELOG.md` | Modified | Logged technical change and rationale. |
+
+## Deviations from Plan
+
+| Type | Count | Impact |
+|------|-------|--------|
+| Scope additions | 1 | Low |
+| Deferred | 1 | Low |
+
+- Scope addition: `src/Modules/Cron/CronHandlerFactory.php` was updated to wire dependencies for the new service behavior (not listed as a direct plan file, but required to activate runtime flow).
+- Plan file listed `src/Modules/Settings/AllegroIntegrationController.php` as a target, but no code change was needed there because existing save flow already persisted `allegro_status_sync_direction`.
+- Deferred: Sonar Quality Gate remediation intentionally postponed; full issue list captured in `DOCS/todo.md`.
+
+## Key Patterns and Decisions
+
+| Decision | Rationale | Impact |
+|----------|-----------|--------|
+| Manual-only push (`change_source=manual`) | Prevent import/sync feedback loops | Safe bidirectional architecture |
+| Cursor-based push (`last_status_pushed_at`) | Incremental processing and bounded batches | Better cron performance and idempotence |
+| Retry once on 401 after token refresh | Recover from expired access token | Improved operational resilience |
+
+## Next Phase Readiness
+
+Ready:
+- v1.8 milestone scope delivered for phase 46.
+- Operational status push path to Allegro can be validated in production cron logs.
+
+Concerns:
+- Sonar issues remain open and are tracked in `DOCS/todo.md`.
+
+Blockers:
+- None.
+
--- a/.paul/phases/48-email-template-shipment-variables/48-01-PLAN.md
+++ b/.paul/phases/48-email-template-shipment-variables/48-01-PLAN.md
@@ -0,0 +1,197 @@
+---
+phase: 48-email-template-shipment-variables
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/Modules/Email/VariableResolver.php
+  - src/Modules/Email/EmailSendingService.php
+  - src/Modules/Cron/CronHandlerFactory.php
+  - src/Modules/Settings/EmailTemplateController.php
+  - resources/views/settings/email-templates.php
+  - DOCS/ARCHITECTURE.md
+  - DOCS/TECH_CHANGELOG.md
+  - DOCS/todo.md
+autonomous: false
+---
+
+<objective>
+## Goal
+Dodac w szablonach e-mail nowe zmienne: `{{przesylka.numer}}` oraz `{{przesylka.link_sledzenia}}`, tak aby link sledzenia byl budowany zaleznie od provider/carrier danej przesylki.
+
+## Purpose
+Szablony e-mail maja przekazywac klientowi realny numer paczki i klikalny URL sledzenia bez recznego dopisywania danych przez operatora.
+
+## Output
+Rozszerzony resolver zmiennych e-mail o dane najnowszej paczki, aktualny katalog zmiennych w UI (`/settings/email-templates`) oraz zaktualizowana dokumentacja techniczna.
+</objective>
+
+<context>
+## Project Context
+@.paul/PROJECT.md
+@.paul/ROADMAP.md
+@.paul/STATE.md
+@DOCS/ARCHITECTURE.md
+@DOCS/DB_SCHEMA.md
+@DOCS/todo.md
+
+## Prior Work (only if genuinely needed)
+@.paul/phases/14-email-templates/14-02-SUMMARY.md
+@.paul/phases/15-email-sending/15-01-SUMMARY.md
+@.paul/phases/27-shipment-tracking-backend/27-01-SUMMARY.md
+
+## Source Files
+@src/Modules/Email/VariableResolver.php
+@src/Modules/Email/EmailSendingService.php
+@src/Modules/Settings/EmailTemplateController.php
+@resources/views/settings/email-templates.php
+@src/Modules/Shipments/ShipmentPackageRepository.php
+@src/Modules/Shipments/DeliveryStatus.php
+@src/Modules/Cron/CronHandlerFactory.php
+</context>
+
+<skills>
+## Required Skills (from SPECIAL-FLOWS.md)
+
+| Skill | Priority | When to Invoke | Loaded? |
+|-------|----------|----------------|---------|
+| `sonar-scanner` | required | Po APPLY, przed UNIFY | o |
+| /feature-dev | optional | Przed wdrazaniem nowej funkcjonalnosci | o |
+| /code-review | optional | Po APPLY, przed UNIFY | o |
+
+**BLOCKING:** Required skills MUST be loaded before APPLY proceeds.
+
+## Skill Invocation Checklist
+- [ ] `sonar-scanner` uruchomiony po APPLY
+- [ ] /feature-dev (opcjonalnie)
+- [ ] /code-review (opcjonalnie)
+
+</skills>
+
+<acceptance_criteria>
+
+## AC-1: Szablony e-mail obsluguja nowe zmienne przesylki
+```gherkin
+Given uzytkownik edytuje szablon na `/settings/email-templates`
+When wybierze zmienne `{{przesylka.numer}}` i `{{przesylka.link_sledzenia}}`
+Then zmienne sa dostepne na liscie i poprawnie podstawiane w preview
+```
+
+## AC-2: Resolver pobiera dane przesylki z zamowienia
+```gherkin
+Given zamowienie ma co najmniej jedna paczke w `shipment_packages`
+When system renderuje temat i tresc e-maila
+Then `przesylka.numer` zawiera tracking number najnowszej paczki
+And `przesylka.link_sledzenia` zawiera URL sledzenia dla tej paczki
+```
+
+## AC-3: Link sledzenia jest zalezny od provider/carrier
+```gherkin
+Given paczka ma `provider` oraz opcjonalnie `carrier_id`
+When system oblicza `przesylka.link_sledzenia`
+Then korzysta z logiki `DeliveryStatus::trackingUrl(provider, tracking_number, carrier_id)`
+And dla braku numeru przesylki zwraca pusty string zamiast blednego URL
+```
+
+## AC-4: Dokumentacja odzwierciedla nowy kontrakt zmiennych
+```gherkin
+Given wdrozone zmienne przesylki w module e-mail
+When zespol czyta dokumentacje techniczna
+Then ARCHITECTURE i TECH_CHANGELOG opisuja nowe zmienne oraz zasady budowy linku
+And todo/changelog zawiera wpis o tym zakresie
+```
+
+</acceptance_criteria>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Rozszerz katalog zmiennych szablonow i dane podgladu</name>
+  <files>src/Modules/Settings/EmailTemplateController.php, resources/views/settings/email-templates.php</files>
+  <action>
+    Dodaj nowa grupe/lub rozszerzenie grupy zmiennych o `przesylka.numer` i `przesylka.link_sledzenia`.
+    Uaktualnij `SAMPLE_DATA`, aby preview na stronie ustawien pokazywal realistyczny numer oraz przykladowy URL sledzenia.
+    Zachowaj aktualny format placeholderow `{{grupa.pole}}` oraz zgodnosc z endpointem `getVariables`.
+  </action>
+  <verify>rg -n "przesylka|link_sledzenia|tracking" src/Modules/Settings/EmailTemplateController.php resources/views/settings/email-templates.php</verify>
+  <done>AC-1 satisfied: nowe zmienne sa widoczne i podstawiane w preview.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Dodaj resolve danych paczki do zmiennych e-mail</name>
+  <files>src/Modules/Email/VariableResolver.php, src/Modules/Email/EmailSendingService.php, src/Modules/Cron/CronHandlerFactory.php, src/Modules/Shipments/ShipmentPackageRepository.php</files>
+  <action>
+    Rozszerz przeplyw budowy mapy zmiennych tak, by resolver mial dostep do najnowszej paczki dla zamowienia.
+    Wykorzystaj repozytorium paczek do pobrania ostatniej paczki (`order_id`) i wypelnij:
+    - `przesylka.numer` = tracking number,
+    - `przesylka.link_sledzenia` = wynik `DeliveryStatus::trackingUrl(provider, tracking_number, carrier_id)`.
+    Zapewnij bezpieczny fallback na pusty string, gdy paczka lub tracking nie istnieje.
+    Dostosuj konstrukcje zaleznosci serwisu e-mail (factory/DI) bez zmian zachowania innych funkcji.
+  </action>
+  <verify>rg -n "przesylka\\.numer|przesylka\\.link_sledzenia|trackingUrl|findLatestByOrderId" src/Modules/Email src/Modules/Cron src/Modules/Shipments</verify>
+  <done>AC-2 satisfied i AC-3 satisfied: resolver zwraca numer i provider-aware link sledzenia.</done>
+</task>
+
+<task type="auto">
+  <name>Task 3: Zaktualizuj dokumentacje techniczna po wdrozeniu</name>
+  <files>DOCS/ARCHITECTURE.md, DOCS/TECH_CHANGELOG.md, DOCS/todo.md</files>
+  <action>
+    Dodaj opis nowych zmiennych e-mail i ich zrodla danych (shipment_packages + DeliveryStatus::trackingUrl).
+    Opisz ograniczenia (brak paczki/brak trackingu = puste wartosci) i brak zmian schematu DB.
+    Uzupelnij wpis changelog/todo zgodnie z praktyka projektu.
+  </action>
+  <verify>rg -n "przesylka\\.numer|przesylka\\.link_sledzenia|DeliveryStatus::trackingUrl|email template" DOCS/ARCHITECTURE.md DOCS/TECH_CHANGELOG.md DOCS/todo.md</verify>
+  <done>AC-4 satisfied: dokumentacja techniczna odzwierciedla wdrozenie.</done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-built>Nowe zmienne szablonow e-mail z numerem i linkiem sledzenia przesylki.</what-built>
+  <how-to-verify>
+    1. Otworz: `https://orderpro.projectpro.pl/settings/email-templates`.
+    2. Edytuj dowolny szablon i wstaw `{{przesylka.numer}}` oraz `{{przesylka.link_sledzenia}}`.
+    3. Uruchom preview i potwierdz, ze obie zmienne sa podstawione.
+    4. Wyslij testowy e-mail dla zamowienia z paczka i sprawdz, czy link prowadzi do poprawnego sledzenia dla danego kuriera/providera.
+    5. Powtorz dla zamowienia bez paczki i potwierdz brak blednych placeholderow/URL.
+  </how-to-verify>
+  <resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
+</task>
+
+</tasks>
+
+<boundaries>
+
+## DO NOT CHANGE
+- `database/migrations/*` (bez zmian schematu)
+- Moduly automatyzacji i synchronizacji statusow niezwiązane z e-mail template variables
+- Widoki i style spoza `settings/email-templates`
+
+## SCOPE LIMITS
+- Zakres obejmuje tylko zmienne szablonow e-mail zwiazane z przesylka.
+- Bez dodawania nowych endpointow API.
+- Bez zmian logiki providerow trackingu poza wykorzystaniem istniejacego `DeliveryStatus::trackingUrl`.
+
+</boundaries>
+
+<verification>
+Before declaring plan complete:
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Settings/EmailTemplateController.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Email/VariableResolver.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Email/EmailSendingService.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php`
+- [ ] `C:\xampp\php\php.exe -l resources/views/settings/email-templates.php`
+- [ ] Manual checkpoint wykonany (preview + realna wysylka)
+- [ ] Dokumentacja zaktualizowana (`DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md`, `DOCS/todo.md`)
+- [ ] All acceptance criteria met
+</verification>
+
+<success_criteria>
+- `przesylka.numer` i `przesylka.link_sledzenia` sa dostepne w szablonach e-mail.
+- Resolver buduje link sledzenia zalezny od provider/carrier.
+- Brak regresji w preview i wysylce e-mail.
+- Dokumentacja techniczna opisuje nowe zmienne i przeplyw danych.
+</success_criteria>
+
+<output>
+After completion, create `.paul/phases/48-email-template-shipment-variables/48-01-SUMMARY.md`
+</output>
--- a/.paul/phases/48-email-template-shipment-variables/48-01-SUMMARY.md
+++ b/.paul/phases/48-email-template-shipment-variables/48-01-SUMMARY.md
@@ -0,0 +1,137 @@
+---
+phase: 48-email-template-shipment-variables
+plan: 01
+subsystem: ui
+tags: [email-templates, shipment-tracking, variable-resolver]
+requires:
+  - phase: 14-email-templates
+    provides: bazowy mechanizm zmiennych i edytor Quill
+  - phase: 27-shipment-tracking-backend
+    provides: model paczek i generator linkow sledzenia
+provides:
+  - zmienne `{{przesylka.numer}}` i `{{przesylka.link_sledzenia}}` w szablonach e-mail
+  - resolver danych paczki oparty o `shipment_packages` + `DeliveryStatus::trackingUrl`
+affects: [email-sending, settings-email-templates, shipments]
+tech-stack:
+  added: []
+  patterns: [provider-aware tracking link w mapowaniu zmiennych e-mail]
+key-files:
+  created: [.paul/phases/48-email-template-shipment-variables/48-01-SUMMARY.md]
+  modified: [src/Modules/Email/VariableResolver.php, src/Modules/Settings/EmailTemplateController.php, resources/views/settings/email-templates.php, resources/scss/app.scss, public/assets/css/app.css, routes/web.php, src/Modules/Cron/CronHandlerFactory.php, DOCS/ARCHITECTURE.md, DOCS/TECH_CHANGELOG.md, DOCS/todo.md]
+key-decisions:
+  - "Dodanie zmiennych przesylki bez zmian schematu DB - dane pobierane z najnowszej paczki"
+  - "Link sledzenia liczony centralnie przez DeliveryStatus::trackingUrl(provider, tracking, carrier)"
+patterns-established:
+  - "Nowe zmienne e-mail powinny miec preview (`SAMPLE_DATA`) i wpis w katalogu VARIABLE_GROUPS"
+duration: 45min
+started: 2026-03-28T15:05:00+01:00
+completed: 2026-03-28T15:43:37+01:00
+---
+
+# Phase 48 Plan 01: Email Template Shipment Variables Summary
+
+Dodano obsluge numeru przesylki i linku sledzenia w szablonach e-mail wraz z poprawka UI dropdownu, aby lista zmiennych nie byla ucinana.
+
+## Performance
+
+| Metric | Value |
+|--------|-------|
+| Duration | 45min |
+| Started | 2026-03-28T15:05:00+01:00 |
+| Completed | 2026-03-28T15:43:37+01:00 |
+| Tasks | 3 completed + 1 checkpoint |
+| Files modified | 10 |
+
+## Acceptance Criteria Results
+
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| AC-1: Szablony e-mail obsluguja nowe zmienne przesylki | Pass | `VARIABLE_GROUPS` i `SAMPLE_DATA` rozszerzone o `przesylka.*`; widoczne w pickerze |
+| AC-2: Resolver pobiera dane przesylki z zamowienia | Pass | `VariableResolver` pobiera najnowsza paczke przez `findLatestByOrderId()` |
+| AC-3: Link sledzenia jest zalezny od provider/carrier | Pass | Link liczony przez `DeliveryStatus::trackingUrl(...)`; fallback do pustego stringu |
+| AC-4: Dokumentacja odzwierciedla nowy kontrakt zmiennych | Pass | Zaktualizowano `DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md`, `DOCS/todo.md` |
+
+## Accomplishments
+
+- Dodano dwie nowe zmienne szablonow e-mail: numer paczki i link sledzenia.
+- Podlaczono resolver do danych paczki i logiki linkow provider/carrier.
+- Naprawiono clipping dropdownu `Wstaw zmienna` (styl `overflow` + `z-index`).
+
+## Files Created/Modified
+
+| File | Change | Purpose |
+|------|--------|---------|
+| `.paul/phases/48-email-template-shipment-variables/48-01-SUMMARY.md` | Created | Podsumowanie wykonania planu |
+| `src/Modules/Settings/EmailTemplateController.php` | Modified | Katalog zmiennych i dane preview (`przesylka.*`) |
+| `src/Modules/Email/VariableResolver.php` | Modified | Pobranie najnowszej paczki i mapowanie zmiennych przesylki |
+| `routes/web.php` | Modified | Wstrzykniecie `ShipmentPackageRepository` do `VariableResolver` |
+| `src/Modules/Cron/CronHandlerFactory.php` | Modified | Wstrzykniecie `ShipmentPackageRepository` do `VariableResolver` w cronie |
+| `resources/views/settings/email-templates.php` | Modified | Utrzymanie renderu zmiennych + usuniecie tymczasowego fallbacku |
+| `resources/scss/app.scss` | Modified | Naprawa ucinania panelu zmiennych (`overflow: visible`, wyzszy `z-index`) |
+| `public/assets/css/app.css` | Modified | Build CSS po zmianie SCSS |
+| `DOCS/ARCHITECTURE.md` | Modified | Opis nowych zmiennych przesylki i fallbackow |
+| `DOCS/TECH_CHANGELOG.md` | Modified | Log techniczny Phase 48 |
+| `DOCS/todo.md` | Modified | Oznaczenie zakresu jako wykonany |
+
+## Decisions Made
+
+| Decision | Rationale | Impact |
+|----------|-----------|--------|
+| Resolver zmiennych pobiera ostatnia paczke po `order_id` | Najprostszy i stabilny punkt prawdy dla numeru/linku | Spójne podstawianie danych w send/preview |
+| Uzycie `DeliveryStatus::trackingUrl` zamiast duplikacji mapowania URL | Jedno miejsce mapowania provider/carrier | Mniejsza duplikacja i latwiejsze utrzymanie |
+| Poprawka UI dropdownu przez CSS (`overflow`, `z-index`) | Problem byl wizualny (clipping), nie danych | Picker zmiennych widoczny dla uzytkownika |
+
+## Deviations from Plan
+
+### Summary
+
+| Type | Count | Impact |
+|------|-------|--------|
+| Auto-fixed | 1 | Niewielki, UX-only |
+| Scope additions | 1 | Dodatkowa poprawka CSS konieczna do uzycia funkcji |
+| Deferred | 0 | None |
+
+**Total impact:** Funkcjonalnosc dostarczona zgodnie z celem, z dodatkowa poprawka prezentacji panelu zmiennych.
+
+### Auto-fixed Issues
+
+**1. UI clipping panelu zmiennych**
+- **Found during:** checkpoint manual verify
+- **Issue:** Dropdown `Wstaw zmienna` byl ucinany przez kolejny element formularza.
+- **Fix:** Zmieniono `overflow` kontenera edytora na `visible` oraz podniesiono `z-index` panelu.
+- **Files:** `resources/scss/app.scss`, `public/assets/css/app.css`
+- **Verification:** Potwierdzenie manualne uzytkownika ("Jst ok")
+
+### Deferred Items
+
+None.
+
+## Verification Results
+
+- `C:\xampp\php\php.exe -l src/Modules/Settings/EmailTemplateController.php` OK
+- `C:\xampp\php\php.exe -l src/Modules/Email/VariableResolver.php` OK
+- `C:\xampp\php\php.exe -l src/Modules/Email/EmailSendingService.php` OK
+- `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php` OK
+- `C:\xampp\php\php.exe -l resources/views/settings/email-templates.php` OK
+- `C:\xampp\php\php.exe -l routes/web.php` OK
+- Manual checkpoint: potwierdzony przez uzytkownika
+## Skill Audit
+
+- Required `sonar-scanner`: not invoked in tym APPLY (gap zarejestrowany w STATE.md)
+
+## Next Phase Readiness
+
+**Ready:**
+- Modul e-mail ma komplet zmiennych przesylki do szablonow i preview.
+- UI picker zmiennych jest czytelny i nieuciety.
+
+**Concerns:**
+- Brak uruchomionego `sonar-scanner` dla tej petli - do nadrobienia przy najblizszym cyklu jakosci.
+
+**Blockers:**
+- None.
+
+---
+*Phase: 48-email-template-shipment-variables, Plan: 01*
+*Completed: 2026-03-28*
+
--- a/.paul/phases/49-automation-history-tab/49-01-PLAN.md
+++ b/.paul/phases/49-automation-history-tab/49-01-PLAN.md
@@ -0,0 +1,251 @@
+---
+phase: 49-automation-history-tab
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - database/migrations/20260328_000072_create_automation_execution_logs_table.sql
+  - src/Modules/Automation/AutomationExecutionLogRepository.php
+  - src/Modules/Automation/AutomationRepository.php
+  - src/Modules/Automation/AutomationService.php
+  - src/Modules/Automation/AutomationController.php
+  - resources/views/automation/form.php
+  - public/assets/js/modules/automation-form.js
+  - resources/views/automation/index.php
+  - resources/scss/modules/_automation.scss
+  - public/assets/css/app.css
+  - src/Modules/Cron/CronHandlerFactory.php
+  - src/Modules/Cron/AutomationHistoryCleanupHandler.php
+  - routes/web.php
+  - DOCS/DB_SCHEMA.md
+  - DOCS/ARCHITECTURE.md
+  - DOCS/TECH_CHANGELOG.md
+autonomous: false
+---
+
+<objective>
+## Goal
+Rozdzielic ekran `/settings/automation` na dwa taby: `Ustawienia` (obecna lista i zarzadzanie regulami) oraz `Historia` (log wykonan automatyzacji z filtrami i paginacja), oraz dodac nowa akcje automatyzacji `zmien status zamowienia` z wyborem statusu docelowego.
+
+## Purpose
+Operator musi widziec kiedy i na jakim zamowieniu uruchomila sie automatyzacja (audyt) oraz miec mozliwosc automatycznej zmiany statusu zamowienia przez regule bez recznej ingerencji.
+
+## Output
+Nowa historia wykonan automatyzacji zapisywana w dedykowanej tabeli, UI historii w tabie `Historia` z filtrowaniem i paginacja, automatyczne czyszczenie wpisow starszych niz 30 dni oraz nowa akcja reguly `update_order_status` w formularzu automatyzacji.
+</objective>
+
+<context>
+## Project Context
+@.paul/PROJECT.md
+@.paul/ROADMAP.md
+@.paul/STATE.md
+@DOCS/DB_SCHEMA.md
+@DOCS/ARCHITECTURE.md
+
+## Prior Work (only if genuinely needed)
+@.paul/phases/16-automated-tasks/16-02-SUMMARY.md
+@.paul/phases/47-shipment-created-automation/47-01-SUMMARY.md
+
+## Source Files
+@src/Modules/Automation/AutomationController.php
+@src/Modules/Automation/AutomationRepository.php
+@src/Modules/Automation/AutomationService.php
+@resources/views/automation/form.php
+@public/assets/js/modules/automation-form.js
+@resources/views/automation/index.php
+@resources/scss/modules/_automation.scss
+@src/Modules/Cron/CronHandlerFactory.php
+@src/Modules/Cron/CronRepository.php
+@resources/views/settings/cron.php
+@routes/web.php
+</context>
+
+<skills>
+## Required Skills (from SPECIAL-FLOWS.md)
+
+| Skill | Priority | When to Invoke | Loaded? |
+|-------|----------|----------------|---------|
+| `sonar-scanner` | required | Po APPLY, przed UNIFY | o |
+| /frontend-design | optional | Przy dopracowaniu ukladu tabow i tabeli historii | o |
+| /code-review | optional | Po APPLY, przed UNIFY | o |
+
+**BLOCKING:** Required skills MUST be loaded before APPLY proceeds.
+
+## Skill Invocation Checklist
+- [ ] `sonar-scanner` uruchomiony po APPLY
+- [ ] /frontend-design (opcjonalnie)
+- [ ] /code-review (opcjonalnie)
+
+</skills>
+
+<acceptance_criteria>
+
+## AC-1: Zakladka automatyzacji ma dwa taby z rozdzielonym zakresem
+```gherkin
+Given uzytkownik otwiera `/settings/automation`
+When laduje sie ekran
+Then widzi tab `Ustawienia` z obecna lista regul i akcjami CRUD
+And widzi tab `Historia` z lista wykonan automatyzacji
+```
+
+## AC-2: Historia pokazuje co, kiedy i dla jakiego zamowienia
+```gherkin
+Given regula automatyzacji zostala wywolana przez trigger
+When wykonanie reguly zakonczy sie sukcesem lub bledem
+Then system zapisuje wpis historii zawierajacy co najmniej: event_type, rule_id/rule_name, order_id, status wykonania i timestamp
+And wpis jest widoczny w tabie `Historia`
+```
+
+## AC-3: Historia wspiera filtrowanie i paginacje
+```gherkin
+Given tab `Historia` zawiera wpisy z wielu regul i zdarzen
+When uzytkownik uzyje filtrow (np. event, status, rule, order_id, zakres dat) i zmieni strone
+Then widok pokazuje tylko pasujace rekordy
+And paginacja zachowuje aktywne filtry
+```
+
+## AC-4: Wpisy starsze niz 30 dni sa usuwane automatycznie
+```gherkin
+Given historia zawiera wpisy starsze niz 30 dni
+When uruchomi sie harmonogram czyszczenia
+Then wpisy starsze niz 30 dni zostana usuniete
+And nowsze wpisy pozostaja bez zmian
+```
+
+## AC-5: Dokumentacja odzwierciedla nowy kontrakt historii automatyzacji
+```gherkin
+Given wdrozono nowa tabele i flow zapisu historii automatyzacji
+When zespol czyta dokumentacje techniczna
+Then `DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md` i `DOCS/TECH_CHANGELOG.md` opisuja nowe elementy
+```
+
+## AC-6: Automatyzacja obsluguje akcje zmiany statusu zamowienia
+```gherkin
+Given uzytkownik tworzy lub edytuje regule na `/settings/automation/create`
+When wybierze akcje `Zmien status zamowienia` i wskaze status docelowy
+Then konfiguracja zapisuje sie poprawnie
+And po triggerze reguly status zamowienia jest zmieniany na wskazany status
+And aktualizacja statusu jest zapisana zgodnie z obecnym flow historii statusow/activity log
+```
+
+</acceptance_criteria>
+
+<tasks>
+
+<task type="auto">
+  <name>Task 1: Dodaj model danych historii wykonania automatyzacji i retencje 30 dni</name>
+  <files>database/migrations/20260328_000072_create_automation_execution_logs_table.sql, src/Modules/Automation/AutomationExecutionLogRepository.php, src/Modules/Cron/AutomationHistoryCleanupHandler.php, src/Modules/Cron/CronHandlerFactory.php</files>
+  <action>
+    Dodaj migracje tworzaca tabele historii wykonan automatyzacji (`automation_execution_logs`) z indeksami pod filtry i sortowanie po czasie.
+    Dodaj repozytorium historii z metodami: insert wpisu wykonania, paginowane pobieranie z filtrami, count, purgeOlderThanDays(30).
+    Dodaj handler crona do cyklicznego usuwania starych wpisow i podlacz go w `CronHandlerFactory`.
+    Dodaj seed harmonogramu cleanup (`automation_history_cleanup`) tak, aby dzialal automatycznie bez recznej konfiguracji.
+    Trzymaj sie medoo/prepared statements i bez laczenia SQL stringiem przez wartosci dynamiczne.
+  </action>
+  <verify>rg -n "automation_execution_logs|automation_history_cleanup|purgeOlderThanDays|AutomationHistoryCleanupHandler" database/migrations src/Modules/Automation src/Modules/Cron</verify>
+  <done>AC-2 satisfied i AC-4 satisfied: dane historii sa zapisywane i maja automatyczna retencje 30 dni.</done>
+</task>
+
+<task type="auto">
+  <name>Task 2: Rozszerz AutomationService i kontroler o zapis historii oraz endpoint listowania</name>
+  <files>src/Modules/Automation/AutomationService.php, src/Modules/Automation/AutomationController.php, src/Modules/Automation/AutomationRepository.php, routes/web.php</files>
+  <action>
+    W `AutomationService::trigger` dodaj rejestracje wykonania per regula (co najmniej: event_type, rule_id, rule_name, order_id, result_status, result_message, executed_at), z logowaniem sukcesu i bledow bez zatrzymywania kolejnych regul.
+    Rozszerz `AutomationController::index` o obsluge query filtrow i paginacji historii oraz przekazanie danych do widoku.
+    Dodaj potrzebne metody repository do listowania filtrow pomocniczych (np. aktywne reguly/eventy) jesli sa potrzebne do UI.
+    Zadbaj, aby filtry/paginacja historii nie ingerowaly w istniejaca liste regul i zachowaly kompatybilnosc obecnych akcji CRUD.
+  </action>
+  <verify>rg -n "execution log|history|history_page|history_filters|logExecution|automation history" src/Modules/Automation routes/web.php</verify>
+  <done>AC-2 satisfied i AC-3 satisfied: backend dostarcza pelna historie z filtrowaniem i paginacja.</done>
+</task>
+
+<task type="auto">
+  <name>Task 3: Dodaj akcje `update_order_status` do automatyzacji (backend + formularz)</name>
+  <files>src/Modules/Automation/AutomationController.php, src/Modules/Automation/AutomationService.php, resources/views/automation/form.php, public/assets/js/modules/automation-form.js</files>
+  <action>
+    Rozszerz `ALLOWED_ACTION_TYPES` o nowa akcje `update_order_status` oraz walidacje konfiguracji tej akcji.
+    W `AutomationService` dodaj wykonanie akcji aktualizacji statusu zamowienia przez istniejacy, centralny flow domenowy (z zachowaniem wpisu historii statusow i activity log).
+    W formularzu automatyzacji dodaj nowa opcje akcji `Zmien status zamowienia` oraz selector statusu docelowego oparty o aktywne statusy orderPRO.
+    Utrzymaj zgodnosc create/edit i dynamicznego JS dodajacego kolejne akcje.
+  </action>
+  <verify>rg -n "update_order_status|Zmien status zamowienia|order_status|action_type" src/Modules/Automation resources/views/automation public/assets/js/modules/automation-form.js</verify>
+  <done>AC-6 satisfied: nowa akcja jest konfigurowalna i zmienia status zamowienia.</done>
+</task>
+
+<task type="auto">
+  <name>Task 4: Zbuduj UI dwoch tabow (Ustawienia/Historia) i zaktualizuj dokumentacje</name>
+  <files>resources/views/automation/index.php, resources/scss/modules/_automation.scss, public/assets/css/app.css, DOCS/DB_SCHEMA.md, DOCS/ARCHITECTURE.md, DOCS/TECH_CHANGELOG.md</files>
+  <action>
+    Przebuduj widok `/settings/automation` na taby zgodne ze stylem projektu (`content-tabs-nav` / `content-tab-panel`):
+    - tab `Ustawienia`: zachowuje obecna liste regul i akcje,
+    - tab `Historia`: tabela historii + formularz filtrow + paginacja.
+    Zachowaj kompaktowy layout (male odstepy, duza gestosc informacji) i brak natywnych `alert()/confirm()`.
+    Dodaj/uzupelnij style SCSS tylko w plikach SCSS, a nastepnie przebuduj CSS.
+    Zaktualizuj dokumentacje techniczna o nowa tabele historii oraz nowa akcje `update_order_status`.
+  </action>
+  <verify>rg -n "content-tabs-nav|Historia|Ustawienia|automation history|30 dni|automation_execution_logs|update_order_status" resources/views/automation/index.php resources/scss/modules/_automation.scss DOCS/DB_SCHEMA.md DOCS/ARCHITECTURE.md DOCS/TECH_CHANGELOG.md</verify>
+  <done>AC-1 satisfied i AC-5 satisfied: UI i dokumentacja sa zgodne z nowa funkcjonalnoscia.</done>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-built>Tab `Historia` na `/settings/automation` z filtrowaniem i paginacja, automatyczna retencja wpisow 30 dni oraz akcja `Zmien status zamowienia`.</what-built>
+  <how-to-verify>
+    1. Otworz: `https://orderpro.projectpro.pl/settings/automation`.
+    2. Potwierdz obecnosc tabow: `Ustawienia` i `Historia`.
+    3. W tabie `Historia` ustaw filtry (event, status, order ID lub zakres dat) i sprawdz czy lista oraz licznik/paginacja sa zgodne.
+    4. Wywolaj testowo regule automatyzacji i potwierdz pojawienie sie nowego wpisu (co, kiedy, jakie zamowienie).
+    5. W `Ustawienia > Zadania automatyczne > Dodaj zadanie` wybierz akcje `Zmien status zamowienia`, ustaw status docelowy i zapisz regule.
+    6. Wyzwol regule i potwierdz realna zmiane statusu zamowienia na wybrany status.
+    7. Potwierdz dzialanie cleanupu wpisow >30 dni (przez uruchomienie joba cron lub test na danych historycznych).
+  </how-to-verify>
+  <resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
+</task>
+
+</tasks>
+
+<boundaries>
+
+## DO NOT CHANGE
+- Logika tworzenia/edycji reguly automatyzacji poza koniecznymi zmianami pod nowe taby.
+- Istniejace flow wysylki e-mail/paragonow/statusow przesylki poza dodaniem logowania wykonan.
+- Istniejace flow zmiany statusu zamowienia poza rozszerzeniem go jako nowej akcji automatyzacji.
+- Konfiguracja runtime DB host (`DB_HOST` pozostaje runtime; bez podpinania `DB_HOST_REMOTE`).
+
+## SCOPE LIMITS
+- Zakres dotyczy tylko ekranu `/settings/automation` i warstwy historii automatyzacji.
+- Zakres obejmuje dodanie jednej nowej akcji automatyzacji: `update_order_status`.
+- Bez zmian w innych ekranach ustawien.
+- Bez dodatkowych funkcji biznesowych automatyzacji niezwi¹zanych z historia.
+
+</boundaries>
+
+<verification>
+Before declaring plan complete:
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationController.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationRepository.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationExecutionLogRepository.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationService.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php`
+- [ ] `C:\xampp\php\php.exe -l src/Modules/Cron/AutomationHistoryCleanupHandler.php`
+- [ ] `C:\xampp\php\php.exe -l resources/views/automation/form.php`
+- [ ] `C:\xampp\php\php.exe -l resources/views/automation/index.php`
+- [ ] Migracja wykonuje sie poprawnie i tworzy indeksy historii
+- [ ] Test paginacji/filtrow historii przechodzi
+- [ ] Test akcji `update_order_status` przechodzi (zapis + wykonanie + zmiana statusu)
+- [ ] Test cleanupu wpisow >30 dni przechodzi
+- [ ] Dokumentacja zaktualizowana (`DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md`)
+- [ ] All acceptance criteria met
+</verification>
+
+<success_criteria>
+- `/settings/automation` ma dwa taby: `Ustawienia` i `Historia`.
+- Historia pokazuje wykonania regul (co, kiedy, order) i ma filtry + paginacje.
+- Akcja `Zmien status zamowienia` jest dostepna i poprawnie zmienia status na wybrany przez uzytkownika.
+- Wpisy starsze niz 30 dni sa usuwane automatycznie.
+- Dokumentacja techniczna odzwierciedla nowy model i przeplyw.
+</success_criteria>
+
+<output>
+After completion, create `.paul/phases/49-automation-history-tab/49-01-SUMMARY.md`
+</output>
--- a/.paul/phases/49-automation-history-tab/49-01-SUMMARY.md
+++ b/.paul/phases/49-automation-history-tab/49-01-SUMMARY.md
@@ -0,0 +1,147 @@
+---
+phase: 49-automation-history-tab
+plan: 01
+subsystem: automation
+tags: [automation, history, cron, tabs, update_order_status]
+
+requires:
+  - phase: 47-shipment-created-automation
+    provides: automation trigger shipment.created i akcje automatyzacji
+provides:
+  - historia wykonan automatyzacji z filtrami i paginacja
+  - retencja historii 30 dni przez cron cleanup
+  - akcja automatyzacji update_order_status
+affects: [settings-automation, cron, automation-service]
+
+tech-stack:
+  added: []
+  patterns: [execution-log-per-rule, tabbed-settings-view, safe-automation-action-validation]
+
+key-files:
+  created:
+    - database/migrations/20260328_000072_create_automation_execution_logs_table.sql
+    - src/Modules/Automation/AutomationExecutionLogRepository.php
+    - src/Modules/Cron/AutomationHistoryCleanupHandler.php
+  modified:
+    - src/Modules/Automation/AutomationController.php
+    - src/Modules/Automation/AutomationRepository.php
+    - src/Modules/Automation/AutomationService.php
+    - resources/views/automation/index.php
+    - resources/views/automation/form.php
+    - public/assets/js/modules/automation-form.js
+
+key-decisions:
+  - "Historia automatyzacji zapisywana per regula (success/failed) bez blokowania glownego flow"
+  - "Nowa akcja update_order_status korzysta z centralnego OrdersRepository::updateOrderStatus"
+  - "Retencja historii realizowana cronem automation_history_cleanup (30 dni)"
+
+patterns-established:
+  - "Tab settings/history z zapamietywaniem aktywnej zakladki"
+  - "Walidacja configu akcji automatyzacji po stronie kontrolera"
+
+duration: ~55min
+started: 2026-03-28T13:50:03+01:00
+completed: 2026-03-28T14:45:16+01:00
+---
+
+# Phase 49 Plan 01: Automation History + Update Order Status Summary
+
+**Dostarczono rozdzielenie `/settings/automation` na `Ustawienia/Historia`, audyt historii wykonan regul i akcje `update_order_status`, a dodatkowo po testach wdrozono hotfix fallbacku daty pickup dla Apaczka.**
+
+## Performance
+
+| Metric | Value |
+|--------|-------|
+| Duration | ~55 min |
+| Started | 2026-03-28T13:50:03+01:00 |
+| Completed | 2026-03-28T14:45:16+01:00 |
+| Tasks | 4 completed |
+| Files modified | 16+ |
+
+## Acceptance Criteria Results
+
+| Criterion | Status | Notes |
+|-----------|--------|-------|
+| AC-1: Dwa taby na `/settings/automation` | Pass | `resources/views/automation/index.php` ma taby `Ustawienia` i `Historia` |
+| AC-2: Log co/kiedy/jakie zamowienie | Pass | `AutomationService::logExecution()` + `automation_execution_logs` |
+| AC-3: Filtry + paginacja historii | Pass | `AutomationController::index` + `AutomationExecutionLogRepository::paginate/count` |
+| AC-4: Auto-usuwanie wpisow >30 dni | Pass | cron `automation_history_cleanup` + `purgeOlderThanDays()` |
+| AC-5: Dokumentacja techniczna | Pass | zaktualizowane `DOCS/DB_SCHEMA.md`, `DOCS/ARCHITECTURE.md`, `DOCS/TECH_CHANGELOG.md` |
+| AC-6: Akcja `update_order_status` | Pass | formularz + walidacja + wykonanie przez `OrdersRepository::updateOrderStatus` |
+
+## Verification Results
+
+- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationController.php` -> OK
+- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationRepository.php` -> OK
+- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationExecutionLogRepository.php` -> OK
+- `C:\xampp\php\php.exe -l src/Modules/Automation/AutomationService.php` -> OK
+- `C:\xampp\php\php.exe -l src/Modules/Cron/CronHandlerFactory.php` -> OK
+- `C:\xampp\php\php.exe -l src/Modules/Cron/AutomationHistoryCleanupHandler.php` -> OK
+- `C:\xampp\php\php.exe -l resources/views/automation/form.php` -> OK
+- `C:\xampp\php\php.exe -l resources/views/automation/index.php` -> OK
+- `sonar-scanner` uruchomiony pomyslnie (project `orderPRO`, dashboard updated)
+
+## Files Created/Modified
+
+| File | Change | Purpose |
+|------|--------|---------|
+| `database/migrations/20260328_000072_create_automation_execution_logs_table.sql` | Created | tabela historii + seed cleanup cron |
+| `src/Modules/Automation/AutomationExecutionLogRepository.php` | Created | zapis/listowanie/paginacja/purge historii |
+| `src/Modules/Cron/AutomationHistoryCleanupHandler.php` | Created | czyszczenie wpisow >30 dni |
+| `src/Modules/Cron/CronHandlerFactory.php` | Modified | podpiety handler cleanup |
+| `src/Modules/Automation/AutomationController.php` | Modified | backend tabu historii + nowa akcja update_order_status |
+| `src/Modules/Automation/AutomationRepository.php` | Modified | sortowanie nazw regul + statusy zamowien do akcji |
+| `src/Modules/Automation/AutomationService.php` | Modified | log execution + wykonanie update_order_status |
+| `resources/views/automation/index.php` | Modified | taby, filtry i paginacja historii |
+| `resources/views/automation/form.php` | Modified | UI akcji `Zmiana statusu zamowienia` |
+| `public/assets/js/modules/automation-form.js` | Modified | dynamiczna obsluga nowej akcji |
+| `DOCS/DB_SCHEMA.md` | Modified | kontrakt tabeli historii i zmiany flow |
+| `DOCS/ARCHITECTURE.md` | Modified | opis nowego flow i akcji |
+| `DOCS/TECH_CHANGELOG.md` | Modified | chronologia wdrozenia |
+
+## Decisions Made
+
+| Decision | Rationale | Impact |
+|----------|-----------|--------|
+| Log historii per regula (success/failed) | pelny audyt bez przerywania triggera | szybsza diagnostyka automatyzacji |
+| `update_order_status` przez `OrdersRepository::updateOrderStatus` | reuse centralnego flow status history + activity log | brak duplikacji logiki i spojnosc domenowa |
+| Cleanup historii jako cron | retencja bez manualnej obslugi | stabilny rozmiar danych |
+
+## Deviations from Plan
+
+### Summary
+
+| Type | Count | Impact |
+|------|-------|--------|
+| Auto-fixed | 0 | None |
+| Scope additions | 1 | Niski, uzasadniony produkcyjnym bledem |
+| Deferred | 0 | None |
+
+### Scope addition
+
+- Po APPLY i testach produkcyjnych dodano hotfix `ApaczkaShipmentService`:
+  - fallback retry dla bledow niedostepnego dnia pickup (`Pickup not available...` oraz `you can't place an order today`),
+  - automatyczne przesuwanie `pickup.date` na kolejny dzien roboczy (max 7 prob).
+- Powod: rzeczywisty blad operacyjny blokujacy tworzenie przesylek.
+
+## Skill Audit
+
+- Required `sonar-scanner`: invoked ✓
+- Optional `/code-review`: not invoked
+- Optional `/frontend-design`: not invoked
+
+## Next Phase Readiness
+
+**Ready:**
+- Automatyzacja ma audytowalna historie z retencja.
+- Reguly obsluguja automatyczna zmiane statusu zamowienia.
+
+**Concerns:**
+- Warto rozwazyc logowanie rowniez przypadkow `skipped` (warunki niespelnione), aby ulatwic debug bez diagnostyki DB.
+
+**Blockers:**
+- None
+
+---
+*Phase: 49-automation-history-tab, Plan: 01*
+*Completed: 2026-03-28*