Document Luban UK and Chile phone tests

2026-05-11 22:33:59 +08:00
parent fe492e0f2e
commit c29567eda6
4 changed files with 236 additions and 2 deletions
@@ -0,0 +1,85 @@
+# Luban Chile OpenAI phone test: immediate reject (2026-05-11)
+
+## Context
+
+Account under test:
+
+```text
+2925 account: chickliu2031@2925.com
+OpenAI alias: chickliu2031som6d8@2925.com
+Email verification: passed
+OpenAI page before test: https://auth.openai.com/add-phone
+SMS provider: Luban SMS
+Country/service: Chile / 智利, OpenAI
+Luban service_id: 508058
+Cost observed: 0.05
+```
+
+Secrets, full phone numbers, SMS/email codes, API keys, and proxy strings are omitted.
+
+## Command
+
+```bash
+PYTHONUNBUFFERED=1 ATTEMPTS=1 PHONE_POLL_SECONDS=190 \
+  /Users/chick/homebrew/opt/python@3.11/bin/python3.11 \
+  /tmp/luban_chile_2031_attempt.py \
+  | tee /tmp/luban_chile_2031_attempt.log
+```
+
+BOSS policy followed: hold Luban order for at least 3 minutes before release.
+
+## Result
+
+```json
+{
+  "attempts": 1,
+  "bought": 1,
+  "rejected_by_openai": 1,
+  "sms_timeout": 0,
+  "sms_received": 0,
+  "success": false,
+  "submit_no_sms_page": 0
+}
+```
+
+Request id tested:
+
+```text
+34131960
+```
+
+Flow:
+
+```text
+Country gate: CL / 智利 OK
+Luban number bought OK
+OpenAI phone submit stayed on add-phone and was classified as immediate reject
+No SMS polling was needed because OpenAI did not enter phone-verification
+Order was held for the 3-minute minimum window and released successfully
+```
+
+Evidence snippets:
+
+```json
+{"phase":"country_gate","ok":true,"countryValue":"CL","countryText":"智利"}
+{"phase":"activation_bought","request_id":34131960,"country":"chile","phone_redacted":"[REDACTED]8874"}
+{"phase":"phone_submitted","href":"https://auth.openai.com/add-phone","rejected":true,"sms_page":false}
+{"phase":"activation_reject","request_id":34131960,"http":200,"ok":true,"msg":"success"}
+```
+
+## Operational conclusion
+
+For this account/session and Luban service `508058` (Chile OpenAI):
+
+```text
+The first Chile number was directly rejected by OpenAI, so Luban Chile is worse than Luban UK in this sample.
+```
+
+Comparison:
+
+```text
+Luban UK service_id=537935: attempts 1-9 entered phone-verification but 0/10 SMS delivered after ~190s each.
+Luban Chile service_id=508058: first attempt was immediately rejected by OpenAI.
+```
+
+Recommended next step: do not continue only Chile unless BOSS explicitly wants more samples; prefer a different Luban country/service_id or return to 5sim/free-country strategy.
@@ -0,0 +1,117 @@
+# Luban UK OpenAI phone test: 10 attempts, no SMS (2026-05-11)
+
+## Context
+
+Account under test:
+
+```text
+2925 account: chickliu2031@2925.com
+OpenAI alias: chickliu2031som6d8@2925.com
+Email verification: passed
+OpenAI page before test: https://auth.openai.com/add-phone
+SMS provider: Luban SMS
+Country/service: United Kingdom/England, OpenAI
+Luban service_id: 537935
+Cost observed: 0.05
+```
+
+Secrets, full phone numbers, email/SMS codes, API keys, and proxy strings are omitted.
+
+## Runner policy
+
+Command:
+
+```bash
+PYTHONUNBUFFERED=1 ATTEMPTS=10 PHONE_POLL_SECONDS=190 \
+  /Users/chick/homebrew/opt/python@3.11/bin/python3.11 \
+  /tmp/luban_uk_2031_10_attempts.py \
+  | tee /tmp/luban_uk_2031_10_attempts.log
+```
+
+Important policy from BOSS:
+
+```text
+Wait at least 3 minutes per Luban order before releasing it.
+```
+
+The runner waited about 190s per order and only called `setStatus?...&status=reject` after the 3-minute window.
+
+## Result summary
+
+```json
+{
+  "attempts": 10,
+  "bought": 10,
+  "rejected_by_openai": 0,
+  "sms_timeout": 10,
+  "sms_received": 0,
+  "success": false
+}
+```
+
+Request ids tested:
+
+```text
+34130967
+34131038
+34131130
+34131213
+34131300
+34131384
+34131459
+34131551
+34131640
+34131710
+```
+
+All 10 orders were released successfully via Luban `setStatus`:
+
+```text
+activation_reject ok=true msg=success
+```
+
+## Details
+
+Attempts 1-9:
+
+```text
+OpenAI country gate: GB / 英国 OK
+Luban number bought OK
+OpenAI phone submit entered https://auth.openai.com/phone-verification
+OpenAI did not immediately reject the number
+Luban getSms kept returning msg=wait for ~190s
+No SMS code arrived
+Order released successfully
+```
+
+Attempt 10 nuance:
+
+```text
+Country gate OK and Luban number bought OK.
+After submit, page remained https://auth.openai.com/add-phone instead of phone-verification.
+The runner still polled Luban for ~190s and got only msg=wait, then released the order successfully.
+Treat this as submit/page-state failure + no SMS, not as confirmed OpenAI SMS-page entry.
+```
+
+## Operational conclusion
+
+For this specific account/session and Luban service `537935` (United Kingdom/England OpenAI):
+
+```text
+Luban UK numbers were accepted by OpenAI for attempts 1-9, but no SMS arrived after >3 minutes each.
+Continuing the same Luban UK service is low-yield unless BOSS wants more spend/testing.
+```
+
+Recommended next options:
+
+1. Try a different Luban country/provider/service_id if available.
+2. Return to 5sim/free-country strategy, since previous successful OpenAI phone verification happened with a non-UK 5sim activation.
+3. If staying on Luban, query multiple OpenAI/ChatGPT service entries and avoid repeatedly using only `service_id=537935`.
+
+## Script improvement note
+
+The runner should be patched before reuse:
+
+- Only poll SMS if phone submit lands on `phone-verification` / SMS verification page.
+- If submit remains on `add-phone` without explicit reject, classify as `submit_no_sms_page`, release after the required minimum hold time, and continue.
+- Keep the 3-minute minimum release window for Luban provider orders.
@@ -0,0 +1,28 @@
+# 2925 + Luban continuation notes (2026-05-11)
+
+## 2925 Webmail false-negative lesson
+
+BOSS manually checked 2925 accounts and found OpenAI verification mail that automation had reported missing. Treat automation `candidateCount=0` / `no code` as suspect until checked against visible/manual UI.
+
+Correct 2925 scraping rules:
+
+1. Do not navigate by `#/mailList?type=收件箱` and trust the resulting list; it can show an empty/stale view.
+2. Click the left `收件箱` navigation item and then click the visible toolbar `刷新`.
+3. Read rows from `table.maillist-table tr`, not generic `div/li` selectors.
+4. Inspect hidden tooltip/title/textContent; current alias may only appear in OpenAI bounce sender text such as `...-<aliasLocal>=2925.com@tm1.openai.com`.
+5. Open the newest matching row and extract the 6-digit code from the body near `输入此临时验证码以继续：`.
+6. If OpenAI says `代码不正确`, request a new email and select the newest row by timestamp; do not reuse older code candidates.
+
+The 2031 run (`chickliu2031...`) passed OpenAI email verification after this correction and reached `https://auth.openai.com/add-phone`.
+
+## Luban UK first phone attempt
+
+For the 2031 add-phone page, Luban resolved OpenAI service:
+
+```text
+country: United Kingdom/England
+service_id: 537935
+cost: 0.05
+```
+
+OpenAI country gate passed with `countryValue=GB`, visible `英国`. The first Luban UK number was bought and submitted successfully; OpenAI moved to `phone-verification` and did not immediately reject the number. SMS polling returned `msg=wait` for 90s. Immediate reject/cancel returned a supplier timing message requiring a later stop (`停用失败,该供应商需要在两分钟后停止`). Future runners should schedule delayed cancellation/re-check rather than assuming the activation is released.