# 联泰下单助手 README（治理前完整快照）

Chrome MV3 unpacked extension for the LTJT ERP business-operation workflows.

## What It Does

- Accepts the structured business operation produced by the platform parser; natural-language parsing remains outside the extension.
- Opens the LTJT `orders_add.asp` form inside the logged-in ERP page.
- Resolves choice-backed fields from existing LTJT options.
- Runs the product template side effect through the page's own `Find_product()`.
- Preserves product-generated receivable rows and prices, then applies passenger quantities and derived amounts.
- Captures the page's own `SubmitInfoForm()` branch with `DoInfoJH` blocked before network.
- Allows live submit only after a passed preflight, captured submit hash, server-issued execution ID, and the LianSyn-platform operator's explicit confirmation. The background executor submits confirmed formal operations without opening the popup.
- Verifies the saved order through `JH_OrderList` by the ERP group-number receipt.
- Returns the ERP order-entry frame to the independent-order list after verification, filtered by departure date and the ERP receipt identifier.
- Keeps the extension popup as a minimal business-system connection status panel with an ERP-operation enable switch.
- Persists a server-issued `execution_id` guard before starting. A duplicate page message, page refresh, bridge reinjection, or extension service-worker restart cannot execute the same task again.
- Persists `write_started` before any real ERP write. Any crash or unknown result after that boundary becomes reconciliation-required and is never retried automatically.

## Absorbed ERP Operation Rules

The extension now recognizes the handoff package's complete business-operation matrix instead of treating every non-create task as an invalid order:

- `team_order_create`: the guarded production browser path; live submit requires the existing confirmation, execution-ID, payload-hash, and ERP re-query gates.
- `team_order_batch_create`: opens the native `orders_adds.asp` batch form, resolves customer/product keywords deterministically, selects explicit dates or native cycle shortcuts, intercepts `DoInfoJHs` during preflight, and returns the ERP group-number receipt after re-query. It never falls back to creating separate single-date orders.

The native batch path was live-verified on the repaired `lwlt.hisy.cc` deployment on 2026-08-06: one authorized case returned three ERP group numbers and all three were found again through `JH_OrderList`. The older per-date `DoInfoJH` fallback remains a separate compatibility route and is not silently substituted for native batch execution.
- `shared_plan_create` and `shared_child_order_create`: the parent path submits required native split-plan mother fields and conditionally maps supported `split_order.customer` / `split_order.passenger_counts` fields; each is independently optional and absent fields remain untouched. It re-queries the parent/list row. The split-parent adapter accepts explicit dates or a date range/recurrence and one plan per date. Product lookup must resolve to exactly one candidate; zero or multiple candidates block with a user-facing prompt. A multi-date split-plan receipt preserves `group_numbers` and `group_count` for every returned ERP group, while retaining the first `group_number` as a compatibility field. A multi-date request carrying split-order facts remains a dedicated `TEST-202609` probe: after save, every date must resolve to one exact parent `tid`, a complete native `OPEN_update(parentTid, childDdid)` child-link scan, and explicit customer/passenger visibility booleans. Missing per-date facts return uncertain; a determined parent-only or field-mismatch outcome stays `manual_review_required` and is not advertised as validated batch child creation.
- `order_update`: remains the legacy read-only preview compatibility action; it is not silently migrated to the three lifecycle update actions.
- `passenger_list_import`, five `arrangement_*`, three `order_update_*`, `order_cancel`, and `order_restore` use the staged lifecycle path: the front gate accepts only user-visible identifiers and narrow business targets; a read-only ERP resolver then derives exact object/resource references and current state; only that enriched operation can enter the strict pre-write gate. `order_delete` remains test-only. Historical operations that explicitly carry `source.test_context` retain the stricter account, `TEST-202609`, September-date, created-reference, and allowlist rules.
- `order_restore` is edit-only: native list restore `JH_set_quxiao(cz=0)` is disabled after two live reproductions returned HTTP 200 while remaining canceled. Shared-plan restore uses `收客中` and does not restore its children.
- `confirmation_export` accepts ten canonical source types and rejects a parent plan as a customer-document target. Its `confirmation` object accepts only canonical `type`, not language, format, or delivery options. Shared-child export requires both a parent group/plan reference for the ERP list search and a concrete child number or `ddid` for one exact leaf row; supplied `ddid/tid` values are reconciled with that row before any source is read. Every response freezes byte count and SHA-256 and explicitly reports `downloaded=false`, `converted=false`, `scheduled=false`, and `sent=false`.

The pure planning rules live in `operation-plans.js`; `lifecycle-result.js` defines the unified evidence shape; `lifecycle-adapters.js` contains the fail-closed native lifecycle adapter. Business rules remain testable without opening Chrome or touching ERP.

## Install Locally

