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. |