LWLT-AI/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.
- Resolving whether the instruction is test or formal before any write operation.

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`, `order_update`, `passenger_list_import`, `confirmation_export`
- `order_nature`: `test` or `formal`
- `product`, `route`, `departure_dates`
- `customer`
- `passenger_counts`
- `room_counts`
- `prices`
- `op_user`, `sales_user`
- 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` | Save endpoint, full add-form schema, standard operation schema, local mapping, lookup resolver, product-side-effect inspector, and browser preflight are built. This is the most mature path. | Run browser preflight against a real standard operation whose customer/product/route/staff names exist in LTJT, then plan a controlled submit test. |
| 团队-批量下单 | 独立团计划表 -> 批量下单, likely `/System/Business/orders_adds.asp?fabudanwei=...` | Native `DoInfoJHs` remains unverified; the root plugin now absorbs the verified handoff rule and can run marked test tasks through sequential `team_single` fallback. | Run a separately authorized multi-date test, then decide whether to retain fallback or capture native batch submit. |
| 散拼-创建母团计划 | 散拼团计划表 -> `/System/Business/plan_add.asp?fabudanwei=...` | Handoff route, required fields, date-slot mapping, and page probe are absorbed. Root plugin performs read-only capability inspection; save/re-query is not enabled. | Capture a no-save form schema and a controlled parent-plan save/re-query test before enabling writes. |
| 散拼-拼单/录入子单 | 散拼团计划表 -> 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 disagree with the standard operation for product, trip, route, route prefix, customer, or customer id.
- Product-generated receivable rows are not deliberately preserved or cleared/rebuilt from the standard operation's price rows.
- 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 pure business template for 团队-单个下单 does not explicitly require 预订客户/组团社, but the LTJT independent-order form requires `zutuanshe`. The upstream standard object must provide this customer field or an explicit configured default before dry-run.
- Business price fields are human-simple, but the LTJT form stores receivable rows with item, unit, currency, quantity, unit price, amount, payment-state metadata, and remarks. A deterministic price-to-receivable mapping is required.
- `游客名单附件` 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 now accept all seven root action names (the six handoff business families plus the existing team-single baseline). “纳入” currently means deterministic normalization, safety validation, route planning, and read-only browser inspection for the previously unconnected workflows. It does not mean that a plan-only task has already modified or exported ERP data. A new write route may be promoted only after the corresponding form payload, submit-intercept, and post-operation re-query evidence is captured.

## 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 dry-run behavior is non-submitting: it validates a supplied standard operation object, maps fields, opens `orders_add.asp` in an authorized browser session, and compares the live browser `ListForm.serialize()` payload. The next artifact should perform deterministic LTJT lookup selections/resolution and stop before `Act=DoInfoJH` submit.

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 matches the standard operation
- standard-owned receivable rows are cleared/rebuilt 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 obvious test marker is visible in the authorized `JH_OrderList` response

## Controlled Submit Status

The independent-team create-order path was previously exercised through a guarded live test. Its detailed reports and test-record identifiers were intentionally removed as historical validation artifacts during repository cleanup.

This historical result is not a production approval. Any future write still requires a real standard operation object and the same deterministic lookup, product-side-effect, preflight, submit-intercept, approved-submit, and post-operation verification sequence.