1. Open Chrome and go to `chrome://extensions`.
2. Enable `Developer mode`.
3. Click `Load unpacked`.
4. Select this folder:

   `/Users/inmanx/Documents/lwltAPI/chrome-extension/ltjt-order-assistant`

5. Open or refresh the logged-in LWLT ERP page: `https://lwlt.hisy.cc/System/Mainlt.asp`.
6. Click the extension icon and use the popup.

## Safe Preflight / Save Flow

1. Paste the raw instruction or structured JSON.
2. Click `解析/格式化`.
3. Click `预检并拦截`.
4. Review the report. A good preflight has:
   - `status = raw_instruction_preflight_passed`
   - `submit_intercept.status = submit_intercept_captured`
   - no blockers
5. Tick the confirmation checkbox.
6. Click `确认真实保存`.
7. Click `回查 ERP 回执`.

## LianSyn-platform Integration

The repository contains the LianSyn-platform operation page and parser adapter:

`/Users/inmanx/Documents/lwltAPI/LianSyn-platform`

When opened through a local HTTP server, the page communicates with the extension through `business-bridge.js`.

For the production-hardened control plane, use the central server at its configured HTTPS origin. The page owns the administrator session and the extension remains a session-bound ERP adapter; `chrome.storage.local` is only a temporary execution cache. The production manifest must include the real business-system origin in its `host_permissions` and `content_scripts.matches` before packaging.

1. Reload the unpacked extension after any code change.
2. Start the standalone platform adapter:

   ```bash
   cd /Users/inmanx/Documents/lwltAPI/LianSyn-platform
   node server.mjs
   ```

3. Open the adapter page at `http://127.0.0.1:8765/` or use the central control plane at `http://127.0.0.1:8786/`.
4. Paste the raw business instruction into the single text box.
5. Configure `DEERFLOW_BASE_URL` and `DEERFLOW_OPEN_API_KEY` in the platform adapter environment before starting it.
6. Click `创建任务`.
7. Wait for the Agent result, review the returned operation JSON, and click `确认并提交到 ERP 插件` in the selected task detail.
8. The extension background executor then finds or opens the logged-in LTJT ERP tab, runs preflight, submits the confirmed formal operation, and verifies the ERP receipt according to the ERP automation switch.
9. Track progress from the LianSyn-platform task card. The popup remains available for adapter status, but business users do not need to open it.

The platform adapter exposes `/api/parse`. The server creates one independent Open Agent Session per task, streams the request to the published external Profile, and returns the standard `operation` JSON. The external Profile prompt and API policy are managed outside this repository; the browser never receives the external API key.

## Current Guardrails

