Generated __pycache__ files were already ignored in some paths but remained tracked in the repository, which caused merge noise and binary conflicts. This removes the tracked bytecode from the index and adds an explicit recursive ignore rule so future Python runs do not reintroduce them.
Constraint: Existing repository history already tracked pycache files across app, backend, and source_code
Rejected: Delete local pycache directories from disk | only repository tracking needed to be removed
Confidence: high
Scope-risk: narrow
Directive: Do not force-add __pycache__ or *.pyc files unless there is a documented runtime packaging reason
Tested: git ls-files shows no remaining paths containing __pycache__/
Not-tested: Application runtime; change only affects tracked generated artifacts and ignore rules
The merge keeps dev/koko patrol-delete asset fallback behavior while accepting the latest master feature work. Conflicts were limited to ignore rules, local environment/config artifacts, tracked pycache binaries, and the Flask main blueprint.
Constraint: master and dev/koko both edited app/blueprints/main.py around brand and asset serving
Rejected: Drop dev/koko asset fallback logic | patrol delete and rebuilt Vite assets still need hashed asset resolution across app/new_web_source locations
Confidence: medium
Scope-risk: broad
Directive: app/.env remains a tracked local-config file in this repository; do not print or normalize secrets during conflict handling
Tested: uv run python -m py_compile blueprints\\main.py amazon\\base.py amazon\\main.py
Tested: uv run --group dev pytest tests\\test_amazon_base.py tests\\test_patrol_delete.py
Not-tested: Full backend-java/frontend-vue test suites
The patrol-delete flow now waits for country and listing-status controls before acting, uses the dedicated PatrolDeleteTask entry point, and includes the browser helper scripts required by the bulk-delete path. Tests cover delayed dropdown readiness, payload rejection/retry behavior, complete-draft normalization, filtered bulk deletion, and asset fallback lookup.
Constraint: Amazon listing UI exposes status controls through dynamic KAT components and delayed option rendering
Rejected: Keep row-by-row delete flow | bulk selection is the current implemented path and is covered by the added helper scripts
Confidence: high
Scope-risk: moderate
Directive: Do not remove the patrol_delete JS helper files without checking app/amazon/patrol_delete.py script loading
Tested: uv run --group dev pytest tests\\test_amazon_base.py tests\\test_patrol_delete.py
Tested: uv run python -m py_compile amazon\\base.py amazon\\main.py blueprints\\main.py
Not-tested: Real Amazon Seller Central browser session
Patrol delete can spend a long time switching countries, reading listing states, and confirming deletes, so the flow now emits concise progress logs around each high-value step. The logs avoid full DOM dumps outside existing diagnostics and focus on task, shop, country, status, deletion counts, and callback boundaries.
Constraint: Existing patrol delete runs are browser-driven and need observable progress without changing deletion behavior
Rejected: Log every DOM probe | too noisy for routine task monitoring
Confidence: high
Scope-risk: narrow
Tested: uv run --group dev pytest tests\\test_patrol_delete.py
Tested: uv run --group dev ruff check amazon\\patrol_delete.py
Tested: uv run python -m py_compile amazon\\patrol_delete.py
Not-tested: Live Seller Central browser run
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
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)
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)
