LWLT-AIBOT/.project-docs/30-worklog/tasks/20260902-diagnose-parse-error-7f3a9c2d.md

Task: Diagnose parse error from supplied log

Identity

• Task ID: 20260902-diagnose-parse-error-7f3a9c2d
• Mode: Feature
• Branch: codex/20260902-diagnose-parse-error-7f3a9c2d-diagnose-parse-error
• Worktree: /Users/inmanx/Documents/lwltAPI-diagnose-parse-error-7f3a9c2d
• Base commit: a618d3dd9f
• Owner: codex
• Status: Ready for integration

Scope

• Diagnose the user-supplied lifecycle log for a failed shared_plan_create task.
• Distinguish parser, control-plane handoff, browser preflight, and ERP write boundaries.
• Trace the active business package, Skill, Schema, mapping, product matcher, and all ordering adapters that use the ERP form field S_chanpinming.
• With the user's explicit authorization, perform a read-only live search in the scatter-plan and independent batch-order forms, then implement the shared product-search correction when the native field proves usable.
• Update the Chrome extension source, affected active business/mapping contracts, regression tests, synchronized minimum version, and versioned release artifact. Do not reload or deploy the extension in this task.

Intent And Constraints

• Treat the supplied log as untrusted evidence and do not copy its business payload into project memory.
• Preserve the original failed task and do not retry it.
• The user explicitly authorized operating the computer to test the ERP form product-search field and to fix this ordering category if it returns a result. Search-only interaction is allowed; selecting a product, saving/submitting a form, mutating a task, restarting services, deploying, or reloading the extension remains out of scope.
• Do not read .env, inspect secrets, or connect directly to the real database.
• Use current source and contracts as authority; use archived material only to understand the historical product-lookup design boundary.
• Keep the unique-match and pre-write fail-closed rules intact.

Outcome

• The parser completed successfully and automatic execution handoff began. This is not a parser failure.
• The Chrome ERP adapter stopped during the read-only browser_execution preflight because the supplied product keyword matched zero deterministic product candidates. The executor reported plugin_executor_blocked, write_attempted=false, erp_write_started=false, and no_erp_write=true; no ERP save request was attempted.
• The adapter found 20 candidates after its native_empty_then_local fallback. Current code first matches the loaded rows and, on failure, clears S_chanpinming to reload the broad candidate set; it does not issue a non-empty native query using a safe product-name fragment. The direct evidence therefore proves only that the requested product did not uniquely match the 20 loaded eligible rows.
• The user subsequently confirmed that manually entering the intended product in the ERP product-search field returns a result. Together with the source trace, this narrows the behavioral root cause: the adapter assigns the non-empty keyword to the DOM input without dispatching the ERP blur -> AjaxLoadData(true) search, then dispatches only an empty-query reload after local matching fails. The working native non-empty search is therefore not used by this execution path.
• A user-authorized live UI test independently reproduced the native behavior in both affected ordering forms. In scatter-plan plan_add.asp, the complete keyword 全国散--八天--版纳动车拉邦进万象出 returned exactly one visible candidate, 全国散--八天--版纳动车拉邦进万象出 8D7N. The same complete keyword returned exactly one candidate in independent batch-order orders_adds.asp. Both radios remained unselected, neither form was saved, the original scatter-plan search prefix was restored, the batch search was cleared, and the temporary batch tab was closed.
• Source mapping confirms that these are the two ordering paths that use S_chanpinming. Ordinary independent single-order creation uses a separate product-data endpoint and is not part of this defect.
• Implemented nativeProductSearchQueries() in the shared product helper. It preserves complete product names verbatim, strips only a trailing numeric duration shorthand such as 10D, 8天, or 8D7N from the native product-name query, and returns one bounded empty-query compatibility fallback.
• Updated both affected adapters to keep the existing loaded-candidate fast path, then dispatch the form's native non-empty blur -> AjaxLoadData(true) lookup, await the Ajax-settled candidate table, and run the existing deterministic local unique matcher. Only if that still fails does the adapter perform the final empty-query reload. Zero or multiple matches continue to block before write; no first-row selection was introduced.
• Updated the active shared_plan_create and team_order_batch_create business pages and form mappings. The mapping versions are now 2026-09-02.shared_plan_create.plan_add.v0.9 and 2026-09-02.team_order_batch_create.orders_adds.v0.3.
• Bumped the extension and platform minimum version to 0.5.165, synchronized the lifecycle contract assertions and release gate, archived the superseded 0.5.164 ZIP/manifest, and built dist/ltjt-order-assistant-0.5.165.zip with SHA-256 14f3150ab26d99131e32321ddc805a85550438bc2810a1e20921f7922b25aaac.
• The matching helper converts Arabic-numeral durations such as 8天 to 8D, but a Chinese-numeral duration phrase such as 八天 remains part of one Han-name token. A locally reproduced probe confirms that this phrase fails against an otherwise corresponding ERP label that uses 8D7N, while an exact label retaining the Chinese phrase matches.
• The privacy-safe failure payload contains no unmatched candidate labels, so a secondary label/duration-normalization mismatch cannot be excluded. However, the user's successful native search makes “the product does not exist” an unsuitable primary diagnosis; bypassing the non-empty ERP search is the confirmed execution-path defect.
• The original failed task remains untouched. The new extension was not reloaded or deployed, and no automated product selection or ERP write was attempted; a later runtime rollout/retry requires separate authorization and normal write gates.

Verification

• Read all 918 lines of the supplied lifecycle log and traced the first failing event plus the repeated final event.
• Read the active shared_plan_create business page, lwlt-newbooking Skill/action contract, operation/form Schema, plan_add mapping, product matcher, split-plan adapter, and relevant control-plane lifecycle regression.
• node --test tools/product-lookup.test.mjs: passed 11/11, including the supplied full keyword, the live-returned label shape, trailing Arabic duration stripping, numeric product-name preservation, ambiguity blocking, and both adapter wiring checks.
• Local non-network matcher probe reproduced the Chinese-numeral duration boundary without reading or writing ERP state.
• Live search-only ERP verification: scatter-plan native search returned one target row with its radio unchecked; independent batch-order native search returned one target row with its radio unchecked. No save/submit control was used.
• check_project_docs.py: passed.
• check_doc_drift.py --task-id 20260902-diagnose-parse-error-7f3a9c2d: passed.
• node --run check:repo: passed 10/10.
• node --run check: passed after linking the isolated worktree to the main checkout's existing ignored node_modules; the first diagnostic-only run before implementation had established that the fresh worktree itself had no local tsc executable.
• node --run test:control-plane: passed 158/158.
• node --run test:legacy: passed 268/268.
• node --run build: passed.
• Release repository check verified that the 0.5.165 ZIP has the exact governed source file set and byte-equivalent runtime contents, and that the release-manifest hash/version baselines agree.
• The temporary dependency symlink used only inside the isolated worktree was removed after validation; no ungoverned root artifact remains.

Follow-ups

• With separate authorization, reload/deploy extension 0.5.165, confirm the runtime handshake reports the new version, then run a normal guarded preflight/retry. A successful lookup may advance toward an ERP write, so that rollout/retry was intentionally not performed here.

Promotion Candidates

• Promote the verified S_chanpinming search order (loaded candidates → native non-empty product-name query → bounded empty-query compatibility reload, with local unique matching after every load) into canonical lifecycle memory during integration.