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