orderPRO/.paul/phases/99-order-delivery-payment-edit/99-01-PLAN.md

---
phase: 99-order-delivery-payment-edit
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
  - src/Modules/Orders/OrdersController.php
  - src/Modules/Orders/OrdersRepository.php
  - resources/views/orders/show.php
  - resources/scss/views/orders/_show.scss
  - routes/web.php
autonomous: false
delegation: off
---

<objective>
## Goal
Umozliwic uzytkownikowi zmiane formy dostawy (delivery_method) oraz formy platnosci (payment_method + external_payment_type_id) w istniejacym zamowieniu z poziomu widoku szczegolow /orders/{id} — ze szczegolnym wsparciem scenariusza "przedplata -> pobranie".

## Purpose
Klient kontaktuje sie po zlozeniu zamowienia i prosi o zmiane sposobu dostawy albo o zmiane formy platnosci na pobranie. Dzis wymaga to edycji w zrodle (shopPRO/Allegro) i re-importu albo recznej ingerencji w DB. Funkcja pozwoli obsluzyc to w jednym miejscu, spojnie z reszta przeplywu (activity log, automatyzacje oparte o `order.payment_method` z Phase 96, warunek COD w presetach przesylek).

## Output
- Nowy formularz edycji w karcie "payment_shipping" w `show.php` (modal lub inline form) z dwoma polami: forma dostawy + forma platnosci
- Nowa akcja POST `/orders/{id}/details/update` w `OrdersController`
- Metoda `OrdersRepository::updateDeliveryAndPayment()` z walidacja i atomowym zapisem
- Wpis w `order_activity_log` (`event_type = 'details_change'`) z before/after w `details_json`
- Automatyczna synchronizacja `external_payment_type_id` do `CASH_ON_DELIVERY` przy wyborze pobrania, aby Phase 96 warunek COD i presety autofill dzialaly bez re-importu
</objective>

<context>
## Project Context
@.paul/PROJECT.md
@.paul/ROADMAP.md
@.paul/STATE.md

## Prior Work
@.paul/phases/96-automation-payment-method/96-01-SUMMARY.md
@.paul/phases/77-cod-amount-fix/

## Source Files
@src/Modules/Orders/OrdersController.php
@src/Modules/Orders/OrdersRepository.php
@resources/views/orders/show.php
@src/Core/Support/StringHelper.php
@routes/web.php
</context>

<acceptance_criteria>

## AC-1: Edycja formy dostawy
```gherkin
Given zamowienie w /orders/{id} z delivery_method = "Kurier DPD"
When uzytkownik otworzy formularz edycji, wybierze "InPost Paczkomat" i zatwierdzi
Then delivery_method w DB = "InPost Paczkomat"
  And widok po przeladowaniu pokazuje nowa wartosc
  And w order_activity_log jest wpis event_type='details_change' z before/after w details_json
```

## AC-2: Zmiana platnosci przedplata -> pobranie
```gherkin
Given zamowienie z payment_method = "Przelew" i external_payment_type_id != 'CASH_ON_DELIVERY'
When uzytkownik wybierze forme platnosci "Pobranie" i zatwierdzi
Then payment_method zawiera wartosc wybrana przez uzytkownika (np. "Pobranie")
  And external_payment_type_id = 'CASH_ON_DELIVERY'
  And StringHelper::isCodPayment($order['external_payment_type_id']) zwraca true
  And warunek automatyzacji `order.payment_method = COD` (Phase 96) wyzwala regule na tym zamowieniu
  And autofill kwoty pobrania w formularzu przesylki (Phase 77) dziala dla tego zamowienia
```

## AC-3: Walidacja i bezpieczenstwo
```gherkin
Given uzytkownik wysyla POST /orders/{id}/details/update
When brakuje _token CSRF lub zamowienie nie istnieje
Then kontroler zwraca blad (403 dla CSRF, 404 dla brak zamowienia) bez modyfikacji DB
  And gdy payment_method i delivery_method sa puste po trim, zwraca walidacyjny Flash error i nie zapisuje nic
```

</acceptance_criteria>

<tasks>

