LWLT-AIBOT/archive/project-history/2026-08-12/task_plan.full.md

LTJT Business Module API Research Plan

2026-08-10 — LianSyn-platform 正式化与持久登录

Goal: 将正式平台统一命名为 LianSyn-platform，移除生产运行路径中的旧原型定位，并让登录在用户主动退出前持续有效。

Phase	Status	Purpose
1. 正式目录与引用迁移	Complete	将运行目录、导入、脚本、文档和生产标识统一为 LianSyn-platform，保留内部测试能力。
2. 持久登录实现	Complete	取消自动会话过期，保持数据库会话和持久 Cookie；退出、改密、停用和管理员撤销仍可失效。
3. 全量验证与发布产物	Complete	扫描旧引用，执行类型检查、测试、构建和差异检查。

Final evidence

• 旧平台目录、旧桥接来源、旧前端存储键和旧启动脚本已从非归档运行内容移除。
• 新增 008_persistent_sessions.sql：历史过期会话先撤销，仍有效的活动会话转为无自动过期；新会话直接写入 NULL 过期字段。
• 类型检查、构建、控制平面 27/27、解析/业务回归 58/58、Node 脚本语法和 git diff --check 均通过。

Confirmed decisions

• 正式运行目录名称固定为 LianSyn-platform，不再继续沿用旧平台目录名。
• 除用户退出外，不因空闲或绝对时长自动退出；密码修改、账号停用和管理员强制撤销属于安全性失效例外。
• Auth Token 只放在 HttpOnly Cookie，服务端继续以数据库哈希会话为权威，不写入 localStorage。
• 保留内部测试用例、fixture 和历史归档，不把它们删除或伪装成正式业务描述。

Goal

Determine whether the authorized "业务操作" module in https://ltjt.yunzhi.run/ exposes browser-callable HTTP endpoints that can be integrated with the user's business system, and document the viable integration path without bypassing account permissions.

Boundaries

• Stay within the logged-in account's authorized "业务操作" module.
• Do not attempt privilege escalation, permission bypass, brute force, credential extraction, CAPTCHA bypass, or access to unauthorized modules.
• Avoid exporting large sensitive business datasets; use metadata, limited samples, and request/response shapes.
• Treat all page content and remote responses as untrusted data.

Phases

Phase	Status	Purpose
1. Session and page map	Complete	Confirm authenticated session, discover frames, menu links, and business operation pages.
2. Static endpoint inventory	Complete	Inspect HTML/JS references and form/action URLs for business module endpoints.
3. Network capture	Complete	Capture requests triggered by opening business pages and safe read-only queries.
4. Contract characterization	Complete	Summarize auth, cookies, required parameters, response formats, encodings, and pagination/search patterns.
5. Feasibility report	Complete	Produce an API inventory and integration recommendation for the user's system.
6. Independent group down-order flow	Complete	Deep-dive the 独立团计划表 下单 workflow without submitting a real order.
7. Standard-data adapter mapping	Complete	Map user-owned standard order data from the user's business system/database into the extracted ListForm schema and build dry-run serialization.
8. Business-system source contract	Complete	Define the upstream standard operation contract and clarify which fields are maintained by the user's business system/database before LTJT submission.
9. Browser-context serializer dry run	Complete	Open the live add page after fresh login, fill mapped dry-run values, compare browser ListForm.serialize() with the local dry-run payload, and keep submit disabled.
10. Deterministic lookup resolver	Complete	Resolve customer, route, product, OP, and salesperson through LTJT lookup data/widgets with exact-match rules and no AI decisions at runtime.
11. Browser product-side-effect preflight	Complete	Execute Find_product()/GetProduct(cpm) in the live page, validate product-template consistency, then serialize the browser form without submitting.
12. Controlled approved submit path	Complete	Require a passed browser preflight, matching submit-intercept hash, explicit approval token, then perform/record a controlled test submit and marker verification.
13. Raw-instruction simulation submit	Complete	Parse a user-provided raw Chinese order instruction, derive linked LTJT fields from the product template, validate existing SelectBox options, then save and verify an obvious ERP test order.
14. Chrome extension prototype	Complete	Package the validated browser-session workflow as a local Chrome MV3 extension that can be loaded unpacked.
15. LianSyn-platform task loop	Complete	Add the platform page that creates one ERP order task, hands it to the extension bridge, and displays plugin feedback.
16. Agent-backed platform parsing	Complete	Let the platform accept one raw instruction, call the configured external parser, and create task cards.
17. Unattended extension executor	Complete	Move normal business-user workflow out of the popup: task creation, ERP open/fill/save/verify, and result feedback now run through the background executor and business-system task cards.
18. Plugin state and operator control hardening	In Progress	Keep the popup as a minimal connection/status switch, propagate ERP-operation enable/disable state back to the business system, and harden reload/disconnection behavior.

Incremental Business-System and Browser-Plugin Absorption

Previous scope confirmed by user: the handoff-package absorption pass did not integrate an external Agent. The later external parsing refactor is tracked separately below and does not change the ERP/plugin boundary.

Phase	Status	Purpose
A. Baseline and boundary	Completed	Mapped handoff operations to root task cards, plugin message flow, and current browser executor without changing the external Agent path.
B. Business task model	Completed	Added operation-aware summaries, capability planning, export-type normalization, and safe no-write states for update/traveler/export/split workflows.
C. Browser operation routing	Completed (live proven subset)	Connected team-batch fallback to sequential team-single execution; added guarded live test-only adapters for split parent/child creation; added source-only confirmation export; kept order update and traveler import as read-only/dry-run routes where ERP persistence is not proven.
D. Verification	Completed	Completed authorized live tests through the business-system bridge and logged-in ERP, plus syntax checks, 12/12 operation-plan tests, schema validation, extension reload/PING verification, and ZIP integrity checks.
E. Live ERP evidence and safe blockers	Completed	Recorded created test groups/orders for manual cleanup and documented the remaining fail-closed blockers: order update returns HTTP 200 with an empty non-persisting response, and native traveler import has a phone-field mapping offset that was not saved.

External Agent Parsing Refactor (2026-07-12)

Scope confirmed by user: replace only the business-system input parsing path with the external Agent Profile Open API. ERP operations, browser automation, Chrome extension routing, and deterministic ERP validation remain out of scope.

Phase	Status	Purpose
1. Architecture confirmation	Complete	Confirm external-only parsing, preserved operation contract, task-isolated sessions, SSE transport, server-only credentials, external prompt ownership, and removal of local Agent terminology/endpoints.
2. Server adapter	Complete	Create one external session per task, send the raw instruction through SSE, collect the final JSON, normalize the existing operation contract, and expose /api/parse.
3. Business-system UI	Complete	Remove local model/prompt configuration and Agent wording; keep task creation and task-card behavior intact.
4. Contract/docs/tests	Complete	Add environment examples, parser transport coverage, error handling tests, and migration notes without storing the supplied secret.
5. Verification	Blocked by external prerequisite	Local syntax/tests/smoke checks pass. Real authentication/session/SSE pass, but the current published Profile returns a generic response instead of the required operation contract and must be republished/configured externally.

UI observability refinement

• The business page now renders an immediate parse_sending response before waiting for /api/parse.
• The right-side task detail shows the external request stage, SSE event count, session-created flag, error code, and formatted technical JSON; secrets are not displayed.
• Local connection failures and unexpected task-creation exceptions are persisted as task-card failure states instead of leaving a task in an ambiguous running state.
• A real in-scope business-input test reached the external Profile and completed SSE, but the Profile returned skill_error:ltjt_business_operation; this is an external Skill/Profile prerequisite, not a local transport failure.

External refactor verification notes

• The real Open API key was loaded only from the user's private environment file for smoke calls; it was not printed, persisted, or copied into the workspace.
• Real SSE events use metadata, values, repeated messages, and end; assistant output arrives as AIMessageChunk entries inside messages arrays.
• The current token's published Profile returned generic JSON keys such as reply, intent, missingFields, nextStep, profileSuggestion, keyInfoSuggestions, citations, and riskFlags. The adapter returns external_result_contract_mismatch rather than inventing an order operation.

External refactor errors

Error	Attempt	Resolution
Port 8765 already in use	Started the refactored server on its documented default port for smoke testing	Retested on port 18765 without touching the existing process; the refactored server started and passed local smoke checks.
First SSE collector returned no JSON	Assumed the sample event names were message.delta; the real stream emitted messages arrays with AIMessageChunk items	Added event-shape inspection, assistant-chunk aggregation, and regression tests.
Published Profile output did not match operation contract	Ran real parser smoke calls with a synthetic test instruction	Added a deterministic contract-mismatch blocker and documented that the external Profile must be published with the agreed standard operation output.

2026-07-12 — Task deletion and cancellation

Goal: add a delete action in the right task panel, remove the top-level clear/feedback controls, and cancel the matching extension task before removing its business-system card and logs.

Phase	Status	Purpose
1. UI action surface	Complete	Added right-panel delete action; removed top clear/feedback controls and their event bindings.
2. Bridge cancellation	Complete	Added single-task delete/cancel bridge handling and removed matching stored task data, including batch child IDs.
3. Executor cancellation	Complete	Added cancellation flags, phase-boundary guards, and cancellation-aware result writes.
4. Verification	Complete	Syntax checks, 12/12 operation-plan tests, focused cancellation assertions, local HTTP load, and ZIP integrity all pass.

2026-07-12 — AI workbench header refinement

Goal: replace the old header titles with the supplied 联新旅行社平台 logo and a stretched horizontal menu whose active item is AI操作台; keep AI/plugin connection indicators at the far right as clickable status tags.

Phase	Status	Purpose
1. Header structure and asset	Complete	Add the supplied logo, remove old titles, and make AI操作台 the active horizontal menu item.
2. Status tag refresh	Complete	Keep AI/plugin tags at the far right; clicking each tag refreshes its own probe, with only green 已开启 and red 未连接 states.
3. AI connectivity probe	Complete	Add a no-session external API authentication/reachability probe and periodic frontend refresh instead of checking only local Key presence.
4. Verification	Complete	Pass syntax, 13 external parser/HTTP tests, header structure, API, asset MIME, and page-resource checks.

2026-07-12 — Three-stage project status UI

Goal: add a clear stage indicator above the right-side task log so operators can distinguish Agent parsing, business-system execution, and ERP receipt acquisition at a glance.

Phase	Status	Purpose
1. Status mapping	Complete	Map existing task/result statuses and receipt data into the three requested stages and sub-statuses.
2. Right-panel UI	Complete	Render the three large stages above the terminal-like log without removing existing task details/actions.
3. Verification	Complete	Check empty and failed states in a real browser, plus syntax, structure, style, and resource loading.

2026-07-12 — Confirmation action relocation

Goal: move the manual confirmation action from each left task card into the selected task's right-side detail header while preserving the existing confirmation-to-handoff behavior.

Phase	Status	Purpose
1. Action relocation	Complete	Remove the card-level confirmation button and add 确认执行 beside the selected task state and delete action.
2. Lifecycle wiring	Complete	Keep the existing confirmTask() path and show the button only while the selected task requires manual confirmation.
3. Verification	Complete	Pass syntax and static assertions; verify the right detail action surface loads without reintroducing the card button.

2026-07-12 — Input area copy refinement

Goal: simplify the left input panel labels to match the approved UI wording.

Phase	Status	Purpose
1. Copy update	Complete	Rename 原始指令 to 输入区域, remove 编辑发送区, and rename the action button to 创建任务.
2. Verification	Complete	Pass JavaScript syntax, static assertions, and served-page marker checks.

2026-07-12 — Separate task logs and return JSON

Goal: keep the right-side process log separate from the returned JSON so parser, plugin, and ERP response data remains visible.

Phase	Status	Purpose
1. Root-cause confirmation	Complete	Confirmed the detail panel only rendered task.logs; structured responses were not displayed.
2. Response persistence and UI	Complete	Persist the full parser response and render independent black log/JSON panels, while masking sensitive keys.
3. Verification	Complete	Passed syntax checks, 13/13 parser/HTTP tests, extension syntax checks, and static UI resource smoke checks.

Errors Encountered

Time	Error	Attempt	Resolution
2026-07-07	In-app browser navigation timed out	Tried opening the site in the Codex in-app browser	Switched to a dedicated temporary Chrome profile on port 9223.
2026-07-07	CDP helper defaulted to the user's main Chrome port	Tried cdp.mjs without a matching DevToolsActivePort file	Use direct 127.0.0.1:9223 DevTools JSON/WebSocket for the temporary collaboration window.
2026-07-07	Reloading System/Mainlt.asp returned to login page	Used network capture with Page.reload	Avoid main-page reload while researching; ask user to log in again before interactive capture. Static map from the authenticated page was saved before logout.
2026-07-07	Direct dat endpoint fetch returned login-timeout script	Tried safe fetch probes with future/no-match filters after the session had become unstable	Treat dat endpoints as session/page-context sensitive. Need fresh login and natural page-triggered XHR to capture successful response-body structure.
2026-07-07	CDP port 127.0.0.1:9223 was offline	Tried a read-only target probe before browser-context dry run	Browser comparison tool is prepared, but live ListForm.serialize() comparison requires reopening/logging into the collaboration Chrome window.
2026-07-07	Browser dry run reused a stale/partially loaded form	Initial reruns returned 878 fields, then 102 fields	Updated tools/browser_order_add_dry_run.mjs so --open-form forces a fresh URL timestamp and waits for the full ListForm before filling.
2026-07-09	MiniMax model connectivity returned HTTP 401	Tested the configured OpenAI-compatible chat endpoint and key diagnostics	Switched to the MiniMax China endpoint https://api.minimaxi.com/v1/chat/completions; kept key diagnostics redacted and documented provider hints.
2026-07-09	ERP appeared to stay loading after successful save	Live save succeeded but ERP remained on the order-entry frame with a loading overlay/success state	Changed the extension flow to return the ERP order-entry frame to the independent-order list after verification, filtered by departure date and test marker.
2026-07-09	Popup/business-system connection state diverged	Business page saw the bridge but popup still reported not connected, especially after extension reload	Simplified popup to a status-only panel, added bridge ping, propagated erp_automation_enabled, and added v0.2.12 context-invalidated reinjection handling.
2026-07-09	Multi-browser expectation mismatch	Asked whether business system and plugin can run across different browsers/profiles	Current MV3 bridge only works inside the same browser profile. Multi-browser support requires a local bridge hub service or shared backend queue.
2026-07-12	Planning-file append patch context mismatch	First append used an outdated historical line	Re-read file tails and appended the new phase with verified context.

2026-07-12 — Project development and maintenance standard

Goal: create one project-level standard that tells business maintainers when to update the Agent Prompt, unified Skill, operation Schema, ERP control scripts, tests, packages, and cloud Profile.

Phase	Status	Purpose
1. Repository and handoff review	Complete	Compare the root Agent/ERP design, current operation contract, ERP form/mapping, scripts, and handoff package boundaries.
2. Standard document	Complete	Create 开发维护规范.md with the command registry, ownership rules, Skill-first workflow, ERP script gates, test matrix, and maintenance checklist.
3. First-line command protocol	Planned	Enforce an exact first non-empty input line before invoking the Skill; unknown or missing commands must block.
4. Per-business implementation	Planned	For each command, complete the Skill reference first, then the operation Schema/mapping, ERP control script, fixtures, and evidence.
5. Release and cloud synchronization	Planned	Rebuild the portable .skill package and republish the cloud Prompt/Profile together after contract changes.

Production Architecture Hardening — Confirmed Scope (2026-07-12)

User confirmation: retain LTJT as the initial external operational source of truth and harden the surrounding platform architecture only. Do not add new business capabilities or alter the existing business workflow in this pass.

In scope

• Durable backend API and database foundation for existing tasks, standard operations, execution state, audit evidence, and plugin coordination.
• Reliable task execution boundaries: idempotency, retries with uncertainty handling, durable state transitions, recovery, and post-operation reconciliation.
• Authentication/authorization, secret handling, tenant or organization isolation as confirmed, observability, deployment, backup, and operational checks.
• Production plugin runtime governance while keeping the current Chrome extension as the LTJT browser-session adapter.

Out of scope

• New ERP business routes, new screens, new order capabilities, or changing the existing operation contract.
• Replacing LTJT as the primary ERP or performing a big-bang data migration.

Status

Architecture decisions were confirmed by the user; implementation is underway.

2026-07-12 — Repository cleanup audit

Goal: separate the current external-Agent/ERP adapter source from stale handoff material, validation evidence, generated artifacts, and planning history before any destructive cleanup.

Phase	Status	Purpose
1. Inventory and reference scan	Complete	Counted root areas, checked current references to 交接包/, inspected stale paths, runtime artifacts, generated packages, and missing repository controls.
2. Classification proposal	Complete	Classified active source, reusable legacy knowledge, historical evidence, generated distribution files, and disposable runtime residue.
3. Non-destructive manifest	Complete	Added the root entry map, archive manifest, and explicit source-of-truth/retirement status.
4. Archive and quarantine	Complete	Archived the reusable handoff source and deleted confirmed runtime/report residue.
5. Active-doc consolidation	Complete	Added the root README, reconciled stale report references, and kept planning logs in place for continuity.
6. Repository hygiene gate	In Progress	Added root ignore rules and release/output conventions; periodic stale-artifact review remains future maintenance.

2026-07-12 — Cleanup execution scope

• Preserve active source and contracts in place: agent设计规范/, schemas/, mappings/, tools/, chrome-extension/, LianSyn-platform/, samples/, and current maintenance documents.
• Move 交接包/ to archive/handoff/2026-07-12/legacy-erp-handoff/ as read-only compatibility reference.
• Delete the handoff runtime, diagnostics, generated output, temporary health files, root validation reports, and .DS_Store files because current runtime does not depend on them and the user authorized removal of historical material without dependencies.
• Move the current extension ZIP to dist/; generated packages are release artifacts, not source.
• Keep task_plan.md, progress.md, and findings.md in the root for planning continuity; do not treat their historical sections as active contracts.

2026-07-12 — Cleanup execution result

• Root README.md, .gitignore, archive/README.md, dist/README.md, quarantine/README.md, and reports/README.md were added.
• 交接包/ was moved to archive/handoff/2026-07-12/legacy-erp-handoff/; reusable legacy source remains available as read-only reference.
• Handoff runtime/diagnostics/tools-runtime content, root JSON/TXT reports, and .DS_Store files were removed.
• chrome-extension/ltjt-order-assistant.zip was moved to dist/ltjt-order-assistant.zip.
• Final local gates passed: 25 Node tests, JavaScript syntax checks, four JSON parses, Skill validation, and ZIP integrity.

Confirmed deployment boundary

• Phase one is a single-company, single-tenant private deployment.
• The schema and authorization boundaries should reserve organization isolation fields, but full SaaS multi-tenancy, tenant billing, and cross-organization operations are out of scope.

Confirmed runtime topology

• Use a centralized backend and database as the durable control plane.
• Keep the Chrome extension as an authenticated browser-session Worker: it claims existing tasks, executes the already-defined ERP operation, and reports progress/evidence.
• The browser UI and extension-local storage are caches/transport state only, not the authoritative task store.
• The service should be deployable on Linux/Docker with HTTPS; a persistent connection may use WebSocket with polling fallback.

Confirmed persistence baseline

• PostgreSQL is the authoritative application database.
• Store task lifecycle, standard-operation snapshots, execution attempts, idempotency records, audit evidence, and plugin leases transactionally.
• Redis, if introduced later, is limited to ephemeral cache/locks/transport acceleration and is never the source of truth.

Confirmed identity direction

• Do not integrate enterprise OIDC/SSO in phase one.
• Add native platform account login as a required production foundation.
• The implementation must include password hashing, session/token lifecycle, logout/revocation, authorization checks, login-rate protection, and security audit events; exact account provisioning and recovery policy remains to be confirmed.

Confirmed account provisioning

• Accounts are administrator-created or administrator-invited; public self-registration is disabled.
• The first administrator is created through a one-time deployment/bootstrap flow.

Confirmed phase-one authorization scope

• Phase one has one human role: administrator with full platform permissions.
• Do not build multi-role RBAC or granular business-user permissions in this pass.
• The extension remains a session-bound adapter and does not receive an independent human or service-account credential.

Confirmed plugin identity simplification

• Do not add plugin registration, pairing codes, or independent plugin credentials in phase one.
• The extension operates only inside the administrator's already-authenticated browser/ERP session.
• The extension is treated as a session-bound adapter, not as an independently managed user or service account.

Confirmed human session model

• Administrator login uses a server-side session with a secure, HttpOnly, SameSite cookie.
• Session rotation, idle/absolute expiry, CSRF protection, logout/revocation, and audit events are required.
• Long-lived administrator JWTs must not be stored in browser local storage.

Confirmed authentication exclusions

• MFA is explicitly out of scope for phase one.
• Compensating controls remain required: strong password policy, login rate limiting/temporary lockout, secure session controls, audit events, and a controlled password-recovery path.

Confirmed execution safety invariant

• Preserve the existing execution chain: preflight/dry-run, explicit administrator confirmation, one submit attempt, then ERP re-query.
• An uncertain transport or ERP result enters a pending-reconciliation state; the system must not automatically retry or create a replacement order.

Confirmed production data initialization

• Initialize the production PostgreSQL database from a clean schema migration.
• Do not migrate prototype browser storage, extension cache, historical reports, or test-order records into production.
• Preserve only the required schema, configuration structure, and standard-operation contract definitions.

Confirmed environment policy

• Deploy directly to the production private environment; do not create a separate staging environment in this pass.
• Use offline/static verification, default no-write behavior, explicit confirmation, migration prechecks, and database backups as the release safeguards.

Confirmed backup baseline

• PostgreSQL backups are mandatory and automated.
• Create an additional backup before every schema/data migration.
• Store backups independently from the primary database and verify the restore procedure periodically.

Confirmed observability baseline

