LWLT-AIBOT/archive/research/2026-07-07/system_operation_scope.md

LTJT System Operation Scope

Date: 2026-07-07

Purpose

This document narrows the pure business background into the part that should be automated against the LTJT system.

The business document defines how WeChat instructions are understood, checked, clarified, and replied to. The LTJT adapter should not consume raw chat text directly. It should only receive a validated, standard operation object from the user's business system/database and then perform a deterministic system action.

Layer Boundary

Upstream business layer

Responsible for:

• Identifying the action type from the customer's instruction.
• Checking whether one message contains exactly one business action.
• Asking follow-up questions when fields are missing or ambiguous.
• Confirming risky passenger-list operations such as modify, delete, replace, full replace, or passenger reduction.
• All active orders are production/formal; the upstream business system's explicit confirmation, server execution ID, and plugin guard control the write boundary.

This layer may use AI during drafting or customer-service assistance, but it must produce structured data and explicit human/system validation results before the LTJT adapter writes anything.

Standard operation layer

Responsible for converting approved business intent and database-maintained field data into a stable object, for example:

• action: team_order_create, team_order_batch_create, shared_plan_create, shared_child_order_create, legacy order_update, passenger_list_import, five arrangement_*, three route-specific order_update_*, order_cancel, edit-only order_restore, guarded order_delete, confirmation_export
• order_nature: active operations use formal; test remains historical compatibility only
• product, route, departure_dates
• customer
• passenger_counts
• room_counts
• shared_plan_create uses planned_capacity and top-level room_counts as required mother-plan fields. ERP-supported child information is represented by optional split_order.customer and split_order.passenger_counts; each may be supplied independently and is written only when present.
• optional prices overrides for compatibility; active product selection/GetProduct owns linked pricing
• optional op_user, sales_user; active runtime resolves login-default staff when omitted
• optional flight, hotel, transfer, special-request, attachment, and passenger-list fields
• existing order_no, plan_no, or child_order_no where required

The LTJT adapter should treat this object as its only input contract.

The user's own business system/database is expected to maintain the source data for these fields, including customer, product, route, passenger counts, room counts, price rules, OP/salesperson assignment, order status, passenger-list metadata, and any configured defaults. The LTJT adapter should not create business meaning from unstructured text; it should only validate and translate the standard object into LTJT's form contract.

LTJT system operation layer

Responsible for:

• Opening the correct LTJT page in an approved session.
• Resolving system-side customer/product/staff/resource values through exact-match or configured deterministic matching.
• Filling the target form or building the same form-encoded request as the page.
• Running dry-run serialization and validation.
• Submitting only after deterministic checks pass and write permission has been explicitly enabled.
• Reading the created or updated system identifier from the response/page.

This layer should not make AI judgments at runtime.

Operation Matrix

Business action	System operation target	Current discovery status	Next technical work
团队-单个下单	独立团计划表 -> 下单 -> /System/Business/orders_add.asp -> POST /System/DAT/orders.asp with Act=DoInfoJH	Extension has the guarded formal preflight/submit path. Product/GetProduct derives linked route, customer, staff defaults and prices; the ERP group-number receipt is used for re-query.	Reverify against the current production account and current product-template price-row positions.
团队-批量下单	独立团计划表 -> per-date team_single fallback	Native DoInfoJHs remains unverified; the root plugin executes formal tasks serially through the verified single-order path and stops on the first incomplete date.	Keep the fallback as the active contract until native batch behavior is separately captured.
散拼-创建母团计划	散拼团计划表 -> /System/Business/plan_add.asp?fabudanwei=...	Extension fills required mother-plan fields and conditionally fills supported split_order customer/passenger fields, submits DoInfoSPs, and re-queries the returned parent group.	Complete one authorized real save with the optional-field matrix and retain the response/requery evidence.
散拼-拼单/录入子单	散拼团计划表 -> existing plan -> /System/Business/plan_order.asp?tdid=...	Handoff parent lookup, child fields, duplicate guard, and page probe are absorbed. Root plugin does not save a child order.	Capture the child form submit evidence and parent-after re-query in the extension context.
补充/修改订单	Existing order lookup -> edit page, likely orders_add.asp?ddid=... or related detail pages	Handoff structured set/delta/append rules are absorbed. Root plugin locates a unique order candidate and produces a no-write preview; no edit submit is enabled.	Capture edit-frame snapshot and submit-intercept evidence for room/remark changes on a dedicated test order.
游客名单导入/补充	Order detail or team/passenger-related pages, TBD	Handoff attachment-path, traveler-upsert, parser, count-check, and PII-redaction boundaries are absorbed. Root plugin verifies task intent and order candidate only; it does not read local workbooks or import rows.	Capture the actual import frame/upload route and row-count verification in the browser plugin.
导出确认件	Existing order -> confirmation/export page, TBD	Handoff export-only/recovery rules and Xingyou/Liantai/JOB source-path mapping are absorbed. Root plugin locates the order and builds source URLs without re-saving or claiming delivery.	Capture download/file-delivery behavior and explicit artifact verification.

Submit Preconditions

The adapter must refuse to submit when any of these are true:

