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

<objective>
## 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
</objective>

<context>
## 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
</context>

<acceptance_criteria>

## AC-1: Event tylko po potwierdzeniu platnosci
```gherkin
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
```gherkin
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
```gherkin
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>

<tasks>

<task type="auto">
  <name>Task 1: Przygotuj backendowy builder payloadu purchase</name>
  <files>autoload/controls/class.Tickets.php</files>
  <action>
    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.
  </action>
  <verify>php -l autoload/controls/class.Tickets.php</verify>
  <done>AC-2 satisfied: payload ecommerce zawiera pelny i spojny zestaw danych</done>
</task>

<task type="auto">
  <name>Task 2: Przepnij emisje purchase na order_confirm po oplaceniu</name>
  <files>autoload/controls/class.Tickets.php, templates/tickets/order-confirm.php</files>
  <action>
    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.
  </action>
  <verify>php -l autoload/controls/class.Tickets.php && php -l templates/tickets/order-confirm.php</verify>
  <done>AC-1 satisfied: purchase emituje sie po potwierdzonej platnosci na stronie potwierdzenia</done>
</task>

<task type="auto">
  <name>Task 3: Usun przedwczesny purchase z widoku przelewy24 i sprawdz brak regresji</name>
  <files>templates/tickets/przelewy24.php</files>
  <action>
    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.
  </action>
  <verify>php -l templates/tickets/przelewy24.php</verify>
  <done>AC-3 satisfied: purchase nie odpala sie przed potwierdzeniem platnosci</done>
</task>

</tasks>

<boundaries>

## 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

</boundaries>

<verification>
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
</verification>

<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>

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