fix: decouple manual tidy from vehicle assignment

docs/superpowers/plans/2026-07-24-wms-manual-tidy-capacity.md

@@ -31,7 +31,7 @@
 - Produces: `CapacityResult calculate(List<VehicleSnapshot> vehicles, int activeManualWorkflows, int maxConcurrency)`.
 - Produces: `int AlgorithmProperties.getTidyManualMaxConcurrency()` and `void setTidyManualMaxConcurrency(int value)`.
 
-- [ ] **Step 1: Write failing capacity and default tests**
+- [x] **Step 1: Write failing capacity and default tests**
 
 Replace assigned-vehicle assertions with literal cases proving:
 
@@ -43,7 +43,7 @@ assertThat(capacity.calculate(unavailableVehicles, 0, 3).newSlots()).isZero();
 assertThat(new AlgorithmProperties().getTidyManualMaxConcurrency()).isEqualTo(3);
 ```
 
-- [ ] **Step 2: Run tests and verify RED**
+- [x] **Step 2: Run tests and verify RED**
 
 Run:
 
@@ -53,7 +53,7 @@ mvn -pl ruoyi-admin -am -Dtest=TidyVehicleCapacityTest,AlgorithmConfigurationTes
 
 Expected: test compilation fails because the new capacity signature and property getter do not exist.
 
-- [ ] **Step 3: Implement the minimal capacity and configuration changes**
+- [x] **Step 3: Implement the minimal capacity and configuration changes**
 
 Implement:
 
@@ -69,7 +69,7 @@ Add `tidyManualMaxConcurrency = 3` plus getter/setter to `AlgorithmProperties`,
 tidy-manual-max-concurrency: ${FORTUCKY_TIDY_MANUAL_MAX_CONCURRENCY:3}
 ```
 
-- [ ] **Step 4: Run focused tests and verify GREEN**
+- [x] **Step 4: Run focused tests and verify GREEN**
 
 Run the command from Step 2. Expected: all specified tests pass.
 
@@ -85,11 +85,11 @@ Run the command from Step 2. Expected: all specified tests pass.
 - Consumes: `TidyVehicleCapacity.calculate(vehicles, activeWorkflows, properties.getTidyManualMaxConcurrency())`.
 - Removes: `selectActiveManualTidyVehicleIds` and `assignTidyWorkflowVehicle` runtime mapper operations.
 
-- [ ] **Step 1: Write a failing scheduler behavior test**
+- [x] **Step 1: Write a failing scheduler behavior test**
 
 Create a scheduler with mocked database/external boundaries. Return two healthy idle vehicles, one active workflow, maximum concurrency `3`, and two planner candidates. Assert that `TidyWorkflowTransaction.start` receives both candidates in planner order. The existing implementation starts only one because it subtracts the active workflow from the already-idle snapshot.
 
-- [ ] **Step 2: Run the scheduler test and verify RED**
+- [x] **Step 2: Run the scheduler test and verify RED**
 
 Run:
 
@@ -99,7 +99,7 @@ mvn -pl ruoyi-admin -am -Dtest=ManualTidySchedulerTest -Dsurefire.failIfNoSpecif
 
 Expected: FAIL because only one workflow is started or compilation fails until the scheduler adopts the new capacity signature.
 
-- [ ] **Step 3: Implement scheduler ownership changes**
+- [x] **Step 3: Implement scheduler ownership changes**
 
 Remove assigned-vehicle collection and the vehicle iterator. Calculate slots with the configured ceiling, iterate only planner candidates, and call:
 
@@ -111,7 +111,7 @@ Do not update a workflow vehicle. Log a candidate-oriented warning if workflow c
 
 Remove the two unused vehicle-binding methods from `WmsAlgorithmMapper` and their MyBatis XML statements. Leave the schema column and diagnostics unchanged.
 
-- [ ] **Step 4: Run focused tidy tests and verify GREEN**
+- [x] **Step 4: Run focused tidy tests and verify GREEN**
 
 Run:
 
