chore: upload current WMS changes

doc/algorithm-migration/IMPLEMENTATION_PLAN.md

@@ -0,0 +1,28 @@
+# FT546 B Algorithm WMS Integration Plan
+
+## Goal
+
+Move the verified Java B algorithm into FT546MWS while keeping WMS as the owner of business transactions and keeping the existing WCS, shuttle, and lift execution policy unchanged.
+
+## Global Constraints
+
+- Inbound fills a dense lane from inner to outer positions.
+- Outbound removes a dense lane from outer to inner positions.
+- A lane with a pending outbound task cannot accept inbound.
+- A deep exact-tray request executes `MOVE_OUT -> OUTBOUND -> RESTORE`.
+- Buffer or floor-lock contention returns `WAITING`; it must not fall back or reject the business task.
+- Only inbound with no legal space may be rejected.
+- Project outbound matches project number only and defaults to whole-tray outbound.
+- Production starts in `SHADOW`; `ACTIVE` requires data diagnostics, concurrency checks, and operator approval.
+
+## Tasks
+
+1. [Complete] Persist and advance deep outbound workflows, creating only the next executable WMS job.
+2. [Complete] Connect move/outbound completion callbacks from WCS and whole-tray confirmation from PDA.
+3. [Complete] Replace whole-warehouse refresh on each request with dirty-lane incremental refresh.
+4. [Complete] Complete SQL Server install, diagnostics, uninstall, configuration, and operator documentation.
+5. [Complete] Run focused tests, the algorithm suite, the WMS suite, a full Maven build, and final review.
+
+## Transaction Boundary
+
+The algorithm produces a plan. A Spring transaction in `ruoyi-admin` validates live WMS rows, persists the workflow and space locks, and creates one executable `mydo_job` row. WCS continues consuming the existing job table. Each completion callback advances at most one workflow step. The algorithm repository is constructed with the same WMS `PlatformTransactionManager` and `DataSource`; startup rejects a mismatched transaction manager.