Remove internal planning docs from PR follow-up
This commit is contained in:
QLHazyCoder
@@ -1,136 +0,0 @@
|
||||
# Operation Delay Drift Adjudication Ledger
|
||||
|
||||
Immutable spec path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/docs/superpowers/specs/2026-05-07-operation-delay-design.md`
|
||||
|
||||
Immutable plan path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/docs/superpowers/plans/2026-05-07-operation-delay-plan.md`
|
||||
|
||||
Controller-only mutation rule: only the P9/controller may create, append, supersede, close, summarize, or otherwise mutate this ledger. Subagents may read it, cite `DRIFT_ID`, report evidence, and request supersession, but may not edit it directly.
|
||||
|
||||
## Active Adjudications Summary
|
||||
|
||||
| DRIFT_ID | STATUS | SCOPE | P9_FINAL_ADJUDICATION | EFFECTIVE_EXECUTION_CONTRACT |
|
||||
|---|---|---|---|---|
|
||||
| DRIFT-2026-05-08-T2-001 | ACTIVE | Task 2 sidepanel switch copy | PLAN_DRIFT_CONTINUE_SAFE | Use sidepanel switch copy that communicates input, selection, click, submit, continue, authorization, and 2 seconds; do not regress to the narrower frozen-plan snippet. |
|
||||
| DRIFT-2026-05-08-T3-001 | ACTIVE | Task 3 2925 provider metadata test scope | PLAN_DRIFT_CONTINUE_SAFE | Treat `tests/background-icloud-mail-provider.test.js` as in scope for Task 3 checkpoint because it asserts the 2925 provider metadata changed by the required operation-delay injection. |
|
||||
| DRIFT-2026-05-08-T4-001 | ACTIVE | Task 4 Step 3 direct-complete test scope | PLAN_DRIFT_CONTINUE_SAFE | Treat `tests/step3-direct-complete.test.js` as in scope for Task 4 checkpoint because it verifies Step 3 completion-before-navigation plus deferred password-submit operation-delay behavior. |
|
||||
| DRIFT-2026-05-08-T7-001 | ACTIVE | Task 7 mail-2925 full-suite harness scope | PLAN_DRIFT_CONTINUE_SAFE | Treat `tests/mail-2925-content.test.js` as in scope for Task 7 only for a narrow stale-harness fix providing `performOperationWithDelay` to the existing `ensureAgreementChecked` harness. |
|
||||
|
||||
## DRIFT-2026-05-08-T2-001
|
||||
|
||||
DRIFT_ID: DRIFT-2026-05-08-T2-001
|
||||
|
||||
STATUS: ACTIVE
|
||||
|
||||
SUPERSEDES_DRIFT_ID: NONE
|
||||
|
||||
SUPERSEDED_BY_DRIFT_ID: NONE
|
||||
|
||||
SCOPE: Task 2 sidepanel switch copy
|
||||
|
||||
TRIGGER: Task 2 spec reviewer reported that the frozen Task 2 Step 3 HTML copy snippet omitted required operation categories while the implementation used spec-complete copy.
|
||||
|
||||
FROZEN_PLAN_STEP: `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:330-348`, especially line 337 title copy and line 344 caption copy.
|
||||
|
||||
GOVERNING_SPEC_REQUIREMENT: `docs/superpowers/specs/2026-05-07-operation-delay-design.md:36-38` requires the sidepanel boolean operation-delay switch label to communicate waits after page input, selection, click, submit, continue, and authorization operations.
|
||||
|
||||
REPO_OR_WORKTREE_EVIDENCE: `sidepanel/sidepanel.html:578-589` implements the switch; line 582 title copy and line 589 visible caption copy cover input, selection, click, submit, continue, authorization, and 2 seconds.
|
||||
|
||||
INVESTIGATOR_JUDGMENTS: Two fresh read-only investigators returned `PLAN_DRIFT_CONTINUE_SAFE`. Investigator 1 found the implementation aligned with the immutable spec and literal frozen-plan copy would under-satisfy the spec. Investigator 2 found Task 2 Step 3's literal HTML snippet not executable as written for the copy requirement, while the rest of Task 2 remains safely executable.
|
||||
|
||||
P9_FINAL_ADJUDICATION: PLAN_DRIFT_CONTINUE_SAFE
|
||||
|
||||
EFFECTIVE_EXECUTION_CONTRACT: For Task 2 and later reviews, treat the immutable spec's all-six-category sidepanel switch copy requirement as controlling. Preserve copy that communicates input, selection, click, submit, continue, authorization, and 2 seconds. Do not request or implement a regression to the narrower frozen-plan snippet.
|
||||
|
||||
SAFE_TO_CONTINUE: YES
|
||||
|
||||
REOPEN_ONLY_IF: New immutable spec evidence changes the sidepanel switch copy requirement, or repo evidence shows the implementation no longer communicates all six operation categories and the 2 second duration.
|
||||
|
||||
## DRIFT-2026-05-08-T3-001
|
||||
|
||||
DRIFT_ID: DRIFT-2026-05-08-T3-001
|
||||
|
||||
STATUS: ACTIVE
|
||||
|
||||
SUPERSEDES_DRIFT_ID: NONE
|
||||
|
||||
SUPERSEDED_BY_DRIFT_ID: NONE
|
||||
|
||||
SCOPE: Task 3 2925 provider metadata test scope
|
||||
|
||||
TRIGGER: Task 3 spec reviewer reported that the frozen Task 3 file list and commit step omitted `tests/background-icloud-mail-provider.test.js`, but full-suite verification required updating that existing 2925 provider metadata expectation after the required 2925 operation-delay injection change.
|
||||
|
||||
FROZEN_PLAN_STEP: `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:421-431` lists Task 3 files and tests without `tests/background-icloud-mail-provider.test.js`; `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:656-660` gives a Task 3 commit step that also omits that test file.
|
||||
|
||||
GOVERNING_SPEC_REQUIREMENT: `docs/superpowers/specs/2026-05-07-operation-delay-design.md:16-22`, `44-52`, and `80-83` require covered page operations to use the centralized content-side operation delay gate and current enabled state, while excluding only disabled/background/excluded work.
|
||||
|
||||
REPO_OR_WORKTREE_EVIDENCE: `background.js:11173-11180` implements the 2925 provider reuse metadata with `content/utils.js`, `content/operation-delay.js`, and `content/mail-2925.js` in order. `background/mail-2925-session.js:32-36` implements the matching session injection order. `tests/background-icloud-mail-provider.test.js:140-152` is an existing assertion over the same 2925 provider metadata and must expect `content/operation-delay.js` for the full suite to remain aligned. `npm test` passed 817/817 with that update.
|
||||
|
||||
INVESTIGATOR_JUDGMENTS: Two fresh read-only investigators returned `PLAN_DRIFT_CONTINUE_SAFE`. Both found the frozen plan's 2925 production requirement spec-correct, but the file list and commit step incomplete because they omitted an existing metadata test naturally affected by the required `background.js` provider metadata change.
|
||||
|
||||
P9_FINAL_ADJUDICATION: PLAN_DRIFT_CONTINUE_SAFE
|
||||
|
||||
EFFECTIVE_EXECUTION_CONTRACT: For Task 3 and later reviews, treat `tests/background-icloud-mail-provider.test.js` as in scope. Include it in the Task 3 checkpoint commit with the frozen Task 3 files. Preserve 2925 injection order as `content/utils.js`, `content/operation-delay.js`, `content/mail-2925.js` in both provider reuse and Mail2925 session paths. Do not treat this test update as unrelated scope creep.
|
||||
|
||||
SAFE_TO_CONTINUE: YES
|
||||
|
||||
REOPEN_ONLY_IF: New repo evidence shows `tests/background-icloud-mail-provider.test.js` no longer asserts the 2925 provider metadata changed by Task 3, or immutable spec evidence removes the 2925/provider reuse operation-delay injection need.
|
||||
|
||||
## DRIFT-2026-05-08-T4-001
|
||||
|
||||
DRIFT_ID: DRIFT-2026-05-08-T4-001
|
||||
|
||||
STATUS: ACTIVE
|
||||
|
||||
SUPERSEDES_DRIFT_ID: NONE
|
||||
|
||||
SUPERSEDED_BY_DRIFT_ID: NONE
|
||||
|
||||
SCOPE: Task 4 Step 3 direct-complete test scope
|
||||
|
||||
TRIGGER: Task 4 spec reviewer reported that the frozen Task 4 file list and commit step omitted `tests/step3-direct-complete.test.js`, but Step 3 operation-delay migration must preserve the existing completion-before-navigation contract while routing the deferred password submit through the operation-delay gate.
|
||||
|
||||
FROZEN_PLAN_STEP: `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:667-674` lists Task 4 files and tests without `tests/step3-direct-complete.test.js`; `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:788-790` gives a Task 4 commit step that also omits that test file.
|
||||
|
||||
GOVERNING_SPEC_REQUIREMENT: `docs/superpowers/specs/2026-05-07-operation-delay-design.md:18-20`, `44-52`, `55-60`, and `80-83` require covered page fills/submits/continues to use the centralized content-side operation delay gate. `docs/superpowers/specs/2026-05-07-operation-delay-design.md:111` makes `data/step-definitions.js` canonical for step keys, and `data/step-definitions.js:14` defines Step 3 as `fill-password`.
|
||||
|
||||
REPO_OR_WORKTREE_EVIDENCE: `content/signup-page.js:2463-2580` implements `step3_fillEmailPassword`; `content/signup-page.js:2533-2536` routes password fill through `performOperationWithDelay`; `content/signup-page.js:2559` reports Step 3 completion before deferred submit navigation; `content/signup-page.js:2561-2570` routes the deferred password submit through `performOperationWithDelay`. `tests/step3-direct-complete.test.js:54-235` verifies completion-before-navigation and deferred submit operation-delay behavior. Targeted verification including this test passed 38/38.
|
||||
|
||||
INVESTIGATOR_JUDGMENTS: Two fresh read-only investigators returned `PLAN_DRIFT_CONTINUE_SAFE`. Both found the frozen plan's broad Task 4 requirement covers Step 3 signup-page operations, but its exact file list and commit step are incomplete because they omit an existing regression test materially affected by the required `content/signup-page.js` change.
|
||||
|
||||
P9_FINAL_ADJUDICATION: PLAN_DRIFT_CONTINUE_SAFE
|
||||
|
||||
EFFECTIVE_EXECUTION_CONTRACT: For Task 4 and later reviews, treat `tests/step3-direct-complete.test.js` as in scope. Include it in the Task 4 checkpoint commit with the frozen Task 4 files. Preserve Step 3 completion/report before the deferred navigation-prone submit, and keep both password fill and deferred password submit routed through the shared operation-delay gate.
|
||||
|
||||
SAFE_TO_CONTINUE: YES
|
||||
|
||||
REOPEN_ONLY_IF: New repo evidence shows `tests/step3-direct-complete.test.js` no longer asserts Step 3 direct-completion behavior affected by Task 4, or immutable spec evidence removes Step 3 password fill/submit from covered OpenAI/auth page operations.
|
||||
|
||||
## DRIFT-2026-05-08-T7-001
|
||||
|
||||
DRIFT_ID: DRIFT-2026-05-08-T7-001
|
||||
|
||||
STATUS: ACTIVE
|
||||
|
||||
SUPERSEDES_DRIFT_ID: NONE
|
||||
|
||||
SUPERSEDED_BY_DRIFT_ID: NONE
|
||||
|
||||
SCOPE: Task 7 mail-2925 full-suite harness scope
|
||||
|
||||
TRIGGER: Task 7 implementer reported that targeted docs/exclusion tests passed but full `npm test` failed in `tests/mail-2925-content.test.js` because its extracted `ensureAgreementChecked` harness did not provide the new `performOperationWithDelay` dependency introduced by the spec-correct Task 6 `content/mail-2925.js` operation-delay wrapping.
|
||||
|
||||
FROZEN_PLAN_STEP: `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:1031-1039` lists Task 7 files and full existing test verification but omits `tests/mail-2925-content.test.js`; `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:1107-1115` requires full `npm test` to pass; `docs/superpowers/plans/2026-05-07-operation-delay-plan.md:1117-1121` gives a Task 7 commit step that omits that harness file.
|
||||
|
||||
GOVERNING_SPEC_REQUIREMENT: `docs/superpowers/specs/2026-05-07-operation-delay-design.md:18-22`, `44-52`, `53-62`, and `80-83` require covered page clicks/submits/controls to use the centralized content-side operation delay gate, while `64-71` excludes polling/background work, not 2925 login/session UI clicks.
|
||||
|
||||
REPO_OR_WORKTREE_EVIDENCE: `content/mail-2925.js:490-512` has `ensureAgreementChecked()` calling `performOperationWithDelay` for checkbox clicks, `content/mail-2925.js:1057-1060` defines that helper, and `content/mail-2925.js:1144` calls `ensureAgreementChecked()` from `ensureMail2925Session()`. `tests/mail-2925-content.test.js:896-902` extracts `ensureAgreementChecked` without extracting or stubbing `performOperationWithDelay`, causing `node --test tests/mail-2925-content.test.js` to fail 14/1 and full `npm test` to fail 841/1.
|
||||
|
||||
INVESTIGATOR_JUDGMENTS: Two fresh read-only investigators returned `PLAN_DRIFT_CONTINUE_SAFE`. Both found the production `content/mail-2925.js` change spec-correct and the failure a narrow stale test harness issue. Both found Task 7's full-suite requirement makes the harness update necessary despite omission from the frozen Task 7 file list and commit step.
|
||||
|
||||
P9_FINAL_ADJUDICATION: PLAN_DRIFT_CONTINUE_SAFE
|
||||
|
||||
EFFECTIVE_EXECUTION_CONTRACT: For Task 7 and later reviews, treat `tests/mail-2925-content.test.js` as in scope only for a narrow stale-harness fix that provides or extracts `performOperationWithDelay` for the existing `ensureAgreementChecked` test. Include that test update in the Task 7 checkpoint. Do not change runtime `content/mail-2925.js`, do not remove operation-delay wrapping from 2925 session UI, and do not wrap polling/cleanup handlers.
|
||||
|
||||
SAFE_TO_CONTINUE: YES
|
||||
|
||||
REOPEN_ONLY_IF: New evidence shows `tests/mail-2925-content.test.js` no longer exercises `ensureAgreementChecked`, or immutable spec evidence removes 2925 login/session UI checkbox clicks from covered operation-delay behavior.
|
||||
@@ -1,12 +0,0 @@
|
||||
# iCloud Polling And Add Phone Handoff Drift Adjudication Ledger
|
||||
|
||||
Immutable spec path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/.worktrees/fix-icloud-polling-addphone-handoff/docs/superpowers/specs/2026-05-08-icloud-polling-addphone-fix-design.md`
|
||||
|
||||
Immutable plan path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/.worktrees/fix-icloud-polling-addphone-handoff/docs/superpowers/plans/2026-05-08-icloud-polling-addphone-fix-plan.md`
|
||||
|
||||
Controller-only mutation rule: only the P9/controller may create, append, supersede, close, summarize, or otherwise mutate this ledger. Subagents may read it, cite `DRIFT_ID`, report evidence, and request supersession, but may not edit it directly.
|
||||
|
||||
## Active Adjudications Summary
|
||||
|
||||
| DRIFT_ID | STATUS | SCOPE | P9_FINAL_ADJUDICATION | EFFECTIVE_EXECUTION_CONTRACT |
|
||||
|---|---|---|---|---|
|
||||
-10
@@ -1,10 +0,0 @@
|
||||
# Phone Signup Stale Email Verification Drift Adjudication Ledger
|
||||
|
||||
Immutable spec: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/.worktrees/fix-icloud-polling-addphone-handoff/docs/superpowers/specs/2026-05-09-phone-signup-stale-email-verification-design.md`
|
||||
|
||||
Immutable plan: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu8.0/codex-oauth-automation-extension/.worktrees/fix-icloud-polling-addphone-handoff/docs/superpowers/plans/2026-05-09-phone-signup-stale-email-verification-plan.md`
|
||||
|
||||
## Active Adjudications Summary
|
||||
|
||||
| DRIFT_ID | STATUS | SCOPE | P9_FINAL_ADJUDICATION | EFFECTIVE_EXECUTION_CONTRACT |
|
||||
| --- | --- | --- | --- | --- |
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,85 +0,0 @@
|
||||
# iCloud Polling And Add Phone Handoff Fix Plan
|
||||
|
||||
## Goal
|
||||
|
||||
Implement the fix described in `docs/superpowers/specs/2026-05-08-icloud-polling-addphone-fix-design.md` on the Ultra8.0 operation-delay branch.
|
||||
|
||||
## Architecture
|
||||
|
||||
- Keep operation-delay excluded from polling.
|
||||
- Adjust iCloud polling in the verification flow and/or iCloud polling payload construction so normal no-code polling uses a larger iCloud-specific attempt/time window.
|
||||
- Reuse the existing shared phone verification flow when Step 7 lands on `/add-phone` and phone verification is enabled.
|
||||
- Preserve fatal behavior when phone verification is disabled.
|
||||
|
||||
## Implementation Granularity
|
||||
|
||||
- Implementer granularity: TaskGroup.
|
||||
- Reviewer granularity: TaskGroup.
|
||||
- One checkpoint commit after both spec and code reviewers approve.
|
||||
|
||||
## TaskGroup 1: iCloud polling and Step 7 add-phone handoff
|
||||
|
||||
### Task 1: Expand iCloud polling window without using operation-delay
|
||||
|
||||
Files likely involved:
|
||||
|
||||
- `background/verification-flow.js`
|
||||
- `content/icloud-mail.js`
|
||||
- `tests/verification-flow-polling.test.js`
|
||||
- `tests/icloud-mail-content.test.js`
|
||||
- Existing operation-delay exclusion tests as regression coverage.
|
||||
|
||||
Required behavior:
|
||||
|
||||
- Add failing tests proving iCloud Step 4 no-code polling is not configured as one attempt under normal conditions.
|
||||
- Add failing tests proving iCloud response timeout is large enough to cover the configured attempt count and interval.
|
||||
- Implement the minimum production change that gives iCloud at least 5 configured polling attempts and a response timeout derived from the iCloud polling window.
|
||||
- Do not wrap iCloud `POLL_EMAIL` handlers with `performOperationWithDelay`.
|
||||
- Keep provider-specific fast-failure for actual transport non-response.
|
||||
|
||||
Suggested verification:
|
||||
|
||||
```bash
|
||||
node --test tests/verification-flow-polling.test.js tests/icloud-mail-content.test.js tests/mail-polling-operation-delay-exclusion.test.js
|
||||
```
|
||||
|
||||
### Task 2: Continue Step 7 direct add-phone through shared phone verification when enabled
|
||||
|
||||
Files likely involved:
|
||||
|
||||
- `content/signup-page.js`
|
||||
- `background/steps/oauth-login.js`
|
||||
- `background.js`
|
||||
- `tests/background-step6-retry-limit.test.js`
|
||||
- `tests/auto-run-step6-restart.test.js`
|
||||
- `tests/step7-phone-login-entry.test.js`
|
||||
- `tests/step8-retry-page-recovery.test.js`
|
||||
- `tests/phone-verification-flow.test.js`
|
||||
|
||||
Required behavior:
|
||||
|
||||
- Add failing tests for Step 7 password submit landing on `/add-phone` with phone verification enabled.
|
||||
- Add or preserve tests for Step 7 password submit landing on `/add-phone` with phone verification disabled.
|
||||
- Add or preserve tests proving phone-login entry pages are not misclassified as add-phone.
|
||||
- Reuse existing shared phone verification helpers; do not implement new phone/SMS submission logic in Step 7.
|
||||
- Keep existing fatal propagation for shared phone verification failures.
|
||||
|
||||
Suggested verification:
|
||||
|
||||
```bash
|
||||
node --test tests/background-step6-retry-limit.test.js tests/auto-run-step6-restart.test.js tests/step7-phone-login-entry.test.js tests/step8-retry-page-recovery.test.js tests/phone-verification-flow.test.js
|
||||
```
|
||||
|
||||
## Final Verification
|
||||
|
||||
Run these before completion:
|
||||
|
||||
```bash
|
||||
node --test tests/verification-flow-polling.test.js tests/icloud-mail-content.test.js tests/mail-polling-operation-delay-exclusion.test.js tests/operation-delay-injection.test.js tests/content-operation-delay.test.js
|
||||
node --test tests/background-step6-retry-limit.test.js tests/auto-run-step6-restart.test.js tests/step7-phone-login-entry.test.js tests/step8-retry-page-recovery.test.js tests/phone-verification-flow.test.js
|
||||
npm test
|
||||
git diff --check
|
||||
git status --short --branch --untracked-files=all
|
||||
```
|
||||
|
||||
If `npm test` creates `scripts/__pycache__/`, remove it before final status.
|
||||
@@ -1,18 +0,0 @@
|
||||
# Phone Signup Stale Email Verification Fix Plan
|
||||
|
||||
## Task 1: Detect Stale Email Verification During Phone SMS Wait
|
||||
|
||||
- Add a TDD regression test in the existing phone verification test area.
|
||||
- Simulate `completeSignupPhoneVerificationFlow()` or its SMS wait helper entering phone-signup Step 4 with a valid signup phone activation while the auth tab is already on `/email-verification`.
|
||||
- The failing test must show the helper currently continues SMS polling instead of returning/failing fast.
|
||||
- Implement the smallest background-side page-state check needed to stop SMS waiting when the auth tab is already on email verification before SMS submission.
|
||||
- Return or throw a distinct stale-phone-signup condition that `executeStep4()` can use to fail fast without treating it as a successful post-SMS handoff.
|
||||
- Preserve existing successful post-SMS `emailVerificationRequired` handoff behavior.
|
||||
|
||||
## Task 2: Verification And Integration
|
||||
|
||||
- Run targeted tests covering phone verification and Step 4 handoff.
|
||||
- Run full `PYTHONDONTWRITEBYTECODE=1 npm test`.
|
||||
- Clean generated `scripts/__pycache__` artifacts.
|
||||
- Create one checkpoint commit only after spec and code reviewers approve.
|
||||
- Push the resulting branch to the Git export refs and the existing GitHub PR fork branch after final verification.
|
||||
@@ -1,115 +0,0 @@
|
||||
# Operation Delay Design Spec
|
||||
|
||||
## Goal
|
||||
|
||||
Add a default-enabled, sidepanel-controlled 2 second delay between individual page automation operations in Ultra7.0. The feature reduces rapid page interaction failures on slow or unstable networks while keeping the behavior modular enough to port across future upstream versions.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- The feature does not add step-to-step delay as its primary behavior.
|
||||
- The feature does not slow email polling, SMS polling, backend API calls, network retries, background timers, or storage persistence.
|
||||
- The feature does not run inside `confirm-oauth` or `platform-verify` flows.
|
||||
- The feature does not create a second tips or log console.
|
||||
- The feature does not expose a user-editable delay duration in this version.
|
||||
- The feature does not become Auto-only; manual single-step execution uses the same behavior.
|
||||
|
||||
## Scope
|
||||
|
||||
The feature covers page-side operations triggered by extension automation during Auto runs and manual single-step runs. A covered operation includes any automation action that writes page DOM state, changes page execution state, selects a value, clicks a page control, submits a form, continues a page flow, or authorizes a page flow.
|
||||
|
||||
The delay duration is fixed at 2000 milliseconds. When the setting is enabled, automation waits 2000 milliseconds after each covered page operation completes. For ordinary chains, that pause separates one covered operation from the next. The first covered operation after a page is ready starts immediately. Terminal submit, continue, and authorization actions also receive the 2000 millisecond pause after they complete, even when no later covered operation follows.
|
||||
|
||||
The feature treats grouped split verification-code entry as one covered operation. A grouped split code operation fills the full group without per-character or per-field pauses, then receives one 2000 millisecond delay after the group is filled.
|
||||
|
||||
## Actors And Entry Points
|
||||
|
||||
- Sidepanel user: views and toggles the `操作间延迟` setting in the existing sidepanel settings surface.
|
||||
- Auto runner: executes the full automation flow and applies the same operation delay setting.
|
||||
- Manual step runner: executes a selected step from the sidepanel and applies the same operation delay setting.
|
||||
- Content scripts: perform covered page operations and enforce the delay gate after those operations complete.
|
||||
- Bottom tips/log console: reports setting changes and setting recovery failures through the existing `log-area` flow.
|
||||
|
||||
## Functional Behavior
|
||||
|
||||
### Sidepanel Setting
|
||||
|
||||
- The sidepanel displays a boolean `操作间延迟` switch in the existing settings surface.
|
||||
- The switch defaults to enabled when no valid persisted value exists, including first install and upgrades from versions that did not store this setting.
|
||||
- The switch label communicates that enabled mode waits 2 seconds after page input, selection, click, submit, continue, and authorization operations.
|
||||
- Toggling the switch persists the new value through the existing settings channel.
|
||||
- Toggling the switch writes one bottom tips/log entry that states the new enabled or disabled state.
|
||||
- The enabled-state log message includes the 2 second delay duration.
|
||||
- The disabled-state log message states that operation delay is off.
|
||||
|
||||
### Operation Delay Runtime
|
||||
|
||||
- The operation delay gate runs after each covered page operation while the setting is enabled.
|
||||
- The operation delay gate is skipped while the setting is disabled.
|
||||
- The operation delay gate is skipped inside steps whose step key is `confirm-oauth` or `platform-verify`.
|
||||
- The operation delay gate is skipped for background-only work that does not execute page operations.
|
||||
- A setting change during an active run takes effect after the current covered page operation finishes. A delay already in progress completes unless the user stops the flow.
|
||||
- A user Stop request interrupts an active 2 second operation delay and propagates the same stop error behavior used by existing content-script waits.
|
||||
|
||||
### Covered Operation Examples
|
||||
|
||||
- Filling a visible input field is one covered operation.
|
||||
- Filling a hidden synchronization field is one covered operation.
|
||||
- Updating page execution state through DOM writes or synthetic input/change events is one covered operation.
|
||||
- Selecting a dropdown value is one covered operation.
|
||||
- Clicking a button, link, checkbox, or role-based control is one covered operation.
|
||||
- Submitting a form through click, dispatch, or request-submit behavior is one covered operation.
|
||||
- Clicking a continue or authorization button is one covered operation unless the current step key is excluded.
|
||||
- Filling split OTP or split verification-code fields is one grouped covered operation.
|
||||
|
||||
### Excluded Work Examples
|
||||
|
||||
- Waiting for an element to appear is not a covered operation.
|
||||
- Polling mailbox or SMS provider APIs is not a covered operation.
|
||||
- Sleeping between retry attempts is not a covered operation.
|
||||
- Writing logs is not a covered operation.
|
||||
- Persisting sidepanel settings or run state in extension storage is not a covered operation.
|
||||
- Background tab bookkeeping is not a covered operation.
|
||||
|
||||
## State And Data Contracts
|
||||
|
||||
- `operationDelayEnabled` is a persisted boolean setting.
|
||||
- If the persisted value is absent or invalid, the runtime uses `operationDelayEnabled = true`.
|
||||
- A valid persisted `false` remains `false` across later restores and upgrades.
|
||||
- The fixed delay duration is 2000 milliseconds.
|
||||
- The delay duration is not user-editable.
|
||||
- Runtime page-operation code reads the current enabled state at the start of the delay gate for a covered operation.
|
||||
- The exclusion set contains exactly these step keys: `confirm-oauth`, `platform-verify`.
|
||||
- The sidepanel writes setting-change feedback to the existing bottom tips/log stream. It does not write to a separate console.
|
||||
- Content-side delay enforcement is centralized behind a shared operation delay gate so new page-operation call sites have one integration point.
|
||||
|
||||
## Error Handling And Edge Cases
|
||||
|
||||
- Missing persisted setting value resolves to enabled.
|
||||
- Invalid persisted setting value resolves to enabled.
|
||||
- If setting restoration fails in the sidepanel, the sidepanel displays the default enabled state and writes one warning entry to the bottom tips/log stream.
|
||||
- If saving a user toggle fails, the sidepanel writes one error entry to the bottom tips/log stream and keeps the visible switch aligned with the last confirmed persisted state.
|
||||
- If content-side code cannot resolve the setting for a covered operation, the operation delay gate uses enabled mode and a 2000 millisecond delay.
|
||||
- If a Stop request arrives during an operation delay, the delay rejects with the existing stop error and the current flow stops through the existing stop path.
|
||||
- Split verification-code input remains a single grouped operation even when the page exposes multiple fields.
|
||||
- `confirm-oauth` and `platform-verify` perform no operation delay even when they click or submit page controls.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Opening the sidepanel with no persisted setting shows `操作间延迟` enabled.
|
||||
- Disabling the setting persists `operationDelayEnabled = false` and writes a bottom tips/log entry stating that operation delay is off.
|
||||
- Enabling the setting persists `operationDelayEnabled = true` and writes a bottom tips/log entry stating that page operations wait 2 seconds.
|
||||
- Auto execution and manual single-step execution both honor the same setting.
|
||||
- With the setting enabled, a profile-fill flow starts the first covered page operation immediately after the page is ready, waits 2 seconds after that operation completes, then starts the next covered operation, waits 2 seconds after that operation completes, then starts the next one, and waits 2 seconds after the terminal submit or complete action completes.
|
||||
- With the setting enabled, a split verification-code flow fills the full group as one covered operation, then waits 2 seconds after the group is filled. It does not wait 2 seconds between individual split fields.
|
||||
- With the setting disabled, covered page operations run without the 2 second operation delay.
|
||||
- Email polling, SMS polling, backend retries, background timers, and storage persistence keep their existing cadence.
|
||||
- `confirm-oauth` and `platform-verify` keep their existing interaction cadence.
|
||||
- A Stop request during a 2 second operation delay stops the flow through the existing stop behavior.
|
||||
|
||||
## Locked Assumptions
|
||||
|
||||
- Ultra7.0 uses `data/step-definitions.js` as the canonical source for step keys.
|
||||
- The existing bottom `log-area` flow is the only tips/log feedback target for this feature.
|
||||
- The first implementation uses one boolean sidepanel switch and one fixed 2000 millisecond duration.
|
||||
- The implementation uses a shared content-side operation delay gate instead of scattered business-step sleeps.
|
||||
- Future page operation call sites use the shared operation delay gate for covered operations.
|
||||
@@ -1,60 +0,0 @@
|
||||
# iCloud Polling And Add Phone Handoff Fix Spec
|
||||
|
||||
## Goal
|
||||
|
||||
Fix two Ultra8.0 runtime failures on top of the migrated operation-delay branch:
|
||||
|
||||
- iCloud verification email polling must wait longer and perform more than one check before declaring the code missing.
|
||||
- Step 7 password login that lands directly on `https://auth.openai.com/add-phone` must continue into the existing phone verification flow when phone verification is enabled, instead of failing immediately.
|
||||
|
||||
## Non-Goals
|
||||
|
||||
- Do not add operation-delay waits to email polling, SMS polling, backend retries, or background timers.
|
||||
- Do not change non-iCloud provider polling cadence unless required by shared test harness setup.
|
||||
- Do not duplicate phone verification logic inside Step 7.
|
||||
- Do not treat ordinary phone-login entry pages as add-phone pages.
|
||||
- Do not continue add-phone when phone verification is disabled or when the existing phone verification flow reports a fatal error.
|
||||
|
||||
## iCloud Polling Behavior
|
||||
|
||||
The current failure log shows Step 4 iCloud polling using fast timeout protection with a 22 second response timeout and a `最多 1 次` polling payload, then failing after roughly 3 seconds. This is too short for the user's active iCloud-only workflow.
|
||||
|
||||
For iCloud verification-code polling:
|
||||
|
||||
- Step 4 signup-code polling and Step 8 login-code polling must not be reduced to a single attempt under normal no-code conditions.
|
||||
- The iCloud polling payload must use an iCloud-specific minimum attempt floor of at least 5 attempts.
|
||||
- The iCloud polling interval must allow delayed mail arrival and may be longer than the current 3 second effective no-code window.
|
||||
- The tab-message response timeout for iCloud polling must be large enough for the configured iCloud polling attempts and intervals to complete, plus a small transport margin.
|
||||
- Transport-unresponsive protection must remain: if the iCloud content script itself does not respond, the flow should fail or recover through the existing transport-error path instead of hanging indefinitely.
|
||||
- Logs must accurately describe the actual iCloud attempt count and wait window.
|
||||
- Operation-delay remains excluded from all email polling paths.
|
||||
|
||||
## Add Phone Handoff Behavior
|
||||
|
||||
When Step 7 password submission transitions directly to an add-phone page:
|
||||
|
||||
- If phone verification is enabled, Step 7 must not throw the current fatal `提交密码后页面直接进入手机号页面，未经过登录验证码页` error.
|
||||
- The flow must hand off to the existing shared phone verification implementation used by later steps.
|
||||
- After successful phone verification, the automation should continue through the existing OAuth/login flow instead of stopping the run.
|
||||
- If phone verification is disabled, the flow must keep a clear fatal error telling the user that add-phone requires phone verification to be enabled.
|
||||
- Existing fatal conditions from the shared phone verification flow remain fatal, including unavailable phone numbers, provider failures, phone already exists, and user stop.
|
||||
- Existing phone-login entry detection must remain separate from add-phone detection.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- Reproducing the reported iCloud Step 4 path no longer emits `开始轮询 iCloud 邮箱（最多 1 次）` for normal iCloud no-code polling.
|
||||
- iCloud Step 4 no-code polling performs at least 5 configured attempts before the missing-code failure path.
|
||||
- iCloud polling response timeout is derived from the configured iCloud attempt count and interval rather than being capped to a too-short single-attempt window.
|
||||
- Mail polling operation-delay exclusion tests still pass.
|
||||
- Existing non-iCloud provider tests continue to pass.
|
||||
- Step 7 password-submit to `/add-phone` with phone verification enabled continues into the shared phone verification flow.
|
||||
- Step 7 password-submit to `/add-phone` with phone verification disabled still fails clearly.
|
||||
- Step 7 phone-login entry pages are still treated as login phone input, not add-phone.
|
||||
- Relevant targeted tests and full `npm test` pass.
|
||||
|
||||
## Verification Targets
|
||||
|
||||
- `node --test tests/verification-flow-polling.test.js tests/icloud-mail-content.test.js`
|
||||
- `node --test tests/background-step6-retry-limit.test.js tests/auto-run-step6-restart.test.js tests/step7-phone-login-entry.test.js tests/step8-retry-page-recovery.test.js tests/phone-verification-flow.test.js`
|
||||
- `node --test tests/mail-polling-operation-delay-exclusion.test.js tests/operation-delay-injection.test.js tests/content-operation-delay.test.js`
|
||||
- `npm test`
|
||||
@@ -1,26 +0,0 @@
|
||||
# Phone Signup Stale Email Verification Fix Design
|
||||
|
||||
## Scope
|
||||
|
||||
Fix phone-signup Step 4 behavior when OpenAI has already moved the auth tab to an email verification page before a phone SMS verification code is submitted.
|
||||
|
||||
## Required Behavior
|
||||
|
||||
- If phone-signup Step 4 is waiting for an SMS code and the auth tab is still on the phone verification page, keep polling the configured SMS provider.
|
||||
- If phone-signup Step 4 is waiting for an SMS code but the auth tab has moved to `/email-verification`, stop waiting for SMS immediately.
|
||||
- The `/email-verification` transition before SMS submission means the phone number is not usable for a new phone-signup account in this run. The flow must fail fast with a clear, actionable error so the current auto-run attempt can rotate/restart instead of hanging.
|
||||
- If phone-signup Step 4 submits a valid phone SMS code and then OpenAI moves to `/email-verification`, preserve the existing handoff behavior and continue mailbox verification.
|
||||
- Do not add operation-delay to SMS polling, email polling, backend retries, or background timers.
|
||||
- Do not broaden iCloud-specific polling behavior to other mail providers.
|
||||
|
||||
## Error Semantics
|
||||
|
||||
The stale email-verification bailout must be distinguishable from SMS-provider timeout, invalid SMS code, user stop, and normal post-SMS email-verification handoff.
|
||||
|
||||
The user-facing message should explain that OpenAI moved to email verification before phone SMS verification completed, likely because the phone number is already associated with an existing account or login path, and the current number should be replaced.
|
||||
|
||||
## Testing Requirements
|
||||
|
||||
- Add a regression test that simulates phone-signup Step 4 polling while the auth tab is already on `/email-verification`; the test must fail before the implementation and pass after.
|
||||
- Add or update tests to prove normal post-SMS email-verification handoff still works.
|
||||
- Run targeted phone Step 4 tests and the full suite before completion.
|
||||
Reference in New Issue
Block a user