<task type="auto">
  <name>Task 1: Repository + route + controller action</name>
  <files>
    src/Modules/Orders/OrdersRepository.php,
    src/Modules/Orders/OrdersController.php,
    routes/web.php
  </files>
  <action>
    1. `OrdersRepository::updateDeliveryAndPayment(int $orderId, ?string $deliveryMethod, ?string $paymentMethod, ?string $externalPaymentTypeId, array $actor): bool`
       - Pobierz biezacy order przez `findDetails()` (before-snapshot)
       - Buduj UPDATE dynamicznie (tylko pola != null po trim, reszta bez zmian)
       - Prepared statement Medoo, bez sklejania SQL
       - Po UPDATE: `recordActivity($orderId, 'details_change', summary, detailsJson)` — detailsJson zawiera pola zmienione z kluczami `before` / `after`
       - Zwroc true gdy faktycznie cokolwiek zmienione, false gdy no-op
       - Zero efektow ubocznych poza orders + order_activity_log (NIE pushuj do shopPRO/Allegro — out of scope)
    2. `OrdersController::updateDetails(int $orderId): Response`
       - Walidacja _token (wzorzec jak `updateStatus()` linia 267)
       - `findDetails()` -> 404 gdy brak
       - Odczyt `delivery_method`, `payment_method` z POST, trim, oba puste -> Flash::set('orders.error') + redirect
       - Gdy uzytkownik zaznaczyl checkbox/flaga `is_cod` (patrz Task 2) ustaw `externalPaymentTypeId = 'CASH_ON_DELIVERY'`, w przeciwnym razie przepusz istniejaca wartosc bez zmiany (null → repo pominie pole)
       - Wywolaj repo, Flash::set('orders.success', 'Dane zamowienia zaktualizowane'), redirect do /orders/{id}
       - Actor z SessionUserContext jak w istniejacych akcjach
    3. `routes/web.php`: zarejestruj POST `/orders/{id}/details/update` → `OrdersController@updateDetails`, middleware identyczny jak inne POST na /orders (csrf + auth)
    Avoid: dodawania logiki push do zrodla (shopPRO/Allegro) — zaznaczone jako out of scope. Avoid: sklejania SQL. Avoid: zmiany `findDetails()` — tylko odczyt snapshot przez istniejaca metode.
  </action>
  <verify>
    curl -X POST z validnym CSRF i body `delivery_method=Kurier&payment_method=Pobranie&is_cod=1` zwraca 302 do /orders/{id};
    SELECT z orders pokazuje zaktualizowane 3 pola;
    SELECT z order_activity_log pokazuje wpis event_type='details_change' z details_json zawierajacym `delivery_method.before/after` i `external_payment_type_id.before/after`
  </verify>
  <done>AC-1, AC-3 satisfied na poziomie backend</done>
</task>

<task type="auto">
  <name>Task 2: UI form w karcie payment_shipping</name>
  <files>
    resources/views/orders/show.php,
    resources/scss/views/orders/_show.scss
  </files>
  <action>
    1. W `show.php` w karcie "payment_shipping" dodaj ikonke ✎ (pattern zgodny z feedback memory — hover + dropdown/inline) ktora otwiera inline form pod naglowkiem karty.
    2. Form:
       - `<form method="POST" action="/orders/{id}/details/update">`
       - Ukryty `_token`
       - `<input type="text" name="delivery_method" value="<?= e($order['delivery_method']) ?>">` z listą datalist bazujaca na DISTINCT delivery_method z ostatnich 50 zamowien (lekki helper w controllerze — przekaz przez $data)
       - `<input type="text" name="payment_method" value="...">` analogicznie
       - `<label><input type="checkbox" name="is_cod" value="1" <?= StringHelper::isCodPayment($order['external_payment_type_id']) ? 'checked' : '' ?>> Pobranie (COD)</label>` — wyjasnia ze zaznaczenie ustawi external_payment_type_id
       - Submit button "Zapisz" + cancel (ukryj form)
    3. Kompaktowy uklad (zgodnie z CLAUDE.md: gesty), style w `_show.scss`, zero CSS w widoku
    4. OrderProAlerts dla ewentualnych komunikatow (nie natywne alert)
    Avoid: natywnego alert/confirm, CSS w widoku, duplikacji — jezeli datalist juz istnieje dla formy, reuse
  </action>
  <verify>
    Otworz /orders/{id} w przegladarce; kliknij ✎ przy payment_shipping; zmien pola; zatwierdz; po redirect widac zaktualizowane dane w karcie
  </verify>
  <done>AC-1, AC-2 satisfied na poziomie UI</done>
