# ZAKON-QA — Real-User Testing Standard (mandatory all agents) — 2026-06-05

# ZAKON-QA: Real-User Testing Standard (MANDATORY for ALL agents)

**Authority:** CEO directive 2026-06-05 (Bilko demo bug campaign, MC #102887). Proven across 14+ bugs the CEO found in minutes that "54/54 green" API tests missed. This is now the required testing methodology for EVERY agent (Proveo/Angie Jones, Maria Santos, CodeCraft, FlowForge, any QA/build dispatch) on EVERY web product. Violating it = invalid QA.

## The 7 hard rules

### 1. Test as a REAL USER, not the API
API-with-token tests give false green — they assert "feature exists in code", not "a user can do this". Drive the REAL UI with REAL clicks (Playwright/browser). Use reliable auth (API-login + session-cookie injection, the `real-demo-smoke.spec.ts` pattern) — flaky UI-form login silently lands on `/login` and poisons every check. Log in as the actual product user.

### 2. FULL CRUD round-trips, not "page renders"
For EVERY entity (invoices, expenses, contacts, articles, …): **create → it MUST appear in the list → open its detail → edit → reuse it.** "No error on click" ≠ "works". Verify the OUTCOME: the created item actually appears, the edited value actually persists, the deleted item actually disappears. A test that clicks a button and only checks "no exception" is NOT a test.

### 3. Verify by LIVE OUTCOME — never by "build SUCCESS" or git-sha label
A green build with the correct commit label CAN ship a STALE bundle (dead-code edit, Docker/BuildKit layer cache). NEVER claim a fix is live because the build passed or the Cloud Run revision is labeled with the new sha. Confirm on the LIVE url with a screenshot you ACTUALLY LOOK AT (e.g. "PDV shows €30,50, not €NaN"). **Assert the page RENDERED a known element BEFORE asserting the fix** — a blank page / login redirect falsely passes "no NaN on page".

### 4. REJECT your own false positives — and NEVER fabricate
When something looks like a bug, verify the real affordance/data before reporting: wrong test account (e.g. logged in as a different org with empty data), wrong selector, guessed-wrong URL, checking the wrong field/page, already-sorted data. If your control case also "fails", your TEST is broken, not the app. A regression test that PASSES by SKIPPING its assertion ("could not create draft — skipping") is NOT a pass. Never invent a bug to look busy; reporting a false bug is a worse failure than finding none.

### 5. CONSISTENCY / completeness audit
Systematically check that each entity has: list + detail view + create + edit + sort + REACHABLE navigation (row/name click → detail). Inconsistency between entities (invoices have detail, contacts don't) is exactly where real bugs hide. Audit the route tree + the actual nav affordances (Link href / onClick), not just "does the list render".

### 6. Don't rationalize broken UX as "intentional stub"
If a real user hits an error toast / 403 / 501 / dead button, it IS a bug — regardless of backend intent. Either make the feature work or degrade it GRACEFULLY (clear "not available" notice, hidden/disabled button + upsell). A 501 that makes the client `throw` an error toast is a bug even if storage is "intentionally" unconfigured.

### 7. Capture EVERYTHING + mobile
On every page: capture console errors, all HTTP ≥400, NaN/undefined/raw-i18n-key leaks, horizontal overflow at 390px mobile. Screenshot each state and LOOK at it.

## Process when a bug is found
Reproduce (live, real clicks) → root-cause (edit the LIVE/compiled file, not dead code) → fix → CI green (required gates) → deploy → **re-verify the OUTCOME on the live surface with a screenshot** → only then "done". Per [[feedback_verify_by_live_outcome_not_green_build_2026-06-04]].

## Reusable harness
`apps/e2e/tests/regression-102887.spec.ts` + `_hunt*.mjs` cookie-auth pattern in the Bilko repo are the reference implementation. The `webapp-testing`, `deploy-verify`, `mobile-uat`, and `uat-browser` skills MUST follow these 7 rules.