Keep the patrol deletion test module aligned with the renamed patrol_delete implementation and update test function names so future searches no longer point at the old product module name.
Constraint: This is a naming-only follow-up to the patrol_delete module rename
Confidence: high
Scope-risk: narrow
Tested: uv run pytest tests/test_patrol_delete.py
Rename the patrol deletion implementation and browser helper scripts away from the generic product name so the filesystem matches the queued patrol-delete task domain. Update imports, script loading, and tests to use the patrol_delete module path.
Constraint: Existing task class remains ProductTask to avoid broad API churn beyond the requested file and script naming
Rejected: Rename ProductTask class now | would expand the change into a larger API update across tests and task dispatch
Confidence: high
Scope-risk: narrow
Directive: Keep patrol-delete script paths under app/amazon/scripts/patrol_delete when adding new helper scripts
Tested: uv run pytest tests/test_product.py
Not-tested: Remote push before this commit due previous SSH publickey failure
Rename the patrol deletion implementation and browser helper scripts away from the generic product name so the filesystem matches the queued patrol-delete task domain. Update imports, script loading, and tests to use the patrol_delete module path.
Constraint: Existing task class remains ProductTask to avoid broad API churn beyond the requested file and script naming
Rejected: Rename ProductTask class now | would expand the change into a larger API update across tests and task dispatch
Confidence: high
Scope-risk: narrow
Directive: Keep patrol-delete script paths under app/amazon/scripts/patrol_delete when adding new helper scripts
Tested: uv run pytest tests/test_product.py
Not-tested: Remote push before this commit due previous SSH publickey failure
Merge origin/master into dev/koko while preserving the patrol delete task added on dev/koko. The task dispatcher now recognizes both patrol deletion and appearance patent collection, and the master-side SpiderTask implementation is included.
Constraint: origin fetch and push over SSH are blocked in this environment by Gitee publickey authentication
Rejected: Overwrite dev/koko with master | would drop the patrol delete branch work
Confidence: medium
Scope-risk: moderate
Directive: Do not remove either patrol-delete-run or appearance-patent-run without checking queued task producers
Tested: python -m py_compile app/amazon/approve.py app/amazon/asin_status.py app/amazon/detail_spider.py app/amazon/main.py app/amazon/match_action.py app/amazon/price_match.py
Not-tested: Remote push, blocked by SSH publickey authentication
Merge origin/master into dev/koko while preserving the patrol delete task added on dev/koko. The task dispatcher now recognizes both patrol deletion and appearance patent collection, and the master-side SpiderTask implementation is included.
Constraint: origin fetch and push over SSH are blocked in this environment by Gitee publickey authentication
Rejected: Overwrite dev/koko with master | would drop the patrol delete branch work
Confidence: medium
Scope-risk: moderate
Directive: Do not remove either patrol-delete-run or appearance-patent-run without checking queued task producers
Tested: python -m py_compile app/amazon/approve.py app/amazon/asin_status.py app/amazon/detail_spider.py app/amazon/main.py app/amazon/match_action.py app/amazon/price_match.py
Not-tested: Remote push, blocked by SSH publickey authentication
Update the README so new contributors start from the latest patrol-delete automation flow instead of treating delete-brand as the primary example. Keep the older delete-brand path as contrast for the file-driven workflow.
Constraint: Recent repository changes made patrol-delete the newest automation module, so the onboarding example needed to match current development reality
Rejected: Leave delete-brand as the primary example | would mislead readers about the latest automation entry point
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Revisit this section when a newer automation module replaces patrol-delete as the primary example
Tested: README diff review
Not-tested: lint, typecheck, unit/integration tests not run (documentation-only change)
Update the README so new contributors start from the latest patrol-delete automation flow instead of treating delete-brand as the primary example. Keep the older delete-brand path as contrast for the file-driven workflow.
Constraint: Recent repository changes made patrol-delete the newest automation module, so the onboarding example needed to match current development reality
Rejected: Leave delete-brand as the primary example | would mislead readers about the latest automation entry point
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Revisit this section when a newer automation module replaces patrol-delete as the primary example
Tested: README diff review
Not-tested: lint, typecheck, unit/integration tests not run (documentation-only change)
new file: "brand - \345\211\257\346\234\254.html"
new file: "brand-\346\227\247.html"
new file: brand.html
new file: home.html
new file: index.html
new file: login.html
Add a root README that explains the active runtime layers and onboarding path, and keep local OMX session state out of version control so developer tooling does not interfere with pulls.
Constraint: Local OMX state is developer-specific and should not block branch sync or appear in shared history
Rejected: Keep onboarding notes untracked | easy to lose and hard to share with the team
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep the README aligned with the active app/backend-java/frontend-vue execution path; revisit if the runtime architecture changes
Tested: git diff review; git status after staging
Not-tested: lint, typecheck, unit/integration tests not run (docs and ignore rules only)
Add a root README that explains the active runtime layers and onboarding path, and keep local OMX session state out of version control so developer tooling does not interfere with pulls.
Constraint: Local OMX state is developer-specific and should not block branch sync or appear in shared history
Rejected: Keep onboarding notes untracked | easy to lose and hard to share with the team
Confidence: high
Scope-risk: narrow
Reversibility: clean
Directive: Keep the README aligned with the active app/backend-java/frontend-vue execution path; revisit if the runtime architecture changes
Tested: git diff review; git status after staging
Not-tested: lint, typecheck, unit/integration tests not run (docs and ignore rules only)
