Test results & evidence

UAT — the release under test automated live round 2026-08-27 green manual round pending

4H Phase 1 + Phase 2 merged to uat on 2026-08-25 (cut day — the 2026-08-27/28 live gouat round below is newer). The automated matrix below was run on the merge result and is green; the 121 manual cases were handed to QA on 2026-08-26. On 2026-08-27 an automated first pass was run live against gouat (block below) and its results are entered in the Result column; every other row still awaits manual QA. Nothing on this page claims a full manual UAT pass.

UAT database — cut-day snapshot, verified 2026-08-25

Credentials are identical on godev.* and gouat.* — so veni-tests/.env.uat is .env.dev plus the go-import block from .env.local with godev. swapped for gouat.. No new logins to chase; .gitignore already covers .env.*.

Payer setup — QA uses their own client card

Every auto-apply case below depends on the payer being AUTO. QA ticks 4H AUTO on their own client card in PAKAS and tests as their own account — no DB change, no borrowed payer, nothing to restore for anyone else. Set GO_IMPORT_USER_ID in .env.uat to your own client id.

If a case returns siunt_4rp = 0 where you expected 1, check the payer’s switch before raising anything: a MANUAL payer returning 0 is the feature working, and it is indistinguishable from the feature being broken. SELECT kl_id, kl_pav, kl_4rp_auto FROM tbl_klientai WHERE kl_id = <your client id>;

Client ids are consistent between dev and uat — verified on demovenipak_new 2026-08-26 — so whatever id works locally is the same id on uat. On uat there are exactly 4 AUTO clients out of 166 561 (3464 JYSK BALTIC, 89398 ROMITEKA, 157673 ELECTRONIC TRADE, 158280 PRO TRADE), which is the seeded cutover set. Leave that count at 4 when the round ends.

Cron: pack_4rp sweeps yesterday+today nightly. Every case below that says “run the cron” means a manual trigger — ask the developer rather than waiting overnight.

Automated results — run on the merge result 305 green

Each suite was run against origin/uat + the branch, not the branch alone.

Every failure accounted for

Direct 4H functional evidence: all five four-hands-notice.spec.ts cases (VDT-3407 — notice, badges, the 25.99/26.00 kg inclusive floor, PL-receiver removal) passed on the siunta merge result.

Automated — live uat round 2026-08-27 · 191 suite + 33 targeted green

