feat: add configurable operation delay

This commit is contained in:
root
2026-05-08 12:50:20 -04:00
parent 872f382815
commit c23461261b
44 changed files with 4770 additions and 193 deletions
@@ -0,0 +1,136 @@
# Operation Delay Drift Adjudication Ledger
Immutable spec path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu7.3/codex-oauth-automation-extension/.worktrees/feature-operation-delay-ultra73/docs/superpowers/specs/2026-05-07-operation-delay-design.md`
Immutable plan path: `/root/projects/resister-codex/codex-oauth-automation-extension-upstream-base-vu7.3/codex-oauth-automation-extension/.worktrees/feature-operation-delay-ultra73/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.
File diff suppressed because it is too large Load Diff
@@ -0,0 +1,115 @@
# 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.
+8
View File
@@ -70,3 +70,11 @@
4. 如果需要支付和订阅,再看 `06``07`
5. 如果需要代理配置,再看 `08`
6. 如果需要 `GPC` 卡密、`API Key` 或自动化接入,再看 `09`
---
## 7. 操作间延迟
`操作间延迟` 默认开启。开启后,自动流程和手动单步在每个页面输入、选择、点击、提交、继续或授权操作完成后固定等待 2 秒;第一项页面操作不会提前等待。分格 OTP/验证码会先整组填完,然后只等待一次。
该开关不同于步间间隔,不影响邮箱轮询、短信/WhatsApp 轮询、后台 API、网络重试、后台定时器或存储持久化,也不影响 `confirm-oauth``platform-verify` 的交互节奏。