bilety.brzezovka.pl/.paul/phases/01-purchase-data-layer/01-01-PLAN.md

phase, plan, type, wave, depends_on, files_modified, autonomous, delegation

phase	plan	type	wave	depends_on	files_modified	autonomous	delegation
01-purchase-data-layer	01	execute	1		autoload/controls/class.Tickets.php templates/tickets/order-confirm.php templates/tickets/przelewy24.php	true	auto

## Goal Wdroc event `purchase` do `dataLayer` dopiero po skutecznie oplaconym zamowieniu oraz przekazac maksymalnie kompletne dane transakcji i pozycji biletowych.

Purpose

Klient potrzebuje wiarygodnego trackingu ecommerce, w ktorym event zakupu nie odpala sie przed potwierdzeniem platnosci i zawiera dane gotowe do analityki GA4/GTM.

Output

• Logika backend przygotowujaca payload purchase z zamowienia
• Przekazanie payloadu do widoku potwierdzenia zamowienia
• Emisja dataLayer.push tylko dla zakonczonej platnosci
• Usuniecie przedwczesnego eventu z widoku przekierowania do Przelewy24

## Project Context @.paul/PROJECT.md @.paul/ROADMAP.md @.paul/STATE.md

Source Files

@autoload/controls/class.Tickets.php @autoload/factory/class.Tickets.php @templates/tickets/order-confirm.php @templates/tickets/przelewy24.php

<acceptance_criteria>

AC-1: Event tylko po potwierdzeniu platnosci

Given uzytkownik finalizuje zakup i wraca na strone potwierdzenia
When zamowienie ma payment_status = 1
Then event "purchase" jest pushowany do dataLayer na stronie order_confirm

AC-2: Pelny payload ecommerce

Given event "purchase" jest emitowany
When skrypt buduje dane ecommerce
Then payload zawiera transaction_id, value, currency, payment_date oraz items z product_id, name, quantity, price i date_visit

AC-3: Brak falszywych eventow

Given uzytkownik jest przekierowany do bramki platnosci
When strona przelewy24 jest renderowana przed zakonczeniem platnosci
Then event "purchase" nie jest emitowany na tym etapie

</acceptance_criteria>

Task 1: Przygotuj backendowy builder payloadu purchase autoload/controls/class.Tickets.php Dodaj wydzielona metode budujaca tablice danych dla data layer na podstawie danych zamowienia: - Ustal stale pola ecommerce (transaction_id, value, currency, shipping) - Dodaj pola transakcyjne dostepne w systemie (payment_date, order_id, vat, city, zip_code) - Zmapuj pozycje `order_tickets` do `items` (item_id/product_id, item_name/name, quantity, price, date_visit) - Zapewnij poprawne typy liczbowe (float/int) i bezpieczne wartosci domyslne Unikaj: mieszania logiki mapowania danych bezposrednio w widoku. php -l autoload/controls/class.Tickets.php AC-2 satisfied: payload ecommerce zawiera pelny i spojny zestaw danych Task 2: Przepnij emisje purchase na order_confirm po oplaceniu autoload/controls/class.Tickets.php, templates/tickets/order-confirm.php W kontrolerze `order_confirm` przekaz do widoku gotowy payload purchase tylko gdy zamowienie jest skutecznie oplacone. W widoku `order-confirm.php` dodaj warunkowy skrypt: - reset ecommerce (`dataLayer.push({ ecommerce: null })`) - push eventu `purchase` z payloadem z backendu - serializacja przez `json_encode(..., JSON_HEX_TAG|JSON_HEX_AMP|JSON_HEX_APOS|JSON_HEX_QUOT)` dla bezpieczenstwa XSS - defensywna obsluga przypadku braku `window.dataLayer` Unikaj: recznego skladania JSON przez konkatenacje stringow. php -l autoload/controls/class.Tickets.php && php -l templates/tickets/order-confirm.php AC-1 satisfied: purchase emituje sie po potwierdzonej platnosci na stronie potwierdzenia Task 3: Usun przedwczesny purchase z widoku przelewy24 i sprawdz brak regresji templates/tickets/przelewy24.php Usun blok `dataLayer.push` z eventem `purchase` z `przelewy24.php`, pozostawiajac tylko auto-submit formularza do bramki platnosci. Zweryfikuj recznie scenariusz: - Wejscie na strone Przelewy24 nie emituje `purchase` - Powrot na `order_confirm` po statusie payment_status=1 emituje `purchase` z danymi Unikaj: modyfikacji logiki podpisu i parametrow requestu do Przelewy24. php -l templates/tickets/przelewy24.php AC-3 satisfied: purchase nie odpala sie przed potwierdzeniem platnosci

DO NOT CHANGE

• Logika weryfikacji podpisu i statusu w przelewy24_response()
• Integracja fakturowania w class.Tickets.php (sekcja fakturowo API)
• Inne moduly niezwiązane z checkoutem biletowym

SCOPE LIMITS

• Bez zmian schematu bazy danych
• Bez przebudowy calego widoku order-confirm.php poza sekcja data layer
• Bez zmian flow koszyka i formularza zamowienia poza danymi eventu purchase

Before declaring plan complete: - [ ] `php -l autoload/controls/class.Tickets.php` - [ ] `php -l templates/tickets/order-confirm.php` - [ ] `php -l templates/tickets/przelewy24.php` - [ ] Reczny test checkout: brak purchase na `przelewy24`, obecny purchase na `order_confirm` po platnosci - [ ] Wszystkie acceptance criteria spelnione

<success_criteria>

• Wszystkie taski wykonane bez regresji flow zakupowego
• Event purchase wysylany tylko po skutecznej platnosci
• Payload zawiera komplet dostepnych danych transakcyjnych i pozycje biletowe
• Kod pozostaje zgodny z zasadami czytelnosci i bezpieczenstwa widokow </success_criteria>

After completion, create `.paul/phases/01-purchase-data-layer/01-01-SUMMARY.md`