Files
orderPRO/.paul/phases/07-pre-expansion-fixes/07-05-PLAN.md
Jacek Pyziak 03c18f6782 plan(07-pre-expansion-fixes): create 5 plans for pre-expansion fixes
07-01: Performance — N+1 subqueries, information_schema static, DB indexes
07-02: Stability — SSL verification (4 clients), cron throttle→DB, migration 000014b
07-03: UX — orderpro_to_allegro disable, orders list items 14-17
07-04: Tests — AllegroTokenManager + AllegroOrderImportService unit tests
07-05: InPost ShipmentProviderInterface (replaces allegro_wza workaround)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-03-13 17:44:42 +01:00

221 lines
8.6 KiB
Markdown

---
phase: 07-pre-expansion-fixes
plan: 05
type: execute
wave: 2
depends_on: []
files_modified:
- src/Modules/Settings/InpostShipmentService.php
- src/Modules/Shipments/ShipmentController.php
- src/Modules/Shipments/ShipmentProviderRegistry.php
- src/Core/Application.php
autonomous: false
---
<objective>
## Goal
Zastąpić workaround `inpost → allegro_wza` prawdziwym `InpostShipmentService implements ShipmentProviderInterface`, korzystającym z credentiali z `InpostIntegrationRepository`.
## Purpose
Obecnie InPost shipments są tworzone przez Allegro WZA API, co oznacza że użytkownik potrzebuje aktywnej integracji Allegro żeby nadawać przez InPost. To jest cichy bloker dla użytkowników z InPost-only. Każdy nowy przewoźnik dodany bez własnego providera będzie powielał ten pattern.
## Output
- `src/Modules/Settings/InpostShipmentService.php` — implementacja ShipmentProviderInterface
- `ShipmentController.php` — usunięty workaround remap `inpost → allegro_wza`
- Wiring w Application.php / ShipmentProviderRegistry
</objective>
<context>
## Project Context
@.paul/PROJECT.md
## Source Files
@src/Modules/Shipments/ShipmentProviderInterface.php
@src/Modules/Shipments/ShipmentController.php
@src/Modules/Settings/InpostIntegrationRepository.php
@src/Modules/Settings/AllegroShipmentService.php
</context>
<acceptance_criteria>
## AC-1: InpostShipmentService implementuje ShipmentProviderInterface
```gherkin
Given ShipmentProviderInterface definiuje kontrakt dla providerów przesyłek
When tworzysz InpostShipmentService
Then klasa implementuje ShipmentProviderInterface
AND php -l nie zgłasza błędów
AND klasa poprawnie typuje wszystkie wymagane metody interfejsu
```
## AC-2: InPost shipments tworzone przez InPost API (nie Allegro WZA)
```gherkin
Given użytkownik ma skonfigurowane credentiale InPost (token w InpostIntegrationRepository)
AND nie ma skonfigurowanej integracji Allegro
When tworzy przesyłkę InPost przez ShipmentController
Then ShipmentController używa InpostShipmentService (nie AllegroShipmentService)
AND workaround "if (inpost) { providerCode = allegro_wza }" jest usunięty
```
## AC-3: Brak regresji dla istniejących Allegro WZA shipments
```gherkin
Given użytkownik tworzy przesyłkę przez Allegro WZA (provider_code = allegro_wza)
When ShipmentController przetwarza żądanie
Then flow Allegro WZA działa dokładnie jak przed zmianami
AND InPost nie jest mylony z Allegro WZA
```
</acceptance_criteria>
<tasks>
<task type="checkpoint:decision" gate="blocking">
<decision>Który endpoint InPost API do tworzenia paczek?</decision>
<context>
InPost ma dwa API:
A) Allegro WZA (paczkomaty przez Allegro) — obecny workaround, wymaga Allegro auth
B) InPost ShipX API (natywne API InPost) — bezpośrednie, wymaga tokenu InPost
InpostIntegrationRepository przechowuje credentiale — sprawdź jakie pola.
Odczytaj: src/Modules/Settings/InpostIntegrationRepository.php
Opcja A: Zaimplementuj natywny InPost ShipX API (wymaga dokumentacji i tokenu)
Opcja B: Wydziel logikę Allegro WZA do oddzielnego providera bez remapu,
a InPost nadal przez Allegro WZA ale bez tajnego remapu (jawny config)
</context>
<options>
<option id="shipx">
<name>Natywny InPost ShipX API</name>
<pros>Pełna niezależność od Allegro; własne credentiale wystarczą; długoterminowo poprawne</pros>
<cons>Wymaga znajomości ShipX API; potrzebne credentiale testowe do weryfikacji</cons>
</option>
<option id="allegro-wza-explicit">
<name>Allegro WZA ale jawnie skonfigurowany (bez tajnego remapu)</name>
<pros>Szybkie; nie wymaga nowej integracji API; eliminuje workaround kod</pros>
<cons>Nadal wymaga integracji Allegro; nie rozwiązuje problemu InPost-only użytkowników</cons>
</option>
</options>
<resume-signal>Wybierz: "shipx" lub "allegro-wza-explicit", lub opisz inne podejście</resume-signal>
</task>
<task type="auto">
<name>Task 1: Implementuj InpostShipmentService zgodnie z wybraną opcją</name>
<files>
src/Modules/Settings/InpostShipmentService.php,
src/Modules/Settings/InpostIntegrationRepository.php
</files>
<action>
Przeczytaj `src/Modules/Shipments/ShipmentProviderInterface.php` — zrozum wymagany kontrakt.
Przeczytaj `src/Modules/Settings/AllegroShipmentService.php` — jako wzorzec implementacji.
Przeczytaj `src/Modules/Settings/InpostIntegrationRepository.php` — jakie credentiale są dostępne.
**Jeśli wybrano "shipx" (natywny InPost ShipX API):**
- Stwórz `InpostShipmentService implements ShipmentProviderInterface`
- Konstruktor przyjmuje `InpostIntegrationRepository` (dla tokenu)
- Metoda create(): wywołuje ShipX API endpoint tworzenia przesyłki
- Metoda getLabel(): pobiera etykietę przez ShipX API
- Używaj cURL (jak inne ApiClienty) z SSL verification
- Endpointy ShipX: `https://api-shipx-pl.easypack24.net/v1/`
**Jeśli wybrano "allegro-wza-explicit":**
- Stwórz `InpostShipmentService` który wrapuje `AllegroShipmentService`
- Zamiast tajnego remapu — jawna delegacja
- Konstruktor przyjmuje `AllegroShipmentService $allegroService`
- Każda metoda deleguje do $allegroService
W obu przypadkach: namespace App\Modules\Settings, php -l musi przejść.
</action>
<verify>
php -l src/Modules/Settings/InpostShipmentService.php
grep "implements ShipmentProviderInterface" src/Modules/Settings/InpostShipmentService.php
</verify>
<done>AC-1 satisfied: InpostShipmentService implementuje ShipmentProviderInterface</done>
</task>
<task type="auto">
<name>Task 2: Usuń workaround z ShipmentController, podłącz InpostShipmentService</name>
<files>
src/Modules/Shipments/ShipmentController.php,
src/Core/Application.php
</files>
<action>
**W ShipmentController.php:**
Znajdź linie ~164-166:
```php
if ($providerCode === 'inpost') {
$providerCode = 'allegro_wza';
}
```
Usuń ten blok. ShipmentProviderRegistry powinien teraz zawierać 'inpost' jako zarejestrowany provider.
Sprawdź czy jest podobny remap w innych miejscach ShipmentController (linia ~239, ~286) — usuń wszystkie.
**W Application.php (lub ShipmentProviderRegistry):**
Znajdź gdzie rejestrowane są shipment providers.
Dodaj rejestrację InpostShipmentService pod kluczem 'inpost':
```php
$inpostService = new InpostShipmentService(...); // odpowiednie zależności
$providerRegistry->register('inpost', $inpostService);
```
Sprawdź jak AllegroShipmentService jest rejestrowany — użyj tego samego wzorca.
NIE usuwaj rejestracji allegro_wza — nadal musi działać.
</action>
<verify>
php -l src/Modules/Shipments/ShipmentController.php
php -l src/Core/Application.php
grep -n "inpost.*allegro_wza\|allegro_wza.*inpost" src/Modules/Shipments/ShipmentController.php
# Powinno zwrócić 0 — remap usunięty
</verify>
<done>AC-2 i AC-3 satisfied: workaround usunięty, InpostShipmentService zarejestrowany</done>
</task>
<task type="checkpoint:human-verify" gate="blocking">
<what-built>
InpostShipmentService zaimplementowany i podłączony.
Workaround remap inpost→allegro_wza usunięty.
</what-built>
<how-to-verify>
1. Uruchom aplikację (XAMPP)
2. Przejdź do tworzenia przesyłki InPost
3. Sprawdź że przesyłka InPost jest tworzona (lub zwraca czytelny błąd bez PHP errors)
4. Sprawdź że tworzenie przesyłki Allegro WZA nadal działa
5. Sprawdź logi PHP — brak Fatal errors
</how-to-verify>
<resume-signal>Wpisz "approved" jeśli działa, lub opisz błędy</resume-signal>
</task>
</tasks>
<boundaries>
## DO NOT CHANGE
- AllegroShipmentService — nie modyfikuj istniejącej logiki
- ShipmentProviderInterface — nie zmieniaj kontraktu
- Routing (routes/web.php) — nie zmieniaj URL endpointów
## SCOPE LIMITS
- Nie implementuj InPost tracking/status sync — tylko create shipment + label
- Nie zmieniaj UI wyboru przewoźnika — tylko backend provider
- Apaczka, InPost paczkomat przez Allegro WZA nadal działa niezależnie
</boundaries>
<verification>
Przed zamknięciem planu:
- [ ] php -l InpostShipmentService.php
- [ ] php -l ShipmentController.php
- [ ] grep inpost.*allegro_wza ShipmentController.php — 0 wyników
- [ ] Checkpoint human-verify zaliczony
</verification>
<success_criteria>
- InpostShipmentService.php istnieje i implementuje ShipmentProviderInterface
- Remap usunięty z ShipmentController
- Allegro WZA flow bez regresji
- Checkpoint human-verify: approved
</success_criteria>
<output>
Po zakończeniu utwórz `.paul/phases/07-pre-expansion-fixes/07-05-SUMMARY.md`
</output>