Move CPA oauth url/callback handling to management API first, persist state/origin runtime keys, and fail fast on invalid callback or missing management auth to reduce flaky panel-driven auth failures.
This keeps the existing CPA, SUB2API, and contribution flows intact
while introducing codex2api as a separate source that plugs into
Step 7 and Step 10 through backend APIs instead of page DOM.
The sidepanel now exposes codex2api settings, preserves the built-in
local default through placeholder-only UI, and accepts user-provided
public admin URLs. Step 7 now treats missing or invalid management
secrets as terminal config errors so the flow stops instead of retrying
needlessly.
Constraint: New source must be additive and must not break existing CPA/SUB2API/contribution paths
Rejected: Drive codex2api through admin page button clicks | too brittle against frontend DOM changes
Rejected: Reuse contribution mode as a source surface | violates existing panelMode/runtime-mode boundary
Confidence: high
Scope-risk: moderate
Reversibility: clean
Directive: Keep codex2api on the protocol path unless its API becomes insufficient; do not add a panel content script without proving the protocol path cannot work
Tested: npm test; targeted codex2api/auth retry loops repeated 40 times; full suite repeated 5 times
Not-tested: Real browser run against a live codex2api instance with a real Admin Secret and OpenAI authorization
- Added a new feature to allow users to select multiple account records and delete them.
- Introduced a filter system to categorize account records based on their status (success, failed, stopped, retry).
- Enhanced the UI with a toolbar for selection and deletion actions, including a confirmation modal for deletions.
- Updated the CSS for better styling of the new toolbar and selection states.
- Implemented backend support for deleting selected records and syncing the remaining records.
- Added unit tests to ensure the new functionality works as expected.
Expose a configurable default proxy for SUB2API, resolve the proxy once,
persist the proxy_id in state, and reuse it across auth URL generation,
code exchange, and account creation so one OAuth flow stays on one proxy.
Constraint: Upstream GitHub permission is READ, so publication must use a fork PR
Rejected: Push to origin | current GitHub viewer permission does not allow upstream branch publication
Rejected: Resolve proxy independently in later steps | could drift from the proxy chosen at auth URL generation
Confidence: high
Scope-risk: moderate
Reversibility: clean
Tested: npm test passed 183/183
Not-tested: Manual browser extension flow against a live SUB2API deployment
- Implemented `background/account-run-history.js` to persist account run results (success, failure, stop) in `chrome.storage.local` and log to a text file when the local Hotmail helper is enabled.
- Enhanced `background/auto-run-controller.js` and `background/message-router.js` to utilize the new account run record functionality.
- Updated steps in `background/steps/fetch-login-code.js`, `background/steps/fetch-signup-code.js`, and `background/steps/oauth-login.js` to handle retries and logging appropriately.
- Introduced tests for account run history and step retry limits to ensure functionality and reliability.
- Modified documentation to reflect new features and changes in behavior for specific providers (e.g., 2925).
- Introduced a new module for step definitions in `data/step-definitions.js` to manage shared step metadata.
- Updated `sidepanel.html` to dynamically render steps based on the new step definitions module.
- Refactored `sidepanel.js` to utilize the step definitions for rendering and managing step statuses.
- Enhanced tests to validate the step definitions module and its integration with the sidepanel.
- Cleaned up existing tests to ensure they align with the new structure and functionality.
朴圣佑