@@ -130,13 +130,13 @@ Expected: all specified tests pass.
 **Interfaces:**
 - Produces: deployable `ruoyi-admin/target/ruoyi-admin.jar` and an updated handoff record.
 
-- [ ] **Step 1: Run source and diff checks**
+- [x] **Step 1: Run source and diff checks**
 
 ```powershell
 git diff --check
 ```
 
-- [ ] **Step 2: Run the full reactor tests**
+- [x] **Step 2: Run the full reactor tests**
 
 ```powershell
 mvn test
@@ -144,7 +144,7 @@ mvn test
 
 Expected: all reactor tests pass with zero failures and errors.
 
-- [ ] **Step 3: Build the deployment artifact**
+- [x] **Step 3: Build the deployment artifact**
 
 ```powershell
 mvn -DskipTests package
@@ -152,10 +152,10 @@ mvn -DskipTests package
 
 Expected: all reactor modules report `SUCCESS`.
 
-- [ ] **Step 4: Update the handoff record**
+- [x] **Step 4: Update the handoff record**
 
 Record the capacity-ownership change, verification totals, JAR size, and current SHA-256. Preserve the existing statement that an actual-WCS read-only snapshot smoke test remains a deployment step.
 
-- [ ] **Step 5: Review and commit exact files**
+- [x] **Step 5: Review and commit exact files**
 
 Run `git diff --cached --check`, inspect the complete staged diff, and commit only the implementation, tests, configuration, spec/plan files that belong to this change. Verify `git show --name-status HEAD` after committing.

docs/superpowers/specs/2026-07-24-wms-manual-tidy-capacity-design.md

@@ -30,12 +30,16 @@ On every manual tidy reconciliation cycle, WMS first performs workflow recovery
 
 WMS asks the planner for candidates only when at least one slot exists. It starts at most the calculated number of workflows in planner order. No candidate is paired with a snapshot row, and no `vehicle_id` update is issued. WCS later receives the ordinary move job and chooses the actual vehicle using its existing dispatch rules.
 
+The manual scheduling cycle is one database transaction. `TidyModeService.reconcile` reads the warehouse's `alg.tidy_mode` row with `UPDLOCK, HOLDLOCK`; keeping that lock until the scheduling transaction commits serializes capacity calculation and workflow creation for the same warehouse across WMS instances. Different warehouses continue to use different mode rows.
+
 ## Failure Handling
 
 If the WCS snapshot URL is absent, the request fails, the response is empty, or the response cannot be parsed, the snapshot client returns an empty list. The calculated idle count is then zero, so WMS creates no new manual tidy workflows during that cycle. Existing workflows and WCS queues continue independently and can still complete.
 
 This fail-closed behavior avoids building an unbounded WCS queue when real-time fleet availability is unknown. Operators can distinguish this condition through the existing snapshot warning log.
 
+If any workflow creation fails, the scheduler logs the candidate type and propagates the exception. The complete scheduling batch rolls back so a partial batch cannot consume capacity outside the locked count. The next scheduled cycle can retry from a consistent database state.
+
 ## Compatibility
 
 The existing `alg.tidy_workflow.vehicle_id` column, SQL Server index include, and diagnostic projection remain in place for schema and historical-data compatibility. Runtime code stops reading or writing the column for new manual tidy scheduling. No WCS API or database migration is required.
@@ -64,5 +68,7 @@ The implementation must prove the following behavior with tests written before p
 4. Offline, unhealthy, and busy vehicles do not produce slots.
 5. Manual scheduling starts workflows in planner order without reading or writing vehicle bindings.
 6. The default configured maximum is `3`.
+7. The scheduling cycle has a rollback transaction that holds the existing warehouse mode-row lock.
+8. Workflow creation failures propagate and prevent later candidates in the same batch from starting.
 
 Focused tests must pass before running the full Maven reactor test suite and package build.