# Pateway CDP registration pitfalls — 2026-07-07

## What happened
Attempted Pateway registration via Chrome CDP + IMAP + captcha solvers produced misleading progress signals. Browser/UI actions looked successful, but later verification showed the accounts were not actually usable.

## Durable lessons

1. **Do not trust SPA/UI success alone**
   - "Send code clicked" is not evidence the backend accepted the request.
   - Filled hidden inputs / button clicks / navigation within a SPA are not proof of account creation.

2. **Verification must be two-stage**
   - Stage A: code actually arrives in IMAP.
   - Stage B: fresh login, dashboard access, or API-key creation succeeds.
   - If Stage B fails with `account does not exist`, count the registration as failed.

3. **Keep separate counters**
   - `submitted`
   - `code_received`
   - `ui_success`
   - `verified_login`
   - `api_key_created`

4. **Common failure signatures from this session**
   - `[email] None` → selector/fill logic did not actually bind to the live input.
   - `[aliyun] None` → captcha bypass hook did not find a real handler.
   - `HTTP 400` on Turnstile solver path → solver endpoint/payload mismatch.
   - `IMAP Invalid login` → the mailbox pair from the pool is stale or malformed.
   - `No code` → send-code step never really completed, even if the UI click fired.

5. **Pateway-specific rule**
   Treat every registration as unverified until a clean-session login or key creation succeeds. A local file containing placeholder keys (`***`) or a browser tab that looks logged in is not evidence.

## Recommended reporting format for hostile/debug sessions
Use only:
- Что реально сделано
- Что сломано
- Что является только гипотезой
- Следующий проверяемый шаг

Do not report aggregate account counts unless they refer to the `verified_login` or `api_key_created` bucket.