Zamówienie testowe
ważność średniamierzonysposób shop_test_order
Pełna ścieżka zakupu aż do bramki płatności w trybie testowym.
Wdrożony 02.10: jedyny test, który tworzy prawdziwe zamówienie — tylko w sklepach, które się zgodziły (CREATO_PING config/sklepy.toml), co 7 dni; pozostałe sklepy — nie dotyczy.
WIKI
wiedza ze źródeł zewnętrznychArtykuł o parametrze „Zamówienie testowe” jest w przygotowaniu. Powstaje po kolei dla wszystkich 87 parametrów, każde twierdzenie z przypisem do źródła.
STATS
wyniki z systemu · tylko liczby zbiorczeTen parametr nie zapisuje odczytu per strona — przebieg zostawia tylko ustalenia, więc liczby sprawdzonych stron i wyników „ok” system nie ma. Pojawią się po wdrożeniu zapisu przebiegów per strona per parametr.
Ten parametr nie otworzył jeszcze żadnego ustalenia w bazie LAB247. Pusto nie znaczy „czysto” — znaczy, że nic nie przekroczyło reguły.
Harmonogram nie zapisał jeszcze przebiegu ze sposobem „shop_test_order”. Zapis przebiegów z n8n działa od 2026-09-14.
CARD
karta z kodu CREATO_PING, odczyt 02.10.2026Jak ten parametr trafia do ClickUpa: wynik sondy to linia w subtasku 2. Pomiar, a usterka, którą otwiera — linia w subtasku 1. Podsumowanie (z identyfikatorem CWE i kategorią OWASP), skąd liczy się wskaźnik zagrożenia i status strony. Projekcja z bazy skanera odświeża oba subtaski co godzinę. Do 22.09 każde ustalenie dostawało własny subtask i status ze starego słownika (PODATNA, WARNING…) — te słowa zostały jeszcze w części opisów pomiaru niżej jako język wewnętrzny sond.
| Obszar i ważność | E-commerce · średnia (E10) |
|---|---|
| Workflow i częstotliwość | skaner_badanie działa na LAB247Skaner 2.0, badanie kohorty: premium co 12 h, reszta co 24–48 h · Od 2026-10-01 zestawy kohort (premium_pelny, tani_ciezki, tani_lekki) mają tury higiena, serwer, sklep, kasa i strony (wyciek ścieżek B41, CMS po EOL B44, kluczowe podstrony S08, odnośniki kontaktowe D10); nocny pomiar wydajności (trend, waga, od 01.10 też metryki pasma W01–W04 i W07) tylko premium — u reszty prośba o pomiar zagłodziłaby nocny plan. Sklep: strona bez WooCommerce = „nie dotyczy”. |
| Sonda i helper | sposób shop_test_order · CREATO_PING/helpers/sklep_check.py |
| Testy |
|
| Typ wyniku | ok z numerem zamówienia, statusem płatności i adresem przekierowania; 0 albo 1 ustalenie shop_test_order_failed; nie_dalo_sie_sprawdzic (`brak_zgody` = nie dotyczy, `zrodlo_nie_odpowiada`) |
| Jednostka | brak — wynik jakościowy (czy zamówienie doszło do bramki płatności) |
| Próg i reguła | Reguła: zamówienie nie powstało albo payment_result.payment_status nie jest success ani pending = shop_test_order_failed (wysoka, ewidentna, alarm). |
| Gdzie leżą pokrętła | CREATO_PING/config/sklepy.toml → [zamowienie_testowe] sklepy, co_dni, klientCREATO_PING/helpers/sklep_check.py → zamowienie_testowe, _zloz_zamowienieCREATO_PING/config/incident_policy.toml → [finding] shop_test_order_failed |
| Retencja odczytów | Surowy pomiar jako NIEZMIENNY wiersz tabeli `odczyty` w bazie skanera (wejście, wyjście, dowody, sha karty sondy i helpera, commit kodu) — trigger odrzuca każdą zmianę. Okno retencji z kohorty: 90 dni premium, 30 dni reszta; poza oknem zostają odczyty z werdyktem problemu, akcją albo etykietą, bo replay reguł ich potrzebuje (`skaner/retencja.py`). Poza odczytem zostaje werdykt w tabeli `werdykty`. Panel klienta LAB247 czyta najnowszy odczyt na żądanie (`GET /latest-readings`). |
| Znane rozbieżności |
|
| Karta przepisana z | CREATO_PING/helpers/sklep_check.py · CREATO_PING/config/sklepy.toml · CREATO_PING/config/incident_policy.toml · odczyt 02.10.2026 |
shop_test_order_failed: bramka polityki otwarta (gate=true) → sprawa w skanerze → Zamówienie testowe nie dochodzi do płatności — sklep nie sprzedaje — waga 4 → ocena 7–8 (pomarańczowy), status strony „wysoki”, dopóki sprawa jest otwarta. Ten test chodzi wyłącznie w badaniu kohort, a sprawy zakłada worker tylko dla zleceń z harmonogramu (`skaner/worker.py` → ZRODLA_PRODUKCJI): w badaniu droga kończy się na werdykcie i usterce przebiegu, która podnosi wskaźnik tego badania.
| Kod | Finding | Severity | Pewność | Skutek | Finding / alarm | Waga → ocena | Co zrobić |
|---|---|---|---|---|---|---|---|
| E10.01 | Zamówienie testowe nie dochodzi do płatności — sklep nie sprzedajeshop_test_order_failed | Wysoka | — | usterka niekrytyczna | tak / — | waga 4 → ocena 7–8 (pomarańczowy) | — |
| Kod i klucz | E10.01 · shop_test_order_failed · w tabeli typów |
|---|---|
| Co znaczy | opis do opracowania |
| Kiedy powstaje | Test shop_test_order (badanie kohort, tura sklep, od 02.10) tylko dla sklepów z config/sklepy.toml [zamowienie_testowe] (zgoda klienta), najwyżej co 7 dni: Cart-Token, add-item (produkt z konfiguracji), POST /wc/store/v1/checkout z danymi testowymi i metodą płatności. Finding, gdy zamówienie nie powstało albo payment_result.payment_status nie jest success ani pending. Między zamówieniami test oddaje ostatni wynik z pamięci. |
| Severity · pewność | Wysoka |
| Skutek dla strony | usterka niekrytyczna · zakłada Finding |
| Waga → ocena | waga 4 → ocena 7–8 (pomarańczowy) |
| Klasyfikacja | OCSF 1.9.0: poza klasami Findingu |
| Rekord OCSF | finding_info.analytic.uid = "E10.01" · analytic.name = "shop_test_order_failed" · finding_info.types = ["E10 Zamówienie testowe"] |
| Co zrobić | — |
| Wersje typu |
|
LOOP
bez pętliTrafności jeszcze nie liczymy: zamknięcie subtaska nie niesie dziś werdyktu (prawdziwy / fałszywy / nie dało się sprawdzić). Cztery liczby pojawią się, gdy każde zamknięcie dostanie werdykt — to warunek startu pętli 1.
Ten parametr nie przeszedł jeszcze żadnej pętli. Kolejność po pierwszych pięciu grupach ustali miara trafności.