it ok
This commit is contained in:
@@ -0,0 +1,87 @@
|
||||
# 163 Mail Body Fallback Implementation Plan
|
||||
|
||||
> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.
|
||||
|
||||
**Goal:** Let the 163 mailbox provider read verification codes from opened email bodies when the inbox list does not show the code inline.
|
||||
|
||||
**Architecture:** Keep the existing list-first polling flow in `content/mail-163.js`, then add a provider-local fallback that opens candidate messages, reads body text, and returns to the inbox before continuing. Do not add `targetEmail` filtering in this change.
|
||||
|
||||
**Tech Stack:** Manifest V3 Chrome extension, plain JavaScript content scripts, Node built-in test runner
|
||||
|
||||
---
|
||||
|
||||
### Task 1: Lock the regression with a failing test
|
||||
|
||||
**Files:**
|
||||
- Create: `D:\github\codex-oauth-automation-extension-Pro2.0\tests\mail-163-content.test.js`
|
||||
- Test: `D:\github\codex-oauth-automation-extension-Pro2.0\tests\mail-163-content.test.js`
|
||||
|
||||
- [ ] **Step 1: Write the failing test**
|
||||
|
||||
```js
|
||||
test('handlePollEmail opens a matching 163 message and reads the body when the list row has no inline code', async () => {
|
||||
const bundle = extractFunction('handlePollEmail');
|
||||
const api = new Function(`...`)();
|
||||
const result = await api.handlePollEmail(8, {
|
||||
senderFilters: ['openai'],
|
||||
subjectFilters: ['chatgpt'],
|
||||
maxAttempts: 1,
|
||||
intervalMs: 1,
|
||||
});
|
||||
assert.equal(result.code, '480382');
|
||||
});
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Run test to verify it fails**
|
||||
|
||||
Run: `node --test tests/mail-163-content.test.js`
|
||||
Expected: FAIL because `handlePollEmail` never opens the message body.
|
||||
|
||||
### Task 2: Add the 163 opened-mail fallback
|
||||
|
||||
**Files:**
|
||||
- Modify: `D:\github\codex-oauth-automation-extension-Pro2.0\content\mail-163.js`
|
||||
- Test: `D:\github\codex-oauth-automation-extension-Pro2.0\tests\mail-163-content.test.js`
|
||||
|
||||
- [ ] **Step 1: Add minimal helpers**
|
||||
|
||||
```js
|
||||
function findInboxLink() { /* find the 163 inbox entry */ }
|
||||
async function returnToInbox() { /* restore inbox list view */ }
|
||||
function readOpenedMailText() { /* read visible detail text and iframe text */ }
|
||||
async function openMailAndGetMessageText(item) { /* open, read, return */ }
|
||||
```
|
||||
|
||||
- [ ] **Step 2: Update `handlePollEmail`**
|
||||
|
||||
```js
|
||||
if (!code) {
|
||||
const openedText = await openMailAndGetMessageText(item);
|
||||
const bodyCode = extractVerificationCode(openedText);
|
||||
if (bodyCode) {
|
||||
return { ok: true, code: bodyCode, emailTimestamp: Date.now(), mailId: id };
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- [ ] **Step 3: Run the targeted test**
|
||||
|
||||
Run: `node --test tests/mail-163-content.test.js`
|
||||
Expected: PASS
|
||||
|
||||
### Task 3: Verify no regressions in adjacent polling logic
|
||||
|
||||
**Files:**
|
||||
- Test: `D:\github\codex-oauth-automation-extension-Pro2.0\tests\mail-163-content.test.js`
|
||||
- Test: `D:\github\codex-oauth-automation-extension-Pro2.0\tests\verification-flow-polling.test.js`
|
||||
|
||||
- [ ] **Step 1: Run the local regression slice**
|
||||
|
||||
Run: `node --test tests/mail-163-content.test.js tests/verification-flow-polling.test.js`
|
||||
Expected: PASS
|
||||
|
||||
- [ ] **Step 2: Update docs only if behavior scope changed**
|
||||
|
||||
```md
|
||||
No root docs update is required if the change stays inside existing 163 polling behavior and does not alter the documented top-level flow.
|
||||
```
|
||||
@@ -0,0 +1,57 @@
|
||||
# 163 Mail Body Fallback Design
|
||||
|
||||
## Goal
|
||||
|
||||
Make the `163` and `163-vip` mailbox polling flow able to read verification codes from the opened email body when the inbox list does not expose the six-digit code.
|
||||
|
||||
## Existing Problem
|
||||
|
||||
- `content/mail-163.js` currently matches candidate emails from the inbox list only.
|
||||
- It extracts the code from the row subject text and the row `aria-label`.
|
||||
- If the subject line only says something like "你的临时 ChatGPT 登录代码" and the row metadata does not include the code, polling fails even when the opened email body clearly shows the code.
|
||||
|
||||
## Approved Scope
|
||||
|
||||
- Add a body-reading fallback for `163` and `163-vip`.
|
||||
- Keep the current list-based fast path.
|
||||
- Do not add `targetEmail` filtering in this change.
|
||||
- Keep cleanup as best effort only.
|
||||
|
||||
## Design Summary
|
||||
|
||||
`content/mail-163.js` will move from a single-stage detector to a two-stage detector:
|
||||
|
||||
1. Scan inbox rows exactly as today.
|
||||
2. If a matching row does not contain a code in its subject or `aria-label`, open that email.
|
||||
3. Read visible detail text from the opened mail view, including same-origin iframe content when available.
|
||||
4. Extract the six-digit code from the opened content.
|
||||
5. Return to the inbox before continuing.
|
||||
|
||||
## Architecture Notes
|
||||
|
||||
### Row-first detection stays in place
|
||||
|
||||
The existing sender, subject, time-window, and seen-code checks stay as the first filter because they are cheap and already fit the current provider flow.
|
||||
|
||||
### Opened-mail fallback is local to `content/mail-163.js`
|
||||
|
||||
The background verification flow does not need to change. The mailbox content script already owns the provider-specific polling behavior, so the new logic should stay inside the 163 content script.
|
||||
|
||||
### No target-email filtering in this revision
|
||||
|
||||
Step 8 already passes `targetEmail` through the background payload, but this revision intentionally leaves that field unused for 163. The goal is to fix the missing body fallback without widening the scope of behavior changes.
|
||||
|
||||
## Error Handling
|
||||
|
||||
- If opening a candidate mail does not reveal readable detail text, polling should continue to the next candidate or next round.
|
||||
- If the helper opens a mail successfully, it should try to return to the inbox before continuing.
|
||||
- Cleanup and deletion remain best effort and must not block successful code extraction.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
Add a focused regression test for `content/mail-163.js` that proves:
|
||||
|
||||
- a matching 163 inbox row without an inline code does not succeed from list text alone
|
||||
- the script opens the row
|
||||
- the script reads the opened body text
|
||||
- the code extracted from the body is returned to the background flow
|
||||
Reference in New Issue
Block a user