orderPRO/.paul/phases/03-tech-debt/03-01-PLAN.md

---
phase: 03-tech-debt
plan: 01
type: execute
wave: 1
depends_on: []
files_modified:
  - src/Modules/Orders/OrdersController.php
  - src/Modules/Shipments/ShipmentController.php
  - resources/views/orders/show.php
  - resources/views/shipments/prepare.php
autonomous: true
---

<objective>
## Cel
Ustandaryzować nazwę pola CSRF token we wszystkich kontrolerach i widokach — zmienić `_csrf_token` na `_token` (standard używany przez większość kodu).

## Uzasadnienie
`OrdersController` i `ShipmentController` czytają pole formularza `_csrf_token`, podczas gdy wszystkie pozostałe kontrolery (Settings, Auth, Users) używają `_token`. Widoki zamówień i przesyłek wysyłają token pod nazwą `_csrf_token`, co jest niezgodne z resztą aplikacji. Rozbieżność stwarza ryzyko użycia złej nazwy przy dodawaniu nowych formularzy i cichego złamania ochrony CSRF.

## Wynik
Wszystkie formularze i kontrolery w aplikacji używają jednolitej nazwy `_token` dla pola CSRF. Concern usunięty z `CONCERNS.md`.
</objective>

<context>
## Kontekst projektu
@.paul/PROJECT.md
@.paul/ROADMAP.md
@.paul/STATE.md

## Pliki źródłowe
@src/Modules/Orders/OrdersController.php
@src/Modules/Shipments/ShipmentController.php
@resources/views/orders/show.php
@resources/views/shipments/prepare.php
</context>

<skills>
## Wymagane skille (z SPECIAL-FLOWS.md)

| Skill | Priorytet | Kiedy wywołać | Załadowany? |
|-------|-----------|---------------|-------------|
| sonar-scanner (CLI) | required | Po APPLY, przed UNIFY | ○ |
| /code-review | optional | Po implementacji, przed UNIFY | ○ |

**BLOKUJĄCE:** `sonar-scanner` MUSI być uruchomiony po APPLY, przed UNIFY.

## Checklist
- [ ] sonar-scanner uruchomiony (po APPLY)
- [ ] /code-review (opcjonalnie)
</skills>

<acceptance_criteria>

## AC-1: Kontrolery używają `_token`
```gherkin
Given OrdersController i ShipmentController czytają pole CSRF
When aplikacja przetwarza POST z formularza zamówień lub przesyłki
Then kontrolery odczytują pole pod nazwą `_token` (nie `_csrf_token`)
```

## AC-2: Widoki wysyłają `_token`
```gherkin
Given widoki orders/show.php i shipments/prepare.php renderują formularze
When strona zostanie wczytana
Then pola hidden mają atrybut name="_token" (nie name="_csrf_token")
```

## AC-3: Ochrona CSRF działa po zmianie
```gherkin
Given aplikacja jest uruchomiona lokalnie
When użytkownik prześle formularz z widoku zamówień lub przesyłki
Then walidacja CSRF przechodzi i akcja wykonuje się poprawnie
```

</acceptance_criteria>

<tasks>

<task type="auto">
  <name>Zadanie 1: Zmień nazwę pola CSRF w kontrolerach</name>
  <files>src/Modules/Orders/OrdersController.php, src/Modules/Shipments/ShipmentController.php</files>
  <action>
    W obu plikach zamień wszystkie wywołania `$request->input('_csrf_token', '')` na `$request->input('_token', '')`.

    OrdersController.php: 1 wystąpienie (ok. linia 202)
    ShipmentController.php: 2 wystąpienia (ok. linie 153 i 270)

    Nie zmieniaj niczego poza samą nazwą pola — logika walidacji, zmienne, komunikaty błędów pozostają bez zmian.
    Nie zmieniaj SESSION_KEY w Csrf.php — to jest klucz sesji (wewnętrzny), nie nazwa pola formularza.
  </action>
  <verify>grep -n "_csrf_token" src/Modules/Orders/OrdersController.php src/Modules/Shipments/ShipmentController.php — musi zwrócić 0 wyników</verify>
  <done>AC-1 spełnione: kontrolery czytają `_token`</done>
</task>

<task type="auto">
  <name>Zadanie 2: Zmień nazwę pola CSRF w widokach</name>
  <files>resources/views/orders/show.php, resources/views/shipments/prepare.php</files>
  <action>
    W obu plikach zamień wszystkie `name="_csrf_token"` na `name="_token"`.

    resources/views/orders/show.php: 1 wystąpienie (ok. linia 67)
    resources/views/shipments/prepare.php: 2 wystąpienia (ok. linie 108 i 141)

    Nie zmieniaj niczego poza atrybutem name w tagach input hidden.
  </action>
  <verify>grep -n "_csrf_token" resources/views/orders/show.php resources/views/shipments/prepare.php — musi zwrócić 0 wyników</verify>
  <done>AC-2 spełnione: widoki wysyłają `_token`</done>
</task>

<task type="auto">
  <name>Zadanie 3: Usuń concern z CONCERNS.md</name>
  <files>.paul/codebase/CONCERNS.md</files>
  <action>
    Usuń całą sekcję `### [MEDIUM] CSRF Token Field Name Inconsistency` (wraz z pustą linią przed i po) z pliku `.paul/codebase/CONCERNS.md`.
    Zgodnie z zasadą projektu: po naprawieniu concernu — usuwamy go całkowicie.
  </action>
  <verify>grep -n "CSRF Token Field Name" .paul/codebase/CONCERNS.md — musi zwrócić 0 wyników</verify>
  <done>Concern usunięty z rejestru</done>
</task>

</tasks>

<boundaries>

## DO NOT CHANGE
- `src/Core/Security/Csrf.php` — klasa Csrf nie jest zmieniana; `SESSION_KEY = '_csrf_token'` to wewnętrzny klucz sesji, nie nazwa pola HTTP
- Wszystkie inne widoki i kontrolery korzystające już z `_token` — nie wymagają zmian
- Logika walidacji CSRF — zmieniamy tylko nazwę pola, nie algorytm

## SCOPE LIMITS
- Ten plan dotyczy wyłącznie ustandaryzowania nazwy pola `_csrf_token` → `_token`
- Nie naprawiamy przy okazji innych problemów CSRF (rotacja tokenu, middleware) — to osobne concerny
- Nie modyfikujemy żadnych innych plików poza wymienionymi w `files_modified`

</boundaries>

<verification>
Przed uznaniem planu za kompletny:
- [ ] grep -rn "_csrf_token" src/ resources/views/ — brak wyników (poza Csrf.php SESSION_KEY)
- [ ] Aplikacja uruchamia się bez błędów PHP (`php -l` na zmienionych plikach)
- [ ] Formularz przesyłki (shipments/prepare.php) przesyła się poprawnie
- [ ] Formularz zamówień (orders/show.php) działa poprawnie
- [ ] Wszystkie 3 zadania ukończone
</verification>

<success_criteria>
- Wszystkie zadania ukończone
- 0 wystąpień `_csrf_token` w src/ i resources/views/ (poza SESSION_KEY w Csrf.php)
- Aplikacja działa poprawnie — formularze zamówień i przesyłek przechodzą walidację CSRF
- Concern usunięty z CONCERNS.md
- Brak nowych błędów PHP
</success_criteria>

<output>
Po zakończeniu utwórz `.paul/phases/03-tech-debt/03-01-SUMMARY.md`
</output>