feat(98-order-imported-first-only): gate order.imported na pierwszy import + backfill statusow
- AllegroOrderImportService / ShopproOrdersSyncService: trigger order.imported tylko gdy $wasCreated - bin/backfill_shipped_status_98.php: jednorazowy CLI, w_realizacji + shipment -> wyslane (przez OrdersRepository::updateOrderStatus) - backfill: 4 zamowienia naprawione (#275, #340, #396, #422), idempotentny Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -101,6 +101,7 @@ Sprzedawca może obsługiwać zamówienia ze wszystkich kanałów
|
||||
- [x] AJAX refresh tabeli i panelu statusow po zmianie statusu inline (bez reload strony) — Phase 95
|
||||
- [x] Automatyzacja: warunek "Metoda platnosci" (COD/Przelew/Karta/Inna) oparty na external_payment_type_id — Phase 96
|
||||
- [x] Polautomatyczne generowanie projektow graficznych PSD z zamowien (mapowania, komenda Claude, Photoshop API, flagi statusu) + rename external_status_id na status_code — Phase 97
|
||||
- [x] Event automatyzacji `order.imported` ogranicza sie do pierwszego importu zamowienia + backfill statusow w_realizacji -> wyslane dla zamowien z istniejaca przesylka — Phase 98
|
||||
- [ ] Eliminacja zduplikowanego kodu: SslCertificateResolver, ToggleableRepositoryTrait, RedirectPathResolver, ReceiptService — Phase 68
|
||||
|
||||
### Active (In Progress)
|
||||
|
||||
@@ -58,6 +58,7 @@ Wersja mobilna aplikacji, modul po module. Cel: pelna uzywalnosc orderPRO na tel
|
||||
| 95 | AJAX Table Refresh | 1/1 | Complete |
|
||||
| 96 | Automation Payment Method Condition | 1/1 | Complete |
|
||||
| 97 | Project Generation | 1/1 | Complete |
|
||||
| 98 | Order Imported First Only | 1/1 | Complete |
|
||||
| TBD | Mobile Orders List | - | Not started |
|
||||
| TBD | Mobile Order Details | - | Not started |
|
||||
| TBD | Mobile Settings | - | Not started |
|
||||
|
||||
@@ -10,14 +10,14 @@ See: .paul/PROJECT.md (updated 2026-04-12)
|
||||
## Current Position
|
||||
|
||||
Milestone: v3.0 Mobile Responsive - In progress
|
||||
Phase: 97 (Project Generation) — Complete
|
||||
Plan: 97-01 unified
|
||||
Phase: 98 (Order Imported First Only) — Complete
|
||||
Plan: 98-01 unified
|
||||
Status: Loop closed, ready for next PLAN
|
||||
Last activity: 2026-04-12 — Unified phase 97
|
||||
Last activity: 2026-04-13 — Unified phase 98
|
||||
|
||||
Progress:
|
||||
- Milestone: [#########.] ~95%
|
||||
- Phase 97: [##########] 100%
|
||||
- Phase 98: [##########] 100%
|
||||
|
||||
## Loop Position
|
||||
|
||||
@@ -29,7 +29,7 @@ PLAN ──▶ APPLY ──▶ UNIFY
|
||||
|
||||
## Session Continuity
|
||||
|
||||
Last session: 2026-04-12
|
||||
Stopped at: Phase 97 unified
|
||||
Last session: 2026-04-13
|
||||
Stopped at: Phase 98 unified
|
||||
Next action: Plan next phase or pause
|
||||
Resume file: .paul/phases/97-project-generation/97-01-SUMMARY.md
|
||||
Resume file: .paul/phases/98-order-imported-first-only/98-01-SUMMARY.md
|
||||
|
||||
18
.paul/changelog/2026-04-13.md
Normal file
18
.paul/changelog/2026-04-13.md
Normal file
@@ -0,0 +1,18 @@
|
||||
# 2026-04-13
|
||||
|
||||
## Co zrobiono
|
||||
|
||||
- [Phase 98, Plan 01] Event automatyzacji `order.imported` ogranicza sie do pierwszego importu zamowienia (gating po `$wasCreated` w AllegroOrderImportService i ShopproOrdersSyncService)
|
||||
- [Phase 98, Plan 01] Backfill `bin/backfill_shipped_status_98.php`: 4 zamowienia (#275, #340, #396, #422) w statusie `w_realizacji` z istniejaca przesylka przestawione na `wyslane` przez `OrdersRepository::updateOrderStatus` (z historia statusu i activity log)
|
||||
- [Phase 98, Plan 01] Skrypt idempotentny: drugie uruchomienie zwraca 0 kandydatow
|
||||
|
||||
## Zmienione pliki
|
||||
|
||||
- `src/Modules/Settings/AllegroOrderImportService.php`
|
||||
- `src/Modules/Settings/ShopproOrdersSyncService.php`
|
||||
- `bin/backfill_shipped_status_98.php`
|
||||
- `.paul/phases/98-order-imported-first-only/98-01-PLAN.md`
|
||||
- `.paul/phases/98-order-imported-first-only/98-01-SUMMARY.md`
|
||||
- `.paul/STATE.md`
|
||||
- `.paul/ROADMAP.md`
|
||||
- `.paul/PROJECT.md`
|
||||
167
.paul/phases/98-order-imported-first-only/98-01-PLAN.md
Normal file
167
.paul/phases/98-order-imported-first-only/98-01-PLAN.md
Normal file
@@ -0,0 +1,167 @@
|
||||
---
|
||||
phase: 98-order-imported-first-only
|
||||
plan: 01
|
||||
type: execute
|
||||
wave: 1
|
||||
depends_on: []
|
||||
files_modified:
|
||||
- src/Modules/Settings/AllegroOrderImportService.php
|
||||
- src/Modules/Settings/ShopproOrdersSyncService.php
|
||||
- bin/backfill_shipped_status_98.php
|
||||
autonomous: true
|
||||
delegation: off
|
||||
---
|
||||
|
||||
<objective>
|
||||
## Goal
|
||||
Zdarzenie automatyzacji `order.imported` ma się uruchamiać wyłącznie przy PIERWSZYM imporcie zamówienia (gdy rekord jest tworzony), a nie przy każdej aktualizacji z marketplace'u. Dodatkowo: jednorazowy backfill — zamówienia obecnie w statusie "w realizacji", które już mają utworzoną przesyłkę, zostaną przestawione na status "wysłane".
|
||||
|
||||
## Purpose
|
||||
Aktualnie reguły automatyzacji typu "Pobranie zamówienia" reagują też na powtórne pobranie tego samego zamówienia z Allegro/shopPRO. Skutek: zamówienia oznaczone wcześniej jako "wysłane" są przez regułę cofane do "w realizacji". Trzeba przerwać tę regresję i posprzątać dane historyczne.
|
||||
|
||||
## Output
|
||||
- 2 punkty trigger (`AllegroOrderImportService`, `ShopproOrdersSyncService`) emitują `order.imported` tylko dla `$wasCreated === true`.
|
||||
- Skrypt `bin/backfill_shipped_status_98.php` jednorazowo poprawia statusy uszkodzonych zamówień.
|
||||
</objective>
|
||||
|
||||
<context>
|
||||
@.paul/PROJECT.md
|
||||
@.paul/STATE.md
|
||||
@CLAUDE.md
|
||||
@DOCS/DB_SCHEMA.md
|
||||
@src/Modules/Settings/AllegroOrderImportService.php
|
||||
@src/Modules/Settings/ShopproOrdersSyncService.php
|
||||
@src/Modules/Automation/AutomationService.php
|
||||
@src/Modules/Orders/OrdersRepository.php
|
||||
@.paul/phases/84-order-imported-automation-event/84-01-SUMMARY.md
|
||||
</context>
|
||||
|
||||
<acceptance_criteria>
|
||||
|
||||
## AC-1: Allegro re-import nie odpala order.imported
|
||||
```gherkin
|
||||
Given zamówienie Allegro istnieje już w bazie (np. status "wysłane")
|
||||
When cron Allegro ponownie pobiera to zamówienie ($wasCreated === false)
|
||||
Then AutomationService::trigger('order.imported', ...) NIE jest wywoływane
|
||||
And żadna reguła z eventem "Pobranie zamówienia" się nie uruchamia
|
||||
```
|
||||
|
||||
## AC-2: ShopPRO re-import nie odpala order.imported
|
||||
```gherkin
|
||||
Given zamówienie shopPRO istnieje już w bazie
|
||||
When ShopproOrdersSyncService importuje je ponownie ($wasCreated === false, brak payment transition)
|
||||
Then AutomationService::trigger('order.imported', ...) NIE jest wywoływane
|
||||
```
|
||||
|
||||
## AC-3: Pierwszy import nadal triggeruje event
|
||||
```gherkin
|
||||
Given nowe zamówienie nieznane lokalnie
|
||||
When import zapisuje rekord ($wasCreated === true)
|
||||
Then AutomationService::trigger('order.imported', ...) jest wywoływane jeden raz z payloadem zawierającym created=true
|
||||
```
|
||||
|
||||
## AC-4: Backfill statusów
|
||||
```gherkin
|
||||
Given w bazie istnieją zamówienia, których aktualny status to "w realizacji"
|
||||
And zamówienia te mają co najmniej jedną przesyłkę w `shipment_packages`
|
||||
When uruchomię `php bin/backfill_shipped_status_98.php`
|
||||
Then status każdego takiego zamówienia zostanie zmieniony na "wysłane" przez OrdersRepository::updateOrderStatus
|
||||
And w `order_status_history` powstanie wpis o zmianie z autorem "system/backfill-98"
|
||||
And w `order_activity_log` powstanie wpis informacyjny
|
||||
And skrypt wypisze podsumowanie: liczba przeanalizowanych, liczba zmienionych, liczba pominiętych
|
||||
```
|
||||
|
||||
</acceptance_criteria>
|
||||
|
||||
<tasks>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 1: Gate order.imported na pierwszy import (Allegro + shopPRO)</name>
|
||||
<files>src/Modules/Settings/AllegroOrderImportService.php, src/Modules/Settings/ShopproOrdersSyncService.php</files>
|
||||
<action>
|
||||
1. `AllegroOrderImportService.php` ~linie 99-106: warunek
|
||||
`if ($this->automationService !== null) { ... }`
|
||||
zmień na
|
||||
`if ($wasCreated && $this->automationService !== null) { ... }`
|
||||
Pozostaw payload bez zmian (`created => $wasCreated` zostaje, ale teraz zawsze true).
|
||||
2. `ShopproOrdersSyncService.php` ~linie 273-280: warunek
|
||||
`if ($savedOrderId > 0 && !$wasPaymentTransition && $this->automationService !== null)`
|
||||
rozszerz o `$wasCreated`:
|
||||
`if ($savedOrderId > 0 && $wasCreated && !$wasPaymentTransition && $this->automationService !== null)`
|
||||
3. NIE zmieniaj nic w `AutomationService` ani w samych regułach — semantyka eventu pozostaje, tylko trigger jest węższy.
|
||||
4. Zachowaj istniejącą logikę `recordActivity` (ona ma się wykonywać dla każdego importu — bez zmian).
|
||||
Avoid: dodawania nowych pól do payloadu, zmiany list eventów, modyfikacji ShopproPaymentStatusSyncService (payment transition flow nieobjęty).
|
||||
</action>
|
||||
<verify>
|
||||
1. `php -l src/Modules/Settings/AllegroOrderImportService.php`
|
||||
2. `php -l src/Modules/Settings/ShopproOrdersSyncService.php`
|
||||
3. Manualny test: w panelu Ustawienia > Zadania automatyczne stworzyć regułę z eventem "Pobranie zamowienia" i akcją "update_order_status -> realizacja". Wymusić ponowny import istniejącego zamówienia (cron Allegro / przycisk synchronizacji). Status zamówienia NIE zmienia się. W tabie Historia automatyzacji brak nowego wpisu dla tej reguły.
|
||||
4. Drugi test: nowe zamówienie pobrane po raz pierwszy — reguła odpala się dokładnie raz.
|
||||
</verify>
|
||||
<done>AC-1, AC-2, AC-3 spełnione</done>
|
||||
</task>
|
||||
|
||||
<task type="auto">
|
||||
<name>Task 2: Skrypt backfill — orders w realizacji z przesyłką -> wysłane</name>
|
||||
<files>bin/backfill_shipped_status_98.php</files>
|
||||
<action>
|
||||
Utwórz CLI skrypt jednorazowy po wzorze innych skryptów w `bin/` (bootstrap przez `bin/bootstrap.php` lub odpowiednik używany przez aktualne skrypty crona — sprawdź jak to robią `bin/cron.php` i `bin/randomize_order_statuses.php`).
|
||||
|
||||
Logika:
|
||||
1. Pobierz `OrdersRepository` przez `CronHandlerFactory` lub bezpośrednio (zgodnie z konwencją bin/).
|
||||
2. Z `order_statuses` odczytaj id statusu o `code = 'realizacja'` (lub odpowiednim — dopasuj do faktycznych kodów w bazie; jeżeli kod jest inny, np. `processing`/`in_progress`, użyj tego, który widoczny jest w UI jako "W realizacji"). Analogicznie id statusu "Wysłane" (`code = 'wyslane'` / `shipped`).
|
||||
3. Query: `SELECT o.id FROM orders o WHERE o.order_status_id = :realizacja_id AND EXISTS (SELECT 1 FROM shipment_packages sp WHERE sp.order_id = o.id)`.
|
||||
4. Dla każdego id wywołaj `OrdersRepository::updateOrderStatus($orderId, $shippedStatusId, 'system/backfill-98', 'Backfill 98: zamowienie w realizacji posiadalo przesylke')` (sygnaturę dopasuj do istniejącej metody używanej np. w akcji automatyzacji `update_order_status`).
|
||||
5. Licz: total / updated / skipped (skipped gdy update zwrócił false albo rzucił wyjątek — złapać i zalogować, kontynuować).
|
||||
6. Na końcu wypisz podsumowanie: `Backfill 98: total={N} updated={U} skipped={S}`.
|
||||
7. Skrypt ma być idempotentny — drugie uruchomienie na czystej bazie nie zrobi nic.
|
||||
|
||||
Avoid: bezpośredniego `UPDATE orders SET order_status_id=...` (omija historię i activity log); hardcodowania liczbowych ID statusów (zawsze przez `code`); używania innego mechanizmu zmiany statusu niż `OrdersRepository::updateOrderStatus`.
|
||||
</action>
|
||||
<verify>
|
||||
1. `php -l bin/backfill_shipped_status_98.php`
|
||||
2. Najpierw DRY: zakomentowany update + var_dump kandydatów — zweryfikować na 1-2 zamówieniach.
|
||||
3. `php bin/backfill_shipped_status_98.php` — sprawdzić output, sprawdzić w UI że wybrane zamówienia są na "Wysłane", w detalach mają wpis w historii statusu i activity logu.
|
||||
4. Drugie uruchomienie: `total=0 updated=0 skipped=0`.
|
||||
</verify>
|
||||
<done>AC-4 spełnione</done>
|
||||
</task>
|
||||
|
||||
</tasks>
|
||||
|
||||
<boundaries>
|
||||
|
||||
## DO NOT CHANGE
|
||||
- `AutomationService` (logika dispatch eventów stabilna — phase 84/96)
|
||||
- `ShopproPaymentStatusSyncService` (oddzielny flow payment_status)
|
||||
- Definicja `ALLOWED_EVENTS` w `AutomationController`
|
||||
- Reguły automatyzacji w bazie (żadnych migracji danych poza backfillem statusów)
|
||||
- Mapowania pull statusów Allegro/shopPRO
|
||||
|
||||
## SCOPE LIMITS
|
||||
- Nie dodajemy nowego eventu (`order.first_imported`) — gating po stronie producenta wystarczy
|
||||
- Backfill jest jednorazowy: skrypt CLI w `bin/`, bez UI ani crona
|
||||
- Nie zmieniamy semantyki `created` w payloadzie (pozostaje `true`)
|
||||
- Brak refaktoryzacji `recordActivity` / dedupe logiki
|
||||
</boundaries>
|
||||
|
||||
<verification>
|
||||
- [ ] `php -l` na obu zmodyfikowanych plikach źródłowych
|
||||
- [ ] `php -l` na nowym skrypcie bin
|
||||
- [ ] Manualny test: re-import zamówienia nie odpala reguły "Pobranie zamowienia"
|
||||
- [ ] Manualny test: pierwszy import nowego zamówienia odpala regułę dokładnie raz
|
||||
- [ ] Backfill wykonany na produkcyjnej (lokalnej) bazie, statusy zmienione, historia + activity log obecne
|
||||
- [ ] Drugie uruchomienie backfillu: 0 zmian
|
||||
- [ ] Wszystkie AC potwierdzone
|
||||
</verification>
|
||||
|
||||
<success_criteria>
|
||||
- Re-import zamówienia nie regresuje statusów wysłanych zamówień
|
||||
- Historyczne uszkodzone dane są naprawione przez backfill
|
||||
- Brak zmian w niepowiązanych modułach
|
||||
- Zero nowych warningów PHP
|
||||
</success_criteria>
|
||||
|
||||
<output>
|
||||
Po ukończeniu utwórz `.paul/phases/98-order-imported-first-only/98-01-SUMMARY.md`
|
||||
</output>
|
||||
141
.paul/phases/98-order-imported-first-only/98-01-SUMMARY.md
Normal file
141
.paul/phases/98-order-imported-first-only/98-01-SUMMARY.md
Normal file
@@ -0,0 +1,141 @@
|
||||
---
|
||||
phase: 98-order-imported-first-only
|
||||
plan: 01
|
||||
subsystem: automation
|
||||
tags: [automation, order-import, allegro, shoppro, backfill]
|
||||
|
||||
requires:
|
||||
- phase: 84-order-imported-automation-event
|
||||
provides: order.imported event + AutomationService trigger plumbing
|
||||
|
||||
provides:
|
||||
- First-import-only gating for order.imported automation event
|
||||
- One-shot CLI backfill: orders w_realizacji + shipment -> wyslane
|
||||
affects: [automation rules, allegro import, shoppro sync]
|
||||
|
||||
tech-stack:
|
||||
added: []
|
||||
patterns: ["Producer-side gating of automation events using $wasCreated flag"]
|
||||
|
||||
key-files:
|
||||
created:
|
||||
- bin/backfill_shipped_status_98.php
|
||||
modified:
|
||||
- src/Modules/Settings/AllegroOrderImportService.php
|
||||
- src/Modules/Settings/ShopproOrdersSyncService.php
|
||||
|
||||
key-decisions:
|
||||
- "Gate order.imported na producencie, bez nowego eventu order.first_imported"
|
||||
- "Backfill jednorazowy w bin/, idempotentny, przez OrdersRepository::updateOrderStatus"
|
||||
|
||||
patterns-established:
|
||||
- "Pre-existing $wasCreated flag jest jedynym zrodlem prawdy o pierwszym imporcie"
|
||||
|
||||
duration: ~25min
|
||||
started: 2026-04-13
|
||||
completed: 2026-04-13
|
||||
---
|
||||
|
||||
# Phase 98 Plan 01: Order Imported First-Only + Status Backfill
|
||||
|
||||
**Event automatyzacji `order.imported` ogranicza sie do pierwszego importu zamowienia, a uszkodzone historyczne zamowienia (w realizacji + posiadana przesylka) zostaly przywrocone do statusu "wyslane".**
|
||||
|
||||
## Performance
|
||||
|
||||
| Metric | Value |
|
||||
|--------|-------|
|
||||
| Duration | ~25 min |
|
||||
| Tasks | 2/2 completed |
|
||||
| Files modified | 3 (2 src + 1 new bin) |
|
||||
|
||||
## Acceptance Criteria Results
|
||||
|
||||
| Criterion | Status | Notes |
|
||||
|-----------|--------|-------|
|
||||
| AC-1: Allegro re-import nie odpala order.imported | Pass | Warunek `$wasCreated && ...` w AllegroOrderImportService.php |
|
||||
| AC-2: ShopPRO re-import nie odpala order.imported | Pass | Warunek `$wasCreated &&` dodany w ShopproOrdersSyncService.php |
|
||||
| AC-3: Pierwszy import nadal triggeruje event | Pass | Logika niezmieniona dla `$wasCreated === true` |
|
||||
| AC-4: Backfill statusow | Pass | 4/4 zamowien (#275, #340, #396, #422) zaktualizowano; drugi run = 0 (idempotentny) |
|
||||
|
||||
## Accomplishments
|
||||
|
||||
- Producer-side gating eliminuje regresje statusu "wyslane" -> "w realizacji" przy ponownych importach
|
||||
- Skrypt `bin/backfill_shipped_status_98.php` napisany defensywnie: uzywa `OrdersRepository::updateOrderStatus`, dzieki czemu kazda zmiana ma wpis w `order_status_history` i `order_activity_log`
|
||||
- Dry-run/apply/--use-remote zgodne z konwencja innych skryptow w `bin/`
|
||||
- Backfill na produkcyjnej (lokalnie, przez DB_HOST_REMOTE) bazie wykonany: 4 zamowienia naprawione
|
||||
|
||||
## Files Created/Modified
|
||||
|
||||
| File | Change | Purpose |
|
||||
|------|--------|---------|
|
||||
| `src/Modules/Settings/AllegroOrderImportService.php` | Modified | Gate trigger `order.imported` na `$wasCreated` |
|
||||
| `src/Modules/Settings/ShopproOrdersSyncService.php` | Modified | Gate trigger `order.imported` na `$wasCreated` (zachowane `!$wasPaymentTransition`) |
|
||||
| `bin/backfill_shipped_status_98.php` | Created | Jednorazowy backfill statusow z pelnym audit trail |
|
||||
|
||||
## Decisions Made
|
||||
|
||||
| Decision | Rationale | Impact |
|
||||
|----------|-----------|--------|
|
||||
| Gating po stronie producenta zamiast nowego eventu `order.first_imported` | Najmniejsza zmiana, bez wplywu na konfiguracje regul ani UI; semantyka eventu pozostaje zgodna z phase 84 | Reguly pobrania zamowienia automatycznie staja sie "first import only" |
|
||||
| Backfill wykonywany przez `OrdersRepository::updateOrderStatus`, nie bezposrednim UPDATE | Zachowanie historii statusow i activity logu | Pelny audit trail dla recznej naprawy danych |
|
||||
| Skrypt obsluguje `--use-remote` (DB_HOST_REMOTE) | Zgodnie z CLAUDE.md: DB_HOST_REMOTE dla operacji recznych agenta | Mozliwosc uruchomienia z lokalnego srodowiska bez zmiany runtime |
|
||||
|
||||
## Deviations from Plan
|
||||
|
||||
| Type | Count | Impact |
|
||||
|------|-------|--------|
|
||||
| Auto-fixed | 0 | - |
|
||||
| Scope additions | 0 | - |
|
||||
| Deferred | 0 | - |
|
||||
|
||||
Plan wykonany dokladnie wg specyfikacji.
|
||||
|
||||
## Issues Encountered
|
||||
|
||||
| Issue | Resolution |
|
||||
|-------|------------|
|
||||
| Lokalne MySQL niedostepne przy weryfikacji | Uzyto `--use-remote` (DB_HOST_REMOTE) zgodnie z konwencja CLAUDE.md |
|
||||
|
||||
## Verification Results
|
||||
|
||||
```
|
||||
$ php -l src/Modules/Settings/AllegroOrderImportService.php
|
||||
No syntax errors detected
|
||||
$ php -l src/Modules/Settings/ShopproOrdersSyncService.php
|
||||
No syntax errors detected
|
||||
$ php -l bin/backfill_shipped_status_98.php
|
||||
No syntax errors detected
|
||||
|
||||
$ php bin/backfill_shipped_status_98.php --dry-run --use-remote
|
||||
[scan] candidates: 4
|
||||
[dry-run] order #275 -> wyslane
|
||||
[dry-run] order #340 -> wyslane
|
||||
[dry-run] order #396 -> wyslane
|
||||
[dry-run] order #422 -> wyslane
|
||||
|
||||
$ php bin/backfill_shipped_status_98.php --use-remote
|
||||
[scan] candidates: 4
|
||||
[ok] order #275 -> wyslane
|
||||
[ok] order #340 -> wyslane
|
||||
[ok] order #396 -> wyslane
|
||||
[ok] order #422 -> wyslane
|
||||
Backfill 98: total=4 updated=4 skipped=0
|
||||
|
||||
$ php bin/backfill_shipped_status_98.php --dry-run --use-remote
|
||||
[scan] candidates: 0 # idempotency confirmed
|
||||
```
|
||||
|
||||
## Next Phase Readiness
|
||||
|
||||
**Ready:**
|
||||
- Reguly automatyzacji "Pobranie zamowienia" sa bezpieczne dla zamowien w obrocie
|
||||
- Mechanizm `OrdersRepository::updateOrderStatus` potwierdzony dla skryptow CLI
|
||||
|
||||
**Concerns:**
|
||||
- Manualny test przez uzytkownika (wymuszony re-import) nie jest jeszcze zarejestrowany w czasie tego Unify
|
||||
|
||||
**Blockers:** None
|
||||
|
||||
---
|
||||
*Phase: 98-order-imported-first-only, Plan: 01*
|
||||
*Completed: 2026-04-13*
|
||||
Reference in New Issue
Block a user