• Provide structured, redacted application logs and health checks for the service, PostgreSQL, backup process, task execution, plugin connectivity, and ERP reconciliation.
• Alert on service/database failure, backup failure, stuck tasks, plugin disconnects, and uncertain ERP outcomes.
• Do not add a third-party monitoring platform in phase one; emit logs/health signals through the private deployment environment.

Confirmed secret handling baseline

• Inject production secrets only through protected deployment-host secret files, Docker Secrets, or equivalent environment injection.
• Database credentials, external API keys, session-signing keys, and ERP session material must not be committed, baked into images, logged, persisted in the database, or exposed to frontend/extension storage.
• Secret rotation is a controlled server-side maintenance operation.

Confirmed password recovery

• Password recovery is server-side and operator-controlled through a deployment/administration script.
• Do not add email self-service recovery in phase one.

Recommended technical implementation baseline — awaiting final confirmation

• Runtime: production TypeScript control plane on Node.js with Fastify, Zod contract validation, Pino structured logs, and explicit SQL migrations using node-postgres; preserve the current ESM scripts and business contracts.
• Service boundary: keep the existing Agent/Skill/schema/mapping/ERP adapter chain; add only the durable control-plane API, authentication, task persistence, execution state, audit, and transport needed to replace browser-local authority.
• Database: PostgreSQL only. Use transactional task claiming with row leases/FOR UPDATE SKIP LOCKED, a durable task-event/outbox table, idempotency records, attempts, and reconciliation states. Do not add Redis in phase one.
• Transport: same-origin REST for commands plus Server-Sent Events with polling fallback for task/status updates. The browser bridge remains the transport boundary to the session-bound extension.
• Data model: include organization isolation fields, users, sessions, tasks, task events, attempts, idempotency keys, audit events, browser-session/plugin connection heartbeats, and configuration metadata; do not create new business entities or routes.
• Authentication: native administrator login, Argon2id password hashing, server-side hashed session tokens, HttpOnly/Secure/SameSite cookies, CSRF protection, rate limiting/temporary lockout, bootstrap/reset CLI, no public registration, no MFA.
• Data protection: raw instructions and sensitive operation snapshots are encrypted or field-redacted at rest; logs contain only redacted summaries and hashes. Retention is configurable with a conservative default and a scheduled cleanup job.
• Deployment: Linux Docker Compose with the control plane, PostgreSQL, HTTPS reverse proxy, and backup job; no staging deployment and no third-party monitoring platform.
• Release gates: offline/static tests, disposable local database migration smoke tests, clean production initialization, pre-migration backup, no-write default, explicit administrator confirmation, and post-submit ERP re-query. No automatic retry for uncertain writes.

Final confirmation gate

User confirmed the consolidated scope and technical baseline; implementation is authorized. Remaining gates are target-environment PostgreSQL migration, backup/restore verification, and final production smoke checks.

Implementation progress — architecture hardening (2026-07-12)

Phase	Status	Result
Control-plane scaffold and migrations	Complete	Added root Node/TypeScript package, PostgreSQL schema, encrypted fields, migration runner, and health endpoints.
Admin authentication	Complete	Added native admin login, Argon2id hashes, revocable server sessions, CSRF, login rate limiting/lockout, bootstrap/reset CLI, and no public registration.
Durable task API	Complete	Added task creation, idempotency, parse leases, confirmation, browser claim, result persistence, cancellation, audit, outbox, SSE, and polling-compatible list endpoints.
Existing UI/adapter wiring	In progress	The operator page now uses backend task APIs and login; the extension remains a session-bound adapter and release package is rebuilt.
Production operations	Complete	Added Docker Compose, HTTPS reverse proxy, protected env template, backup/restore scripts, retention job, predeploy gate, and runbook.
Final verification	Pending target environment	Local static/type/legacy tests, dependency audit, health/static smoke, and ZIP integrity pass; PostgreSQL migration, administrator bootstrap, backup/restore, and Compose smoke require the target Linux production environment.

2026-07-13 — Automatic environment loading

Goal: make local control-plane and parser startup load project-local environment configuration automatically, without requiring the operator to export variables manually.

Phase	Status	Purpose
1. Startup-path audit	Complete	Confirmed the 8765 parser service and 8786 control plane use separate startup paths; control plane was running without DEERFLOW_* configuration.
2. Project env and scripts	Complete	Added ignored project-local env configuration and made development, production, migration, admin, retention, and adapter-start commands load it.
3. Service restart and status verification	Complete	Restarted the control plane through the new project command and verified database readiness, login route, and AI connectivity.
4. Regression gate	Complete	npm test passed all 25 tests; project startup logs and health endpoints verified.

Production note: replace the ignored root .env or inject equivalent protected deployment variables; do not commit the actual file or its API key.

Implementation progress — parse stall hardening (2026-07-13)

Area	Status	Result
Agent transport safety	Complete	Read-only health probe, 30-second cache, 180-second total parse budget, terminal SSE/[DONE] handling, and regression tests.
Parse lease safety	Complete	Same-process active-task exclusion, durable parse_running message, lease-owner guarded result persistence, and stale-result rejection.
Runtime verification	Complete	Typecheck, build, 26 tests, service restart, database readiness, and Agent health endpoint checks passed.
Existing stuck task	Intentionally not retried	The task was already cancelled during diagnosis; no new business task was created without an explicit operator request.

2026-07-13 — Delete task visibility fix

Goal: make the right-side “删除任务” action visibly remove the selected task while retaining its cancellation record for audit.

Phase	Status	Purpose
1. Root-cause diagnosis	Complete	Confirmed cancellation succeeded, but the default task list returned cancelled rows and the SSE refresh re-added the card.
2. Active-list filtering	Complete	Exclude cancelled tasks from the default server list and add a frontend defensive filter for stale/SSE responses.
3. Verification	Complete	TypeScript check, full 26-test suite, build, served-resource assertion, and live/ready health checks pass after service restart.

2026-07-13 — Parse reliability and end-to-end completion

Area	Status	Evidence
Persistence root cause	Complete	Real Agent returned; PostgreSQL 22P02 identified the empty system actor UUID and the boundary is fixed/tested.
Worker lifecycle	Complete	Durable attempts, 240-second watchdog, propagated cancellation, 10-minute lease, no automatic expired-task replay, and stale-result guard.
Agent transport	Complete	Real session and SSE stream completed; one attempt produced agent_parse_passed and a valid dry-run operation.
Backend state machine	Complete	Authenticated no-write verification passed through confirmation, browser claim, result persistence, terminal lease release, events, and audit.
UI/SSE pressure	Complete	Event cursor and refresh coalescing remove initial history-replay request storms.
Production database	Complete	Migrations 001-003 applied; no active/expired parse rows, running attempts, terminal leases, duplicate attempt keys, or lock waits.
Final verification	Complete	27 tests, build, syntax checks, 0 dependency vulnerabilities, compiled runtime, health/readiness, Agent authentication evidence, and extension heartbeat pass.

2026-07-13 — ERP dispatch idempotency and receipt recovery

Goal: eliminate repeated ERP execution after page refresh/reconnect and ensure a claimed task continues collecting its final plugin result without automatic resubmission.

Area	Status	Result
Incident containment	Complete	Stopped the old control-plane process before diagnosis; task TASK-20260713103736-9tLJa4w is now reconciliation_pending, has no lease, cannot be deleted/reclaimed, and was not rerun.
Server dispatch authority	Complete	Claim now precedes plugin delivery, accepts only the first confirmed transition, creates one durable ERP attempt/execution ID, and returns duplicate same-owner claims as claimed=false.
Result integrity	Complete	Plugin results require connection and execution IDs, repeated identical results are idempotent, terminal states are immutable, expired execution leases enter reconciliation, and post-write uncertainty cannot become retryable.
Operator-page behavior	Complete	Removed automatic handoff on refresh/bridge-ready/heartbeat and removed “重交”; refresh only polls active claimed tasks until a terminal result. Old extension versions are blocked before confirmation.
Extension execution guard	Complete	Version 0.3.1 persists task/execution acquisition atomically, blocks replay after service-worker restart, records write_started before ERP mutation, and converts post-write failures to uncertainty.
Production rollout	Complete	Created and checksum-verified a pre-migration backup, applied migration 004_erp_execution_idempotency, rebuilt/reloaded the extension, restarted the compiled server, and verified health/readiness.
Verification	Complete	30/30 tests, build, JS syntax, ZIP integrity, 0 dependency vulnerabilities, transactional duplicate-index proof, isolated no-write lifecycle proof, and live browser refresh proof all pass.

2026-08-05 — Task-scoped Agent session continuation

Goal: persist one Superagent session per business task, support recoverable missing-input turns, resume tasks through a generic message API, and leave ERP/plugin execution unchanged.

Phase	Status	Purpose
1. Baseline and contract alignment	Complete	Preserve existing user changes, add the agent_parse_needs_input result contract, and keep the complete operation schema unchanged.
2. Durable task/session model	Complete	Add encrypted Agent session/message tables, conversation matching indexes, lifecycle states, legacy backfill, and terminal cleanup hooks.
3. Task message API and worker continuation	Complete	Add authenticated message ingestion, task matching, idempotency, status transitions, and parser-worker continuation.
4. Superagent adapter and recovery	Complete	Reuse stored session IDs, create per-turn keys, and perform at most one safe session rebuild.
5. Operator UI and verification	Complete	Show missing fields/questions, accept replies, update docs, and pass the full test/build gates.

Implementation decisions

• agent_parse_needs_input is a non-terminal parse result with operation: null, missing_fields, questions, and captured_facts.
• A caller-provided task_id wins; without it, exactly one pending task in the same conversation may be matched automatically. Multiple matches return task_selection_required; no match creates a new task.
• Full user/assistant message rounds are encrypted in the business system. A missing external session is rebuilt at most once; ERP/plugin work is never replayed.
• This pass updates local Skill/contracts/adapter/UI only. WeChat and online Profile publication remain follow-up integration work.

Verification result

• TypeScript check and build passed using the workspace-bundled Node/TypeScript runtime.
• Control-plane tests: 10 passed; legacy/external Agent/ERP tests: 43 passed.
• JavaScript syntax checks, JSON Schema parsing, migration marker checks, and git diff --check passed.
• PostgreSQL migration execution and online Profile publication were intentionally not performed in this code implementation pass.

2026-08-05 — Login session persistence fix

Phase	Status	Purpose
1. Session diagnosis	Complete	Confirmed active durable PostgreSQL sessions and isolated browser initialization/origin/caching risks.
2. Persistence and refresh fix	Complete	Added explicit persistent Cookie expiry, no-store auth responses, and a session-recovery loading state before showing the login form.
3. Runtime verification	Complete	Rebuilt, restarted the 8786 control plane, verified health/AI status, auth no-store headers, served cache-buster, and all regression tests.

Final behavior

• The session token remains HttpOnly and server-validated; it is not copied to localStorage.
• Login now sends both Max-Age and Expires, matching the server's absolute session TTL.
• On refresh, the page first checks /api/auth/me and only shows the login form after that check fails.
• The authenticated control plane is documented at http://127.0.0.1:8786/; port 8765 remains parser-only.

2026-08-05 — Login refresh false-logout diagnosis complete

• Runtime logs proved /api/auth/me and /api/auth/csrf returned 200 after refresh; the apparent logout was caused by /api/tasks returning 500 because migration 005_agent_task_sessions had not been applied.
• Applied the pending migration to the configured PostgreSQL database; agent_sessions and agent_session_messages now exist and task listing returns 200.
• Split session restoration from task synchronization in the page so a database/task-list error cannot hide an otherwise valid authenticated workbench.
• Added canonical redirects for non-standard static hosts and a 8765-to-8786 operation-console redirect.

2026-08-05 — Manual Agent-to-ERP handoff boundary

Goal: keep Agent parsing automatic, require one explicit operator action after the Agent response to confirm and submit the operation to the ERP plugin, and retain the plugin's internal automation switch for preflight, form filling, submit, and verification.

Phase	Status	Purpose
1. Current-flow alignment	Complete	Confirmed the existing server/UI/plugin transition and identified misleading handoff labels; no hidden automatic handoff path needs to be added.
2. Manual boundary implementation	Complete	Made the single operator action explicit, preserved durable confirmation/claim/idempotency behavior, and avoided adding a second confirmation gate.
3. Regression verification	Complete	Source tests, TypeScript check, build, JavaScript syntax, static UI assertions, and diff checks all pass.

Final behavior

• User clicks 创建任务 to enqueue the raw input; Agent parsing remains automatic.
• When the structured result returns, the selected task shows one action: 确认并提交到 ERP 插件.
• That action confirms the Agent result, obtains the single server-side ERP execution ID, and hands the task to the plugin.
• After handoff, the plugin continues its existing automation according to the ERP automation switch: preflight, form filling, submit, and verification.
• No refresh, SSE event, bridge reconnect, or polling path submits the task automatically.

Errors encountered in this phase