</task>

<task type="checkpoint:human-verify" gate="blocking">
  <what-built>
    Edycja formy dostawy i platnosci w /orders/{id}:
    - Ikonka ✎ w karcie payment_shipping, inline form, datalist podpowiedzi
    - Checkbox "Pobranie (COD)" ustawia external_payment_type_id = CASH_ON_DELIVERY
    - Wpis w activity log details_change
  </what-built>
  <how-to-verify>
    1. Otworz /orders/{id} z zamowieniem platnym przelewem (external_payment_type_id != CASH_ON_DELIVERY)
    2. Kliknij ✎ w karcie Platnosc i wysylka
    3. Zmien delivery_method na dowolna inna wartosc, zmien payment_method na "Pobranie", zaznacz checkbox COD, zapisz
    4. Po redirect sprawdz:
       - karta pokazuje nowe wartosci
       - zakladka Historia (activity log) ma wpis "Zmiana danych zamowienia" (details_change)
       - Przejdz do formularza przesylki — autofill kwoty pobrania (Phase 77) dziala
       - Jesli masz regule automatyzacji z warunkiem Metoda platnosci = COD (Phase 96) + jakims triggerem manualnym — zweryfikuj ze regula pasuje do tego zamowienia
    5. Test walidacji: sprobuj zapisac z obydwoma polami pustymi — powinien pojawic sie Flash error i brak zmian
  </how-to-verify>
  <resume-signal>Type "approved" to continue, or describe issues to fix</resume-signal>
</task>

</tasks>

<boundaries>

## DO NOT CHANGE
- `OrderImportRepository.php` — logika importu jest stabilna (Phase 62/75 re-import safety)
- `ShopproApiClient`, `AllegroApiClient` — push do zrodla poza zakresem
- `findDetails()`, `paginate()` — tylko konsumenci, nie modyfikacja
- Schemat DB — wszystkie pola juz istnieja (delivery_method, payment_method, external_payment_type_id)

## SCOPE LIMITS
- Brak push zmiany formy platnosci / dostawy do shopPRO ani Allegro (jeden kierunek: orderPRO lokalnie)
- Brak nowej tabeli / migracji
- Brak rozszerzania modulu Automatyzacji o nowy event `details_changed` — to osobna faza jezeli potrzebne
- Brak walidacji ze slownika form platnosci — free text z datalist podpowiedzi (spojne z dzisiejszym importem)
- Brak edycji delivery_price / kwoty pobrania — tylko metody
- Brak edycji danych odbiorcy / adresu — osobny scope

</boundaries>

<verification>
Przed zamknieciem planu:
- [ ] `php -l` na zmodyfikowanych plikach PHP
- [ ] Manualny test AC-1, AC-2, AC-3 w przegladarce
- [ ] SELECT z order_activity_log potwierdza wpis details_change z poprawnym JSON
- [ ] Po zmianie na COD: autofill kwoty pobrania (Phase 77) dziala, warunek Metoda platnosci = COD (Phase 96) matchuje
- [ ] Brak natywnych alert/confirm w dodanym UI
- [ ] Brak CSS w widoku, style w `_show.scss`
</verification>

<success_criteria>
- Wszystkie 3 AC spelnione
- Zero regresji w istniejacych akcjach /orders/{id} (status change, add payment)
- Spojnosc z Phase 77 (COD autofill) i Phase 96 (automation COD condition) — obie korzystaja z nowego stanu bez zadnych dodatkowych zmian
- Nowa akcja ma CSRF + auth, Medoo prepared statements
</success_criteria>

<output>
After completion, create `.paul/phases/99-order-delivery-payment-edit/99-01-SUMMARY.md`
</output>