LWLT-AI/task_plan.md

LTJT Business Module API Research Plan

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. Mock business-system task loop	Complete	Add a minimal local web page that creates one ERP order task, hands it to the extension bridge, and displays plugin feedback.
16. Agent-backed mock business system	Complete	Let the mock business system accept one raw instruction, call a configurable OpenAI-compatible model API or local mock parser, edit the LTJT field-understanding prompt, 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, mock 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/, mock-business-system/, 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 mock-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.