Error	Attempt	Resolution
TypeScript test source imported missing control-plane/src/*.js files	Ran the test source directly with Node before compiling	Use the repository's build/test entrypoint so TypeScript is compiled before tests run.
Compiled dist tests could not find migration/static fixture files	Ran node --test dist/control-plane/test/control-plane.test.js after build	Use the supported source test entrypoint with tsx; the current build intentionally emits TypeScript runtime files only and does not copy non-code fixtures.

2026-08-05 — Clickable AI and plugin diagnostics

Goal: make the top-level connection indicators reflect transport reachability, and let operators inspect safe diagnostic details and rerun checks without exposing secrets.

Phase	Status	Purpose
1. Status semantics and baseline	Complete	Confirm AI reachability and plugin bridge response as the primary connected states; keep auth/version/automation as diagnostic or warning details.
2. Backend AI status contract	Complete	Return transport-based ai_connected while preserving authentication evidence and timestamps for diagnostics.
3. Frontend diagnostic popover	Complete	Add accessible AI/plugin detail popovers, safe fields, failure reasons, timestamps, and manual recheck actions.
4. Verification and restart	Complete	Run focused/full tests, rebuild, restart the control plane, and verify live status resources.

Confirmed scope

• AI is green when the control plane/database is ready, AI configuration exists, and the external health endpoint is reachable; historical authentication evidence does not gate the primary connection state.
• Plugin bridge response is green; an outdated version or disabled ERP automation is a yellow connected warning; only missing/failed communication is red.
• Clicking a status button opens a lightweight dismissible detail popover with safe diagnostics and a recheck action.
• API keys, raw session IDs, and other sensitive transport values must never be rendered.

Errors encountered

Error	Attempt	Resolution
Planning-file append context mismatch	Tried one multi-file append using a heading absent from progress.md	Re-read each file tail and appended against its actual final context; no source change was made by the failed patch.
Port remained occupied during restart	Terminated the old listener and expected a short empty-port window	The existing service supervisor immediately launched the new process; verified the new PID/start time and live contract instead of starting a duplicate.
Final resource-check command had an unmatched shell quote	Used a double-quoted regex containing an unescaped quote	The shell stopped before executing checks; rerun with a single-quoted regex.

Verification result

• TypeScript check/build, JavaScript syntax, git diff --check, control-plane tests 11/11, and legacy/external/ERP tests 43/43 pass.
• Runtime PID 70360 serves /api/status with ai_connected=true, ai_connection_basis=service_reachability, database ready, configuration present, and upstream reachable.
• Browser interaction verified AI and plugin detail dialogs, safe diagnostic copy, manual recheck controls, aria-expanded, and Escape dismissal.

2026-08-05 — Remove operator reply panel

Goal: remove the large missing-input interaction panel from the operator page while preserving backend task-session continuation for future API/channel integrations.

Phase	Status	Purpose
1. UI and persistence diagnosis	Complete	Confirm the panel is the local /api/messages client and identify the blank operation summary that incorrectly enables ERP confirmation.
2. Frontend removal and guards	Complete	Remove reply markup, styles, state, handlers, and request code; keep missing fields visible in logs/JSON and block ERP confirmation.
3. Backend null-operation fix	Complete	Persist and expose null for NEED_INPUT/blocked operations, including compatibility for existing rows.
4. Verification and restart	Complete	Run regression tests/build, restart 8786, and verify the panel/button are absent for the existing waiting task.

Verification result

• TypeScript check/build, JavaScript syntax, git diff --check, control-plane tests 11/11, and legacy/external/ERP tests 43/43 pass.
• Runtime PID 74979 serves cache-busted UI resources with no reply-panel markup.
• The existing task TASK-20260805093120-JNXZSdM remains awaiting_user_input, exposes operation: null, and retains its diagnostic input_request for logs/JSON and future API channels.

Confirmed scope

• Remove only the operator-page reply UI; retain agent_parse_needs_input, encrypted session/message storage, and /api/messages.
• Missing fields and questions remain observable through process events and returned JSON.
• Waiting-input tasks cannot be confirmed or handed to ERP.
• Normal successful parse and ERP confirmation behavior is unchanged.

Errors Encountered

Error	Attempt	Resolution
Existing working-tree changes overlap the external Agent adapter and operator UI	Baseline inspection	Preserve the user's existing security/reliability changes and layer task-session work on the current files.
Planning-file append context mismatch	First attempt to append the parser-rules phase	Re-read the current file tails and append against the active final context.
node/npm unavailable in the shell PATH	Initial JSON and regression validation	Loaded the bundled Node runtime and ran TypeScript/tests with explicit runtime paths.
Skill quick validator could not import yaml in the bundled Python	First quick_validate.py invocation	Re-ran the same validator with the system Python environment, where PyYAML is installed.
Schema example validator resolved a local relative $ref as a remote URL	First example-schema validation	Re-ran with absolute paths and an explicit local schema store for both existing IDs.

2026-08-05 — Production team-order parser rules

Goal: align the active Agent prompt, lwlt-newbooking Skill, canonical operation schema, and examples with the confirmed production team-order input rules.

Phase	Status	Purpose
1. Baseline and rule alignment	Complete	Confirm the active prompt/Skill path and identify stale test-order, manual-price, manual-staff, and full-room-enumeration rules.
2. Prompt and Skill update	Complete	Add production-only order nature, date normalization, passenger notation, room aliases, default account fields, and auto-synced-field rules.
3. Contract and example alignment	Complete	Remove incompatible create-field requirements from the canonical schemas and update the reference examples.
4. Validation	Complete	Parse JSON, validate documentation consistency, run targeted regressions, and inspect the final diff without touching unrelated work.

2026-08-05 — Four-domain Skill routing redesign

Goal: split the current booking Skill into four business-domain Skills and use the first-line business behavior as a helpful router signal without turning it into a rigid command protocol.

Phase	Status	Purpose
1. Baseline and domain mapping	Complete	Confirm current single-Skill routing, existing seven actions, maintenance-standard assumptions, and the user's four-domain grouping.
2. Business-behavior hint protocol	Complete	Prefer the human-facing business behavior on the first line, tolerate formatting/typos, and use the full input/context as fallback; Skill names remain internal routing targets.
3. Skill split and routing	Complete	Create lwlt-newbooking, lwlt-updating, lwlt-arrangement, and lwlt-confirmation entries; route each domain without cross-loading rules.
4. Contract and documentation alignment	Complete	Add the authoritative behavior registry, update the Agent Prompt, maintenance standard, project README, and active Skill references. Future modification/arrangement actions remain explicitly pending rather than being mapped to an unrelated operation.
5. Validation	Complete	Validate all four Skill packages, registry consistency, schemas, syntax, and existing regressions.

Current implementation result

• Active Skill directories are exactly lwlt-newbooking, lwlt-updating, lwlt-arrangement, and lwlt-confirmation.
• Business users may put the concrete behavior names in the first line for faster routing; internal Skill names are routing metadata only, and minor input errors do not block recognition.
• lwlt-newbooking supports the three create behaviors and lwlt-confirmation supports 导出客户确认单 through the existing operation contracts.
• lwlt-updating and lwlt-arrangement are registered and fail closed with stable capability blockers until their field contracts are built.

Verification result

• quick_validate.py passed for all four Skill directories.
• Registry consistency and representative team_order_create, team_order_batch_create, shared_plan_create, and confirmation_export operations passed JSON Schema validation.
• TypeScript no-emit check passed; existing JavaScript/external/ERP regression suite passed 43/43; git diff --check passed.

Follow-up adjustment: soft behavior hint

• The first line is now documented as a preferred collaboration hint rather than a strict command.
• Minor spacing mistakes, typos, abbreviations, missing first-line labels, and behavior text in the body remain routable when the overall intent is clear.
• Only unresolved or conflicting business intent causes a question/blocker.

Follow-up adjustment: cloud prompt boundary

• Removed the registry link, internal Skill names, internal routing table, and maintenance-only explanations from agent设计规范/agent-prompt.md.
• The cloud prompt now contains only business-intent recognition, tolerant input handling, production-order rules, continuation behavior, and standard JSON output rules.
• The behavior registry remains a maintainer reference and is not part of the cloud Agent prompt.

Follow-up adjustment: internal Skill identifier prefix

• Renamed the four active Skill directories and metadata to lwlt-newbooking, lwlt-updating, lwlt-arrangement, and lwlt-confirmation.
• Updated Skill display names, invocation tokens, internal blocker identifiers, reference headings, registry mappings, README links, and maintenance-document paths.
• Kept the human-facing business behavior names unchanged; the lwlt- identifiers remain internal and are not added to the cloud Agent Prompt.

Follow-up adjustment: runtime package cleanup

• Reduced the four runtime packages to only their executable instructions, UI metadata, and conditionally loaded business references.
• Consolidated lwlt-newbooking into action/field rules, normalization rules, and output contract; moved examples and host integration material to agent设计规范/test-fixtures/.
• Removed duplicated runtime references, repository-relative Schema links, and the stray .DS_Store; rebuilt and validated all four Desktop .skill packages.

Follow-up adjustment: remove redundant failure example

• Removed the concrete blocked-result JSON from the cloud prompt; the shared output Schema owns the exact wrapper fields and blocker shape.

2026-08-05 — Skill/ERP plugin alignment complete

Phase	Status	Purpose
1. Contract and plugin audit	Complete	Compare the four Skill outputs with the extension planner, background executor, ERP page adapter, mapping, Schema, and export paths.
2. Compatibility fixes	Complete	Align formal production routing, login-default staff, product-derived pricing/core fields, sparse room/pax inputs, recurrence dates, ERP receipt verification, and confirmation aliases.
3. Regression and packaging	Complete	Run Skill, Schema, TypeScript, extension syntax, planner, guard, control-plane, and external-parser checks; rebuild four Desktop .skill archives.

Current alignment result

• lwlt-newbooking now emits exactly the operation shapes consumed by the guarded team-single, team-batch fallback, and split-parent browser paths.
• The plugin no longer requires manual price, OP, salesperson, or test-marker fields for active formal create operations; product/GetProduct and ERP login defaults remain authoritative.
• Product-generated receivable rows/prices are preserved; the adapter updates passenger quantities and derived amounts instead of clearing and rebuilding them.
• Split-parent execution accepts cpid/cp_id, explicit dates or recurrence ranges, and verifies the returned ERP group number; it does not invent LW or test suffixes.
• lwlt-confirmation emits canonical export types and recovery flags understood by the source-only export adapter. lwlt-updating and lwlt-arrangement remain explicit blockers because their formal ERP contracts are not connected.
• All four prefixed packages were rebuilt on the Desktop and checked byte-for-byte against their source files, with .DS_Store excluded.

2026-08-06 — Strict Agent operation contract and plugin package update

Goal: make the active lwlt-newbooking Skill, parser adapter, standard Schema, extension planner, and ERP-page preflight enforce the same canonical production operation shape. Historical task compatibility is explicitly out of scope.

Phase	Status	Purpose
1. Contract alignment	Complete	Require canonical action, formal/dry_run, named references, sparse passenger/room objects, and canonical dates at the parser and plugin boundaries.
2. Runtime/plugin cleanup	Complete	Remove legacy flat/test normalization from the active extension path and update the page preflight to the same strict checks.
3. Regression coverage	Complete	Add malformed canonical-output, legacy-output, and plugin-preflight tests; run the targeted and project checks.
4. Extension release artifact	Complete	Bump the extension compatibility version, update operator documentation, and package a reloadable ZIP for the user.

Result

• Parser and plugin planner now fail closed on scalar product/customer references, non-formal/test modes, legacy flat envelopes, unsupported room keys, manual price/staff overrides, and non-canonical confirmation types.
• The corrected reported batch operation passes parser/schema/planner validation; the malformed original is blocked before confirmation/ERP handoff.
• Verification passed: planner/external/guard tests 51/51, control-plane tests 11/11, TypeScript no-emit, JavaScript syntax checks, Schema validation, and git diff --check.
• Published the archived archive/releases/2026-08-06/ltjt-order-assistant-0.3.2.zip and refreshed dist/ltjt-order-assistant.zip; retry semantics remain a separate decision and were not broadened to write-started/uncertain executions.

2026-08-06 — 独立团批量下单原生 ERP 流程

Goal: align lwlt-newbooking and the Chrome ERP plugin with the user's real 独立团批量下单 workflow on https://lwlt.hisy.cc/System/Mainlt.asp, including abbreviated customer/product lookup, date-range entry, weekday/date shortcuts, save, and ERP group-number return.

User authorization: the user explicitly authorized creating real ERP orders for this test using the supplied example data. Do not store credentials or cookies. Preserve the existing preflight, explicit execution, write-started, uncertainty, and ERP re-query gates.

Phase	Status	Purpose
1. Live page discovery	Complete	Connect to the user-authorized logged-in Chrome session, locate the native batch-order page, and capture the actual DOM/events/request/response contract without saving.
2. Skill and standard operation contract	Complete	Represent date range, customer/product search terms, passenger/room facts, explicit cycle dates, and expected group-number result without leaking selectors or ERP metadata into the Skill.
3. Native batch ERP adapter	Complete	Implement ordered page operations, deterministic candidate selection for fuzzy user terms, date-range/cycle controls, validation, submit, modal receipt parsing, and fail-closed blockers.
4. Business-system/plugin handoff	Complete	Route the new operation through the background executor and return one or more ERP group numbers to the business system with status/evidence.
5. Real authorized execution	Complete	After the ERP-side bug fix, run the supplied case once under a new execution ID and verify all returned group numbers by ERP re-query.
6. Regression, packaging, and documentation	Complete	Add fixtures/tests, update operator docs, rebuild the extension and lwlt-newbooking package, and record live evidence and any cleanup obligations.

Completion evidence before final packaging

• The user's first authorized native attempt was stopped after an ERP error callback and produced no group number; the old execution was not automatically retried. A read-only JH_OrderList query found no target row.
• After the user confirmed the ERP bug was fixed, a new execution ID completed the exact native flow. ERP returned three groups and the plugin re-queried all three successfully: LW-260903A-A, LW-260905A-A, and LW-260930A-B.
• The archived implementation was inspected for comparison: its verified batch behavior is the per-date DoInfoJH fallback, while native DoInfoJHs was explicitly deferred. The current native adapter is now separately live-verified on the repaired ERP deployment.
• Rebuilt and integrity-checked dist/ltjt-order-assistant-0.4.0.zip, refreshed dist/ltjt-order-assistant.zip, and rebuilt /Users/inmanx/Desktop/lwlt-newbooking.skill from the updated source with .DS_Store excluded. Both archives contain the native batch adapter and pass unzip -t.

2026-08-06 — 业务设计范式沉淀与历史文件治理

Goal: turn the verified 独立团批量下单 delivery into a reusable, cross-session business-adaptation standard, then classify and safely reduce obsolete repository material without disturbing the current dirty worktree.

Phase	Status	Purpose
1. Repository and contract inventory	Complete	Inspect the current registry, Skills, references, schemas/mappings, ERP adapter, fixtures, release artifacts, archive, ignored runtime paths, and pre-existing worktree changes.
2. Cleanup boundary confirmation	Complete	User confirmed archive/quarantine-first handling; delete only verified disposable duplicates/runtime residue, preserve history, and do not reinterpret existing user changes as cleanup targets.
3. Canonical business-adaptation standard	Complete	Define the required three-part package: user input template/examples, ERP operating flow/evidence, and Skill adaptation, plus ownership, status, and acceptance gates.
4. First-business migration	Complete	Represent 独立团批量下单 as the reference package and link its existing Skill, fixture, ERP handoff, operation contract, adapter, tests, and live evidence without duplicating source rules.
5. Historical classification and cleanup	Complete	Apply the confirmed policy to active, reference, generated, temporary, and obsolete files; preserve recoverable history and avoid interpreting existing user changes as cleanup targets.
6. Validation and delivery map	Complete	Validate links, Skill packages, schemas, tests, release artifacts, and produce a concise maintainer handoff entry for future sessions.

Result

• Replaced the obsolete 开发维护规范.md with the current three-part business-adaptation standard and explicit cross-session reading order.
• Added agent设计规范/business-adaptation-registry.md, agent设计规范/templates/business-adaptation-template.md, and the reference package agent设计规范/businesses/team_order_batch_create.md.
• Added a reusable input template to the lwlt-newbooking fixture and linked the root README, Agent design README, and behavior registry to the new sources of truth.
• Archived api_inventory.md under archive/research/2026-07-07/ and the superseded 0.3.2 extension package under archive/releases/2026-08-06/; removed the explicit .DS_Store residues.
• Current 0.4.0 packages, active source, current Skills, contracts, tests, and live verification evidence remain in place. Existing unrelated worktree changes were preserved.
• Validation passed: local Markdown links, four Skill quick validators, JSON parsing, TypeScript no-emit, control-plane tests 11/11, business/plugin tests 55/55, JavaScript syntax checks, git diff --check, and current/archived ZIP integrity.

2026-08-06 — 独立团单个下单业务梳理启动

Goal: align the second business 独立团单个下单 with the three-part business-adaptation standard, preserve the existing guarded team_order_create route, and add the user's required booking-customer lookup semantics before any live write.

User-supplied flow: open the independent-team single-order function; fill departure date; fuzzy-match and select booking customer; fuzzy-match and select product; click the adjacent “更新行程” button so group-number/business-name fields are populated; fill passengers; fill rooms; save and return the ERP group number.

Phase	Status	Purpose
1. Existing contract and adapter audit	Complete	Confirm current team_order_create Skill/Schema/planner/page adapter behavior and identify differences from the supplied flow.
2. Live ERP read-only discovery	Complete	Open the authorized single-order form without saving and inspect the real entry point, fields, lookup datasets, and product-side effects.
3. Customer disambiguation	Complete	User clarified 人名币 as the RMB customer; the adapter resolves the normalized keyword to one customer record and preserves the raw keyword.
4. Input contract, Skill, and ERP adapter update	Complete	Booking customer is now required, deterministic matching is enforced, and the single-order page flow includes the visible “更新行程” click and customer restoration.
5. Save-before-write preflight	Complete	The completed operation passed page validation, product side-effect checks, customer restoration, and one intercepted DoInfoJH submit with no network write.
6. Authorized execution, reconciliation, and delivery	Complete	Under a fresh execution ID, saved once in ERP, returned LLW-260903A-A, re-queried it successfully, updated the business package/registry, rebuilt packages, and recorded the evidence.

Read-only discovery result

• The single-order entry button is OPEN_update(0,0,0) and opens /System/Business/orders_add.asp in the logged-in ERP context.
• The form has 826 elements; the write action is the existing POST /System/DAT/orders.asp with Act=DoInfoJH.
• 老挝联泰 matches LW老挝联泰（人民币）, LW老挝联泰（美金）, and LW老挝联泰（老挝）; the current page default currency is CNY, but that is not permission to choose the RMB record.
• 遇见老挝 has an exact product candidate plus a longer 遇见老挝（常规） candidate; the deterministic product matcher may accept the single exact match, subject to the selected customer/product-side effect and final consistency checks.
• No save request, DoInfoJH request, or ERP order was created during this discovery.

2026-08-06 — 独立团单个下单保存前预检完成

• 用户补充确认：客户输入为 老挝联泰人名币，产品选择后必须点击旁边的“更新行程”按钮；已按 人名币 → 人民币 的已知别名匹配 LW老挝联泰（人民币），同时保留原始关键词。
• 真实 ERP 只读实测确认：#gengxinxingcheng 是“更新行程”按钮，点击后观察到 GetProduct 成功返回，并自动填入 TianShu、专线/业务名称、团号前缀/后缀及行程字段。
• 发现并固化 ERP 特殊行为：GetProduct 会暂时覆盖客户字段；适配器在联动完成后重新应用客户 SelectBox 映射，并校验客户名称、zutuansheid、币种和最终表单值一致。
• 修改标准 contract、Skill references、fixture、业务适配包、registry、插件 inpage.js、operation planner、Schema 和测试；team_order_create 现在必须带 data.customer。
• 新适配器预检结果：客户归一化匹配唯一、产品精确匹配唯一、更新行程 AJAX 成功、自动字段完整、客户恢复成功、人数 16、房间 9、必填字段无缺失；DoInfoJH 仅被拦截捕获，未发送网络写入。
• 当前业务包状态更新为 预检通过；本轮没有真实保存、没有生成新团号。真实保存仍需业务系统确认和单独的执行授权。

2026-08-06 — 独立团单个下单授权真实保存与业务适配包补齐

用户明确要求：单团业务必须在 ERP 中实际保存，才能算完整验证；同时每个业务必须有独立的一页式业务适配包，格式参照 team_order_batch_create.md。

Phase	Status	Purpose
1. Authorized live submit	Complete	Third fresh execution passed the protected-field gate and sent the approved DoInfoJH request; ERP returned a success receipt.
2. Receipt and ERP re-query	Complete	Parsed LLW-260903A-A and verified it through JH_OrderList with HTTP 200 and no login/permission error.
3. Package and registry update	Complete	Marked team_order_create.md and the registry as 已真实验证, recorded the receipt/evidence, and preserved the three-part package.

Error recorded

• First authorized executor run reached live_submit, but SubmitInfoForm() generated a request hash different from the preflight-approved hash; the plugin set prevented_from_network=true, so no ERP write or group number was produced. The next attempt must diagnose and re-run the preflight after the adapter fix, never bypass the gate or reuse the failed execution ID.
• Second authorized executor run reached the same live-submit boundary but the new synchronous protected-field hash attempted to process decoded Chinese values and threw before $.ajax; no ERP write occurred. The protected projection now uses URL-encoded values and must be exercised only after a fresh extension reload and a new execution ID.

Completion evidence

• Third fresh execution exec-single-20260903-live-1785999502789 passed preflight, sent the real DoInfoJH request, received LLW-260903A-A, and completed ERP re-query successfully. The two prior attempts were blocked before network and were not retried.

2026-08-06 — 散拼团新增计划业务梳理启动

Goal: align shared_plan_create with the user's final lwlt-newbooking business flow, including the plan date range, product lookup, planned capacity, room counts, cycle dates, optional child-order/拼单 customer and passenger counts, save, and complete group-number reconciliation.

User-supplied case: date range 09-01 to 09-30, product keyword 老挝广东8D, planned capacity 30, rooms TWN=8 and SGL=1, explicit cycle dates 2026-09-03, 2026-09-05, 2026-09-30, and a 拼单 information row for customer 南宁国旅 with 15+1. There is no separate 老挝联泰 customer field in this corrected example.

Phase	Status	Purpose
1. Existing contract and adapter audit	Complete	Compared the current shared_plan_create operation with the corrected plan/拼单 inputs and identified missing room/count/nested-customer fields.
2. Live ERP read-only discovery	Complete	Confirm the real散拼计划入口, nested form, field names, product/customer widgets, cycle controls, and save endpoint without submitting.
3. Input contract, Skill, and ERP adapter update	Complete	Apply the confirmed rule that product/customer lookup must be unique; add split_order, room counts, the standalone business package, plan mapping/schema, and the live page adapter.
4. Save-before-write preflight	Complete	Complete page preflight verified date/product/room/cycle/拼单 fields and ERP default personnel before the authorized save.
5. Authorized execution, reconciliation, and delivery	Complete	Saved once on the synchronized extension, parsed all three returned group numbers, re-queried each ERP row, and marked the package status.

Live discovery checkpoint

• The ERP menu opens /System/Business/plan.asp; its 新增计划 control is OPEN_adds() and opens /system/Business/plan_add.asp in iframe[name="dialogWindow2"].
• The real form is InfoForm1, action POST /System/DAT/plan.asp?Act=DoInfoSPs; the visible save control is SubmitButton with value 提交保存.
• The form fields are Riqi1/Riqi2, jihuashu, frenshu0..frenshu5 (SGL/TWN/TRP/DBL/HNM/TL), S_chanpinming, repeated zhouqi checkboxes, and 拼单 fields zutuanshe, darenshu, xiaorenshu, ertrenshu, yingrenshu, quanrenshu.
• The page carries hidden fabudanwei=老挝联泰 from the logged-in ERP context; the corrected user input has no separate first customer. 南宁国旅 maps to the visible 拼单信息 zutuanshe field.
• The page's native product query filters S_zhuanxianlei=散拼团; continuous search for 老挝广东8D is empty, so the adapter matches the loaded scatter list deterministically by product-name/duration tokens. The current list has one match: 老挝行程--广东 8D7N; the other 广东 candidates are 6D/5D and do not match the 8D token. A future 0/multiple match must return a user prompt and stop.
• The complete standard operation now carries planned_capacity, top-level room_counts, and nested split_order.customer/passenger_counts; all pure planner, external contract, Schema, Skill references, mapping, and adapter tests pass.
• No DoInfoSPs request or ERP write has been sent yet in this phase; next step is the fresh-extension live preflight and authorized real save.

Authorized live verification result

• The first two new execution attempts were not reused: one was blocked by the native product search clearing the loaded candidate list; the other used a stale desktop extension copy and returned no browser action result. ERP list checks showed no matching records for those attempts.
• The actual Chrome extension path was identified as /Users/inmanx/Desktop/ltjt-order-assistant-0.4.0; it was synchronized from the tested workspace source before the successful run.
• The successful execution selected cp_id=412 (老挝行程--广东 8D7N) by unique_ordered_tokens, selected LW南宁国旅 by unique_contains_normalized, and passed preflight with capacity 30, room total 9, passenger total 16, and cycle dates 2026-9-3, 2026-9-5, 2026-9-30.
• ERP returned 操作成功，共计新增 3 个团队 with group numbers LW-260903A-A, LW-260905A-A, and LW-260930A-B; all three were independently queried and found in the scatter-plan list.
• The adapter now parses an array of returned group numbers and verifies every one; it keeps the first group_number for backward compatibility and adds group_numbers/group_count for the complete receipt.

2026-08-06 — External parse contract-drift hardening

The final shared_plan_create ERP flow is already live-verified. A later identical input was blocked after the external SSE stream completed because the Profile occasionally emitted an undeclared operation.data field. This is a parser-boundary issue, not an ERP write issue.

Change	Status	Boundary
Explain unknown field names in validator errors	Complete	Strictly reject; never drop arbitrary fields
Send explicit canonical output guidance for the three lwlt-newbooking actions	Complete	External parse request only
Retry one contract-invalid result in the same external session	Complete	Revalidate the repaired JSON; no ERP call
Real same-input parse verification	Complete	Returned shared_plan_create with contract_repair_count=0

2026-08-06 — Unified task lifecycle observability

• [completed] 设计并实现统一的任务生命周期事件模型与明确失败元数据
• [completed] 将外部 Agent 请求阶段、任务事件和技术 JSON 合并到前端时间线
• [completed] 更新解析适配器、契约/schema、测试与文档
• [completed] 完成静态检查、单元测试和端到端状态核对

Verification

• Parser regression: 32/32 passed.
• Control-plane tests: 11/11 passed.
• TypeScript no-emit, JavaScript syntax, schema JSON parse, and git diff --check passed.

2026-08-06 — 真实成功回执与生命周期边界字段修正

Goal: 将用户提供的真实 shared_plan_create 成功日志登记为产品匹配算法的回归证据，并修正控制平面在成功 ERP 执行事件中遗漏边界状态的问题。

Phase	Status	Purpose
1. Successful-run evidence audit	Complete	Read the attached lifecycle log and confirm Agent parse, plugin dispatch, ERP write, receipt count, and ERP re-query independently.
2. Lifecycle-field root cause	Complete	Confirmed recordExecutionResult() used executionFailure?.… ?? false; successful results have no failure object, so their outer event flags were defaulted incorrectly.
3. Boundary normalization and regression tests	Complete	Added executionLifecycleFacts(), normalized the persisted executor result and event payload together, and covered successful, pre-write-blocked, and write-capable-running states.
4. Validation and handoff	Complete	Full regression, production TypeScript build, JavaScript syntax, artifact integrity, and git diff --check all pass; no additional ERP write was performed.

Confirmed live evidence

• Task TASK-20260806095904-M7VZmvA returned a valid shared_plan_create operation and completed the real ERP path.
• Product 江西老挝10D was uniquely resolved locally to cp_id=365 / 江西老挝 10D9N with unique_contiguous; no native composite product query was used.
• ERP saved and returned two groups: LW-260907A-B and LW-260915A-A; both were re-queried as parent_group_found.
• The nested executor result correctly reported submitted, write_attempted=true, no_erp_write=false, and status=completed. The outer final task event incorrectly defaulted several lifecycle boundary flags to false; this is an observability serialization defect, not a parser or ERP failure.

Result

• Successful completion now reports agent_returned=true, plugin_dispatch_started=true, erp_write_started=true, no_erp_write=false, and reconciliation_resolved=true when receipt/re-query evidence is present.
• A write-capable running event reports no_erp_write=false but keeps erp_write_started=false until the actual write boundary; a pre-write blocker reports no_erp_write=true and erp_write_started=false while still showing the plugin boundary as reached.
• Validation passed: control-plane/full regression 80/80, TypeScript no-emit and build, JavaScript syntax, extension/Skill ZIP integrity, and git diff --check.

2026-08-06 — 新一轮散拼计划 ERP 500 与解析阶段边界复核

Goal: 核对用户提供的新一轮 shared_plan_create 生命周期日志，区分 Agent/插件状态问题与 ERP 真实 HTTP 500，并修正解析成功事件仍显示 agent_returned=false 的边界字段。

Phase	Status	Purpose
1. Log evidence audit	Complete	Confirm the new task's operation, product/customer unique matches, POST payload, ERP response, and final lifecycle state.
2. Parser-event boundary audit	Complete	Confirmed applyParseResult() used failure?.… ?? false; valid parse results have no failure object, so the event lost the Agent-returned fact and defaulted no-write facts to false.
3. ERP 500 diagnosis	In Progress	Compare the submitted fields and server response with the known successful split-plan shape; keep the task fail-closed and do not retry the write automatically. User evidence now confirms at least one group was persisted despite HTTP 500.
4. Reconciliation fallback design	Planned	Add a read-only post-write fallback query that can identify persisted group numbers when the ERP response has no receipt, without retrying the write.
5. Regression and handoff	Planned	Add parser/executor boundary tests, run the full checks, and record whether a code-side correction or ERP-side investigation is required.

New log evidence

• Task TASK-20260806101143-Zy0vgtA received a valid shared_plan_create operation; product 广东衡阳6D uniquely matched cp_id=415, and customer 辽宁康辉 uniquely matched LW辽宁康辉.
• Preflight passed: date range 2026-09-01–2026-09-30, dates 2026-09-07/09-15/09-26, planned capacity 40, rooms TWN=8/SGL=1, split passengers 8 adult + 1 child-bed + 1 leader.
• The plugin sent POST /System/DAT/plan.asp with Act=DoInfoSPs; the ERP returned HTTP 500 (内部服务器错误) and the native alert 提交超时！. No group number was returned and ERP list re-query found no group.
• The final event correctly reports agent_returned=true, plugin_dispatch_started=true, erp_write_started=true, no_erp_write=false, reconciliation_resolved=false, and reconciliation_pending; this is an uncertain write result and must not be retried automatically.
• The earlier awaiting_confirmation event still reports agent_returned=false even though its embedded parse response is agent_parse_passed; this is a remaining event-payload normalization defect.
• User screenshot confirms the ERP list contains LW-260907A-B for the submitted case, so the HTTP 500 path can represent “saved but response lost/failed” rather than “not saved”.

Parser event correction

• Added parseLifecycleFacts() and wired applyParseResult() to emit agent_returned=true, plugin_dispatch_started=false, erp_write_started=false, no_plugin_dispatch=true, and no_erp_write=true for a successful parse awaiting confirmation.

Errors encountered

Error	Attempt	Resolution
zsh: command not found: node	Ran the focused control-plane test with the shell's unqualified node command.	Use the bundled workspace Node runtime explicitly; the TypeScript check already passed with that runtime.
unzip: cannot find dist/ltjt-newbooking.skill	Final ZIP check used the wrong filename.	The current artifact is dist/lwlt-newbooking.skill; rerun the integrity check against that exact path.
Existing classifier test expected completed without receipt evidence	Added the new uncertain-result tests and ran the full suite.	Kept the fail-closed classifier behavior and updated the stale assertion to reconciliation_pending; a completed state requires receipt evidence.
Control-plane static UI assertion expected the previous cache version	Ran the control-plane regression after the task-card delete cache bump.	Update the assertion to 20260806-task-card-delete-1 and add hard-delete coverage assertions.
TypeScript reported PublicTask missing success_receipt and error_summary	Final hard-delete validation ran the project type check.	Completed the existing public wrapper contract with a null success receipt and normalized error summary.

2026-08-06 — 全量任务彻底删除

Goal: 用户已明确要求所有任务卡片均可彻底删除，不因是否进入 ERP、是否完成或是否待回查而拦截；同步删除业务系统卡片、控制平面任务及插件本地任务记录。

Phase	Status	Purpose
1. 删除边界与数据库关联审计	Complete	已确认任务子表级联、审计/outbox 独立记录及现有插件取消阻断点。
2. 控制平面硬删除 API	Complete	已增加管理员鉴权的 DELETE 接口，在事务内清理审计/outbox 后删除主任务并依赖级联清理子表。
3. 业务系统与插件清理	Complete	所有卡片启用删除；独立强制删除消息会阻止后台后续结果回写并清理插件本地记录。
4. 回归与交付	Complete	状态覆盖断言、TypeScript、Node 回归、JavaScript 语法和差异检查均通过。

Confirmed destructive scope

• 用户明确确认：即使任务已经进入 ERP，也允许彻底删除平台记录。
• 本次删除不会尝试回滚或修改 ERP 已产生的数据；删除平台记录后，ERP 结果可能无法从本平台回查。

Final verification

• TypeScript --noEmit passed.
• Control-plane tests: 15/15 passed.
• Business/extension regression tests: 57/57 passed.
• Frontend/background/bridge JavaScript syntax checks and git diff --check passed.

2026-08-06 — 任务成功回执与错误摘要时间戳

Goal: 为任务生命周期增加可直接消费的成功回执和错误摘要字段，并分别记录、展示服务端时间戳。

Phase	Status	Purpose
1. Contract and storage audit	Complete	已确认 006_ 迁移、现有回执证据/失败归一化函数和前端生命周期面板边界。
2. Database/API implementation	Complete	已新增 006_task_outcomes.sql、PublicTask 字段和兼容旧任务的读取回退。
3. Lifecycle writes	Complete	成功回执和每次错误状态均在事务内写入专用字段，并继续追加生命周期事件。
4. UI and regression	Complete	已展示成功/错误时间戳与摘要，文档和测试同步；控制面 19/19、旧回归 57/57 通过。

Confirmed contract

• success_receipt 和 error_summary 是任务 API 的固定字段；完整 events 继续保留。
• 只有 completed 且存在可验证 ERP 回执、团号或订单号等证据时才填充 success_receipt；否则保持待回查，不返回成功回执。
• 每次错误追加到事件流；error_summary 始终保存最近一次错误摘要。
• 时间戳由服务端/数据库生成，不接受客户端时间戳；现有脱敏规则继续生效。

Result

• completed 无 ERP 证据时会规范化为 reconciliation_pending，并保留原始 result_status 供诊断。
• 成功字段从 erp_receipt、团号/订单号、验证标记和批量结果中提取安全回执；错误字段从统一失败摘要写入最近一次原因。
• 操作台右侧新增“终态摘要”区域，和生命周期黑框并列展示成功回执或错误摘要及服务端记录时间。

Errors encountered

Error	Attempt	Resolution
计划追加补丁未匹配历史上下文	1	读取 task_plan.md 实际尾部后改用精确追加上下文，未产生代码变更。

2026-08-06 — 任务卡片固定布局与错误日志归位

Goal: 固定任务卡片区域的可用宽度，缩小单卡片，不产生横向滚动；删除入口只保留在任务状态详情面板；状态区只显示短状态，完整错误信息归入下方生命周期日志。

Phase	Status	Purpose
1. UI source audit	Complete	已确认三栏布局、卡片级删除按钮、响应式横向滚动规则，以及截图长错误文案来自 #taskState。
2. Layout and interaction update	Complete	已移除卡片内删除按钮，任务状态详情面板保留唯一删除入口；卡片缩小并使用可收缩列宽。
3. Lifecycle log relocation	Complete	状态区改为短状态；错误摘要不再单独占用终态卡片，并补入下方生命周期日志。
4. Regression and visual verification	Complete	静态布局规则、语法、TypeScript、控制平面 19/19、业务回归 57/57 和差异检查通过；实时页面因未登录无法进入任务区，未使用账号绕过。

Confirmed interpretation

• “左边任务状态模块”按当前页面 DOM 的“任务状态”详情面板理解；保留该面板内的删除按钮，卡片内不再放删除按钮。
• 任务平台记录仍按上一轮已确认的彻底删除语义处理；本轮只调整展示与入口位置，不改删除 API 或 ERP 边界。

Delivery checks

• LianSyn-platform/app.js 仅从任务状态详情面板触发彻底删除；卡片只负责选择任务。
• #taskState 和任务卡片使用短状态标签，完整失败文案由 task_error_summary 生命周期条目承载。
• workbench-grid、任务卡片和日志均设置 min-width: 0；窄屏三栏改为纵向布局，横向滚动规则已移除。
• 浏览器实时核验停在管理员登录页，未读取或尝试猜测凭据，也未操作真实任务/ERP。

2026-08-06 — HTTP 500 后散拼计划回查补强

Phase	Status	Purpose
1. 实际 ERP 证据核对	Complete	在授权的已登录 Chrome 会话中只读按日期查询，确认 LW-260907A-B 已落库，但本次 3 个日期只确认 1 个。
2. 解析/执行边界修正	Complete	成功解析事件明确 Agent 已返回；无可验证团号的写入结果保持待回查，并使用 erp_result_uncertain。
3. 只读回查兜底	Complete	保存响应无团号或异常时按日期查询散拼计划列表，产品、日期、计划人数和拼单人数必须唯一匹配，绝不自动重提。
4. 回归与交付	Complete	控制平面 19/19、业务/插件 69/69、TypeScript/JavaScript、生产构建、ZIP/Skill 完整性和差异检查均通过。

Confirmed result model

• ERP HTTP 500 不再直接等同于“没有保存”：插件会先执行保存后的只读回查。
• 全部日期唯一确认时返回团号回执，并附带“由列表回查确认、未自动重试”的 warning。
• 仅部分日期确认时返回已确认团号、缺失/歧义日期和 reconciliation_pending；平台不能把它显示成完整成功。
• 保存前阻断、写入已发起但回查不到、回查歧义三类状态仍分别保留，不会被模糊匹配算法强行合并。

2026-08-06 — “暂无成功回执”日志原因核对

Check	Status	Evidence
Agent 是否返回	Confirmed	parse_response.status=agent_parse_passed，且外部 SSE 已完成、result_present=true。
插件是否写入 ERP	Confirmed	write_attempted=true、erp_write_started=true，ERP 返回 HTTP 500 与“提交超时”。
是否存在部分 ERP 回执	Confirmed	executor_response.erp_receipt 已包含 LW-260907A-B，来源为 post_write_list_fallback。
为什么终态摘要为空	Confirmed	任务状态为 reconciliation_pending；控制平面只对 completed 写入 success_receipt，界面只读取该字段。
为什么边界字段仍是旧值	Confirmed	日志生成进程 PID 18608 于 17:18 启动，代码修复/构建在 18:27/18:28，旧进程未重启。

Diagnosis

• 本次不是 Agent 没返回，也不是插件没有把团号传回；是“部分回查回执被保存在执行结果中，但因 1/3 日期确认而没有升级为成功回执”。
• 该日志中的 error_code=task_failed、解析阶段 agent_returned=false 与当前源码不一致，说明运行中的控制平面仍是旧代码；重启服务后才会看到 erp_result_uncertain 和正确的解析边界字段。
• ERP 请求的产品、客户和保存前预检均已通过，实际异常仍发生在 ERP DoInfoSPs 的 HTTP 500/部分落库边界，不是模糊匹配阻断。

Delivery checks

• 插件已发布为 0.5.3，生成 dist/ltjt-order-assistant-0.5.3.zip，并刷新 dist/ltjt-order-assistant.zip。
• 包内包含 split-plan-reconciliation.js、product-lookup.js 和 team-batch-inpage.js；manifest 版本为 0.5.3。
• dist/lwlt-newbooking.skill 完整性检查通过；本轮未改 Skill 内容，不重复重建。
• git diff --check 通过；本轮没有再次提交 ERP 写入。

Errors encountered in this phase

Error	Attempt	Resolution
控制平面静态断言仍查找旧的“错误摘要”文案	最后一轮全量回归发现页面当前文案已调整为“错误详情已记录在下方任务生命周期日志”。	将断言同步到当前生命周期日志文案；未改变页面行为。

2026-08-06 — 散拼三日期只成功一单的原因核对

Check	Status	Evidence
用户日期是否解析正确	Confirmed	operation 与预检均包含 2026-9-7/09-15/09-26 三个日期。
插件是否一次提交三个日期	Confirmed	DoInfoSPs 请求的 zhidingzhouqi 包含三项，未发生日期匹配或勾选遗漏。
ERP 是否生成后两单	Not found	当前登录 ERP 只读查询 09-15、09-26 均返回 0 个团队；不是回查条件漏掉。
失败边界	Confirmed	ERP 对同一个三日期 POST 返回 HTTP 500/“提交超时”，但第一日期已部分提交。
精确服务端字段根因	Not determinable from client	ERP 返回 IIS 通用 500 页面，没有业务字段错误；需要 ERP 服务端日志才能指向具体字段/数据库约束。

Comparison with known successful run

• 同样的 DoInfoSPs 多日期机制此前成功创建过 2 单和 3 单，因此“插件只能提交一单”不是通用算法限制。
• 本次与成功案例的实质差异集中在产品 cp_id=415、客户 zutuansheid=8、小孩占床=1 和第三个日期 09-26；这些是 ERP 服务端 500 的排查线索，但客户端证据不足以单独定责。
• 本轮只读查询未再次保存、未尝试逐日期重提，避免把已部分落库的第一单造成重复。

2026-08-06 — 删除按钮无响应修复

Phase	Status	Evidence
1. Runtime path audit	Complete	确认原流程会先等待插件删除响应，最多 4 秒；失败后状态又被重新渲染覆盖。
2. Responsive delete flow	Complete	平台硬删除改为立即请求；插件清理由后台尽力发送，不再阻塞删除。
3. Cache and feedback	Complete	前端脚本/样式缓存版本已更新；按钮显示“删除中…”/“重试删除”。
4. Regression	Complete	TypeScript、控制平面 19/19、业务回归 57/57、JS 语法和 git diff --check 均通过。

Safety boundary

• 仍保留确认框和服务端 CSRF/管理员校验。
• 平台任务删除不再等待 ERP/插件状态；ERP 已发出的写入不做回滚声明。

2026-08-06 — 删除接口运行态恢复

Check	Status	Evidence
浏览器请求定位	Complete	当前页面已加载新版脚本，但真实 DELETE /api/tasks/:taskId 返回 HTTP 404。
运行进程核对	Complete	8786 端口上的控制平面仍是 17:18 启动的旧实例，日志显示 Route DELETE ... not found。
服务恢复	Complete	终止旧实例后守护程序于 19:05 自动拉起新实例并加载最新源码。
非破坏性验证	Complete	/health/live 返回 200；未认证的虚拟任务删除探针返回 401，不再返回 404，确认路由已注册。

Safety boundary

• 未删除任何真实任务；虚拟任务探针未携带登录态，服务在认证阶段拒绝请求。

2026-08-06 — 删除状态按任务隔离

Check	Status	Evidence
后端删除核对	Complete	用户操作对应的三次 DELETE 均返回 HTTP 200，删除本身已成功。
前端状态根因	Complete	共用详情按钮直接保留“删除中…”文字，切换任务时只重算 disabled，未重算文案。
状态隔离	Complete	新增按 taskId 存储的 taskDeleteStates；处理中、失败重试和默认文案随当前任务独立渲染。
Cache and regression	Complete	资源版本更新为 task-delete-per-task-1；语法、TypeScript、19 个控制平面测试和 57 个业务测试通过。

2026-08-06 — 散拼发团周期与独立团统一及 500 继续排查

Goal: 让 shared_plan_create 与 team_order_batch_create 共用相同的 ERP 周期选择语义，并继续区分周期适配缺口与 ERP DoInfoSPs 服务端 500。

Phase	Status	Purpose
1. 周期实现对照	Complete	已确认独立团批量支持 zhidingzhouqi/zhouqi 双通道，散拼仅使用显式日期枚举且单双日展开错误。
2. 散拼双通道实现	Complete	两条业务共用 cycleSelectionPlan()：显式日期使用 zhidingzhouqi；daily/weekly/odd/even 使用 zhouqi，单双日按日历日期计算。
3. 回归与版本发布	Complete	插件 0.5.4 已构建；版本包与通用包字节一致，ZIP、manifest、skill 包和工作树格式均校验通过。
4. ERP 失败结论	Complete	已确认三日期均进入原生 POST，ERP 第一日期落库后返回 500；客户端证据不足以定位具体服务端字段/语句，需按提交时间查 ERP 日志。

Safety boundary

• 本轮不重提已部分落库的三日期任务，不向 ERP 发起 DoInfoSPs。
• 周期实现统一后只做 DOM/序列化和只读页面验证；是否重新创建缺失日期需要新的明确授权。

Verification evidence

• 聚焦周期测试 6/6、业务/插件回归 71/71、控制平面 19/19、TypeScript no-emit 和插件 JavaScript 语法均通过。
• 原失败任务的预检与 POST 均含 2026-09-07/09-15/09-26 三个 zhidingzhouqi；统一周期代码不会改变该历史事实。
• dist/ltjt-order-assistant-0.5.4.zip 与 dist/ltjt-order-assistant.zip SHA-256 均为 53b336ef642e4fd6bba8e4190b8c04f1a5dc74677a41f77b91a3cd619f3c76f3。

Errors encountered

• 首次打包命令因包含临时目录清理 rm -rf 被本地安全策略在执行前拒绝；没有生成或覆盖任何包。改用明确目标文件直接构建并单独校验。

2026-08-06 — 控制平面数据库迁移与任务持久化修复

Goal: 修复远程数据库结构与当前控制平面代码不一致导致的解析结果写回失败，并补上部署防回归检查；不重新解析历史卡住任务，不触发插件或 ERP。

Phase	Status	Purpose
1. 运行态与工作树基线	Complete	已记录当前进程、远程迁移版本、任务状态和未提交改动；未覆盖用户既有工作。
2. 数据库迁移	Complete	远程只应用 006_task_outcomes，四个字段和索引已核对存在。
3. 启动与部署防回归	Complete	服务启动前校验 006_task_outcomes；npm run dev/start 先执行迁移，ready health 暴露 schema 状态。
4. 服务重启与运行态验证	Complete	新实例 PID 32880 唯一监听 8786；旧重复 PID 29589 已终止；旧任务未重新解析。
5. 测试与交付	Complete	TypeScript、控制面 20/20、既有业务/外部解析 57/57、构建、health readiness 和 git diff --check 均通过。

Confirmed boundary

• 已获用户授权：可修改当前 .env 指向的远程 PostgreSQL 结构并重启控制平面。
• 明确禁止：重新解析 TASK-20260806111446-V5d0hnc、确认任务、调用插件或 ERP。
• 当前根因：远程 tasks 缺少 success_receipt/success_receipt_at/error_summary/error_summary_at，而应用 applyParseResult() 已引用这些字段。

Errors encountered

Error	Attempt	Resolution
npm: command not found	首次运行 npm run check、npm run test:control-plane	使用项目现有的 bundled Node 直接调用 TypeScript、tsx 和测试命令；不修改环境 PATH。

| 发现无监听的重复控制平面进程 29589 | 重启主监听进程后仍存在一个保持数据库连接的旧 server.ts 进程 | 只终止该明确重复 PID，保留新监听进程 32880；health readiness 复核通过。 |

| 端口冲突可能留下后台队列定时器 | 复核发现 app.listen() 失败后旧异常路径没有调用 app.close() | 在 main() 的 listen 异常路径主动关闭 Fastify，清理队列定时器和数据库连接；重建、重启并复核通过。 |

Final evidence

• 远程迁移命令返回 {"ok":true,"applied":["006_task_outcomes"]}；迁移记录时间为 2026-08-06 19:28:49+08。
• GET /health/ready 返回 200：database=true、schema=true、required_migration=006_task_outcomes。
• GET /api/status 返回数据库 ready、AI configured/reachable/authenticated；没有创建新任务，没有重新解析旧任务。
• 旧任务在迁移前已由页面 DELETE /api/tasks/TASK-20260806111446-V5d0hnc 返回 200 删除；本轮没有重新创建或补写它。

2026-08-10 — AgentBus Bot channel transport

Goal: make the control plane receive channel messages through the AgentBus Bot WebSocket and return user-facing task outcomes through the same connection, while preserving the existing administrator confirmation gate before ERP execution.

Phase	Status	Purpose
1. Transport and lifecycle design	Complete	Confirm AgentBus owns channel adapters; this service owns only the Bot WebSocket; map inbound tasks to the existing task/session pipeline.
2. AgentBus client implementation	Complete	Added configuration, authenticated session lifecycle, reconnect handling, progress frames, and one final result per inbound task.
3. Control-plane task bridge	Complete	Ingests new/continuation messages with conversation identity, triggers the parser queue, and translates task terminal states to channel-safe text.
4. Tests and documentation	Complete	Added transport/configuration tests, environment examples, status visibility, and passed the full existing verification suite without invoking ERP.

Confirmed decisions

• AgentBus handles each channel Adapter; the service does not implement individual channel integrations.
• The service connects to AgentBus as the documented long-lived Bot WebSocket listener.
• Incoming event messages are routed into the existing TaskService and parser queue.
• task.progress is optional; exactly one task.result is sent for each accepted inbound task.
• The current administrator confirmation gate remains in force. AgentBus traffic never auto-confirms or directly triggers ERP execution.

Safety boundary

• Do not copy the supplied WebSocket or Invoke tokens into source, tests, logs, or planning files.
• Do not use the Invoke Token for the listener; it is reserved for the documented Function Call API path.
• Do not call the browser extension or ERP while validating the integration.

Verification evidence

• AgentBus-specific tests: 5/5; control-plane tests: 25/25; existing business/external-parser regression: 57/57.
• TypeScript no-emit and build passed.
• A real short-lived handshake reached session.ready with epoch 1 and the expected Bot address; no business task was sent.

Errors encountered

Error	Attempt	Resolution
Planning-file append context mismatch	First append used an outdated task_plan.md tail	Re-read the actual file tails and insert the new phase using the current section anchor.

2026-08-10 — 散拼团新增计划禁止提交拼团信息

Goal: 按 ERP 真实业务规则修正 shared_plan_create：创建阶段不提交拼团客户名称和人数；旧格式任务不重新解析、不自动迁移。

Phase	Status	Purpose
1. 契约与影响面审计	Complete	已盘点 Schema、Agent 提示/校验、浏览器适配、映射、测试和发布包中的 split_order 使用。
2. 创建链路修复	Complete	已从散拼创建契约移除客户/人数，禁止旧字段穿透，且 ERP 适配器不等待/不填写相关控件。
3. 文档与测试同步	Complete	Skill、映射、fixture、表单说明和回归断言已同步，并覆盖“带拼团信息必须阻断/不传”。
4. 构建与交付验证	Complete	控制面 20/20、业务/插件 72/72、TypeScript、脚本语法、Schema/JSON、ZIP 完整性和 git diff --check 均通过；未触发 ERP 写入。

Confirmed decisions

• shared_plan_create 创建契约完全禁止 split_order，也禁止顶层 customer / passenger_counts 作为旧格式兼容输入。
• 创建时只提交产品、日期/周期、计划收客数和房型；客户名称和人数留给后续补录/修改流程。
• 本轮不重新解析历史任务，不迁移旧任务，不调用插件或 ERP。

Errors encountered

Error	Attempt	Resolution
node 不在当前 shell PATH	尝试用系统 node 校验 Schema JSON	改用项目既有 bundled Node 路径校验；未修改环境。
一次 bundled Node 的内联 Schema 检查路径写错	首次检查通过 JSON 解析但读取错误的 branch 路径，触发 TypeError；随后一次 shell 引号组合不完整	改用正确的 item.if.properties.action.const 路径和简化的单引号脚本；Schema/契约检查最终通过。
zip 直接写入 mktemp 创建的空文件时报结构无效	首次用已存在的临时空文件作为 ZIP 输出	改用 mktemp -d 创建临时目录，再写入新的 ZIP 路径；0.5.5 插件包和 Skill 包均成功生成并通过 unzip -t。

Final evidence

• Chrome 插件已升级为 0.5.5；dist/ltjt-order-assistant-0.5.5.zip 与通用 dist/ltjt-order-assistant.zip SHA-256 均为 cfad9f0cc17835c431c9f1fbd1deb8c7ac4ed3d04759b0278728590a1dbce4b4。
• dist/lwlt-newbooking.skill 已重新打包，包含更新后的创建契约、ERP 衔接、归一化规则和输出契约。
• 运行时边界：旧 shared_plan_create 任务若携带客户/人数会在标准校验阶段阻断；合法创建路径不会打开客户 lookup，不填写 zutuanshe/人数控件，也不调用 GetVisitorsHtml()。
• 本轮没有重新解析历史任务、没有迁移旧任务、没有调用 Chrome 插件或 ERP。

2026-08-10 — 任务来源标签

Goal: 在任务卡片上区分任务来自 AgentBus 渠道还是平台人工输入。

Phase	Status	Purpose
1. 来源字段与链路接入	Complete	为任务增加 manual / agentbus 持久化来源，人工 HTTP 入口和 AgentBus 入口分别写入来源；旧任务默认人工。
2. 卡片显示与缓存更新	Complete	在任务卡片标题行增加来源小标签，AgentBus 与人工输入使用不同样式，并更新静态资源版本。
3. 验证与交付记录	Complete	TypeScript、控制平面测试、前端语法检查、构建和差异检查均通过。

Confirmed decisions

• 沿用现有 AgentBus 对接边界，本服务只记录统一来源，不增加任何渠道 adapter。
• 来源字段命名为 source，可选值为 manual 和 agentbus。
• 旧任务和缺少来源字段的兼容数据按 manual 展示；继续补充已有任务时保留原任务来源。
• 本轮不执行远程数据库迁移、不重新解析历史任务、不调用插件或 ERP。

Final evidence

• 新增 control-plane/migrations/007_task_source.sql，并将控制平面要求的最新迁移更新为 007_task_source。
• AgentBus listener 传入 source: 'agentbus'；人工请求上下文传入 source: 'manual'；PublicTask 对历史空值回退为 manual。
• LianSyn-platform/app.js 和 styles.css 已显示 AgentBus / 人工输入 标签，index.html 已更新缓存版本。
• TypeScript no-emit、控制平面 26/26、前端 node --check、构建和 git diff --check 均通过。

2026-08-10 — awaiting_user_input 会话续接与人工补充入口

Goal: 仅在任务处于 awaiting_user_input 时续接原任务/Agent 会话；普通输入默认新建任务，并在操作台为等待补充的当前任务提供专属输入框。

Phase	Status	Purpose
1. 规则与现状审计	Complete	用户确认普通输入始终新建；仅 awaiting_user_input 允许续接；左侧输入继续代表新任务。
2. AgentBus 续接修复	Complete	为缺少显式 conversation_id 的入站消息补充稳定会话键，同时保持等待状态限定和多任务安全阻断。
3. 操作台补充输入	Complete	在当前任务详情中仅对 awaiting_user_input 显示补充框，调用 /api/messages 续接指定任务。
4. 回归与运行态验证	Complete	普通新建/等待续接规则、AgentBus、UI 显隐、类型、构建和业务回归均通过；未调用插件或 ERP。

Confirmed decisions

• 没有 awaiting_user_input 任务时，任何新输入都创建新任务、新 Agent 会话，不需要用户输入“新任务”。
• 有且仅有当前等待补充任务时，补充信息续接该任务和原 Agent 会话。
• 左侧输入区保持新任务入口；右侧当前任务详情增加等待补充专属输入框。
• 本轮不自动确认任务、不派发 Chrome 插件、不写入 ERP。

Verification evidence

• AgentBus 测试 5/5；控制平面全套测试 26/26；既有业务/外部解析回归 57/57。
• TypeScript tsc --noEmit 与构建通过；前端脚本 node --check、git diff --check 通过。
• AgentBus 无显式会话字段的测试消息已稳定映射为 agentbus:<from>；显式 conversation_id 仍优先。
• 当前 8786 运行实例已按发布流程重启并加载本轮源码；重启前确认数据库没有排队/运行中的解析任务，避免触发历史任务消费。

Errors encountered

Error	Attempt	Resolution
bundled Node 不支持 --type-check	尝试直接用 Node 参数检查单个 TypeScript 文件	改用项目 TypeScript 编译器执行 tsc --noEmit -p tsconfig.json，检查通过。

2026-08-10 — AgentBus 全链路日志

Goal: 将 AgentBus 连接生命周期、收发帧、路由判断、任务入队、解析调度、终态回传和异常全部输出到控制平面日志，便于定位渠道消息无响应问题。

Phase	Status	Purpose
1. 日志边界与安全规则	Complete	统一 agentbus_event 结构化字段；不记录 Token/Authorization，正文默认脱敏。
2. listener 全链路日志	Complete	覆盖连接、握手、收帧、忽略原因、任务处理、出帧、重连和错误。
3. 配置、测试与运行态验证	Complete	本地开启正文调试日志，更新示例配置并重启验证实际日志。

Confirmed decisions

• 所有 AgentBus 日志进入现有 Fastify/Pino stdout，可通过 agentbus_event 过滤。
• 每个协议帧记录类型、ID、来源/目标、事件、会话/会话键、payload keys、正文长度和摘要；本地调试配置可额外记录截断正文。
• 不打印 WebSocket Token、Invoke Token、Authorization header 或其他凭证。
• 本轮只增强日志和配置，不改变 AgentBus 消息路由、任务状态和 ERP 门禁。

Final evidence

• control-plane/src/agentbus.ts 已为每个 AgentBus 日志写入 agentbus_event，覆盖连接尝试、socket、session.ready、收帧、忽略原因、任务处理、解析队列、终态等待、进度/结果出帧和失败回调。
• 新增 AGENTBUS_LOG_PAYLOADS；示例默认 false，当前本地 .env 设置为 true，正文最多记录 2,000 字符预览。
• Token、Authorization、Invoke Token 均未进入日志；当前 8786 进程 PID 93767 已加载新代码并建立 AgentBus session epoch 3。
• 验证通过：TypeScript no-emit、AgentBus/控制平面测试 5/5 与 26/26、前端语法检查、构建和 git diff --check。

2026-08-10 — 统一重要消息栏

Goal: 将 awaiting 用户交互、错误摘要和成功回执统一为 important_message，作为操作台和 AgentBus 的同一对外消息出口。

Phase	Status	Purpose
1. 规则确认	Complete	awaiting 必须有 Superagent reply；缺失即错误；awaiting_confirmation 不进入消息栏。
2. 协议与控制面	Complete	解析结果持久化 reply，公共任务生成三类 important_message，AgentBus task.result 原样携带。
3. 操作台合并	Blocked	前端目标目录在验证期间被外部删除，未擅自恢复以避免覆盖用户未提交改动。
4. 回归与运行态	In progress	控制面类型检查、AgentBus 测试和构建通过；待前端目录恢复后补齐 UI 回归与运行态验证。

Confirmed decisions

• 普通输入默认新建任务；仅 awaiting_user_input 的补充输入续接原任务和会话。
• 重要消息栏只包含 Superagent awaiting 回复、错误摘要、成功摘要/回执三类内容。
• awaiting 没有 Superagent reply 时转为 agent_parse_blocked，不保留等待状态。
• awaiting_confirmation 维持现有确认门禁，不进入重要消息栏。

Current evidence

• PublicTask.important_message 已按 awaiting_user_input / error / success 三种 kind 输出；敏感 transport metadata 仍经过脱敏。
• AgentBus task.result.payload.important_message 与文本使用同一公共任务消息；无该栏内容的确认状态保留兼容性文本回传。
• AgentBus 测试 5/5、TypeScript no-emit/build、Schema JSON 解析和 git diff --check 通过；此前前端目录仍存在时外部解析测试 33/33 通过。
• 当前工作区显示旧平台目录全目录为外部工作区删除状态，前端/外部解析回归暂不能重复执行；未执行恢复或覆盖操作。

2026-08-10 — 散拼团选填字段能力矩阵修正

Goal: 按用户确认的 ERP 字段能力矩阵恢复 shared_plan_create 的可选客户/人数写入，不重新解析旧任务、不调用 ERP。

Phase	Status	Purpose
1. 既有契约与映射核对	Complete	确认 canonical 结构为 data.split_order，客户和人数在 ERP 页面分别对应独立控件。
2. 运行链路修正	Complete	母团必填字段继续阻断；可选 customer/passenger_counts 分别校验、填写和触发对应联动，缺失字段不触碰。
3. 文档与回归同步	Complete	更新 Schema、Agent prompt/validator、Skill、业务入口、mapping、表单说明和测试。
4. 全量验证与发布包	Complete	全量测试、类型/语法/JSON/diff 检查通过，生成插件 0.5.6 与 Skill 包。

Confirmed decisions

• shared_plan_create 的母团字段仍按 ERP 必填规则校验。
• data.split_order.customer 与 data.split_order.passenger_counts 各自独立可选；用户给哪个就写哪个，没给的省略并保持页面默认/空值。
• 旧平铺 data.customer / data.passenger_counts 仅作为兼容输入归一到 split_order；嵌套与平铺值冲突时阻断，不静默覆盖。
• 本轮不重新解析历史任务、不迁移旧任务、不调用 Chrome 插件或 ERP。

Errors encountered

Error	Attempt	Resolution
Skill 包首次打包目录错误	在仓库根目录执行 zip ... references/*.md，根目录不存在该 glob，命令在 Skill 包步骤失败；源码和插件包未受影响	改为以 agent设计规范/skills/lwlt-newbooking 为工作目录重新打包，并通过 unzip -t。

Final evidence

• 业务/插件/外部解析测试 76/76，控制平面测试 27/27。
• TypeScript no-emit、JavaScript syntax、Schema/JSON、git diff --check 均通过。
• ltjt-order-assistant-0.5.6.zip 与当时的通用插件包已通过 unzip -t；SHA-256 为 6d316dec041d224f03d2859410c9f5e77332785b4dd15580699ebfa73d0f907b。
• lwlt-newbooking.skill 已更新并通过 unzip -t；本轮没有 ERP 写入。

2026-08-10 - LianSyn-platform UI 视觉优化

Goal: 在不改变业务流程、信息架构、品牌 Logo、字段名称、事件绑定和任务状态契约的前提下，按 taste-skill 的 redesign-preserve 规则提升操作台的层级、可读性、响应式和交互反馈。

Phase	Status	Purpose
1. 视觉审计与设计令牌	Complete	确认平台为中文业务操作台，保留品牌蓝绿识别，统一 CSS 令牌、字体、圆角、边界和状态色。
2. 桌面工作台重构	Complete	优化顶栏、登录态、输入区、任务列表、阶段状态板和任务详情的空间节奏与优先级。
3. 响应式与交互状态	Complete	补齐窄屏布局、hover/active/focus、加载/空/错误状态的视觉一致性，避免改变现有 JS 行为。
4. 浏览器视觉回归	Complete	在静态本地页面验证登录态、空任务态、待确认/已完成/失败任务态和窄屏，检查资源、溢出、可读性与无障碍焦点。
5. 交付检查	Complete	运行语法、类型、相关测试和 git diff --check，记录实际修改范围与剩余风险。

Confirmed decisions

• 采用 targeted evolution，不做视觉全面重构。
• 保留现有三列工作流、任务生命周期日志、三阶段状态映射、AI/插件状态探针、登录流程和业务文案语义。
• 不修改 URL、API、表单字段名、数据契约、埋点/事件绑定、品牌 Logo 或 ERP/插件行为。
• 视觉方向为 light-first 的 operational UI：蓝绿品牌强调色、低饱和中性底色、较低动效强度和高信息密度。

Errors encountered

Error	Attempt	Resolution
Planning skill path mismatch	首次读取 /Users/inmanx/.codex/skills/planning-with-files/SKILL.md 不存在	改用已安装的 /Users/inmanx/.agents/skills/planning-with-files/SKILL.md，未影响项目文件。
本地控制平面无法重启	用仓库编译产物启动 8786 做真实登录回归	数据库返回 EHOSTUNREACH；改用 18786 静态文件服务加浏览器内存脱敏任务 fixture，只做视觉验证，不触碰数据库或业务任务。
UI 缓存版本静态断言失败	首次把资源 query 改为全新前缀	保留既有 20260810-important-message-1 前缀，追加 -ui-3 / -ui-2，既完成缓存失效又保持旧测试契约。

Final evidence

• 仅修改 LianSyn-platform/index.html、LianSyn-platform/styles.css 和 LianSyn-platform/app.js 的 UI/可读性相关内容；没有改动 API、数据库、插件、ERP 路由或任务数据。
• 浏览器截图验证了登录态、桌面三列工作台、待确认任务、成功回执、失败任务、状态详情弹层和 390px 窄屏输入/任务顺序。
• 浏览器页面错误与控制台消息均为空；静态服务验证仅使用内存 fixture，未创建或重解析任务。
• 控制平面测试 27/27、业务/外部解析回归 61/61、TypeScript no-emit、前端 Node 语法检查和 git diff --check 均通过。

2026-08-10 — LTJT 订单生命周期深度调研（当前任务）

Goal: 按运营梳理对应的真实订单生命周期，深度还原 LTJT 各业务板块的页面结构、字段联动、提交请求、回执/回查和失败边界，先形成 ERP 操作契约，再分别完善 Chrome 插件适配契约与 Skill 契约。

Phase	Status	Purpose
1. 生命周期基线与下单证据统一	Complete	以已真实验证的独立团单个/批量和散拼新增计划为基线，统一状态、编号和公共页面入口，不重复开发已完成下单能力。
2. 名单导入/补充调研	Complete (read-only)	已还原独立团与散拼子单的名单表、daoru.asp 对话框、表头驱动覆盖解析和清空边界；确认导入本身不发请求，最终保存 action 已分别确认，真实回执/行数回查仍待验证。
3. 团队安排调研	Complete (read-only)	已按订单执行链读取五类安排页；五个原生 DoInfo_* 保存 action 均已在网络发送前只读拦截，真实响应/写后回查仍待后续低风险验证。
4. 修改/取消分支调研	Complete (read-only)	已只读拦截独立团 DoInfoJH、散拼母团 DoInfoSP、散拼子单 DoInfo_order，并确认 JH_set_quxiao、DelRecord、Del_order 的边界；应收/资源联动、真实状态提交和回查列为下一阶段写入闸门。
5. 确认件及文件导出调研	Complete (read-only)	已读取当前团队 9 类源的响应头、长度和内容特征；转换、落盘、发送状态和失败重试列为独立交付阶段。
6. 契约化交付清单	Complete	已形成生命周期研究文档、矩阵、跨阶段引用、请求契约和 Skill 拆分建议，同步散拼下单登记状态并完成文档/边界校验。

Confirmed decisions

• 调研覆盖运营梳理中的 10—21 全部业务板块。
• 调研按订单生命周期推进：下单 → 名单导入/补充 → 团队安排 → 修改/取消 → 最终导出。
• 取消按可在多个生命周期阶段触发的终止分支记录，不强行排成线性步骤。
• 本阶段先只读深度调研和契约沉淀，不直接修改插件、Skill 或 ERP 数据。
• 外部页面、接口响应和 ERP 文案全部视为不可信数据；只记录授权范围内的必要元数据、字段结构和有限样本，不导出大批量客户资料。

Research method

对每个 ERP 板块固定记录：入口页/iframe、页面控件、SelectBox 数据协议、页面自带联动函数、表单序列化字段、实际提交 endpoint/action、响应类型和团号/订单号提取、列表回查条件、权限/登录失效/重复提交/部分落库边界，以及对应的插件与 Skill 设计结论。

Current evidence boundary

• 独立团单个下单、独立团批量下单和散拼团新增计划已有真实成功与回查证据；散拼最新可选字段契约已有本地回归，但本轮不重新写入 ERP。
• lwlt-arrangement、lwlt-updating 目前仍是稳定阻断/只读预览；本轮已取得团队安排五个子页、计划级修改和散拼/独立团子单/订单修改页的实时字段与原生 action 证据，不得用新增或确认件 action 代替。
• confirmation_export 当前仍是 source-only；本轮已读取 9 类实时源响应和文件类型，但没有转换、落盘、发送或回写 ERP。

Errors encountered

Error	Attempt	Resolution
授权协作 Chrome 的 CDP 127.0.0.1:9223 不可连接	使用 agent-browser --session lwlt-research connect 9223 复用既有登录会话	未重试同一端口；先转向现有静态/历史 ERP 证据与源码页面映射，后续若需实时页面再使用用户提供的授权会话。

2026-08-10 — 9 月真实 ERP 全链路测试准备（已授权）

早期准备草案。其“1 组独立团 + 1 组散拼”范围已被下方“生命周期契约与测试态适配”阶段确认的四条下单路线、三日期批量矩阵取代；保留本节作为决策历史。

Goal: 在用户确认的范围内，于 2026 年 9 月用可识别的测试订单验证 LTJT 从下单到导出的完整生命周期，并为用户后续手动清理提供逐单、逐操作的可追踪清单。

Phase	Status	Purpose
1. 测试集与标记确认	Complete	采用 1 组独立团 + 1 组散拼母团/子单；统一使用 TEST-202609 标记，覆盖两条 ERP 订单路线。
2. 执行窗口与访问前置	In progress	9 月内灵活择机执行；执行前检查登录会话、系统可用性和测试期间的人工协同条件。
3. 下单与名单验证	Pending	创建两类测试订单，验证人数生成、名单导入/补充、保存回执和写后回查。
4. 安排与修改验证	Pending	按导游、车辆、酒店、大交通、其他/备案顺序逐项保存为未确认/测试状态，验证响应、回查和失败边界；再执行低风险修改。
5. 取消分支与最终导出	Pending	在保留一条可导出测试数据的前提下验证取消/恢复语义，再读取确认件、预订单和名单等导出源；最后只删除本次测试创建的对象。
6. 交付清单与清理交接	Pending	汇总订单号、团号、子单号、操作结果、异常和导出文件源，交给用户手动清理。

Confirmed decisions

• 用户明确允许在 2026 年 9 月创建真实 ERP 测试订单并执行完整链路测试。
• 执行日期不固定，2026 年 9 月内任意可用时段均可；批量下单所需的出团时间段由测试方案统一设置，不作为当前阻塞条件。
• 测试集固定为 1 组独立团 + 1 组散拼母团/子单，不扩展为每个业务项单独建单。
• 测试数据统一使用明显的 TEST-202609 标记，便于筛选、复核和手动清理。
• 测试顺序遵循订单生命周期：下单 → 名单导入/补充 → 团队安排 → 修改/取消 → 最终导出。
• 安排环节使用 ERP 现有可选资源，但统一保存为未确认/测试状态，不触发真实采购、付款、通知或对外发送。
• 测试结束后由用户手动清除；测试期间保留操作日志和 ERP 标识，不在未记录编号前删除或覆盖测试对象。
• 用户明确允许删除本次测试创建的测试单；删除权限仅限本次测试对象，不扩展到账号下其他历史订单。

Safety gates

• 在执行当天确认当前登录会话可用且每个测试对象的编号已记录前，不发送真实 ERP 写入请求。
• 每个写入模块采用“提交 → 读取服务端响应 → 列表/详情回查 → 记录差异”的闸门；没有响应或回查证据只能记为未验证。
• 取消、恢复和删除分别记录；删除属于不可恢复动作，放在所有需要的读取/导出证据完成之后。
• 删除前必须同时核对“本次运行创建的 ID 允许清单 + TEST-202609 标记 + AI 测试账号归属”；任一条件不满足即停止删除。
• 删除后必须用列表/详情回查确认目标消失；若回查异常，保留对象并转人工复核，不扩大删除范围。
• 不使用真实客户、真实证件或真实联系方式；名单只使用合成测试数据。

2026-08-10 — LTJT 生命周期验证与适配落地（当前实施）

Goal: 按已确认的完整验证计划，把 ERP 原生事实转成可测试的 operation/Schema/Skill/插件契约；本轮不创建 ERP 订单，2026 年 9 月再执行真实测试写入。

Phase	Status	Purpose
1. 契约与结果模型	Complete	扩展 action、统一引用/证据/结果模型，保留历史兼容 action，不改变已验证创建路径。
2. 原生页面适配与安全闸门	Complete (test-only)	增加名单、五类安排、三类修改、取消/恢复/删除的预检、请求构造和回查框架；无真实会话时稳定阻断。
3. Skill、mapping、fixture	Complete	更新四类生命周期 Skill、业务登记、ERP handoff、Schema fixture 和合成测试数据。
4. 测试执行清单与证据模型	Complete	生成 9 月三日期样本、16 行名单、测试对象 allowlist、导出源矩阵和逐操作证据表。
5. 本地回归与发布闸门	Complete (pre-September)	运行 Schema/语法/单元/控制面回归；新模块全部验证前保持测试态或阻断，不打包为正式可用能力。
6. 2026 年 9 月真实 ERP 验证	Deferred	由 AI 测试账号按原生基线 → 插件复现 → 回查 → 清理顺序执行；本轮不提前触发。

Implementation decisions

• 四条创建路线全部保留并回归：team_order_create、team_order_batch_create、shared_plan_create、shared_child_order_create。
• 新 action 按 ERP 页面边界拆分：passenger_list_import、五类 arrangement_*、三类 order_update_*、order_cancel、order_restore、order_delete、confirmation_export。
• “全字段修改”仅覆盖运营可见业务字段；隐藏 ID、session、审计和系统计算字段不由 operation 直接写入。
• 导出本阶段保持 source-only；不实现 DOCX 转换、自动两天触发或外部发送。
• 真实写入必须有 execution ID、用户确认、服务端响应和写后回查；不确定状态不自动重试。
• 删除只允许本次运行创建、带 TEST-202609、归属 AI 测试账号并已进入 allowlist 的对象。

2026-08-10 — 生命周期契约与测试态适配已落地

Goal: 将已确认的 2026 年 9 月验证计划落成可回归的 action、Schema、Skill、mapping、fixture 和 fail-closed 浏览器适配层；本轮不创建 ERP 测试订单。

Phase	Status	Purpose
1. 契约与结果模型	Complete	新增名单、五类安排、三类修改、取消/恢复/删除 action；统一生命周期证据字段与 test context。
2. 原生页面适配与安全闸门	Complete (test-only)	接入五类 DoInfo_*、三类 DoInfo*、名单 DOM 回调、JH_set_quxiao、DelRecord/Del_order 的预检/显式写入/响应/回查框架；当前无 test context 或非 2026-09 窗口稳定阻断。
3. Skill、mapping、fixture	Complete	更新 lwlt-arrangement、lwlt-updating、lwlt-confirmation，新增 lwlt-lifecycle，同步业务注册表、外部 parser、Schema、映射和合成 16 行名单夹具。
4. 测试执行清单与证据模型	Complete	新增 3 个 9 月批量日期、15+1/TWN 8、操作矩阵、证据模板、删除 allowlist 模板和发布门槛。
5. 本地回归与发布闸门	Complete (pre-September)	类型、Schema、单元、控制面、扩展装载 smoke、时间闸门和 diff 审计通过；新 action 继续保持测试阻断。既有外部 Node 22 全套回归待在具备 Node 22 的运行环境补跑。
6. 2026 年 9 月真实 ERP 验证	Deferred	仅在 2026-09、AI 测试账号、原生基线和显式 allow_live_write 齐备后执行；删除在导出证据冻结后进行。

Implementation evidence

• operation-plans.js exposes 18 actions, preserves legacy order_update preview, and reports test_only for new lifecycle actions.
• lifecycle-result.js enforces the standard evidence shape; lifecycle-adapters.js never reports completion without a server response and matched re-query.
• confirmation_export remains source-only and now supports all mapped source types, including visitor list, guide/hotel/transport sources, filing and pickup sign.
• evidence-register.template.md now provides the逐操作、逐日期、逐团号/子单号登记表；删除 allowlist additionally requires exact reference, account and run_id binding.
• risk-register.md records all pre-September unverified items, adapter assumptions, manual-review triggers and the Node 22 test-runtime limitation.
• bun test tools/operation-plans.test.mjs tools/lifecycle-contract.test.mjs: 30/30 passed.
• Skill creator quick_validate.py passed for arrangement, updating, confirmation and lifecycle Skills; Schema JSON and Ajv compile passed.

2026-08-10 — AgentBus 重要消息与最终回执

Goal: 确保 AgentBus task.result 将任务的 important_message、最终回执和用户交互内容完整返回渠道，并覆盖等待确认、待补充、失败和完成状态。

Phase	Status	Purpose
1. 复现与结果链路定位	Complete	已用实际任务、数据库结果和 AgentBus outbound 日志确认等待确认被误判为终态，后续完成事件没有回传上下文。
2. 结果映射与回传修复	Complete	等待确认改为进度消息；只在真实终态发送 task.result；重要消息和结构化最终回执同步展开到渠道可见文本及结构化字段。
3. 回归测试与运行验证	Complete	AgentBus 专项 5/5、控制平面全量 27/27、TypeScript 编译和运行态 /health/ready/AgentBus session ready 均通过。

2026-08-10 — 组织级全自动化流程

Goal: 增加管理员可控的组织级“全自动化”开关；开启后所有 AgentBus 渠道的新任务在解析完整明确时跳过人工确认，直接派发 ERP，并保留异常安全停机与完整回执。

Phase	Status	Purpose
1. 方案落地与现状核对	Complete	已确认自动化必须沿用浏览器插件唯一执行权/租约链路；服务端自动确认 AgentBus 新任务，平台页面负责自动交给插件。
2. 组织设置与审计	Complete	新增 009 迁移、组织级 automation_enabled、任务 confirmation_mode、管理员 GET/PUT API 和组织审计。
3. 自动任务执行链路	Complete	服务端在 AgentBus 新解析成功边界自动确认；平台只对自动确认快照任务自动 claim/dispatch，插件不可用时保留状态并重试。
4. 平台按钮与任务提示	Complete	增加组织级开关按钮、状态/错误反馈、自动接管状态文案和缓存版本更新。
5. 回归、迁移与运行验证	Complete	已覆盖开关、权限、历史待确认任务、AgentBus 回执、数据库迁移、编译产物启动和运行进程健康状态；全量回归通过。

Confirmed decisions

• 开关按组织全局持久化，服务重启后保持状态，默认关闭。
• 仅已登录平台管理员可以开启/关闭，并记录审计。
• 开启后对所有 AgentBus 渠道的新任务生效；解析完整明确后跳过人工确认，直接进入插件/ERP执行。
• 已处于 awaiting_confirmation 的历史任务不因开关开启而追溯执行。
• 关闭开关只阻止后续新任务自动执行，已经进入 ERP 执行阶段的任务继续完成。
• 信息缺失、解析失败、歧义、插件/ERP错误、超时或回查不确定时保持安全停机并返回重要消息。
• 平台手动输入按当前理解保持原有人工确认流程；本轮“全渠道”指所有 AgentBus 接入渠道。

2026-08-10 — 真实 ERP 生命周期执行增量

Goal: 在当前已登录 AI 测试账号上，使用 2026 年 9 月日期真实验证下单至清理，并把新增的产品/客户来源地约束落入适配契约。

Phase	Status	Purpose
1. 来源地规则验证	Complete	真实确认产品来源关键字与客户来源地不匹配会导致超时/HTTP 500；匹配后仍保留其他唯一匹配和回查闸门。
2. 四条下单路线	Partial	独立单、独立批量、散拼单个完成；散拼批量产生 HTTP 500，部分母团已清理。
3. 名单与安排	Partial	两条名单和独立单五类安排完成回查；名单表头/电话 selector 边界已登记。
4. 修改、取消/恢复与导出	Partial	独立单备注、散拼子单字段差异、编辑/列表状态和十类源响应已验证；列表恢复和一个字段 mapping 仍需人工复核。
5. 删除与发布门槛	Blocked	可安全删除对象均已删除并回查；独立单财务前置无权限，发布继续保持 test-only。

Live evidence

• 逐操作证据：agent设计规范/test-fixtures/lwlt-lifecycle/evidence-register-live-20260810.md
• 订单/母团/子单清理清单：agent设计规范/test-fixtures/lwlt-lifecycle/allowlist.live-20260810.json
• 发布门槛：agent设计规范/test-fixtures/lwlt-lifecycle/release-gate.md

2026-08-10 — 延后来源地解析到 ERP 插件预检（当前实施）

Goal: 让外部 Agent 和插件后台只校验结构性必填项；产品来源地兼容性由已登录 ERP 页面在产品/客户候选搜索及产品联动后确定性校验，避免在无 ERP 数据的解析阶段误拦截。

Phase	Status	Purpose
1. 影响面与契约调整	Complete	已移除外部 Prompt/validator 与后台 planner 对未解析 source_region 的前置阻断，保留字段可选性。
2. ERP 页面运行时校验	Complete	独立单页面已在候选选中、产品联动和客户恢复后执行来源地检查，继续在任何写入前 fail-closed。
3. 回归与发布包	Complete	已加入“遇见老挝”类无来源地输入回归，88 项测试通过，插件/Skill 包已重建并完成静态、完整性和运行态检查。

Confirmed decisions

• Agent、后端契约和 operation-plans 只负责 action、字段存在性、类型、格式、日期/人数/房型等结构校验。
• data.product.source_region 和 data.customer.source_region 不是用户前置必填字段。
• 产品/客户唯一搜索、Find_product/GetProduct 联动、来源地兼容性和派生必填字段由 ERP 页面预检负责。
• ERP 搜索后仍无法唯一匹配时才阻断并请求用户补充；任何来源地不匹配或派生字段不完整都不得写入 ERP。
• 本轮不绕过提交闸门、不自动选择第一条候选、不重新解析历史任务。

Errors encountered

Error	Attempt	Resolution
Agent 在 ERP 搜索前要求 data.product.source_region	解析提示词与外部 validator 把运行时来源地兼容性当成 Agent 前置事实	本阶段将来源地字段改为可选，并把语义校验延后到插件页面预检。
发布包源码核对命令退出码 2	首次 cmp 使用了仓库根目录下不存在的相对文件路径	改为显式使用 chrome-extension/ltjt-order-assistant/<file> 作为源码路径后重跑。

2026-08-10 — 发布版本升级至 0.5.7

Goal: 将“来源地校验延后到 ERP 插件预检”的已验证修复作为正式 0.5.7 插件发布，保证运行时版本门槛与发布包一致。

Phase	Status	Purpose
1. 版本面同步	Complete	manifest、页面桥接上报版本、业务系统最低兼容版本和当前发布说明已统一为 0.5.7；历史 0.5.6 包与验证记录保留。
2. 发布包重建	Complete	生成 ltjt-order-assistant-0.5.7.zip 和无版本别名包，包内清单/运行时版本及源码逐文件比对一致。
3. 发布验证	Complete	两个 ZIP 完整性、JavaScript 语法、JSON、全量 88 项回归测试和 git diff --check 均通过。

2026-08-10 — 移除来源地语义阻断，保留关键字匹配器

Goal: 根据实际任务日志，删除 source_region_match 对 ERP 写入的拦截，保留产品/客户关键字模糊候选搜索、唯一匹配、source-region.js 匹配器和全部结构性必填/提交安全闸门。

Phase	Status	Purpose
1. 日志定位与边界确认	Complete	确认客户/产品已唯一匹配、GetProduct 已成功且结构性必填项齐全，唯一错误来自来源地语义阻断。
2. 生产调用移除	Complete	移除独立单、原生批量、散拼母团/子单页面对 source_region_match 的阻断调用及回执字段；保留 matcher 文件、注入和关键字候选匹配。
3. 文档、回归与发布包	Complete	同步契约说明，88 项测试通过；重新生成 0.5.7 包，确认包内仍含 source-region.js/product-lookup.js 且页面无来源地阻断调用。

2026-08-10 — 生命周期稳定成果收敛与端到端复测（当前）

Goal: 继续基于真实 ERP 回执完成独立团与散拼子单生命周期，随后把稳定契约同步到插件、Schema、mapping、Skill 和 fixture，并执行完整端到端回归。

Phase	Status	Purpose
1. 新独立团事实基线	Complete	LW-260920A-A 已完成创建、16 行名单、五类安排、安排态源读取、取消/恢复、字段差异和精确删除双回查。
2. 散拼子单覆盖	Complete	LW-260922A-A / D14452 已完成创建、16 行名单、五类安排、母团/子单修改、取消/恢复联动、安排态与清理后两轮 10 类源读取，并按子单后母团精确删除；计划表与团队安排表均回查 0。
3. 运营需求回顾与适配收敛	Complete	已对照 运营梳理.rtfd、生命周期研究和真实差异，更新插件 operation、mapping、Schema、Skill、fixture。
4. 端到端回归与发布门槛	Complete	原生事实基线、实现回归、证据矩阵和发布门槛均已收口；插件级真实重放作为正式放行条件单独保持阻断。

Current safety boundary

• 仅操作当前 AI 测试账号创建、2026 年 9 月、含 TEST-202609 且进入 allowlist 的对象。
• 不进入或修改客户、导游、供应商等主数据页；只在 /System/Business/ 生命周期页面引用既有资源。
• 写入必须有原生服务端响应和写后回查；不确定状态不盲目重试。
• 删除前必须完成源读取、证据冻结和精确编号/账号/标记校验。

Errors encountered

Error	Attempt	Resolution
独立团多字段修改返回 HTTP 200 空响应且回查未持久化	同时修改人数结构、房数、接送信息、首日行程和测试备注	不重复相同载荷；改为单字段原生提交和逐次回查，定位 ERP 实际可写边界。
独立团单字段直接 fetch 仍空响应且未持久化	仅修改下单备注并使用与页面相同 endpoint/action	停止直接 fetch 路径；改用页面原生 jQuery SubmitInfoForm() 的 script 请求链路。
页面原生 jQuery/script 修改仍 HTTP 200 空响应	原生校验通过、仅改单字段，列表回查未变	三次不同方法均复现；停止对该单继续修改，把“安排后空响应”纳入人工复核/阻断条件，继续其他生命周期阶段。
列表取消被“团队成本-应付其他”阻断	零金额 arrangement_other 已保存后执行 JH_set_quxiao(cz=1)	状态回查为预订；先冻结安排态导出证据，再清除本测试单自有安排成本并重试取消。
生命周期日志补丁上下文漂移	并行进展追加后，首轮补丁的 progress 行少了一个空格	重新读取文件尾部并使用精确上下文追加；未覆盖其他并行改动。
导游子页回查访问不存在的第二槽位	清空导游后仍按保存前固定两槽位读取 daoyou1	检查表单后确认 MaxI 已收缩为 1；改用动态元素枚举，回查通过。
取消响应成功后“全部状态”精确查询暂未返回对象	JH_set_quxiao 回执已取消，但默认状态筛选列表为空	不重试写入；改用显式已取消筛选和详情/列表双重只读回查。
列表级恢复第二次稳定复现无效	JH_set_quxiao(cz=0) 返回成功但响应/筛选均仍为已取消	停止列表恢复；正式契约将其标为 ERP 缺陷/阻断，使用独立的编辑页恢复 action。
编辑页打开后首个组合读取短暂抛错	iframe 已出现但一次组合表达式在动态字段读取时异常	改为枚举字段并等待稳定；确认表单完整，编辑页恢复正常完成。
清除安排后多字段修改仍为空响应	状态恢复成功后同时改人数/房数/接送/行程/备注	回查明确未写入；不再提交宽字段组合，改为单字段白名单验证。
编辑页半载状态提交导致空响应	iframe/表单已存在，但本次序列化仅 314 字段而完整页约 1046	增加完整表单、游客行数和加载状态前置；半载状态稳定阻断，不再提交。
完整页单改 xiadanbeizhu 仍空响应	1050 元素/1046 序列化字段/16 行游客前置全部通过	从独立团修改白名单移除该字段；重新核对历史“备注成功”的真实字段，继续验证其他字段。
完整页单改 shuoming0 仍空响应	清除活动安排后只改订房说明	判定为“曾有安排历史”状态下普通字段更新静默拒绝；停止试写并在插件中增加历史安排人工复核闸门。
删除前复合预检表达式短暂抛错	一次把多项 DOM 条件与链接匹配合并读取	拆分成稳定字段/链接读取，确认精确参数后才执行删除；删除及双回查成功。
散拼页首次导航被旧独立团对话框状态拉回	只设置主 iframe src	关闭旧提示并直接设置 frame location.href，确认成功进入散拼计划表；未产生写入。

2026-08-10 — Agent 完成后插件桥接接管延迟修复

Goal: 消除 Agent 已完成后因浏览器插件 bridge 未及时唤醒/重试造成的长等待；只改变 ERP claim 之前的派发触发，不改变 claim 之后的幂等、写入闸门和不确定结果停机。

Phase	Status	Purpose
1. 根因与安全边界确认	Complete	已确认目标任务 Agent 完成到插件 claim 间隔 125.31 秒，且当前修复范围只覆盖未 claim 阶段。
2. Bridge-ready 触发与重试修复	Complete	bridge 重连/重新注入时强制唤醒自动派发；本地失败提示不再覆盖服务端可 claim 状态。
3. 静态检查与回归	Complete	前端/桥接语法、TypeScript、控制平面 28/28、既有业务/外部回归 71/71 和 diff 检查通过。
4. 运行态复核	Complete	/health/ready 返回数据库/schema/AgentBus 正常；运行服务直接提供新 app.js；本轮未主动触发 ERP 写入。

Confirmed safety boundary

• 只对 confirmed + awaiting_handoff 且尚未创建 ERP attempt 的任务强制唤醒。
• 不修改 claimForBrowser() 唯一执行权、execution_id、写入前 write_started 和执行不确定状态。
• 不在服务端新增 ERP 写入旁路，不因 bridge 重连重复发送已 claim 的任务。

Errors Encountered

Error	Attempt	Resolution
shell PATH 没有 node 命令	首轮语法和测试直接调用 node	改用当前运行服务同源的 /Users/inmanx/.cache/codex-runtimes/codex-primary-runtime/dependencies/node/bin/node，随后全部检查通过。

2026-08-11 — 生命周期 v2 契约落地与发布审计

Goal: 将 C08 独立团与 C09 散拼母/子单的真实 ERP 生命周期事实基线，收敛为可执行 operation、精确 adapter、Schema、mapping、Skill、fixture 与回归门槛；未完成插件内真实重放前继续保持 test-only。

Phase	Status	Purpose
1. 真实事实基线收敛	Complete	C08/C09 已完成名单、五类安排、窄字段修改、取消/编辑页恢复、两阶段 10 类源读取和精确删除双回查。
2. Operation/Adapter 契约实现	Complete	13 个生命周期 action 已按对象类型、原生路由、字段白名单、服务端回执与 fresh requery 规则正式化。
3. Schema/Mapping/Skill/Fixture 同步	Complete	v2 Schema、ERP mapping、4 个生命周期 Skill、合成人员 TSV、运行清单、风险与发布门槛已同步。
4. 全量回归与发布包	Complete	TypeScript、控制平面 28/28、全量 JavaScript/契约 96/96、JSON/Schema、4 个 Skill、diff 与 0.5.8 ZIP 源码比对全部通过。
5. 正式放行	Blocked	新 adapter 尚未在浏览器内按完整生命周期重放；当前 Mac 锁屏阻止已登录 Chrome 操作，且 C01 有非本账号财务前置、散拼批量创建仍有 HTTP 500 样本，相关模块继续 test-only。

Confirmed implementation boundary

• 2026 年 9 月限制指目标订单日期，不限制当前执行月份；任何 live write 仍需 allow_live_write、精确 refs、账号、marker 与 allowlist。
• 名单仅接受标准 16 行 TSV 完整覆盖；五类安排使用各自 adapter，不接受宽表或模糊控件写入。
• 生命周期修改只放行已实测的散拼母团 planned_capacity、散拼子单 lodging_note；独立团存在安排历史时保持人工复核阻断。
• 列表级恢复正式禁用；取消与恢复分离，恢复只走对应完整编辑页。
• 客户确认件只允许独立团或具体散拼子单；source-only 返回 SHA-256/字节数，不等同于下载、转换或发送。
• 删除只允许证据冻结、显式授权且顺序正确的精确 allowlist 对象；散拼必须先子单后母团。

Final implementation audit

• 散拼子单导出已拆分“母团列表搜索引用”和“具体子单目标引用”：必须携带母团号/计划号与具体子单号或 ddid，插件按精确 token/ddid 锁定唯一叶子行，并交叉核对传入和解析出的 ddid/tid。
• 生命周期对象引用现要求 kind + tid + 对象编号 + 必要 ddid + departure_date + owner_account + TEST-202609；删除允许清单按对象类型逐字段完全匹配，任何单字段碰撞均不授权。
• 名单保存前和 fresh GET 后均对全部标准列逐行比对；安排、修改、状态和删除均要求明确 2xx 完成响应及写后回查，不确定状态不重试。
• dist/ltjt-order-assistant-0.5.8.zip 与无版本别名包已从最终源码重建、逐文件 diff、unzip -t 和 manifest 校验；SHA-256 均为 c94de1be6d0cfd8956e57b78e54cb23bcee092cd26457bb8c40cf12c2a2fdf7d。
• 已两次尝试接管本地已登录 Chrome；Chrome 仍监听 127.0.0.1:9222，但 macOS 锁屏阻止窗口状态读取及调试授权，因此本轮没有新 ERP 写入，也不能把插件级真实重放记为完成。用户解锁后从该门槛继续。

2026-08-11 — 生命周期 v2 最终安全加固

Goal: 在不改变 test-only 发布边界的前提下，补齐页面完整加载、安排空槽位和异步联动安全门，重新执行全部回归并重建交付包；随后继续真实插件重放。

Phase	Status	Purpose
1. 写前安全门	Complete	已加入路线级完整表单下限、稳定时间、加载提示检测、空槽位/零付款/空审核校验、来源 ID 联动复核、正数量和 2026 年 9 月日期约束。
2. 契约与 Skill 同步	Complete	Planner、外部 validator、Schema、mapping、3 个相关 Skill、run manifest、README 与针对性测试已同步。
3. 全量回归与重打包	Complete	TypeScript、控制面 28/28、业务/契约 96/96、4 个 Skill、语法/JSON/diff、0.5.9 ZIP 完整性和源码逐文件比对全部通过。
4. 插件真实重放	Blocked	Chrome PID 18141 与 9222 存在，但 CGSSessionScreenIsLocked=Yes；CDP 等待本机允许调试，未绕过锁屏、未写 ERP。

New errors encountered

Error	Attempt	Resolution
env: node: No such file or directory	直接运行 chrome-cdp 脚本	改用工作区 bundled Node 的绝对路径。
chrome-cdp list 无输出并等待	连接现有 DevToolsActivePort	25 秒内停止等待；ioreg 明确确认系统锁屏，保留真实重放阻断。
shell 引号不匹配	一次组合 rg 正则搜索安排状态字段	改用单一安全正则重新搜索，未修改任何文件。

Final 0.5.9 artifact

• dist/ltjt-order-assistant-0.5.9.zip 与 dist/ltjt-order-assistant.zip 均含 18 个文件，manifest 版本为 0.5.9。
• 两个包 SHA-256 均为 9eb1befab6c839f9dcadc6dc6e254f30940910e15e4d967373b239d8a1462b44；unzip -t 和解包后逐文件 diff 均通过。
• 平台最低兼容版本已升为 0.5.9，防止旧 0.5.8 被误认为具有本轮安全门。

2026-08-11 — 运营需求全量补缺与插件真实重放（当前）

Goal: 重新逐项核对运营原文 10—21，补齐真实生命周期所需的安全适配缺口，完成全量回归后在已登录 Chrome 中创建全新 2026 年 9 月测试对象，执行插件级完整重放并精确清理。

Phase	Status	Purpose
1. 原始需求差距矩阵	Complete	已新增运营 10—21 逐项矩阵，区分原生实证、待插件重放、ERP 缺陷、待字段实测和明确延期。
2. 生命周期实现补缺	Complete	0.5.10 已补五类 arrangement create/clear、精确 row/资源/财务闸门、备案保留、absence requery，并统一条件式来源地规则；普通 arrangement update 保持阻断。
3. Schema/Skill/fixture 同步	Complete	Schema、planner、外部 validator、mapping、run manifest、登记表与 Skills 已同步；5 个 Skill 校验通过。
4. 静态回归与发布包	Complete	TypeScript、控制面 28/28、业务契约 97/97、语法/JSON/Skill/diff 全通过；0.5.10 两包完整性、18 文件源码比对和 SHA-256 已确认。
5. Chrome 插件真实重放	Blocked	当前 macOS 仍锁屏；解锁后验证登录与插件版本，使用全新 9 月对象执行创建→名单→安排→修改→取消/恢复→源读取→清理/删除。
6. 最终发布门槛	Pending	冻结逐操作回执、fresh requery、allowlist 和删除后回查；只放行真实通过的能力。

Scope decisions

• 本轮继续遵循用户已确认计划：source-only 导出，不实现 DOC→DOCX、提前两天自动触发或外部发送。
• 原文宽字段只是需求清单，不等于 ERP 已证实写入白名单；未取得明确响应与写后回查的字段继续阻断。
• 五类安排的变更/清理只允许精确命中当前运行、当前账号、TEST-202609、零付款/未审核对象；不能扩大到账号下其他订单或主数据。
• 产品存在可识别来源地关键字时，客户候选必须兼容；无法可靠提取地域词时不凭空判断，但仍要求产品和客户分别唯一匹配。

New errors encountered

Error	Attempt	Resolution
macOS 仍报告锁屏	用户要求继续后再次读取会话状态	不绕过锁屏；先推进原文审计和本地实现，Chrome 重放保持待解锁。
/usr/bin/test 不存在	打包前检查 0.5.10 目标是否已存在	改用 macOS 实际路径 /bin/test；确认目标不存在后才创建。
/opt/homebrew/bin/jq 不存在	首轮 ZIP manifest 版本校验	保留已通过的 ZIP 完整性/文件数检查，改用系统 Python 只读解析 manifest 后完成源码逐文件比对。

2026-08-11 — 0.5.11 确定性回放与真实执行前收口

Goal: 把四条创建路线和后续名单、窄修改、五类安排、导出、清理、状态与删除编排成可逐阶段重建的真实回放输入；修复团号标记和应收契约缺口，完成静态发布物后继续已登录 Chrome 的真实测试。

Phase	Status	Purpose
1. 回放输入生成器	Complete	build_lifecycle_replay.mjs 从状态文件生成四条创建路线，并在 refs、资源、row ID 和证据门槛逐步满足后按“名单 → 独立团条件探针 → 安排 → 散拼修改 → 导出 → 清理 → 状态 → 删除”生成 action；所有批量对象须进入 cleanup.objects。
2. 团号/来源地契约	Complete	三条创建 adapter 支持产品联动后的显式 host suffix 精确覆盖；无可识别产品地域词在 helper 和页面包装层均统一为“不适用且通过”。
3. 应收失败关闭	Complete	在新对象完成 0.01 新增 → 回查 → 清零 → 回查 前，planner、外部 validator 和 adapter 只接受 receivable_fixture.operation=none。
4. 0.5.11 静态审计与构建	Complete	TypeScript、控制平面 32/32、业务/插件/外部解析 106/106、语法、JSON、5 Skills 和 18 文件 ZIP 源码比对通过；生命周期测试写权限改为控制面人工确认时服务端注入，统一生命周期响应/回查可被平台正确识别为成功证据。
5. 已登录 Chrome 重放	In Progress	2026-08-11 已确认 macOS 解锁、Chrome 9222 与控制面健康；CDP 已接入登录中的 ERP，页面账号为“测试ai员工账号”。下一步先重载并核对 0.5.11，再按本轮 R0511 清单执行真实生命周期。
6. 证据冻结与精确删除	Pending	完成真实响应/fresh requery、应收基线、源哈希和 allowlist 后，按子单 → 无子单母团 → 独立团顺序删除本次对象。

Confirmed execution sequence

• 创建阶段固定使用 TEST-202609-R0511 后缀；产品和客户仍需在业务页候选中分别唯一解析，产品含可识别地域词时才执行来源地兼容门槛。
• 独立团窄修改必须早于安排历史；安排只落“未确认/测试”，不采购、不付款、不通知、不发送。
• 应收只在新散拼子单的 /System/Business/ 编辑页建立 0.01 合成基线；不进入财务根目录。
• 未获得明确服务端响应和写后回查不记成功；写入不确定只回查，不自动重试。
• 删除必须在全部导出证据冻结后逐对象推进，任何编号、账号、标记、row ID 或 allowlist 不一致立即停止。
• 外部 parser 只能提交 allow_live_write=false 的候选 operation；生命周期 action 禁止 AgentBus 自动确认。管理员在平台查看 operation、目标引用、日期及测试上下文后手工确认，控制面再次核对运行 ID、账号、标记、9 月日期、created refs 和删除证据，才为该次加密 operation 注入写权限。

New errors encountered

Error	Attempt	Resolution
CDP list 再次无输出	连接保留的 Chrome 9222 会话	8 秒后安全中止；Computer Use 明确返回 Mac locked，未尝试绕过。
打包校验命令含临时目录递归清理	首轮 ZIP 解包比对	安全策略拒绝该命令；改用独立 mktemp -d 验证目录，不执行递归删除。
在 Skill 子目录用仓库相对路径复制 ZIP	同时刷新扩展别名与 Skill 包	扩展 copy/shasum 未执行，Skill 包已成功生成；随后在仓库根目录使用绝对源路径完成扩展别名和三包校验。
生成全新回放目录时报父目录不存在	首次输出 generated/live-20260811-r0511-01	生成器现自动递归创建父目录，但仍以非递归方式创建本轮目录并拒绝覆盖；新增回归通过。

2026-08-11 — 0.5.12 散拼子单解析与异步定位修复（当前）

Goal: 补齐 shared_child_order_create 的 Skill/解析契约和测试标记安全门，修复散拼计划列表 Ajax 渲染早于固定等待导致的假未命中，再从 C03 精确母团继续完整生命周期重放。

Phase	Status	Purpose
1. Skill/路由契约	Complete	新增第四条创建行为、业务入口、字段/输出/ERP handoff 与 parser guidance；测试母团要求子单 special_requests 保留 TEST-202609。
2. 失败关闭三层校验	Complete	外部 validator、planner、Schema 对测试子单缺标记一致阻断；Skill 包已重建。
3. 子单母团定位修复	Complete	列表改为稳定轮询、团号唯一、tid 交叉核对，写后等待具体子单引用；首轮无写阻断作为真实回归证据保留。
4. 0.5.12 构建与运行时加载	Complete	业务/插件/解析 111/111、控制面 32/32、TypeScript、五 Skill 通过；18 文件 ZIP 与源码一致，Chrome PING=0.5.12。
5. C05 与后续生命周期	In Progress	重新走平台解析/人工确认后创建具体子单，随后名单、五类安排、修改、源读取、状态与精确清理。

Errors encountered

Error	Attempt	Resolution
Python 缺少 jsonschema	语义验证新增条件 Schema	改用项目已安装 Ajv 2020；有效 C05 通过、缺标记样本失败。
全量测试仍断言 0.5.11	首次 0.5.12 回归	更新版本一致性断言后 111/111 通过。
子单母团列表假未命中	0.5.11 C05 首次插件执行	明确无写；只读确认 Ajax 延迟后母团存在，0.5.12 改稳定轮询并复核 tid。

2026-08-11 — 0.5.13 生命周期自主路由与安排实页校准（当前）

Goal: 让插件从业务操作根页面按精确引用自主进入名单、五类安排和后续生命周期页面，消除依赖人工预先定位页面的缺口，并继续 R0511 的真实重放。

Phase	Status	Purpose
1. 生命周期自主路由	Complete	background 在 adapter 前调用 route preparation；名单按精确列表行进入订单编辑和原生导入弹窗，安排按 data_tr_<tid> 和对应原生入口进入目标子页。
2. 实页安全门校准	Complete	车辆、酒店、大交通、其他的完整表单下限按真实业务页校准，并保留必需控件、slot、稳定 1 秒、无 loading 与候选唯一性校验。
3. 契约与 Skill 同步	Complete	安排 Skill、mapping、Schema、fixture、版本面和回归测试已同步；仍只允许 /System/Business/ 内业务页资源候选。
4. 静态回归与打包	Complete	TypeScript、控制面 32/32、业务/插件/解析 95/95，总计 127/127；语法、JSON、5 Skills、ZIP 完整性与源码逐文件比对通过。
5. Chrome 0.5.13 重载	Complete	扩展精确重载并由 runtime PING 证明 version/minimum=0.5.13；ERP 账号正确，组织全自动化关闭。
6. 真实生命周期重放	In Progress	P01 精确路由成功但实页 readiness 再次安全假阻断，明确无写；由 0.5.14 修复后继续。

0.5.13 artifacts

• dist/ltjt-order-assistant-0.5.13.zip 与通用别名均为 18 文件、manifest 0.5.13，SHA-256 均为 e64f4f40a33e7324dbb4e5f149c36963391c18c4616019e5f0cf18efdc4b5c51。
• dist/lwlt-arrangement.skill 已重建并通过解包校验，SHA-256 为 83b9a92f3f6b590b2cff4f0be49389e5608187f575807bcc7d868decd8fd9de7。
• 历史 0.5.12 的 C05 成功证据保留；P01 的旧阻断明确无写，允许在 0.5.13 下新建等价任务重试；P02 仍未确认、未写。

2026-08-11 — 0.5.14 名单实页身份与隐藏占位修复（当前）

Goal: 修复 0.5.13 已到达精确名单弹窗后，由 art-dialog 隐藏 loading... 占位和编辑页不展示完整团号造成的假预检阻断，继续 P01/P02 及后续生命周期。

Phase	Status	Purpose
1. 0.5.13 真实失败取证	Complete	P01 新任务 TASK-20260811034431-TwHYg2o 已走正常解析/人工确认；route preparation 精确命中 14385/14453、订单编辑页与 daoru.asp，adapter 随后在写前阻断，no_erp_write=true。
2. 根因修复	Complete	loading 文本只读取元素自身直接文本，避免可见 dialog 容器继承隐藏占位子节点文本；完整团号不在编辑表单时，必须由匹配的原生 tid 和必要 ddid 共同证明身份。
3. 全量回归	Complete	TypeScript、控制面 32/32、业务/插件/解析 95/95，总计 127/127；全部 JS/MJS、JSON、5 Skills 与 diff 检查通过。
4. 0.5.14 打包	Complete	两个 18 文件 ZIP 完整、manifest=0.5.14、与源码逐文件一致；SHA-256 均为 1d093344f5713f1f7cb4e3717d04570583fe24d02080bb90d3aef67b8d66b9a0。
5. Chrome 0.5.14 重载	Complete	runtime PING=0.5.14、ERP 账号和组织自动化=false 均通过。
6. P01/P02 真实名单	In Progress	P01 第三次 route/readiness 通过但 ownership 请求契约假阻断，明确无写；由 0.5.15 继续。
7. 剩余生命周期	Pending	U01 → 五类安排 → U02/U03 → 源读取 → 安排清理 → 状态 → 最终源 → 精确删除。

New errors encountered

Error	Attempt	Resolution
npm wrapper 不存在	首次调用 package test script	不改项目脚本；使用 bundled Node 逐项执行同一 tsc、control-plane 和 legacy test 命令，全部通过。
art-dialog 隐藏占位被视为 loading	0.5.13 P01 实页预检	只判断节点直接文本；隐藏 .ui_loading 的子文本不再污染已加载 iframe 容器。
完整团号不在编辑表单文本	0.5.13 P01 实页身份校验	保留列表精确路由；编辑页要求隐藏 tid=14385、ddid=14453 与 refs 同时一致，任一不符仍阻断。

2026-08-11 — 0.5.15 原生列表归属请求契约修复（当前）

Goal: 让生命周期 ownership proof 完全复现独立团/散拼计划原生 SearchForm 请求，消除 action 参数位置错误导致的假未命中。

Phase	Status	Purpose
1. 0.5.14 真实取证	Complete	P01 TASK-20260811035706-Bg6i-88 的 route 与 form readiness 均通过；ownership response HTTP 200 但空结果，保存前阻断且明确无写。
2. 原生请求对照	Complete	独立团实页表单 action=/System/DAT/orders.asp?Act=JH_OrderList，散拼为 /System/DAT/plan.asp?Act=SP_OrderList；body 使用 S_fabudanwei，不存在裸 wode。
3. 修复与只读实页复核	Complete	Act 改入 URL query，body 加入 operation 的 S_fabudanwei 并移除错误裸 wode；同参数只读 POST 返回目标团号9次、tid15次、ddid7次、账号2次。
4. 静态回归与打包	Complete	127/127、语法/JSON/5 Skills/diff 全通过；0.5.15 两个 18 文件 ZIP 与源码一致，SHA-256 均为 35aeaff18fcd422096c2176a362221fd859f6e84a3ade3c52db9464b48a01ce6。
5. Chrome 0.5.15 重载	Complete	runtime PING=0.5.15、ERP 账号及组织自动化=false 全部通过。
6. 名单及后续生命周期	In Progress	P01 的 URL/body 已正确但裸 <tr> 被 DOMParser 丢失，仍在保存前阻断且明确无写；由 0.5.16 继续。

2026-08-11 — 0.5.16 裸列表行解析与 fresh detail 身份修复（当前）

Goal: 正确解析 ERP DAT 接口返回的裸 <tr> 片段，并让名单、修改和安排 fresh detail 在完整业务编号不渲染时使用稳定数字引用回查。

Phase	Status	Purpose
1. 0.5.15 真实取证	Complete	P01 TASK-20260811040614-dV3QMKU 的原生 ownership 请求 HTTP 200/3838 bytes 且原文含团号9次，但 DOMParser 后 tr=0，保存前阻断、确定无写。
2. 裸片段解析	Complete	ownership 与 team summary 的 row fragment 统一包入 <table><tbody> 后解析；C01 只读验证得到 tr=1 且团号/账号均命中。
3. fresh detail 身份	Complete	名单、修改、安排清理的 fresh GET 以完整编号文本或匹配的 tid + 必要 ddid 证明同一对象，并返回结构化 identity 证据。
4. 只读实页预演	Complete	在当前 daoru frame 只读注入新 adapter 后，P01 返回 lifecycle_preflight_ready；readiness 与 ownership 全字段均 true、无 blocker。
5. 回归与打包	Complete	127/127、语法/JSON/5 Skills/diff 全通过；0.5.16 两个 18 文件 ZIP 与源码一致，SHA-256 61f6fef70a5bcad86f4a7c6371c40717aa60fb8a31d050523b22f589cd5205e4。
6. Chrome 重载与 P01	In Progress	重载 0.5.16，核对 PING 后只重试所有历史 execution 均明确无写的 P01。
7. 后续生命周期	Pending	P02 → U01 → 五类安排 → U02/U03 → 导出 → 清理 → 状态 → 最终导出 → 删除。

2026-08-11 — 0.5.17 名单原生持久投影校准（当前）

Goal: 以 P01 实际 DaoRuDones() DOM 结果为事实基线，消除虚构证件类型控件和错误字段 token，完成真实保存后继续全生命周期。

Phase	Status	Purpose
1. 原生映射取证	Complete	P01 TASK-20260811041739-Zs1YC0k 证明原生控件为 pinyinxm/zjhaoma/fazhengri/youxiaori，NAME 会去除空白，证件类型没有独立控件；该次在 server save 前阻断，确定无写。
2. Adapter/Planner/Schema/Skill 校准	Complete	只对 ERP 真实持久字段建立投影；只接受护照，结果明示证件类型不单独持久；三层 validator、mapping 与 Skill 同步。
3. 静态发布门槛	Complete	TypeScript、控制面 32/32、业务/插件/解析 96/96、语法/JSON/diff、5 Skills 全通过；0.5.17 两个 18 文件 ZIP 与源码一致。
4. Chrome 精确重载	In Progress	精确重载 ID kafggjjlhebccdgkechmbgflkaifkccf，复核 runtime/minimum=0.5.17、AI 测试账号和组织自动化=false。
5. P01/P02 真实保存	Pending	新建 P01 等价正常平台任务，明确回执与 fresh projection 命中后再处理 P02。
6. 剩余生命周期	Pending	U01 → 五类安排 → U02/U03 → 导出 → 安排/应收清理 → 取消/恢复 → 最终导出 → allowlist 精确删除。

0.5.17 artifacts

• dist/ltjt-order-assistant-0.5.17.zip 与通用别名均含 18 文件，manifest=0.5.17，解包后与扩展源码逐文件一致。
• 两包 SHA-256 均为 e6104f226aad256b05d018226e11c3cfc56690d0eac2fb24f9fe7e7a16beffb4。

2026-08-11 — 0.5.18 整行空白归一化修复（当前）

Phase	Status	Purpose
1. 0.5.17 真实取证	Complete	P01 TASK-20260811043638-cd-o31A 只剩第 16 行 remark 差异；原生把 TEST-202609 领队 归一为 TEST-202609领队。在 server save 前阻断，确定无写。
2. 整行归一化	Complete	投影对每个真实持久值统一去除所有空白，与 DaoRuDones 拆列前行处理完全一致；Skill/mapping/parser guidance 同步。
3. 静态与发布包	Complete	TypeScript、32/32、96/96、语法/JSON/diff、5 Skills 全通过；0.5.18 两包 18 文件与源码一致，SHA-256 8d9e47e5c8e7c9f1c630e488a76860d9ee2d317667f33c98b321955d3324c5d9。
4. Chrome 重载与 P01	In Progress	重载 0.5.18，重新正常解析/人工确认 P01；只在明确服务端响应与 fresh requery 均命中后记成功。
5. 后续生命周期	Pending	P02 → U01 → 五类安排 → U02/U03 → source-only 导出 → 清理/状态/删除。

2026-08-11 — 0.5.19—0.5.21 P01 只读收敛与业务行/frame 定位（当前）

Phase	Status	Purpose
1. P01 真实保存事实	Complete	0.5.18 TASK-20260811044534-vmFV080 已取得 DoInfoJH HTTP 200“修改成功”，16 行和 16 个 marker 实际落库；首次 mismatch 仅为日期补零格式，禁止重提写入。
2. 0.5.19 只读回查契约	Complete	增加同 operation、同 execution 的管理员显式 fresh requery；该路径只调用 verifyLifecycleOperation，不调用保存。
3. 残留弹窗假重复取证	Complete	首次只读路由发现 ERP 列表同时保留隐藏 art-dialog 团号标题和真实 tr_14385；普通文本唯一性计数为 2，回查安全阻断且无附加写入。
4. 0.5.20 业务行限定	Complete	候选仅接受 tr_<tid>、data_tr_<tid> 或含原生业务 action 的行；隐藏弹窗标题排除。TypeScript、32/32、97/97、语法、44 JSON、5 Skills、diff 和 18 文件 ZIP 全通过。
5. 0.5.20 多 frame 实证	Complete	精确路由通过；daoru、上传、富文本等 4 个 frame 都沿 parent/opener 对同一详情 GET，返回完全相同的 16/16 成功证据，旧 selector 因成功数量大于 1 而安全阻断；没有写入。
6. 0.5.21 名单回查 frame 限定	Complete	仅 daoru.asp 可执行名单 reconciliation；其他 frame 返回 context blocker。TypeScript、32/32、97/97、语法、44 JSON、5 Skills 和 18 文件 ZIP 全通过。
7. Chrome 0.5.21 重载与 P01 收敛	Complete	runtime/minimum=0.5.21、账号、ERP 自动化=true、组织自动化=false；原 execution 只读回查 completed，16/16、hash 相同、无附加写入。
8. 剩余生命周期	In Progress	P02 → U01 → 五类安排 → U02/U03 → 导出 → 清理 → 取消/恢复 → 最终导出 → allowlist 精确删除。

0.5.20 artifact

• dist/ltjt-order-assistant-0.5.20.zip 与通用别名均为 18 文件、manifest 0.5.20、与源码逐文件一致；SHA-256 01a8ff40f53254e24334b8cc88f0271a1f3a8c2c83c9bd1476ac1fad1118c492。
• dist/ltjt-order-assistant-0.5.21.zip 与通用别名均为 18 文件、manifest 0.5.21、与源码逐文件一致；SHA-256 276ce1c2d3fe4cee520381c3cf76df1a66c024eee0826e41a58d671b19c2587c。

2026-08-11 — 0.5.22 散拼子单入口文本边界（当前）

Phase	Status	Purpose
1. P02 首次真实执行	Complete	旧任务 TASK-20260811030755-Oee_Pt4 核心 operation 与 fixture 一致；人工确认后在 route preparation 阻断，passenger_shared_child_edit_link_count:0、write_attempted=false。
2. 原生入口取证	Complete	母团 tr_14389 唯一子单链接文本为 D14457-LW衡阳…，onclick=OPEN_update(14389,14457)。
3. 0.5.22 校准	Complete	子单链接只接受精确 D<数字> 后跟 ERP 固定连字符或结束，同时强制 tid/ddid；名单、修改和删除共用。32/32、97/97、类型/语法/JSON/5 Skills 全通过。
4. P02 新 execution	In Progress	重载 0.5.22 后由正常平台任务重新解析/人工确认；旧 execution 明确无写。

• dist/ltjt-order-assistant-0.5.22.zip 与通用别名均为 18 文件、manifest 0.5.22、与源码逐文件一致；SHA-256 fd08860041b87ff6097b4d0722b488512130c2e5b1ab559df48f2ab6db87364a。

2026-08-11 — 0.5.23 散拼 ownership 裸行边界（当前）

Phase	Status	Purpose
1. 0.5.22 P02 真实预检	Complete	页面入口已正确打开 plan_order.asp?tdid=14389&ddid=14457 和原生导入 frame；表单 403 控件、16 行 ready，但 DAT ownership 裸行因同一连字符边界阻断，write_attempted=false。
2. 0.5.23 ownership parser	Complete	exactRowForIdentifier 对 D<数字> 使用专用后边界并保持叶子行消歧；marker/account/tid/ddid 门槛不变。32/32、97/97、类型/语法/JSON/5 Skills 全通过。
3. 新 P02 任务	In Progress	TASK-20260811052524-0CxBXdY 正常解析中，完成后再次做核心 operation 对照和人工确认。

• dist/ltjt-order-assistant-0.5.23.zip 与通用别名均为 18 文件、manifest 0.5.23、与源码逐文件一致；SHA-256 261c82e8e62501054704e65398626afe9465e275362cfd8d4941d2caccdd8957。

2026-08-11 — 0.5.24 散拼名单证件号控件与 P02 完成（当前）

Phase	Status	Purpose
1. 0.5.23 P02 保存前取证	Complete	canonical JSON 任务 TASK-20260811053631-LjDMyCc 已通过路由、403 控件 readiness 与 ownership；原生 DaoRuDones 把 16 行投影到 DOM，但散拼证件号控件名为 haoma，旧校验只识别 zjhaoma，因此保存前阻断且 write_attempted=false。
2. 0.5.24 双页面映射	Complete	document_no 同时识别独立团 zjhaoma 与散拼子单 haoma；mapping、Skill、README、最低版本和契约测试同步。
3. 全量回归与构建	Complete	TypeScript、控制面 32/32、业务/插件/解析 99/99、JS/MJS、JSON、5 Skills 全通过；18 文件 ZIP 与源码一致，SHA-256 8489f60ea7be77226d0ed32879d171b683fca398a2b47ea7a4f1e5253aa5225d。
4. P02 真实保存	Complete	TASK-20260811054424-EDZ2f-M / execution 1e7a2bc0-21de-4904-a287-2fe6b4b117e3 取得 DoInfo_order HTTP 200“修改成功”；fresh GET 16/16、marker 16、identity/account 与投影 hash 全匹配。
5. 剩余生命周期	In Progress	U01 → 五类安排（独立团与散拼母团）→ U02/U03 → source-only 导出 → 应收基线/清理 → 安排清理 → 取消/恢复 → 最终导出 → allowlist 精确删除。

• dist/ltjt-order-assistant-0.5.24.zip 与通用别名均为 18 文件、manifest 0.5.24、与源码逐文件一致；SHA-256 8489f60ea7be77226d0ed32879d171b683fca398a2b47ea7a4f1e5253aa5225d。

2026-08-11 — 0.5.25 生命周期 frame 收敛与 U01 事实（当前）

Phase	Status	Purpose
1. strict canonical 无关域修复	Complete	canonical JSON 不再被注入原文没有的 passenger_list=none；自然语言路径仍保留兼容默认值。旧 U01 候选保持未确认，新任务核心 hash 与 fixture 一致。
2. U01 frame 竞态取证	Complete	0.5.24 route 已打开精确 orders_add.asp，但首次 all-frame 枚举只看到顶层/列表 frame，导致保存前假阻断且无写。逐 frame 只读对照证明目标页 1015 控件、ownership 全绿。
3. 0.5.25 frame discovery	Complete	route 已证明目标后，仅当全部 blocker 都属于 scope/page/form frame 发现问题时，最多读重试 5 秒；任何业务 blocker 立即停止。
4. U01 真实探针	Complete	TASK-20260811060217-spxiqTg 已使用与原生 SubmitInfoForm() 相同的 Act=DoInfoJH&ListForm.serialize()；HTTP 200/0 bytes，无成功脚本，fresh GET 中 xiadanbeizhu 仍为空，状态 reconciliation_pending，禁止重提。
5. 五类安排	In Progress	U01 已在安排历史前完成有效探针并暴露 ERP 不持久风险；继续 C01/C03 各五类 create，逐项要求服务端成功响应、子页及总表回查。

• dist/ltjt-order-assistant-0.5.25.zip 与通用别名均为 18 文件、manifest 0.5.25、源码逐文件一致；SHA-256 74752ed883e52ea6aa94898d02df159846bd62685f7d6e1bd95419e54a0b2ce2。

2026-08-12 — 第二轮全生命周期完成与 0.5.77 契约收口

Phase	Status	Purpose
1. 第二轮全新对象创建	Complete	sept-2026-lifecycle-plugin-e2e2-01 使用新 suffix、8 个 9 月日期和新 ERP 引用创建独立团 4、散拼母团 4、具体子单 1；四条路线逐日期回查通过。
2. 名单/安排/修改/应收	Complete	两类名单 16/16；两组五类安排 create/clear；散拼母团容量、子单住宿说明、最小应收及独立团零额应收清理均完成。独立团 booking_note 的插件与原生页面请求均不持久化，登记为正式 blocker。
3. 状态与导出	Complete	7 个取消/恢复转换通过；确认母团取消向子单传播、恢复不反向传播；安排态和最终态共 40 个 source-only artifact 冻结哈希。
4. 删除与聚合回查	Complete	D14464 → 4 个无子单母团 → 4 个独立团全部明确删除成功；最终探针 9/9 present=0、running_tasks=[]，删除开关关闭。
5. 适配收口	Complete	0.5.76 增加母团取消逐子单详情验证；0.5.77 将独立团普通修改从 parser、planner、Schema 和 adapter 四层关闭，仅保留 clear_generated_zero。
6. 发布判断	Blocked	第二轮稳定性门槛已满足；统一发布仍等待业务负责人确认模块化边界，独立团普通修改和运营宽字段继续阻断。

最终 replay generated/e2e2-phase12 含 40 个经 parser/planner/Schema 一致校验的 operation、0 个 blocker、0 个删除动作、0 个独立团普通修改探针。

2026-08-12 — 运营原文覆盖审计与第三轮终验（完成，后由第四轮稳定化复核）

Goal: 以运营梳理 10—21 的每个子项重新审计当前事实，修正插件/Schema/mapping/Skills 的误导或未证实边界，并用最终候选执行第三个全新真实订单生命周期后精确清理。

Phase	Status	Purpose
1. 原始需求逐子项审计	Complete	已按 V2/V1/S2/P/B/N/D/X 区分重复验证、代表验证、ERP 阻断、未实测、延后和越权范围。
2. 契约与 Skills 修正	Complete	能力标签、散拼批量事实、source-only 四标志、独立团修改和五类安排边界已同步。
3. 第三轮独立运行准备	Complete	使用新日期、suffix、合成名单和精确 allowlist，包含散拼批量客户/15+1 事实探针。
4. 最终候选真实全流程	Complete	E2E3 已完成创建→名单→安排→窄修改/应收→状态→源读取→删除并 12/12 清理。
5. 全量验收与发布门槛	Complete	第四轮进一步稳定化至 0.5.81；核心候选可提交业务审批，宽能力继续阻断。

Errors encountered

Error	Attempt	Resolution
内置浏览器新建 ERP 标签导航超时并自动重置	在没有可认领用户标签时直接打开 https://ltjt.yunzhi.run/	确认无写入；不重复同一路径，读取浏览器故障说明后改查已登录 Chrome 通道。

2026-08-12 — 0.5.81 第四轮真实稳定化与交付（完成）

Goal: 用本地 Chrome 已登录 AI 测试账号完成新的全生命周期用例，在真实缺陷驱动下收敛最终插件、Schema/mapping、五个 Skills、证据和发布门槛。

Phase	Status	Purpose
1. 四条创建与动态引用	Complete	E2E4 创建独立团 4、散拼母团 4、具体子单 4；C04 三日期均形成子单并持久客户+15+1。
2. 名单/安排/修改/应收	Complete	两类名单 16/16；10 次安排 create/clear；母团容量、子单住宿说明和三次应收操作均回查通过。
3. 状态与源读取	Complete	7 次取消/恢复、母子传播边界及 40/40 source-only artifact 通过。
4. 删除与聚合收尾	Complete	4 子单→4 无子单母团→4 独立团；最终 present=0/12、running_tasks=[]，写入/删除授权关闭。
5. 0.5.81 稳定化	Complete	关闭应收串改、oldtdid 误选、编辑窗残留和辅助 about:blank frame 歧义；受影响尾段真实验证。
6. 文档、Skills、制品和门槛	Complete	需求审计、证据/风险/发布报告、mapping/Schema、五 Skills、18 文件扩展包与 168/168 回归全部完成。

0.5.81 artifacts

• dist/ltjt-order-assistant-0.5.81.zip 与通用别名字节一致、18 文件、与源码逐文件一致；SHA-256 79a9b49035f707d8ca297e7803ab89faf47b14d2bdabb02ce39c948f7ab0c535。
• 五个 .skill 包均通过官方校验并与源目录逐文件一致。
• 发布判断：已验证核心窄契约可提交业务负责人审批；独立团普通修改、运营宽字段、安排变更状态、DOCX/调度/外发仍失败关闭。

2026-08-12 — 运营业务 AI 输入模板体系（完成）

Goal: 以运营原文 10—21、真实 ERP 证据和 0.5.81 契约为基线，建立“第一行标准业务指令 + 后续业务字段”的可复制输入模板，并同步 Skill 路由与业务入口。

Phase	Status	Purpose
1. 现有入口与原始需求盘点	Complete	已对照运营原文、四个业务入口、根 Schema、需求覆盖审计和五个 Skill，区分已验证核心、条件、只读、系统内部及未开放需求。
2. 模板信息架构	Complete	首行固定标准业务指令；第二行起一行一个业务事实；内部 ID、账号、标记和 allowlist 全部排除出用户模板。
3. 全量模板落地	Complete	中央目录覆盖 17 个可执行/系统指令和 5 个需求登记指令，保留用户给出的散拼计划短格式示例。
4. Skill/业务注册表同步	Complete	Agent Prompt、两张注册表、四个既有下单入口、五个 Skill 及五份 input contract 已同步。
5. 校验与交付	Complete	模板契约 5/5、核心回归 122/122、控制面 33/33、TypeScript、五 Skill 官方校验、diff check 和五包源码一致性全部通过。

Errors encountered

Error	Attempt	Resolution
默认 shell 没有 node	首次直接运行模板测试与 pnpm run test:legacy	使用 Codex 工作区自带 Node 绝对路径执行，测试全通过。
工作区 Python 缺少 PyYAML	首次用工作区 Python 运行官方 quick_validate.py	改用已安装 PyYAML 的系统 Python 3.14；五个 Skill 均通过官方校验。

2026-08-12 — 运营输入模板最小化修订（完成）

Goal: 将所有生产用户模板收敛为“最小必填 + 其余选填”，修改类只填写目标内容且由系统读取当前值；移除不属于生产用户入口的测试清理模板与路由。

Phase	Status	Purpose
1. 最小字段审计	Complete	已逐模板区分用户最小必填、可由订单回查/上下文派生字段和真正选填字段。
2. 模板与交互规则修订	Complete	修改类只填目标值；名单/状态按单号读取；源读取最小为单号+文件类型；选填字段统一标注。
3. 生产入口清理	Complete	清理测试订单已从用户模板、业务路由、适配登记和模板测试移除；底层测试回收 action 仅留在测试宿主。
4. Skill 同步	Complete	Agent Prompt、五份 input contract 和五个主 Skill 已同步“先查询、后追问、系统生成 before_snapshot”。
5. 验证与重打包	Complete	模板 7/7、核心 123/123、控制面 33/33、TypeScript、五 Skill 官方校验、链接/diff 和五包源码一致性通过。

2026-08-12 — 输入模板双段式规范化（完成）

Goal: 将全部生产业务操作统一整理为相邻的“模板 + 示例”两段；模板只写占位符并逐字段标注必填/选填，示例只写具体业务值，消除重复说明和格式漂移。

Phase	Status	Purpose
1. 全目录结构审计	Complete	已盘点中央目录、五份 Skill 输入契约和四个既有业务入口；原目录存在单块混排、重复速查及散拼额外示例。
2. 中央目录统一改写	Complete	21 个操作均已改为相邻的“模板/示例”代码块；模板逐字段标注必填/选填，示例使用具体值。
3. Skill 与业务入口同步	Complete	五份 input contract 已覆盖全部 21 个操作；四个下单入口、Agent Prompt、README 和业务适配模板同步为双段式。
4. 契约测试与回归	Complete	模板 10/10、核心回归 127/127、控制平面 33/33、TypeScript 和 diff 检查通过。
5. Skill 校验与制品重建	Complete	五个 Skill 官方校验通过，五个 .skill 已重建并确认逐文件等同源码。

2026-08-12 — 团队文件业务指令改名（完成）

Goal: 将运营侧标准指令从技术名称读取团队文件源响应统一改为导出团队文件，保持内部 action confirmation_export 和当前 ERP 源内容读取边界不变；下载、格式处理与传输明确交由后续平台功能。

Phase	Status	Purpose
1. 当前命名入口盘点	Complete	已定位中央模板、行为/适配注册表、Agent Prompt、confirmation Skill、平台 UI、插件能力标签及模板测试。
2. 用户侧与平台侧改名	Complete	标准首行、中央标题、行为/适配登记、平台任务标签和插件能力标签已统一为导出团队文件；内部 action 保持不变。
3. 边界说明同步	Complete	Agent Prompt、confirmation/lifecycle Skills 与当前发布资料均明确 ERP 源获取和平台后续处理/传输的责任分界。
4. 测试、Skill 校验与打包	Complete	定向 42/42、核心 128/128、控制平面 33/33、TypeScript 和 diff 通过；confirmation/lifecycle Skills 官方校验并重打包完成。

2026-08-12 — 修改类归并与暂缓需求清理（完成）

Goal: 将独立团信息修改和安排变更归入正式“修改”输入范围，去掉需求登记：前缀但保持未验证写入失败关闭；当前运营模板暂时移除真实应收、文件交付自动化和文件上传三项。

Phase	Status	Purpose
1. 分类与安全边界确认	Complete	用户已明确 17/18 属于修改范围、19—21 暂不处理；分类调整不自动放开尚未验证的 ERP 写入。
2. 中央目录重排	Complete	两项已移入修改板块，原 19—21 已从当前入口移除；取消/恢复/导出顺延，目录现为 18 个连续操作。
3. 路由与 Skills 同步	Complete	updating/arrangement/confirmation/lifecycle 输入契约、主 Skill、Agent Prompt、外部解析 guidance、注册表和 README 已同步。
4. 回归、Skill 校验与打包	Complete	模板 12/12、核心 129/129、控制平面 33/33、TypeScript 和 diff 通过；四个受影响 Skill 已校验、重打包并确认源码一致。

2026-08-12 — 原需求 17/18 真实执行适配（完成）

Goal: 不以文档分类代替能力完成；针对原需求 17「独立团信息修改」和 18「安排变更」，在 AI 测试账号自己的 2026 年 9 月测试对象上建立 ERP 原生写入事实，落地插件执行、Schema/mapping/Skill 契约，并完成写后回查与安全收尾。

Phase	Status	Purpose
1. 原文与现有实现审计	Complete	已核对运营原文、既有失败证据、ERP 页面 action 和四层阻断点；能力按字段逐项开放。
2. 测试对象与原生基线	Complete	创建 3 个 AI 账号归属、带 TEST-202609-U1718C 的 9 月独立团；真实取得标间数修改及未确认酒店创建/修改/清除的原生响应和 fresh 回查。
3. 插件与契约实现	Complete	独立团只开放正整数 twin_room_count；安排只开放唯一未确认酒店行的 end_date/room_count，parser/planner/Schema/adapter 与 Skills 已同步。
4. 插件真实复现	Complete	0.5.83 运行时完成 8→9→8 和酒店 09-12/8→09-13/9，均有明确成功响应与写后回查；0.5.84 重载后又完成两次无写只读终态回查。
5. 回归、Skill 与交付	Complete	TypeScript 检查/构建、控制面 33/33、核心 129/129、三 Skill 官方校验、JSON/JS/MJS/diff 和制品一致性均通过；酒店行已清、标间数已恢复，3 个惰性订单留在关闭删除闸门的精确清单中。

Safety boundary

• 仅操作 AI 测试账号创建、2026 年 9 月且带 TEST-202609 标记的测试对象；目标引用不唯一立即停止。
• 安排修改只作用于测试安排，保持未确认/测试态；不触发采购、付款、通知、出票、落实或外发。
• 每次写入先冻结 before，再保留原生服务端响应并 fresh 回查；不确定状态先查不重提。
• 能力按字段逐项开放，不能因为一个代表字段成功而宣称全部宽字段或全部安排状态可用。

Errors encountered

Error	Attempt	Resolution
Chrome ERP 首页完整 DOM snapshot 超时并重置浏览器控制会话	认领已登录 Mainlt.asp 后立即读取跨 iframe 的完整 DOM	未发生点击或写入；重新连接后改用 URL/title、可见 DOM 或定向 locator，不再重复全页 snapshot。
Chrome 现有 ERP 标签认领阶段超时	重连后仅执行 openTabs→claimTab→URL/title，仍在 claim 阶段超时	未发生页面交互或写入；下一次不再认领该标签，改在同一 Chrome 配置中新建专用 ERP 标签。
专用 Chrome 标签导航 ERP 首页等待超时	新标签创建成功，普通 goto(Mainlt.asp) 等待旧 ASP 多 iframe 页完整加载	未发生表单交互或写入；改用该标签的受支持 CDP 能力非阻塞导航，并以 URL/frame/login 事实判断。
原 ERP tab 绑定在延迟接管后变陈旧	有界 claim 最终返回，但首次 CDP 读取报告该 id 已不存在	运行时列出专用标签 927774308 已成功到达 Mainlt.asp；按指引丢弃旧绑定，从当前 tabs.list() 精确取得新绑定。
当前 ERP 标签的首个定向 CDP 读取超时并重置控制会话	精确取得 927774308 后请求 frame tree 与顶层只读元数据	无点击/写入；停止继续消耗 UI 接管重试，改用项目自身已验证的扩展/控制平面通道在同一 Chrome 登录上下文执行并留证。
首次只读数据库状态查询被 shell 展开 $1	将参数化 SQL 放在双引号 -e 中	无数据库变更；改用 shell 单引号包裹 JS 后查询成功，后续不复用易展开写法。
酒店 update 首次预检发现原生回调清空备注	修改离店日/房间数后 update_CZR(0) 把既有测试备注置空	插件在回调稳定后恢复 frozen remark 并再次核对；首次任务写前安全阻断，修复后真实写入通过。
重载后的终端找不到 Node/npm	直接运行聚合 pnpm test 时子脚本找不到运行时	使用工作区捆绑 Node，分别执行 check、控制面和 legacy；所有实际测试通过，未改系统环境。

2026-08-12 — 17/18 插件、Skills 与主提示词最终收口（已完成）

Goal: 以已冻结的原需求 17/18 真实 ERP 回执为唯一事实基线，完善插件执行入口、相关 Skills 与主提示词，使自然语言解析、operation 生成、写前阻断、执行结果和用户说明完全一致。

Phase	Status	Purpose
1. 三层一致性审计	Complete	定位运行时提示无固定版本、主提示词缺 18 路由/状态决策、update 无变化仍触发控件事件，以及 Skill 混入一次性任务/row ID 四类问题。
2. 插件与提示词完善	Complete	插件 0.5.85 写前跳过目标=当前值的字段并在全部无变化时提交前阻断；主提示词/运行时同步 18 路由、三状态决策和固定版本。
3. Skills 完善	Complete	lwlt-updating、lwlt-arrangement、lwlt-lifecycle 重构为精简工作流 + operation/execution reference，更新中文 UI 元数据并通过官方 quick validator。
4. 契约回归与制品	Complete	TypeScript 检查/构建、控制面 33/33、核心 133/133 通过；0.5.85 扩展包精确 18 文件，三个 Skill 包均与源目录逐文件一致。
5. 运行时与交付收尾	Complete	Chrome 已重载 0.5.85；平台最低版本/插件 PING 均为 0.5.85，测试账号与 ERP 会话正常。旧测试对象终检返回 0 候选，用户确认已全部手工删除；两次探针均无 ERP 写入。

Safety boundary

• 本轮完善以本地代码、契约和只读回查为主，不新增 ERP 业务写入；不得借“完善”扩大到未验证宽字段或非酒店安排 update。
• 用户只提供目标值，不要求原值、tid、ddid、row ID、账号、marker 或运行编号。
• 17 仅开放独立团标间数正整数 set；18 仅开放唯一未确认酒店行的离店日期和/或目标房间总数。混入任何其他目标时整单阻断，不拆分执行。

Completion note

• 主提示词版本：ltjt-agent-prompt-v1.0-u1718-live。自然语言 parser 由宿主强制写入该版本；canonical JSON 仍独立记录 canonical-json-v1。
• 扩展 0.5.85 SHA-256：569b858fca9ef1e41dac8564a79c4f860bae6d11947fc601994ce8d3ec9ba58b。
• 本轮没有创建、修改或删除 ERP 对象。用户手工删除旧测试单后，历史 0.5.84 回执仍作为 17/18 真实事实基线；0.5.85 本轮只证明静态回归、制品一致性和运行时版本/会话。