- Version `0.5.123` adds the independent-order room-count mappings `rooms.SGL → frenshu0` and `rooms.TWN → frenshu1` alongside the existing passenger-count mappings `pax.adult → darenshu`, `pax.child_bed → xiaorenshu`, and `pax.leader → quanrenshu`. These targets are set-only, require non-negative integer values, and are checked again from the fresh edit form before the operation can complete; other unvalidated independent fields remain manual-review only. This release is prepared for the next authorized ERP run; no live ERP write was made while producing the package.
- Version `0.5.121` adds tokenized customer matching for identifier-free independent lifecycle lookups. The adapter first preserves the native customer + departure-date query; when ERP's contiguous `S_kehuming` filter returns no usable row, it retries by date and matches customer tokens locally (for example `衡阳国旅广东` against `LW衡阳国旅云南分社（广东市场）`). Product and leader remain optional candidate-row checks, and row-level `OPEN_update(...)`/nested-table compatibility from 0.5.120 remains in place. Update parsing still preserves multiple recognized business targets, while the browser adapter auto-writes only live-validated fields and sends the rest to manual review.
- Version `0.5.112` unified the release numbering and carried the shared-child leader lookup fix: when a leader is supplied, it is no longer sent as a mother-plan list filter. The adapter resolves it in the child form's native transfer SelectBox (`接团地点/标志` → `联系人/领队人` → `电话`) and chooses the first ERP row matching the keyword; the field remains optional.
- Version `0.5.109` introduced the shared-child leader lookup fix now carried forward by the unified `0.5.112` release.
- Version `0.5.108` makes booking customer optional for identifier-free shared-mother-plan capacity updates when the departure date is present; product and leader remain optional narrowing filters. The plan-list leader filter is sent to the ERP `接团/接送地点/标志` field (`S_youkexinxi`), while independent-order searches continue using `S_lingdui`. Every date-only plan lookup still requires one unique ERP candidate before write.
- Version `0.5.107` treats the other/filing settlement-unit field as the same unified SelectBox used by transport. Matching uses the combined visible candidate label, ignores separators, and supports non-contiguous keywords. Multiple candidates default to the first dropdown row; native `SetValToObj` then fills the project/filing description and other linked fields. Quantity is optional: omitted input keeps the ERP default, while a supplied positive quantity overrides it. The Agent no longer requires the project or quantity as input, and never writes `shuoming0` directly from parser text.
- Version `0.5.106` treats the transport settlement-unit field as a unified SelectBox. Matching uses the combined visible candidate label, ignores separators, and supports non-contiguous keywords. Multiple candidates default to the first dropdown row; native `SetValToObj` then fills the ticket/control description and other linked fields. The Agent no longer requires the description as input, and never writes `shuoming0` directly from parser text.
- Version `0.5.105` treats the hotel input as ERP's unified SelectBox. Matching uses the combined visible candidate label (hotel name, room type and linked text), ignores separators, and supports non-contiguous keywords such as `万荣龙吟阁TWN`. The adapter never edits the read-only room-type field: it selects the first matching ERP dropdown row by native `SetValToObj`, letting ERP populate room type and linked fields. Legacy trailing room tokens remain compatibility search text only.
- Version `0.5.103` fixes over-broad hotel matching: when a combined hotel-plus-room query is accompanied by a standalone room token, the most specific smallest candidate set wins instead of returning every matching room row. Hotel creates default to `未安排`, while update/clear accepts the current `未安排` or legacy `未确认` state.
- Version `0.5.102` fixes combined hotel search words such as `万荣龙吟阁TWN`: the unique lookup now searches both the individual ERP cells and their compact hotel-plus-room tuple, then derives the native room type and linked fields.
- Version `0.5.101` aligns `arrangement_hotel/create` with the ERP hotel form: the Agent supplies the hotel fuzzy-search word (which may include the room-type token), check-in/check-out dates, and room count; the unique ERP row supplies `room_type` and linked fields. Hotel creates default to `未安排`, while update/clear accepts the current `未安排` or legacy `未确认` state.
- Version `0.5.100` changes `arrangement_vehicle/create` to the native vehicle fields: the Agent supplies a settlement-unit fuzzy search word, a start/end vehicle date range and quantity; the routed candidate search covers settlement-unit name, vehicle/project text and settlement mode, and the unique match supplies the linked vehicle fields. Vehicle/model text is no longer a user-required field.
- Version `0.5.99` reuses the identifier-only calendar-safe date window for the post-write team-summary requery. A successful arrangement whose input contains only a group number no longer becomes a false `write_after_requery_mismatch` because the final `PrintGridLists` request sent an empty date pair.
- Version `0.5.98` follows the ERP-native guide linkage: the unique guide candidate row supplies ID, name, phone, grade, and its linked `daoguan` value (the row's index 5); login identity, `计调OP`, and `existing_refs.owner_account` remain target ownership evidence only and never fill `daoguan`. A missing or mismatched guide-linked coordinator still blocks before write.
- Version `0.5.97` was superseded: it incorrectly tried to derive `daoguan` from a current-operator/login context. It made no ERP write in the reported failure and must not be used as the current package.
- Version `0.5.95` waits for the arrangement resource SelectBox data and the current guide coordinator value after opening the exact team-arrangement page. This prevents an asynchronously hydrated guide page from being treated as a zero-candidate/empty-coordinator page.

- Version `0.5.91` treats the order passenger count as pre-write slot capacity, not as the number of blank rows ERP must preserve after save. Passenger requery compares every expected nonblank post-merge row and rejects missing, changed, or extra populated rows while accepting ERP's native blank-slot compaction. A later read-only reconciliation can match explicit target rows by sequence or, after compaction, by an exact duplicate-safe content multiset; it never resubmits the save action.
- Version `0.5.94` keeps the 0.5.93 business-key lookup behavior and also recognizes the team-arrangement native total-list request `Act=PrintGridLists` (including its native URL/body filter placement), so guide arrangement route preparation can capture the request ERP actually sends instead of reporting a false list-search timeout.
- Version `0.5.93` keeps the existing action and execution chain while allowing shared-child creation, passenger lists, narrow updates, cancel/restore, and team-file export to resolve a unique ERP target from booking customer plus departure date, with optional product/leader filters and an optional visible number. Arrangement and arrangement-change routes remain number-only. Shared-child creation never treats the new child customer as a mother-plan customer filter.
- Version `0.5.92` restores the extension-reload bridge injection for the current local platform port `8786`, so full automation resumes without refreshing the platform page. ERP identifier lookups with zero or multiple exact matches now return a direct Chinese error with the supplied number and never cross the write boundary.
- Version `0.5.90` applies the identifier-only calendar-safe ±1-year date window to the lifecycle ownership requery as well as initial ERP resolution. A passenger import without a user-supplied date can therefore prove the same exact order again before write; when no row exists, derivative tid/ddid/marker/account/status mismatch blockers are no longer reported.
- Version `0.5.89` reads the real passenger-slot count from the exact ERP edit form instead of copying the Agent's submitted row count. A passenger-list request may contain one or more explicit sequence numbers: blank target rows are filled, identical rows are idempotent, occupied differing rows require explicit replacement confirmation, out-of-range or duplicate sequences block, and every unspecified row is restored after the native `DaoRuDones` parser before the parent form can be saved. Immediate requery compares the complete post-merge passenger projection.
- Version `0.5.88` keeps Agent customer input at the business-keyword level. After exact and unique normalized-name matching fail, the ERP adapter may use all recognizable source-region tokens from the input, but only when those tokens identify exactly one current customer master; zero or multiple candidates still block before write. The shared-child form now reads the selected parent product from its native `tdid` row before enforcing product/customer source compatibility, and successful/non-applicable checks are no longer copied into an unrelated lookup failure's blocker list.
- Version `0.5.87` supplies a calendar-safe execution-day ±1-year date window only when an ERP list lookup has an exact order/group identifier but no dates. User-supplied dates remain unchanged. List filters are assigned without blur-triggered duplicate searches, and the adapter requires the exact native list AJAX request to start, complete, and return HTTP 2xx before reading rows, so a retained result from a previous filter cannot be treated as current evidence.
- Version `0.5.86` separates the plugin front gate from the strict execution gate. The plugin now accepts parse-state business facts, resolves exact ERP objects/resources/current values read-only, builds an internal execution operation, and validates that enriched state immediately before any native write. Platform task/session IDs, summaries, confirmations, and user messages stay outside the business operation.
- Version `0.5.85` embeds the complete 18-directive route/status contract and makes independent/hotel update adapters compare fresh current controls before dispatching any field event. A target that is already current is blocked before native submit with `write_attempted=false`; it is never presented as a server-confirmed write.
- Version `0.5.84` promotes two narrowly live-validated modifications: independent-order `twin_room_count` only, and one exact current `未确认` hotel row's `end_date` and/or `room_count`. Other independent fields, all non-hotel arrangement updates, and hotel resource/room-type/start-date/remark/status changes fail closed. The hotel adapter waits for native `update_CZR(0)`, restores the frozen test remark that callback clears, and rechecks every preserved field before submit.
- Version `0.5.68` accepts the native passenger-import dialog by one exact `daoru.asp` path plus `DaoruText` marker after route preparation has already proven the exact list row, edit-form `tid/ddid`, and dialog opener. The dialog itself does not consistently echo those refs; duplicate dialogs remain ambiguous and the adapter independently rechecks the opener before any save.
- Version `0.5.69` aligns guide-arrangement readiness with the native form's 12 successful controls. The form has 14 elements, while the submit button and unchecked `ap_dy` checkbox are intentionally absent from jQuery serialization; all eight named safety controls remain mandatory.
- Version `0.5.70` treats a reopened arrangement page as fresh only when ERP supplies a new same-origin `Document` with the exact `tdID`. ERP legitimately reuses the same URL, so URL history alone is not an identity signal.
- Version `0.5.71` closes only a stale arrangement dialog whose native form has the same route and exact `tdID`, waits for that document to disappear, then reopens the native entry. A dialog for another `tdID` blocks instead of being closed.
- Version `0.5.72` closes the exact native arrangement dialog after a successful server response and both subpage/team-summary requeries. Dialog cleanup is keyed by the form's exact `tdID` and never changes ERP data.
- Version `0.5.81` excludes auxiliary `about:blank` editor/calendar frames from lifecycle frame discovery. Those frames inherit the surrounding business URL and previously made a uniquely matched list action appear ambiguous; actionable ERP business frames must now have an explicit non-blank frame source (or be the top document).
- Version `0.5.80` keeps the audited operations 10—21 boundary and fixes three full-lifecycle defects found in the third/fourth real replays: shared-child receivable add/clear is a standalone operation that cannot mutate lodging notes; shared-child identity checks prefer the stable hidden `oldtdid`; and completed lifecycle edit dialogs are closed from the surviving top-page context only after exact reference plus fresh ownership requery, with bounded retry and iframe-detachment verification.
- Version `0.5.77` closes the independent-order ordinary-update contract after both plugin and native `SubmitInfoForm` probes returned HTTP 200 without persistence. `order_update_independent` now accepts only exact `clear_generated_zero` cleanup; planner, parser, Schema and browser adapter all reject ordinary fields.
- Version `0.5.76` makes shared-plan list cancellation verify every returned child through a fresh native child-detail GET and requires status `已取消` before the operation can complete. The propagation side effect is now part of the same durable operation result.
- Version `0.5.75` proves a previously open exact lifecycle edit dialog from its native form values as well as visible text before closing it. LTJT stores the test marker and operator in controls that are not necessarily rendered as body text; exact `tid/ddid`, marker, and AI owner are still all required.
- Version `0.5.74` safely closes a previously open exact lifecycle edit dialog only after matching its `tid/ddid`, `TEST-202609` marker, and AI owner, then reopens a fresh native document. Successful edit operations also schedule exact-dialog cleanup 1.5 seconds after returning verified evidence.
- Version `0.5.73` schedules exact arrangement-dialog cleanup 1.5 seconds after returning the verified lifecycle result, so Chrome can persist the server response and requery evidence before the ERP frame is destroyed.
- Version `0.5.67` makes shared-parent deletion prove child absence from the fresh native `SP_OrderList` response twice: once during preflight and again immediately at the write boundary. Any `OPEN_update(parentTid, childDdid)` reference blocks deletion even when an upstream boolean claims children were removed.
- The same version exposes a read-only ERP-session proof through the local platform bridge. Before confirmation, the runner now verifies that an ERP tab exists, contains the `测试ai员工账号` identity, and shows no login/permission boundary; it no longer needs a second DevTools attachment merely to read that guard.
- Version `0.5.66` resolves a shared-child export row by the native `OPEN_update(parentTid, childDdid)` ddid, then independently requires one exact `D<ddid>-...` child link. The generic group-number boundary deliberately treats `-` as part of an identifier and cannot match that child-link display format; export no longer falls back to unrelated links in the parent row.
- Version `0.5.65` extends the exact shared-child source-row stabilization window to 30 seconds after live evidence showed LTJT can populate the child row after the prior 12-second bound. The operation remains read-only and still fails closed if the exact child does not appear within that bounded window.
- Version `0.5.64` waits for the exact shared-child source row after the parent-plan Ajax result stabilizes. A live observation showed the parent row first and `D...` child content later in the same `tr_<tid>`; export now requires one stable parent and one stable child match before resolving source URLs, instead of treating that delay as a missing child.
- Version `0.5.63` applies the same deterministic `收客中` parent-plan filter to source-only shared-child export reconciliation. Export no longer inherits a stale plan-list status from a preceding cancel/restore operation; it still requires one exact parent row, one exact `D...` child row, matching tid/ddid, and ten source responses without download, conversion, save, or send side effects.
- Version `0.5.62` makes shared-child route preparation explicitly filter the parent-plan list to `收客中`. LTJT retains the previous plan-list status across operations; after restoring a parent, a stale `已取消` filter can otherwise hide that active parent. The parent filter is now deterministic, while the child's own `已确认/已取消` boundary remains independently proven on its fresh detail form.
- Version `0.5.61` treats a repeated open of the same ERP edit URL as fresh only when the browser supplies a new native `Document`. LTJT legitimately reuses an identical `plan_order.asp?tdid=...&ddid=...` URL after a child cancellation, so URL inequality is not a freshness proof; document identity plus the existing exact form/tid/ddid checks is.
- Version `0.5.60` proves a shared child's ownership with two independent native reads: the exact parent-plan list row must match the parent number, tid, marker, and AI account, while a fresh `plan_order.asp?tdid=...&ddid=...` detail response must match the child tid/ddid, marker, AI account, and exact child status. The parent list is never treated as if it contained a `D...` child row; child deletion likewise requires the detail form and marker to disappear while the allowlisted parent remains identifiable.
- Version `0.5.59` applies `transition.from_status` only when the list row and transition target are the same object. A shared-child edit is reached through its parent plan row, so the child's `预订/已取消` state must not be used as a parent-list filter; the child form still enforces the exact before-status before saving.
- Version `0.5.58` applies the transition status filter in `prepareExactLifecycleList`, the shared route used by cancel/restore edit preparation. The earlier status assignment was mistakenly placed in the passenger-import route and therefore never reached restoration; the corrected route now passes `from_status` to the proven native Ajax filter.
- Version `0.5.57` validates the exact native status option, writes its paired hidden value without synthetic DOM events, and calls the ERP's own `AjaxLoadData(true)` directly. This uses the same native callback as the menu while eliminating a click-binding race observed during repeated canceled-order restoration attempts.
- Version `0.5.56` additionally proves the ERP's jQuery click handler is attached to the exact status menu item before invoking it. This separates “Ajax function exists” from “native menu binding is live” and blocks at route preparation instead of silently searching the default status.
- Version `0.5.55` waits for the native list document, `AjaxLoadData`, and search bindings before driving a status menu, then verifies that `S_zhuangtai` actually changed. This closes the load-time race where a click issued before ERP scripts bound handlers was silently ignored and a canceled row appeared missing.
- Version `0.5.54` drives the ERP's native `.Menu2[setval]` status control during lifecycle route preparation instead of dispatching synthetic events on the hidden `S_zhuangtai` field. The menu callback performs the real Ajax reload and exposes canceled rows for exact edit-mode restoration; ambiguous or missing status options block before any save.
- Version `0.5.53` carries `transition.from_status` into the native list search's `S_zhuangtai` filter during exact route preparation. This is required to reopen a canceled independent order or shared plan for edit-mode restoration while preserving exact tid, identifier, date, and owner matching.
- Version `0.5.52` lets a receivable-only business update satisfy the fresh form-requery gate when there are intentionally no ordinary field changes. Identity, marker, account ownership, native success, and the full receivable absence contract remain mandatory; this enables read-only reconciliation of a successful `clear_generated_zero` save without another ERP write.
- Version `0.5.51` adds a fail-closed `clear_generated_zero` receivable prerequisite for current-run independent orders. It binds exactly the two persisted native row IDs for `成人团费` and `单人房差`, requires CNY zero price/amount, no payment, no review/settlement, exact AI-account ownership, and no additional active receivable rows, then uses the business edit page's native `GetYSHtml` and requires fresh absence before cancellation can proceed.
- Version `0.5.50` excludes the native search/filter row when resolving an exact lifecycle object on ERP list pages. The resolver now prefers native data-row evidence (`tr_<id>`, `xuanzeid`, or an exact row `ondblclick`) before the generic actionable-row fallback, preventing an echoed `S_tuanxuhao` plus `OPEN_update(0,0,0)` create control from making one real order appear ambiguous.
- Version `0.5.49` separates arrangement create and clear form-completeness baselines. A persisted hotel clear page is accepted at the live-observed 150 successful-control floor while still requiring every route field, a stable page, exact resource/row evidence, and zero financial/audit state; create keeps the stricter 195-field floor.
- Version `0.5.48` applies semantic-date comparison to the fresh `arrangement_other/clear` filing requery. A successful clear whose cost row is absent and whose unchanged filing date is rendered without leading zeroes now reconciles read-only instead of remaining uncertain.
- Version `0.5.47` applies the same semantic-date comparison to the second, post-mutation filing-preservation guard used by `arrangement_other/clear`, so a no-leading-zero ERP filing date is preserved and no longer produces a false write-before-submit blocker.
- Version `0.5.46` compares ERP arrangement and filing dates semantically (`YYYY-M-D`) while keeping exact row/resource/remark/financial guards. This accepts the ERP's persisted no-leading-zero dates without weakening the September target window.
- Version `0.5.45` requires a newly opened ERP edit-session URL for every lifecycle or arrangement write route. Existing matching dialogs are explicitly excluded, preventing a sequential task from preflighting against a previous save's stale in-memory form before the fresh server row IDs have loaded.
- Version `0.5.44` implements the business-page-only minimal receivable fixture for a shared child. It permits only one `其他费用 × 1 × CNY 0.01` test row with `paid=false` and `settled=false`, proves an empty unique slot before add, returns the fresh ERP `row_id`, clears only that exact row through native `GetYSHtml`, and requires row-id/remark/active-row absence after clear. It never enters the finance root or triggers payment/settlement.
- Version `0.5.43` parses ERP edit actions by route shape: `OPEN_update(parentTid, childDdid)` resolves the second argument for a concrete shared child, while independent `OPEN_update(ddid, 0, groupNo)` keeps the first. This prevents source-only child exports from replacing `ddid` with the parent `tid`.
- Version `0.5.42` applies the live-verified shared-child lodging-note boundary: one `append lodging_note` value and the resulting `zhusushuoming` field must both fit within 50 characters. A fresh-session native request persisted 50 characters with an explicit success response; the former 68-character replay value returned HTTP 200 with an empty response and did not persist.
- Version `0.5.41` makes lifecycle writes byte-shape compatible with the ERP page's native jQuery form serialization: submit/reset/file controls such as `DelButton` and `SubmitButton` are excluded, duplicate and multi-select values are preserved, `Act=<native action>` is placed first, and the request carries the native AJAX marker header.
- Version `0.5.40` verifies narrow update and edit-transition writes with two fresh sources: the exact edit form proves the changed field and stable tid/ddid, while the bounded business list proves the test marker, owner and optional target status. Edit forms that do not render list-only marker/account text no longer create a false uncertain result.
- Version `0.5.39` retries only deterministic pre-write transient blockers: a visible loading layer, an unstabilized form, or arrangement candidate data that has not arrived yet. Zero/multiple exact candidates, ownership mismatches, occupied slots and every other business blocker still fail immediately without a write.
- Version `0.5.38` treats a loading element as visible only when its rendered rectangle intersects the current viewport. This mirrors the ERP dialog library, which hides closed dialog loading text by moving it far off-screen, and prevents a complete arrangement form from being blocked by an unrelated closed dialog.
- Version `0.5.37` discovers the exact lifecycle iframe with a lightweight pathname/form/tid/ddid probe before injecting the heavy adapter, then runs preflight and reconciliation only in that unique frame. It also awaits every delegated executor before releasing the in-memory running-task lock, so pre-write recovery cannot race an execution that is still settling.
- Version `0.5.36` adds a second heartbeat in the active ERP tab's isolated extension world. It sends a keepalive message every five seconds while the worker owns an execution, and is removed in `finally`. It also adds an explicit pre-write recovery gate that can resume only the same durable execution while state is `running`, `no_erp_write=true`, and `write_attempted=false`; any later stage is refused.
- Version `0.5.35` adds a worker-local heartbeat during each accepted execution. Every ten seconds it calls a read-only extension API, resetting Chrome's MV3 idle timer even when the platform tab's content-script timers are background-throttled; the heartbeat is cleared in `finally` and never touches ERP.
- Version `0.5.34` fixes the keepalive dispatch envelope so the reserved port command `EXECUTE` cannot be overwritten by the platform-facing message type. The worker now receives and acknowledges the exact claimed execution before any ERP route preparation begins.
- Version `0.5.33` keeps one long-lived extension port open for each accepted ERP execution and sends a bounded heartbeat while the task is active. The MV3 worker therefore remains alive across slow native route preparation, while the platform still receives the acceptance immediately and continues polling the durable execution/result records.
- Version `0.5.32` makes native list-row identity robust to the ERP's table-cell text concatenation. Team-summary rows such as sequence `1` followed by `LW-...` are matched through the row's exact link/action/control evidence, then still subjected to the existing unique actionable leaf-row rule.
- Version `0.5.31` keeps the action-aware read-only create projection for all five arrangements and resolves guide linkage correctly across the ERP's two data sources: persisted values come from a fresh GET, while the exact phone/grade tuple comes from the asynchronously hydrated lookup on the already-routed live business frame. The fresh response is never assumed to contain client-side `data` attributes.
- Version `0.5.30` adds an action-aware read-only create projection for all five arrangements. Both immediate post-write verification and later manual reconciliation rebuild the expected resource, linkage, dates, quantities, status, remark, filing, and test-account fields from the original operation instead of relying on transient execution changes.
- Version `0.5.29` aligns arrangement team-summary reconciliation with the native `teams.asp` search form: it sends pagination, departure-date mode and range, publication unit, and exact team number. This keeps the summary read bounded to the current test team and allows an explicitly successful write with a matched subpage to converge through read-only reconciliation.
- Version `0.5.28` mirrors the ERP guide SelectBox's full deterministic linkage: the unique guide candidate supplies ID, name, phone, and grade together, while `daoguan` remains restricted to the exact test object's `existing_refs.owner_account`. This prevents the ERP from accepting the form but silently dropping an incomplete guide row.
- Version `0.5.27` adds the ERP-native guide-arrangement requirement discovered by live validation: `daoguan` is mandatory. The adapter derives it only from the exact test object's `existing_refs.owner_account`, proves that account is a unique candidate on the current business arrangement page, writes and rechecks it with the guide fields, and never opens or changes employee master data.
- Version `0.5.26` prepares every lifecycle target from exact business-list references before adapter preflight. Passenger import opens the exact independent/shared-child edit form and its native `DaoRuLie('全部','')` dialog; arrangements open the exact `data_tr_<tid>` child page; updates, transitions, and deletes open the correct list or edit route. After route preparation proves the exact target frame, preflight retries frame discovery for at most five seconds only while every blocker is a scope/page/form discovery blocker; any business blocker stops immediately. Arrangement refs still require independent-order `ddid` at the host/list boundary, while the native `teams*.asp` subpage identity correctly uses its actual `tdID`-only contract; the guide page's complete form contains 14 controls but 13 successful controls. Passenger readiness ignores hidden art-dialog loading placeholders after their iframe is complete and accepts matching native `tid/ddid` controls as the stable form identity proof. Exact-row selection only counts ERP business rows (`tr_<tid>`, `data_tr_<tid>`, or rows with native business actions), so retained art-dialog titles cannot create a false duplicate. Passenger reconciliation runs only in the one native `daoru.asp` frame, preventing identical GET evidence from unrelated upload/editor frames from being mislabeled as ambiguous. Shared-child links and bare-list response rows must have exact `D<digits>` identity followed only by the ERP's customer-name hyphen, whitespace, or end-of-text, while their `tid/ddid` references must also match. Ownership requery follows the native list form contract with `Act` in the request URL and `S_fabudanwei` in the form body, parses the ERP's bare `<tr>` response inside a table context, and uses stable numeric refs for fresh detail requery when the full business number is not rendered. The passenger projection uses the ERP's real `pinyinxm/fazhengri/youxiaori` controls plus route-specific document-number aliases (`zjhaoma` for independent orders and `haoma` for shared children), mirrors native whole-row whitespace removal and unpadded `YYYY-M-D` persistence for every relevant value, and treats `证件类型=护照` as an explicit non-persisted source constraint. A lifecycle write with an explicit success response but mismatched requery remains uncertain; an administrator can then run a same-operation, no-save fresh requery that may resolve the original execution without creating a second ERP write.
- Version `0.5.12` makes `shared_child_order_create` a first-class Skill route, preserves an explicit child test remark, requires the same `TEST-202609` marker when the parent is marked, waits for the asynchronous split-plan list row, cross-checks the exact parent `tid`, and waits for the concrete child reference during fresh requery. A missing or mismatched parent remains a read-only blocker.
- Version `0.5.11` keeps the 0.5.10 arrangement create/clear contract, applies an explicit host/business-system `order_number.suffix` only after product linkage and verifies exact persistence, makes the no-recognizable-product-region path consistently non-blocking, and fails closed when `receivable_fixture` requests add/clear before a fresh business-page adapter replay. Ordinary Agent output still does not invent group-number fragments or test markers.
- Version `0.5.10` keeps the 0.5.9 form-readiness and empty-slot guards and adds the real C08/C09 cleanup contract. Arrangement actions accept only `mode=create|clear`: create uses a proven empty slot 0; clear must re-match the same current-run resource, test remark, status/date/item/quantity, zero payment/audit state, and a non-guide native row ID. Clear completion requires an absence-aware fresh subpage requery plus the team summary requery; `arrangement_other` must preserve filing data. Arbitrary arrangement update remains blocked.
- Version `0.5.8` introduced the live-validated lifecycle v2 contract: exact owned-object references, complete canonical passenger projection checks, five action-specific arrangement mappings, one-field route-specific updates, from/to-status enforcement, edit-only restore, exact allowlist deletion, unique-row export reconciliation, and source-response SHA-256 evidence. After both ERP candidates resolve uniquely, the browser adapter also blocks when source-region tokens found in the selected product are absent from the selected customer source information; products without a recognized source token remain unaffected.
- Version `0.5.6` aligns scatter-plan creation with the ERP field matrix: required mother fields still block when missing, while supplied optional customer/passenger fields are independently validated and written; absent fields are left untouched.
- Version `0.5.4` makes scatter-plan and independent-team batch cycle selection use the same ERP rules: explicit dates select one `zhidingzhouqi` node per date, while daily/weekly/odd/even recurrence selects the native `zhouqi` shortcuts. Odd/even expansion now follows calendar dates, and all post-write reconciliation safety from `0.5.3` remains unchanged.
- Version `0.5.3` added post-write scatter-plan list reconciliation: when ERP returns an HTTP error after a write attempt, the plugin performs read-only per-date matching, returns any uniquely confirmed group numbers, and keeps missing/ambiguous dates in reconciliation pending without retrying the write.
- Version `0.5.2` added ERP-compatible product lookup for the three `lwlt-newbooking` routes: product-name/duration shorthands are matched locally from candidate rows, and native `S_chanpinming` is used only for an empty candidate reload. Every write still requires a server-issued execution ID.
- Reload the unpacked extension after upgrading. The business page refuses new ERP execution when the connected extension is older than `0.5.123`.
- Deleting a business task requests best-effort cancellation of its matching background task, removes the task card and stored bridge records, and hard-deletes the control-plane task. A browser/ERP action already in flight cannot be rolled back by deletion.
- New Agent operations must use the canonical standard operation shape: formal/dry-run, named-reference objects, sparse passenger/room objects where the business requires them, and no hidden fields. Lifecycle test actions additionally require the host-injected `TEST-202609` context; `shared_plan_create` carries optional child information only inside `split_order`.
- The single-order live submit uses the intercepted `DoInfoJH` payload hash; native batch uses the intercepted `DoInfoJHs` payload hash.
- If the actual submit payload hash differs at network-send time, the extension blocks the request.
- Split create has a guarded production adapter; export is read-only source fetch with `neverResave=true`.
- Lifecycle update, arrangement, transition, and traveler-import actions now have a guarded production execution path after platform confirmation and ERP unique resolution; unified business release still remains subject to the release gate. The current plugin whitelist is deliberately narrow: independent order `twin_room_count`, `rooms.SGL`, `rooms.TWN`, `pax.adult`, `pax.child_bed`, and `pax.leader` (the mapped room and passenger fields await a fresh authorized ERP run), shared plan `planned_capacity`, shared child `lodging_note`, and an exact `未安排` or `未确认` hotel row's `end_date`/`room_count`. A write is never successful without an explicit native response and fresh requery; uncertain writes stop without automatic retry.
- The ERP native traveler paste routine is not part of the production create contract; do not reuse it for production traveler data without a row-scoped import fix.
- Export recovery is `exportOnly`/`neverResave`; an export failure cannot route back into create-order.
- Traveler attachments stay as paths/metadata in the task; the extension does not silently open local workbooks or put traveler PII into audit output.
- The extension does not store account passwords or cookies.

## Notes

This is a browser-session adapter, not an official LTJT API client. It depends on the logged-in ERP page, the existing page JavaScript, and the current form field names.