Layout note 2026-08-28: the kl_view “4H AUTO” row moved mid-round from the left client card into the all-regions price table (PRs #634 uat / #635 dev, merged; live on gouat) — do not chase it in the left card; it shows only for kl_edit_plius viewers on clients that have a price list. Case 15.8 reworded accordingly; four-hands siunta specs unaffected.

Same veni-tests suites, this time run against the deployed uat apps on gouat (TEST_ENV=uat, .env.uat created 2026-08-27), plus three targeted 4H XML imports. Payer for API imports = the login’s uat client (1 · VENIPAK KAUNAS & MORE, MANUAL), so only MANUAL-side 4H behaviour is provable this way; AUTO-payer cases wait on a client-card ruling, cron cases on the P7 trigger.

Every live-round failure accounted for

Targeted 4H XML imports (payer MANUAL) + DB verification

Post-run DB check (read-only): 26 suite shipments + 3 probes created today for payer 1 — 0 spuriously flagged; tbl_log_siunt_4rp still 0 rows (creation-time initial values do not write provenance; the log records changes). Environment traps hit and fixed exactly as the list predicted: uat GO_IMPORT_USER_ID is the login’s user_id 17802 (dev 20579 / stress 17766 are both wrong — manifest TITLE prefix must equal it), and PAKAS_URL needs a trailing slash. Both fixes live only in .env.uat.

AUTO-payer tranche (owner-approved: client 1 ticked via the client-card UI, unticked after)

With the owner’s say-so, client 1 (the shared uat login’s payer) was set 4H AUTO through the pakas client-card UI (that is case 15.4 itself), the §1–§8 creation-channel matrix was driven through real XML imports and the siunta form, and the card was unticked again (case 15.5, proven by siunt 24478914 staying 0). Final state re-verified: exactly the canonical 4 AUTO clients remain. All flags checked in the DB, read-only. The pack_4rp cron did not run during the window and payer-1 shipments are MANUAL again, so the nightly sweep will not disturb the evidence.

Findings for the owner (not self-judged as defects)

Also observed, consistent with design: siunta-side flag changes (client edits) write no tbl_log_siunt_4rp rows — the provenance log’s writers are pakas-side (cron / siunt_edit / re-weigh); creation-time initial values do not log either. Log row count after the whole round: 0. Language note: the 4H notice rendered correct in EN in one session and LT in another (12.13 partial evidence).

Manual UAT test list — 121 cases handed to QA 2026-08-26

Derived by diffing origin/uat against each merge result, not from ticket intent. The nine tickets’ own validation steps are subsets of this. The Result column is deliberately empty — it is filled by the QA round, not by the developer.

0. Preconditions — verify before any test

1. Weight bands — LT (floor 26.0 inclusive, ceiling 75.0 inclusive)

2. Weight bands — LV and EE (floor 31.0, ceiling 90.0)

3. Volume is gone

4. Multi-pack shipments

5. Gates that must block auto-4H

6. Every channel applies the rule at creation, not overnight

7. Export / manifest reads the real consignee

8. An explicit client decision wins

9. Provenance log

10. Terminal re-weigh

11. Pack reassignment

12. Client-facing UI — siunta (confirm VERSION=50 and hard-reload first)

13. Pakas terminal reports — all three views (…cm.php, …cm_new.php, …_ee48.php)

14. Routing map and courier payload

15. Client card AUTO/MANUAL switch

16. Pricing — the one live money change (CONFIG_2X4RP_LOW_LIMIT 80 → 50)

17. Idempotency and regression

18. Deliberately out of scope — do not raise defects

Coverage matrix — nine tickets, all at Waiting for Q/A testing

Test data needed: one AUTO client (3464), one MANUAL client, LT/LV/EE/PL sender and receiver addresses on posti_service1='1' postcodes, a pallet-flagged pack, receivers named VENIPAK LOCKER and VENIPAK PICKUP, one pre-existing siunt_4rp=1 shipment with a 60 kg LT pack (for 16.1 and 17.2), and a Baltic-domestic price list with kain_4rp still at 50.00.

Historical — dev evidence (2026-08-05 · re-validated 2026-08-12)

Everything below predates the uat cut and was captured against godev.venipak.lt / venipak_dev. Kept as provenance for how the rules were proven; it is not UAT evidence.

0. 2026-08-12 re-validation — the full automated matrix, post-merge dev

Everything below ran against the merged dev branches (pakas 5572933 · siunta 0c0d90c9 · go-import 1ec026a) and the live venipak_dev database, after the dev-sync merges, the INT(8) DDL alignment and the pipeline auto-deploys.

UI evidence — captured by the authenticated Playwright run

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Not captured: the 12-month status report carrying the "Neužsakytos 4 rankos" sort — the page exceeds even a 5-minute render budget on both godev and the local instance — the demo DB holds 61k "in-terminal" packs that never advance status, and the report runs a correlated subquery per row (a pre-existing dataset/report characteristic, unrelated to 4H); its live render was verified in the 2026-08-06 pass.

Two false alarms run down during this pass (documented so nobody re-chases them): (1) go-import API "credential failures" — TEST_ENV=dev loads .env.dev, which carries no import creds; the suite's real environment is TEST_ENV=local. (2) a 4H price-estimate timeout — a local-lab-only vendor inconsistency (pre-rename helper Price.php vs a 0.9.2-synced FourHandsWeightBands); server vendors are composer-resolved and consistent, dev was never affected.

0b. The complete 4H gating matrix — every UI gate, captured (2026-08-12)

Every rule that decides whether a client can order 4H (or whether the system flags it), driven through the real siunta form on the merged dev code by an authenticated Playwright session. Badges: black no 4H = pack weight-qualifies but the service is not ordered; red 4H = ordered.

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Not UI-capturable on this account/dataset: the AUTO-client badge (badge pre-set to red "4H" for kl_4rp_auto payers — the test login is deliberately MANUAL; the cron/client-card halves of that flow are evidenced in sections 1–2 below) and the creation-time strip in go-import (API-level, covered by the XML matrix in section 4 and the 36/36 Baltic contract suite).

1. The nightly cron — the authoritative auto-4H writer

The real pack_4rp.php from the dev branch, executed against the dev database. Test shipments were created, their flags cleared, and the payer switched to AUTO — the cutover scenario Sales will actually perform.

Also learned: the cron only considers shipments whose siunt_priemimo_data falls in the last two days. Freshly created shipments carry 0000-00-00 until pickup is registered, so they are invisible to it — creation-time application in siunta/go-import and the cron cover different moments, and both are needed.

2. PAKAS client card — the Sales switch

The switch is gated behind the kl_edit_plius right (a commercial field, per Product). Enabled and disabled through the real form, reloading each time to prove persistence — not written directly to the database.

Click the image to view full size

Click the image to view full size

The switch was returned to MANUAL through the same form afterwards; dev is back to exactly 4 AUTO clients.

3. siunta UI — creation-time application

Same shipment, only the client switch differs

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

Click the image to view full size

4. XML / API import route — full scenario matrix

Each scenario posts real XML to /import/send_auth_basic.php on dev and the stored flag is read back from the database. Expand any row for the exact request and response.

Request & response, scenario by scenario

<description type="1">
<manifest title="20579260808300">
<shipment>

<consignee>
<name>4H XML auto-30</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546731</pack_no>
<weight>30</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546731</text></answer>

<description type="1">
<manifest title="20579260808301">
<shipment>

<consignee>
<name>4H XML auto-20</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546732</pack_no>
<weight>20</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546732</text></answer>

<description type="1">
<manifest title="20579260808302">
<shipment>

<consignee>
<name>4H XML auto-55</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546733</pack_no>
<weight>55</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546733</text></answer>

<description type="1">
<manifest title="20579260808303">
<shipment>

<consignee>
<name>4H XML auto-80</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546734</pack_no>
<weight>80</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546734</text></answer>

<description type="1">
<manifest title="20579260808304">
<shipment>

<consignee>
<name>4H XML explicit-1</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<attribute>
<four_hands>1</four_hands>
</attribute>
<pack>
<pack_no>V20579E2546735</pack_no>
<weight>10</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546735</text></answer>

<description type="1">
<manifest title="20579260808305">
<shipment>

<consignee>
<name>4H XML explicit-0</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<attribute>
<four_hands>0</four_hands>
</attribute>
<pack>
<pack_no>V20579E2546736</pack_no>
<weight>30</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546736</text></answer>

<description type="1">
<manifest title="20579260808306">
<shipment>

<consignee>
<name>4H XML bad-postcode</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>99999</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<attribute>
<four_hands>1</four_hands>
</attribute>
<pack>
<pack_no>V20579E2546737</pack_no>
<weight>30</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546737</text></answer>

<description type="1">
<manifest title="20579260808307">
<shipment>

<consignee>
<name>4H XML lv-35</name>

<country>LV</country>
<city>Riga</city>
<address>Gedimino pr. 1</address>
<post_code>01981</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546738</pack_no>
<weight>35</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?><answer type="error"><error shipment="0" pack="" code="24"><text>Consignee POST_CODE has to be in digits and exact legth -> 01981.</text></error>
</answer>

<description type="1">
<manifest title="20579260808308">
<shipment>

<consignee>
<name>4H XML lv-25</name>

<country>LV</country>
<city>Riga</city>
<address>Gedimino pr. 1</address>
<post_code>01981</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546739</pack_no>
<weight>25</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?><answer type="error"><error shipment="0" pack="" code="24"><text>Consignee POST_CODE has to be in digits and exact legth -> 01981.</text></error>
</answer>

<description type="1">
<manifest title="20579260808309">
<shipment>

<consignee>
<name>VENIPAK PICKUP Vilnius</name>

<country>LT</country>
<city>Vilnius</city>
<address>Gedimino pr. 1</address>
<post_code>01103</post_code>

<contact_tel>+37061234567</contact_tel>

</consignee>

<pack>
<pack_no>V20579E2546740</pack_no>
<weight>30</weight>




</pack>
</shipment>
</manifest>
</description>

<?xml version="1.0" encoding="UTF-8"?>
  <answer type="ok">
    <text>V20579E2546740</text></answer>

5. Defects found

A. An explicit four_hands=0 cannot be expressed through the API

A client on AUTO who explicitly sends <four_hands>0</four_hands> on an eligible parcel still gets the service applied and billed. Verified on dev: scenario explicit-0, 30 kg, returned siunt_4rp = 1.

Cause: the auto-apply guard is !empty($shipmentData['attribute']['four_hands']), and in PHP empty("0") is true. The validator also defaults an absent field to '0', so “not sent” and “explicitly declined” are indistinguishable by the time the guard runs. siunta handles the same situation correctly because it tests isset() on the posted field instead, which separates blank from an explicit zero.

Impact: billing-relevant, but limited to opt-in AUTO clients who actively send a zero.

FIXED — 2026-08-05, go-import PR #57 (VDT-3403, open to dev, 4 reviewers assigned). Presence is now captured at parse time (four_hands_declared, before the coercion) and the auto-apply is guarded on declaration, not value — siunta's isset() approach. Empty tags (<four_hands/>) and non-scalars count as absent, so integrations that always emit the tag keep auto-apply. Proven end-to-end through the real /import/send_auth_basic.php route: pre-fix, scenario explicit-0 stored siunt_4rp = 1 (shipment 32820245); on the fixed code the identical request stores 0 (shipment 32820247), while absent-tag and explicit-1 controls are unchanged. 70 phpunit tests green (regression pinned — reverting the guard fails the new tests, and one pin runs without DB credentials); veni-guard 42 guards / 0 blocking. Pickup/locker (error 136), pallets and the Baltic-domestic-only gates are untouched.

B. Out-of-home exclusion is not applied at import time

A 30 kg parcel addressed to a receiver named VENIPAK PICKUP Vilnius was flagged for 4H at import (siunt_4rp = 1). The cron excludes exactly this pattern by receiver name; the import path does not replicate that check.

Corrected analysis (2026-08-05, ticketed as VDT-3404): both paths turn out to be name heuristics — there is no structured pickup-point field in the XML import contract at all. The import detects OOH with a comma-anchored match (isPickup() = "venipak pickup,", the canonical generated form; likewise isLocker()), while the cron matches the substring anywhere (%VENIPAK PICKUP%). A canonical pickup order is excluded at import (and an explicit 4H on it errors with 136); only non-canonical free-text names like VENIPAK PICKUP Vilnius (no comma) slip through. Blocked on P11: Evelina confirmed the business rule (no OOH shipment may ever get 4H/2×4H/HF) but explicitly delegated the detection mechanism decision to PO / sys arch — no ruling exists yet, so no code is written. Options on the ticket: align import to the cron's looser match, tighten the cron to canonical forms, or introduce a structured field.

C. LV test scenarios rejected — downgraded on investigation

Both LV scenarios were rejected before any 4H logic ran, with error 24 — Consignee POST_CODE has to be in digits and exact legth. The validator requires LV postcodes to be 4 digits, and the table appeared to hold only 5-digit codes.

Downgraded (2026-08-05, ticketed as VDT-3405): tbl_post_info.posti_kodas is MEDIUMINT(5) UNSIGNED ZEROFILL — the "786 five-digit LV rows" are 4-digit values zero-padded for display only. Real LV consignee postcodes in tbl_siuntos are 4-digit at massive scale (e.g. 1067 ×344 832) and pass the validator, which matches both the published import contract ("LV – 4 digits") and the official LV-NNNN format. The test scenarios failed because they sent the padded form 01981; the harness will be corrected to 4-digit codes. LV 4H is therefore NOT blocked on the API route for canonical input. Residual question on the ticket: whether prod error-24 logs show real clients sending LV--prefixed or zero-padded forms — if so, the fix is input normalisation at the validator boundary, never a change to the 4-digit rule (six call sites depend on it).