• The action type is missing or maps to more than one LTJT workflow.
• order_nature is missing for a write operation.
• Required business fields are missing for the selected action.
• A batch order contains more than one product.
• Product, customer, OP, salesperson, route, or resource lookup returns zero or multiple acceptable matches.
• Product GetProduct(cpm) side effects are not executed in the browser before serialization.
• Product-template fields are empty or disagree with an explicitly supplied standard-operation value for product, trip, route, route prefix, customer, or customer id.
• Product-generated receivable rows and prices are not preserved, or passenger quantities/derived amounts cannot be updated deterministically.
• Passenger-list count exceeds order passenger count.
• Passenger-list operation is modify, delete, replace, full replace, or reduction without explicit confirmation.
• A modification/export request lacks the required existing order number, plan number, or child order number.
• The LTJT page returns login-expired or permission-alert JavaScript.
• The live page schema differs from the versioned mapping used by the adapter.
• Dry-run serialization fails required-field, hidden-id, currency/unit, count, or generated-order-number checks.
• The page's own SubmitInfoForm() has not been tested through an AJAX intercept that prevents DoInfoJH from reaching the network.
• A live submit is attempted without a passed real browser preflight report, a passed real submit-intercept report, matching payload SHA-256 values, --execute-live-submit, and the exact approval token.

Business-To-System Gaps

• The active business template for 团队-单个下单 explicitly requires 预订客户/组团社; the plugin re-applies it after the product “更新行程” side effect instead of trusting the product template customer.
• The active 散拼团新增计划 template treats customer and passenger controls as optional: the plugin fills each supplied supported field independently and leaves absent fields untouched.
• The LTJT form stores receivable rows with item, unit, currency, quantity, unit price, amount, payment-state metadata, and remarks. Product/GetProduct owns the template row and unit price; the plugin updates category quantities and derived amounts without clearing the template.
• 游客名单附件 is not proven to be the same as the general PicFile0/PicFile1 attachment fields in orders_add.asp. The actual passenger-list import workflow still needs capture.
• 确认件类型 is defined by the business template, but the LTJT export endpoint and parameters are still unknown.

Handoff Absorption Boundary

The business system and plugin accept the active create and confirmation actions plus historical compatibility actions. The three lwlt-newbooking behaviors are connected to guarded formal create paths, and lwlt-confirmation is connected to export-only source reads. lwlt-updating and lwlt-arrangement remain Skill-level stable blockers because their formal operation contracts are not published; they must not fall back to unrelated compatibility actions.

Priority Path

The first practical integration target should remain:

team_order_create -> 独立团计划表下单 -> orders_add.asp -> Act=DoInfoJH

Reasons:

• It matches the user's stated priority: 独立团计划表内的下单功能.
• The save endpoint, required fields, page validation flow, and full field schema are already captured.
• It can be implemented as a deterministic dry-run serializer before enabling any real submit.

Non-AI Runtime Contract

Production runtime should be:

business system/database -> standard operation JSON -> versioned mapping -> lookup resolution -> page-context fill -> ListForm.serialize() -> deterministic validation -> optional submit

AI can help maintain discovery notes and propose mapping drafts, but the deployed operation path should be rules, schemas, and tests.

Immediate Build Artifacts

Built first-pass artifacts:

• schemas/standard_system_operation.schema.json
• mappings/orders_add.mapping.json
• tools/dry_run_order_create.mjs
• tools/browser_order_add_dry_run.mjs
• tools/browser_order_add_preflight.mjs
• samples/team_order_create.dry-run.example.json

Current preflight behavior is non-submitting until the business system confirms the task: it validates a standard operation, resolves product and login-default fields, runs Find_product/GetProduct, preserves linked pricing rows, and captures the page's ListForm.serialize()/DoInfoJH payload hash. The confirmed executor then submits once and re-queries the ERP receipt.

Important SelectBox constraint: the live LTJT page uses SelectBox widgets for many visible text fields. These are not free-text fields for production. The adapter must exact-match one existing LTJT option and apply the widget's linked SetVal fields before any submit. This applies at minimum to route, product, customer, OP, salesperson, hotel, restaurant, attraction, flight, and receivable/resource fields.

For team_order_create, submit readiness now requires this non-writing sequence:

• lookup resolution passes for all critical SelectBox fields
• browser-context preflight executes product/page side effects such as GetProduct(cpm)
• product-template route/trip/customer/core metadata is nonempty and matches any explicitly supplied standard-operation value
• product-owned receivable rows and prices are preserved; passenger quantities and derived amounts are updated after product side effects
• final live ListForm.serialize() passes required-field and count checks
• submit-intercept dry run captures exactly one prevented DoInfoJH request and no validation alerts
• approved submit, if used, verifies the current browser payload SHA-256 still matches the approved preflight/intercept hash immediately before allowing the page's real AJAX request
• post-submit verification confirms the ERP group-number receipt is visible in the authorized JH_OrderList response; historical test markers are only a fallback

Controlled Submit Status

The independent-team create-order path uses the same guarded pipeline for formal production operations. A business-system confirmation is not a bypass: deterministic lookup, product-side-effect, preflight, submit-intercept, execution-ID, payload-hash, write-started, and post-operation receipt verification remain mandatory.