# Implementation Plan

## Validation Checklist

- [x] All specification file paths are correct and exist
- [x] Context priming section is complete
- [x] All implementation phases are defined
- [x] Each phase follows TDD: Prime → Test → Implement → Validate
- [x] Dependencies between phases are clear (no circular dependencies)
- [x] Parallel work is properly tagged with `[parallel: true]`
- [x] Activity hints provided for specialist selection `[activity: type]`
- [x] Every phase references relevant SDD sections
- [x] Every test references PRD acceptance criteria
- [x] Integration & E2E tests defined in final phase
- [x] Project commands match actual project setup
- [x] A developer could follow this plan independently

---

## Specification Compliance Guidelines

### How to Ensure Specification Adherence

1. **Before Each Phase**: Complete the Pre-Implementation Specification Gate
2. **During Implementation**: Reference specific SDD sections in each task
3. **After Each Task**: Run Specification Compliance checks
4. **Phase Completion**: Verify all specification requirements are met

### Deviation Protocol

If implementation cannot follow specification exactly:
1. Document the deviation and reason
2. Get approval before proceeding
3. Update SDD if the deviation is an improvement
4. Never deviate without documentation

## Metadata Reference

- `[parallel: true]` - Tasks that can run concurrently
- `[component: component-name]` - For multi-component features
- `[ref: document/section; lines: 1, 2-3]` - Links to specifications, patterns, or interfaces and (if applicable) line(s)
- `[activity: type]` - Activity hint for specialist agent selection

---

## Context Priming

*GATE: You MUST fully read all files mentioned in this section before starting any implementation.*

**Specification**:

- `docs/specs/016-syncfusion-floor-plan-designer/product-requirements.md` - Product Requirements
- `docs/specs/016-syncfusion-floor-plan-designer/solution-design.md` - Solution Design

**Key Design Decisions**:

- **ADR-1**: Use SyncFusion EJ2 Diagram instead of Fabric.js for canvas editor
- **ADR-2**: Dual storage - SyncFusion JSON for visual state + relational tables for business logic
- **ADR-3**: Separate layouts table with assignment snapshots for versioning
- **ADR-4**: Implement IntegrationAdapterInterface for event system compatibility
- **ADR-5**: Server-side aggregation, client-side rendering for heatmaps
- **Single Floor Plan**: MVP supports exactly one floor plan per store
- **Socket Model**: Sockets are logical partitions (not spatial) - MVP uses side panel UX
- **Workbook Permissions**: Workbook endpoints use existing workbook permissions (read: `task-lists`, task completion: `workbook_complete_tasks`)
- **Backstock Bin Flexibility**: Backstock remove tasks can be completed with no bin selected (bin can be assigned later by anyone who can complete tasks)
- **Background Images**: Stored on local filesystem (not in repo) with safe defaults for allowed formats and max size

**Implementation Context**:

- **Commands to run**:
  ```bash
  ./test.sh                           # Run all tests
  ./test.sh --testsuite unit          # Run unit tests only
  ./test.sh --stan                    # Run tests + PHPStan analysis
  php userfrosting/conductor run      # Apply database migrations
  php userfrosting/conductor build-css --minify  # Production CSS build
  ./deploy.sh                         # Test + deploy
  ```

- **Patterns to follow**:
  - `docs/patterns/psr4-autoloading.md` - Namespace conventions
  - `userfrosting/src/BuyerKiosk/EventManagement/Controllers/EventApiController.php` - API controller pattern
  - `userfrosting/src/BuyerKiosk/EventManagement/Adapters/AbstractAdapter.php` - Event integration adapter pattern
  - `userfrosting/src/BuyerKiosk/Workbook/Controllers/BackstockPanelController.php` - Workbook panel pattern
  - `userfrosting/routes/workbook/tasks.php` - Slim 2.x route + permission pattern (avoid Slim 3+ idioms)

- **Interfaces to implement**:
  - `IntegrationAdapterInterface` - For FloorPlanAdapter (Phase 4)
  - SyncFusion EJ2 Diagram API - saveDiagram(), loadDiagram(), symbol palette
  - heatmap.js API - For gradient heatmap visualization (Phase 3)

- **Database conventions**:
  - camelCase for all columns and new table names
  - Per-store databases: `kiosk_{typeNum}`
  - Migration JSON format with `{{store}}` placeholder
  - Timestamp exceptions: `created_at`, `updated_at` remain snake_case

- **Framework/version guardrails**:
  - **Slim**: Slim 2.x only — do not write Slim 3+ route/controller code (no PSR-7 Request/Response injection, no modern middleware signatures).
  - **Twig**: Twig 1.44 — avoid Twig 2/3+ features/filters; mirror existing templates and `{% raw %}` usage patterns when embedding Handlebars.
  - **Naming**: Keep frontend ↔ backend JSON keys aligned (camelCase), and match DB column case exactly (camelCase except timestamps).

---

## Phase Dependency Graph

```
Phase 1 (Foundation) ──┬──> Phase 1b (Usability) ──┐
                       │                           │
                       ├──> Phase 2 (Layout Planning) ──> Phase 4 (Event Integration)
                       │
                       └──> Phase 3 (Heatmaps & Maintenance)
```

**Recommended Order**: 1 → 1b → 2 → 3 → 4 (sequential)
**Parallel Option**: After Phase 1, Phases 2 and 3 can run in parallel

---

## Implementation Phases

### T1 Phase 1: Foundation (MVP)

**Goal**: Enable stores to create and manage floor plans with current state tracking.

**Deliverables**:
- Admin can create floor plan with SyncFusion canvas editor
- Admin can place racks from symbol palette and define sockets
- Admin can assign categories to sockets for "current" layout
- Employees see read-only floor view in workbook (simplified)

**Tables**: `fpFloorPlans`, `fpRackTypes`, `fpRacks`, `fpRackSockets`, `fpLayouts`, `fpSocketAssignments`, `fpAuditLog`, `fpSettings`, `drsCategories`, `drsSubCategories`

---

- [ ] T1.1 Prime Context `[activity: exploration]`
    - [ ] T1.1.1 Read SDD database schema for core tables `[ref: solution-design.md; lines: 617-883]`
    - [ ] T1.1.2 Read SDD API specifications for floor plan CRUD `[ref: solution-design.md; lines: 889-1030]`
    - [ ] T1.1.3 Read SDD directory map for file structure `[ref: solution-design.md; lines: 539-613]`
    - [ ] T1.1.4 Read PRD Feature 1-3 acceptance criteria `[ref: product-requirements.md; lines: 152-220]`
    - [ ] T1.1.5 Read existing EventApiController for API patterns `[ref: userfrosting/src/BuyerKiosk/EventManagement/Controllers/EventApiController.php]`
    - [ ] T1.1.6 Read SyncFusion serialization documentation `[ref: https://ej2.syncfusion.com/javascript/documentation/diagram/serialization]`

- [ ] T1.2 Database Schema & Migrations `[component: database]` `[activity: data-architecture]`
    - [ ] T1.2.1 Create migration `20251212_000_pc_category_lookups.json` for drsCategories/drsSubCategories with CSV seeding (PC stores only) + seed `bsCategories` insert-missing-only (audit inserts) `[ref: solution-design.md; lines: 765-802]`
    - [ ] T1.2.2 Create migration `20251212_001_floorplan_core.json` for fpFloorPlans, fpRackTypes, fpRacks, fpRackSockets `[ref: solution-design.md; lines: 627-710]`
    - [ ] T1.2.3 Create migration `20251212_002_floorplan_layouts.json` for fpLayouts, fpSocketAssignments `[ref: solution-design.md; lines: 715-760]`
    - [ ] T1.2.4 Create migration `20251212_003_floorplan_settings.json` for fpSettings, fpAuditLog `[ref: solution-design.md; lines: 853-883]`
    - [ ] T1.2.5 Create migration `20251212_004_floorplan_permissions.json` for uri_floor_plans and uri_floor_plans_manage permissions
    - [ ] T1.2.6 Seed system rack types (12 predefined fixtures) `[ref: product-requirements.md; lines: 175-200]`
    - [ ] T1.2.7 Run migrations and verify tables created: `php userfrosting/conductor run`

- [ ] T1.3 Domain Models `[component: models]` `[activity: domain-modeling]`
    - [ ] T1.3.1 Create `FloorPlan.php` model with toArray(), createFromRow(), getPresetDimensions() `[ref: solution-design.md; lines: 1350-1374]`
    - [ ] T1.3.2 Create `RackType.php` model with getSyncFusionNodeConfig() `[ref: solution-design.md; lines: 1376-1397]`
    - [ ] T1.3.3 Create `Rack.php` model with getSockets() `[ref: solution-design.md; lines: 1399-1419]`
    - [ ] T1.3.4 Create `RackSocket.php` model with getAssignments() `[ref: solution-design.md; lines: 1421-1429]`
    - [ ] T1.3.5 Create `Layout.php` model with isCurrent(), canBeDeleted() `[ref: solution-design.md; lines: 1431-1453]`
    - [ ] T1.3.6 Create `SocketAssignment.php` model with getSubcategoryName() `[ref: solution-design.md; lines: 1455-1466]`

- [ ] T1.4 Write Unit Tests - Models `[component: tests]` `[activity: test-execution]`
    - [ ] T1.4.1 Test FloorPlan::getPresetDimensions() returns correct canvas sizes `[ref: product-requirements.md; line: 594]`
    - [ ] T1.4.2 Test Rack::toArray() serialization with sockets
    - [ ] T1.4.3 Test Layout::isCurrent() and canBeDeleted() business rules
    - [ ] T1.4.4 Test SocketAssignment subcategory lookup

- [ ] T1.5 Service Layer `[component: services]` `[activity: api-development]`
    - [ ] T1.5.1 Create `FloorPlanService.php` with create(), update(), delete(), getByStore() `[ref: solution-design.md; lines: 559-560]`
    - [ ] T1.5.2 Create `LayoutService.php` with createCurrentLayout(), getAssignments(), assignCategory() `[ref: solution-design.md; lines: 561]`
    - [ ] T1.5.3 Create `AuditService.php` for logging all mutations `[ref: solution-design.md; line: 564]`
    - [ ] T1.5.4 Implement rack sync logic for SyncFusion node → database synchronization (batch updates; avoid syncing on every mousemove)
    - [ ] T1.5.5 Implement user display name lookup strategy for audit/task/maintenance views (global `kiosk_users.users`; consider snapshotting displayName into audit rows to avoid cross-db reads later)

- [ ] T1.6 Write Unit Tests - Services `[component: tests]` `[activity: test-execution]`
    - [ ] T1.6.1 Test FloorPlanService::create() creates plan + current layout
    - [ ] T1.6.2 Test FloorPlanService::syncRacks() creates/updates/deletes racks
    - [ ] T1.6.3 Test LayoutService::assignCategory() creates socket assignment
    - [ ] T1.6.4 Test AuditService logs all entity changes with user/timestamp

- [ ] T1.7 API Controllers `[component: controllers]` `[activity: api-development]`
    - [ ] T1.7.1 Create `FloorPlanApiController.php` with CRUD endpoints `[ref: solution-design.md; lines: 896-956]`
    - [ ] T1.7.2 Create `LayoutApiController.php` with current layout endpoints `[ref: solution-design.md; lines: 1036-1112]`
    - [ ] T1.7.3 Implement permission checks: admin endpoints use uri_floor_plans (read) / uri_floor_plans_manage (write); workbook endpoints use `task-lists` (read) and `workbook_complete_tasks` (task completion)
    - [ ] T1.7.4 Implement CSRF token validation on all mutations

- [ ] T1.8 Write Integration Tests - API `[component: tests]` `[activity: test-execution]`
    - [ ] T1.8.1 Test GET /api/:typeNum/floor-plan/plans returns empty array initially
    - [ ] T1.8.2 Test POST /api/:typeNum/floor-plan/plans creates floor plan with current layout
    - [ ] T1.8.3 Test PUT /api/:typeNum/floor-plan/plans/:planId updates diagram data
    - [ ] T1.8.4 Test POST /api/:typeNum/floor-plan/plans/:planId/sync-racks syncs rack positions
    - [ ] T1.8.5 Test POST /api/:typeNum/floor-plan/layouts/:layoutId/assignments assigns category
    - [ ] T1.8.6 Test permission denied for employee attempting write operations
    - [ ] T1.8.7 Test floor plan workbook endpoint access uses workbook permission strings (`task-lists`) even though route is `/floor-plan/workbook/*`

- [ ] T1.9 Routes Configuration `[component: routes]` `[activity: api-development]`
    - [ ] T1.9.1 Create `userfrosting/routes/groups/floorplan.php` with route definitions
    - [ ] T1.9.2 Register routes in main router
    - [ ] T1.9.3 Add floor plan menu item to admin sidebar (permission-gated)

- [ ] T1.10 Admin Page Controller `[component: controllers]` `[activity: component-development]`
    - [ ] T1.10.1 Create `FloorPlanPageController.php` with dashboard() and designer() methods
    - [ ] T1.10.2 Implement store context loading and permission checks
    - [ ] T1.10.3 Pass SyncFusion license key to template context

- [ ] T1.11 Admin Templates `[component: frontend]` `[activity: component-development]`
    - [ ] T1.11.1 Create `admin/floorplan/dashboard.html` - floor plan management landing
    - [ ] T1.11.2 Create `admin/floorplan/designer.html` - SyncFusion canvas container
    - [ ] T1.11.3 Include SyncFusion EJ2 Diagram CSS/JS assets

- [ ] T1.12 SyncFusion Designer JavaScript `[component: frontend]` `[activity: component-development]`
    - [ ] T1.12.1 Create `public_html/js/admin/floorplan/designer.js` - FloorPlanDesigner class `[ref: solution-design.md; lines: 1569-1702]`
    - [ ] T1.12.2 Create `public_html/js/admin/floorplan/symbol-palette.js` - rack template palette
    - [ ] T1.12.3 Create `public_html/js/admin/floorplan/rack-types.js` - rack type definitions
    - [ ] T1.12.4 Implement diagram initialization with grid, rulers, snap-to-grid
    - [ ] T1.12.5 Implement symbol palette grouped by category (Gondola, Freestanding, etc.)
    - [ ] T1.12.6 Implement save/load via saveDiagram()/loadDiagram()
    - [ ] T1.12.7 Implement rack sync to backend on node add/move/delete (sync on drop/end, debounce bursts)
    - [ ] T1.12.8 Add guardrails for large payloads (avoid saving diagramData too frequently; show warning if save payload exceeds safe threshold)

- [ ] T1.13 Socket Assignment UI `[component: frontend]` `[activity: component-development]`
    - [ ] T1.13.1 Create socket assignment panel (side drawer when rack selected)
    - [ ] T1.13.2 Implement subcategory dropdown with search (from drsSubCategories)
    - [ ] T1.13.3 Implement multi-select for assigning multiple subcategories to socket
    - [ ] T1.13.4 Show assigned categories as badges on rack in diagram

- [ ] T1.14 Feature Styles `[component: frontend]` `[activity: design-foundation]`
    - [ ] T1.14.1 Create `public_html/css/admin/modules/floorplan.css`
    - [ ] T1.14.2 Style designer canvas container, symbol palette, assignment panel
    - [ ] T1.14.3 Use design tokens from tokens.css
    - [ ] T1.14.4 Run CSS build: `php userfrosting/conductor build-css --minify`

- [ ] T1.15 Workbook Panel - Floor View `[component: workbook]` `[activity: component-development]`
    - [ ] T1.15.1 Create `workspace/partials/floor-panel.html` template
    - [ ] T1.15.2 Create `public_html/js/workspace/modules/floorplan/floor-panel.js`
    - [ ] T1.15.3 Implement read-only diagram view with category search
    - [ ] T1.15.4 Register panel in workbook panel registry
    - [ ] T1.15.5 Create API endpoint GET /api/:typeNum/floor-plan/workbook/floor (requires workbook permission `task-lists`, not uri_floor_plans)

- [ ] T1.16 Validate Phase 1 `[activity: test-execution]`
    - [ ] T1.16.1 Run full test suite: `./test.sh`
    - [ ] T1.16.2 Run PHPStan: `cd userfrosting && ./vendor/bin/phpstan analyse src/BuyerKiosk/FloorPlan/`
    - [ ] T1.16.3 Verify acceptance criteria - PRD Feature 1: Floor Plan Designer `[ref: product-requirements.md; lines: 155-169]`
    - [ ] T1.16.4 Verify acceptance criteria - PRD Feature 2: Symbol Palette `[ref: product-requirements.md; lines: 172-206]`
    - [ ] T1.16.5 Verify acceptance criteria - PRD Feature 3: Rack Sockets `[ref: product-requirements.md; lines: 208-220]`
    - [ ] T1.16.6 Verify SyncFusion save/load roundtrip integrity `[ref: solution-design.md; lines: 2168-2177]`
    - [ ] T1.16.7 Manual test: Create floor plan, add racks, assign categories, refresh page, verify state persists

---

### T2 Phase 1b: Usability Enhancements (Should)

**Goal**: Improve day-to-day usability without expanding core scope.

**Deliverables**:
- Background image import + calibration (scale/measure tool)
- Unique rack auto-naming (R1/R2/...) + find rack search
- Draft vs published workflow for current layout
- Export floor plan as JSON and PNG

**Dependency**: Phase 1 complete

---

- [ ] T2.1 Prime Context `[activity: exploration]`
    - [ ] T2.1.1 Read SDD background image/calibration fields `[ref: solution-design.md; lines: 635-639]`
    - [ ] T2.1.2 Read PRD Feature 15-18 acceptance criteria `[ref: product-requirements.md; lines: 351-386]`
    - [ ] T2.1.3 Read SDD draft layout implementation `[ref: solution-design.md; lines: 728-730]`
    - [ ] T2.1.4 Read SDD export endpoints `[ref: solution-design.md; lines: 1273-1295]`

- [ ] T2.2 Background Image & Calibration `[component: designer]` `[activity: component-development]`
    - [ ] T2.2.1 Add background image upload UI to designer (SyncFusion EJ2 Uploader)
    - [ ] T2.2.2 Implement background opacity slider (0.00-1.00) (SyncFusion EJ2 Slider)
    - [ ] T2.2.3 Implement calibration tool: draw measurement line, enter distance
    - [ ] T2.2.4 Store pixelsPerUnit calculation in fpFloorPlans
    - [ ] T2.2.5 Update rulers to reflect calibrated scale
    - [ ] T2.2.6 Implement background image upload endpoint (`POST /api/:typeNum/floor-plan/plans/:planId/background-image`) + storage on local filesystem (not committed to repo); defaults: allow png/jpg/jpeg/webp; max size 5MB; return URL and store as fpFloorPlans.backgroundImageUrl
    - [ ] T2.2.7 Implement lifecycle cleanup: replacing background image deletes old file; deleting a floor plan deletes its background image file(s)
    - [ ] T2.2.8 Ensure background images are served same-origin (avoid CORS-tainted canvas which breaks PNG export)

- [ ] T2.3 Rack Identity & Find `[component: designer]` `[activity: component-development]`
    - [ ] T2.3.1 Implement auto-naming for new racks (R1, R2, R3...)
    - [ ] T2.3.2 Add unique constraint validation on rack names
    - [ ] T2.3.3 Create rename rack UI with duplicate check
    - [ ] T2.3.4 Implement find rack search with zoom-to-rack functionality
    - [ ] T2.3.5 Create API endpoint GET /api/:typeNum/floor-plan/plans/:planId/racks/find `[ref: solution-design.md; lines: 1003-1012]`

- [ ] T2.4 Draft vs Published Workflow `[component: services]` `[activity: api-development]`
    - [ ] T2.4.1 Add `draftOfLayoutId` column handling in LayoutService
    - [ ] T2.4.2 Implement createDraft() - copy current layout to draft
    - [ ] T2.4.3 Implement publishDraft() - make draft the new current
    - [ ] T2.4.4 Implement discardDraft() - delete draft layout
    - [ ] T2.4.5 Update workbook floor view to only return published layout `[ref: solution-design.md; lines: 2206-2212]`

- [ ] T2.5 Draft API Endpoints `[component: controllers]` `[activity: api-development]`
    - [ ] T2.5.1 GET /api/:typeNum/floor-plan/plans/:planId/layouts/current/draft `[ref: solution-design.md; lines: 1057-1060]`
    - [ ] T2.5.2 POST /api/:typeNum/floor-plan/plans/:planId/layouts/current/draft `[ref: solution-design.md; lines: 1062-1070]`
    - [ ] T2.5.3 DELETE /api/:typeNum/floor-plan/plans/:planId/layouts/current/draft `[ref: solution-design.md; lines: 1072-1077]`
    - [ ] T2.5.4 POST /api/:typeNum/floor-plan/plans/:planId/layouts/current/publish `[ref: solution-design.md; lines: 1231-1240]`

- [ ] T2.6 Draft UI Implementation `[component: frontend]` `[activity: component-development]`
    - [ ] T2.6.1 Add "Draft" indicator badge when editing draft
    - [ ] T2.6.2 Add "Publish Draft" button with confirmation
    - [ ] T2.6.3 Add "Discard Draft" button with confirmation
    - [ ] T2.6.4 Show warning when navigating away from unpublished draft

- [ ] T2.7 Export Functionality `[component: services]` `[activity: api-development]`
    - [ ] T2.7.1 Implement JSON export - floor plan + assignments `[ref: solution-design.md; lines: 1275-1286]`
    - [ ] T2.7.2 Implement PNG export - diagram canvas as image `[ref: solution-design.md; lines: 1288-1295]`
    - [ ] T2.7.3 Include layout=published|draft query parameter support

- [ ] T2.8 Export API & UI `[component: frontend]` `[activity: component-development]`
    - [ ] T2.8.1 Create export dropdown menu in designer toolbar
    - [ ] T2.8.2 Implement JSON download trigger
    - [ ] T2.8.3 Implement PNG download using SyncFusion exportImage or canvas-to-image

- [ ] T2.9 Write Tests - Phase 1b `[component: tests]` `[activity: test-execution]`
    - [ ] T2.9.1 Test rack auto-naming sequence (R1, R2, delete R1, new rack = R3)
    - [ ] T2.9.2 Test draft workflow: create → edit → publish `[ref: solution-design.md; lines: 2206-2212]`
    - [ ] T2.9.3 Test draft workflow: create → edit → discard
    - [ ] T2.9.4 Test export JSON contains all expected fields
    - [ ] T2.9.5 Test calibration saves pixelsPerUnit correctly
    - [ ] T2.9.6 Test background image upload constraints (reject unsupported mime, reject > 5MB)

- [ ] T2.10 Validate Phase 1b `[activity: test-execution]`
    - [ ] T2.10.1 Run full test suite: `./test.sh`
    - [ ] T2.10.2 Verify PRD Feature 15: Background Image + Calibration `[ref: product-requirements.md; lines: 351-360]`
    - [ ] T2.10.3 Verify PRD Feature 16: Rack Identity + Find `[ref: product-requirements.md; lines: 362-369]`
    - [ ] T2.10.4 Verify PRD Feature 17: Draft vs Published `[ref: product-requirements.md; lines: 371-378]`
    - [ ] T2.10.5 Verify PRD Feature 18: Export JSON/PNG `[ref: product-requirements.md; lines: 380-386]`

---

### T3 Phase 2: Layout Planning

**Goal**: Enable future layout planning with diff-based task generation.

**Deliverables**:
- Admin can create "wanted" layouts for future states
- System calculates diff between current and wanted
- Move tasks are generated and trackable
- Admin can manually activate a wanted layout

**Tables**: `fpMoveTasks` (add)

**Dependency**: Phase 1 complete

---

- [ ] T3.1 Prime Context `[activity: exploration]`
    - [ ] T3.1.1 Read SDD layout versioning design `[ref: solution-design.md; lines: 395-409]`
    - [ ] T3.1.2 Read SDD fpMoveTasks schema `[ref: solution-design.md; lines: 824-848]`
    - [ ] T3.1.3 Read SDD diff/task API endpoints `[ref: solution-design.md; lines: 1158-1240]`
    - [ ] T3.1.4 Read PRD Feature 4-6 acceptance criteria `[ref: product-requirements.md; lines: 222-260]`
    - [ ] T3.1.5 Read PRD detailed diff specification `[ref: product-requirements.md; lines: 426-472]`
    - [ ] T3.1.6 Read SDD diff algorithm example `[ref: solution-design.md; lines: 1749-1820]`

- [ ] T3.2 Database Migration `[component: database]` `[activity: data-architecture]`
    - [ ] T3.2.1 Create migration `20251212_005_floorplan_tasks.json` for fpMoveTasks table `[ref: solution-design.md; lines: 824-848]`
    - [ ] T3.2.2 Run migration: `php userfrosting/conductor run`

- [ ] T3.3 MoveTask Model `[component: models]` `[activity: domain-modeling]`
    - [ ] T3.3.1 Create `MoveTask.php` model with complete(), toArray() `[ref: solution-design.md; lines: 1468-1485]`
    - [ ] T3.3.2 Implement taskDescription generation logic

- [ ] T3.4 LayoutDiffService `[component: services]` `[activity: api-development]`
    - [ ] T3.4.1 Create `LayoutDiffService.php` `[ref: solution-design.md; line: 562]`
    - [ ] T3.4.2 Implement calculateDiff() - returns additions, removals, moves, dropped `[ref: solution-design.md; lines: 1749-1820]`
    - [ ] T3.4.3 Implement generateTasks() - creates atomic add/remove tasks
    - [ ] T3.4.4 Handle dropped category resolution (gone vs backstock) `[ref: product-requirements.md; lines: 456-471]`
    - [ ] T3.4.5 Implement task regeneration with warning for existing incomplete tasks

- [ ] T3.5 Layout Management Service Updates `[component: services]` `[activity: api-development]`
    - [ ] T3.5.1 Extend LayoutService with createWantedLayout()
    - [ ] T3.5.2 Implement copyFromLayout() for wanted layout creation
    - [ ] T3.5.3 Implement activateLayout() - wanted becomes current, old current archived
    - [ ] T3.5.4 Implement layout deletion validation (cannot delete current/active)

- [ ] T3.6 Write Unit Tests - Diff Service `[component: tests]` `[activity: test-execution]`
    - [ ] T3.6.1 Test diff with category on 3→2 sockets generates correct moves `[ref: solution-design.md; lines: 2178-2188]`
    - [ ] T3.6.2 Test diff with identical layouts returns empty
    - [ ] T3.6.3 Test dropped category detection (present in current, absent in wanted) `[ref: solution-design.md; lines: 2189-2203]`
    - [ ] T3.6.4 Test task generation with backstock resolution creates remove task
    - [ ] T3.6.5 Test task generation with gone resolution creates audit entry only

- [ ] T3.7 Layout API Endpoints `[component: controllers]` `[activity: api-development]`
    - [ ] T3.7.1 POST /api/:typeNum/floor-plan/plans/:planId/layouts (create wanted) `[ref: solution-design.md; lines: 1079-1092]`
    - [ ] T3.7.2 PUT /api/:typeNum/floor-plan/layouts/:layoutId (update wanted) `[ref: solution-design.md; lines: 1094-1104]`
    - [ ] T3.7.3 DELETE /api/:typeNum/floor-plan/layouts/:layoutId (delete wanted) `[ref: solution-design.md; lines: 1106-1112]`
    - [ ] T3.7.4 GET /api/:typeNum/floor-plan/layouts/:layoutId/diff (compare) `[ref: solution-design.md; lines: 1160-1172]`
    - [ ] T3.7.5 POST /api/:typeNum/floor-plan/layouts/:layoutId/generate-tasks `[ref: solution-design.md; lines: 1174-1186]`
    - [ ] T3.7.6 GET /api/:typeNum/floor-plan/layouts/:layoutId/tasks (list tasks) `[ref: solution-design.md; lines: 1188-1196]`
    - [ ] T3.7.7 POST /api/:typeNum/floor-plan/tasks/:taskId/complete (backstock bin optional; completion allowed with bin unset) `[ref: solution-design.md; lines: 1198-1209]`
    - [ ] T3.7.8 POST /api/:typeNum/floor-plan/tasks/:taskId/set-backstock-bin (anyone with task completion permission can set/adjust later) `[ref: solution-design.md; lines: 1210-1219]`
    - [ ] T3.7.9 POST /api/:typeNum/floor-plan/layouts/:layoutId/activate `[ref: solution-design.md; lines: 1222-1229]`

- [ ] T3.8 Write Integration Tests - Layout API `[component: tests]` `[activity: test-execution]`
    - [ ] T3.8.1 Test create wanted layout from copy of current
    - [ ] T3.8.2 Test diff endpoint returns correct structure
    - [ ] T3.8.3 Test generate tasks creates atomic add/remove tasks
    - [ ] T3.8.4 Test generate tasks without dropped resolutions fails with 400 `[ref: solution-design.md; lines: 2189-2203]`
    - [ ] T3.8.5 Test complete task updates status and completedByUserId
    - [ ] T3.8.6 Test activate layout archives previous current
    - [ ] T3.8.7 Test completing backstock task with no bin succeeds (bin remains NULL)
    - [ ] T3.8.8 Test set-backstock-bin endpoint updates task bin after completion

- [ ] T3.9 Admin UI - Layout Manager `[component: frontend]` `[activity: component-development]`
    - [ ] T3.9.1 Create `admin/floorplan/layouts.html` template
    - [ ] T3.9.2 Create `public_html/js/admin/floorplan/layout-manager.js`
    - [ ] T3.9.3 Implement layout list with status badges (current, scheduled, draft, archived)
    - [ ] T3.9.4 Implement "Create New Layout" dialog (name, copy from, activation date)
    - [ ] T3.9.5 Implement layout diff view with visual diff (green/red/yellow highlighting)
    - [ ] T3.9.6 Implement "Generate Tasks" button with dropped category resolution dialog
    - [ ] T3.9.7 Implement task list view with completion status

- [ ] T3.10 Workbook Updates - Move Tasks `[component: workbook]` `[activity: component-development]`
    - [ ] T3.10.1 Add move tasks to workbook maintenance panel
    - [ ] T3.10.2 Show task description with from/to rack context
    - [ ] T3.10.3 Implement "Complete Task" button for employees (requires `workbook_complete_tasks`)
    - [ ] T3.10.4 Implement backstock bin selection for backstock tasks (optional; allow "No bin / decide later")
    - [ ] T3.10.5 Implement "Set Bin" action for backstock tasks completed without bin (calls set-backstock-bin endpoint; requires `workbook_complete_tasks`)
    - [ ] T3.10.6 Confirm floor plan task completion endpoints enforce store-group checks + workbook permissions (even though they are not under `/api/:typeNum/workbook/*`)

- [ ] T3.11 Validate Phase 2 `[activity: test-execution]`
    - [ ] T3.11.1 Run full test suite: `./test.sh`
    - [ ] T3.11.2 Verify PRD Feature 4: Layout Versioning `[ref: product-requirements.md; lines: 222-232]`
    - [ ] T3.11.3 Verify PRD Feature 5: Layout Diff and Move Task Generation `[ref: product-requirements.md; lines: 234-250]`
    - [ ] T3.11.4 Verify PRD Feature 6: Manual Layout Activation `[ref: product-requirements.md; lines: 252-260]`
    - [ ] T3.11.5 Manual test: Create wanted layout, modify assignments, view diff, generate tasks, complete tasks, activate

---

### T4 Phase 3: Heatmaps & Maintenance

**Goal**: Add data visualization and maintenance tracking for operational optimization.

**Deliverables**:
- Sales heatmap overlays category performance on floor plan
- Maintenance heatmap shows time-since-last-service
- Combined scoring algorithm (time + traffic) prioritizes racks
- Employees can mark racks as maintained via workbook

**Tables**: `fpMaintenanceLogs` (add)

**Dependency**: Phase 1 complete (Phase 2 not required)

---

- [ ] T4.1 Prime Context `[activity: exploration]`
    - [ ] T4.1.1 Read SDD heatmap design `[ref: solution-design.md; lines: 417-428]`
    - [ ] T4.1.2 Read SDD heatmap algorithm (dual mode) `[ref: solution-design.md; lines: 1892-1946]`
    - [ ] T4.1.3 Read SDD maintenance score algorithm `[ref: solution-design.md; lines: 1710-1743]`
    - [ ] T4.1.4 Read SDD fpMaintenanceLogs schema `[ref: solution-design.md; lines: 808-822]`
    - [ ] T4.1.5 Read PRD Feature 7-9 acceptance criteria `[ref: product-requirements.md; lines: 262-299]`
    - [ ] T4.1.6 Read PRD heatmap calculation specification `[ref: product-requirements.md; lines: 474-501]`
    - [ ] T4.1.7 Read PRD maintenance priority scoring `[ref: product-requirements.md; lines: 503-519]`

- [ ] T4.2 Database Migration `[component: database]` `[activity: data-architecture]`
    - [ ] T4.2.1 Create migration `20251212_006_floorplan_maintenance.json` for fpMaintenanceLogs `[ref: solution-design.md; lines: 808-822]`
    - [ ] T4.2.2 Run migration: `php userfrosting/conductor run`

- [ ] T4.3 MaintenanceLog Model `[component: models]` `[activity: domain-modeling]`
    - [ ] T4.3.1 Create `MaintenanceLog.php` model with toArray(), getUserName() `[ref: solution-design.md; lines: 1487-1496]`

- [ ] T4.4 HeatmapService `[component: services]` `[activity: api-development]`
    - [ ] T4.4.1 Create `HeatmapService.php` `[ref: solution-design.md; line: 563]`
    - [ ] T4.4.2 Implement getSalesHeatmapData() - aggregate sales by subcategory, map to sockets (sales only; no special-case handling for returns/refunds/discounts) `[ref: solution-design.md; lines: 1513-1527]`
    - [ ] T4.4.3 Implement getMaintenanceHeatmapData() - days since maintenance by rack
    - [ ] T4.4.4 Handle edge cases: no sales data, unassigned categories with sales `[ref: product-requirements.md; lines: 496-501]`
    - [ ] T4.4.5 Implement percentile-based color scaling (5th-95th) for outlier handling

- [ ] T4.5 MaintenanceService `[component: services]` `[activity: api-development]`
    - [ ] T4.5.1 Create `MaintenanceService.php` `[ref: solution-design.md; line: 564]`
    - [ ] T4.5.2 Implement calculateMaintenanceScore() with combined formula `[ref: solution-design.md; lines: 1710-1743]`
    - [ ] T4.5.3 Implement getMaintenanceQueue() - prioritized list
    - [ ] T4.5.4 Implement markMaintained() - log maintenance action
    - [ ] T4.5.5 Implement verifyMaintenance() - double-check by different user

- [ ] T4.6 Extend Rack Model `[component: models]` `[activity: domain-modeling]`
    - [ ] T4.6.1 Add getLastMaintenance(): MaintenanceLog|null
    - [ ] T4.6.2 Add getDaysSinceLastMaintenance(): int
    - [ ] T4.6.3 Add getMaintenanceScore(trafficMultiplier): float

- [ ] T4.7 Write Unit Tests - Heatmap Service `[component: tests]` `[activity: test-execution]`
    - [ ] T4.7.1 Test sales aggregation by subcategory
    - [ ] T4.7.2 Test socket mapping with multi-socket category shows same total on each
    - [ ] T4.7.3 Test percentile-based color scaling with outliers
    - [ ] T4.7.4 Test insufficient sales data detection (< 7 days)

- [ ] T4.8 Write Unit Tests - Maintenance Service `[component: tests]` `[activity: test-execution]`
    - [ ] T4.8.1 Test maintenance score calculation `[ref: solution-design.md; lines: 2215-2224]`
    - [ ] T4.8.2 Test rack with no maintenance history treated as maximally overdue
    - [ ] T4.8.3 Test maintenance queue ordering by score
    - [ ] T4.8.4 Test double-check requires different user than original

- [ ] T4.9 Heatmap API Endpoints `[component: controllers]` `[activity: api-development]`
    - [ ] T4.9.1 Create `HeatmapApiController.php`
    - [ ] T4.9.2 GET /api/:typeNum/floor-plan/plans/:planId/heatmap/sales `[ref: solution-design.md; lines: 1245-1256]`
    - [ ] T4.9.3 GET /api/:typeNum/floor-plan/plans/:planId/heatmap/maintenance `[ref: solution-design.md; lines: 1258-1268]`

- [ ] T4.10 Maintenance API Endpoints `[component: controllers]` `[activity: api-development]`
    - [ ] T4.10.1 Create `MaintenanceApiController.php`
    - [ ] T4.10.2 GET /api/:typeNum/floor-plan/maintenance (priority queue) `[ref: solution-design.md; lines: 1302-1308]`
    - [ ] T4.10.3 POST /api/:typeNum/floor-plan/racks/:rackId/maintain `[ref: solution-design.md; lines: 1310-1319]`

- [ ] T4.11 Write Integration Tests - Heatmap/Maintenance API `[component: tests]` `[activity: test-execution]`
    - [ ] T4.11.1 Test sales heatmap with date range filtering
    - [ ] T4.11.2 Test sales heatmap returns correct structure
    - [ ] T4.11.3 Test maintenance queue ordering
    - [ ] T4.11.4 Test mark maintained creates log entry

- [ ] T4.12 Admin UI - Reports Page `[component: frontend]` `[activity: component-development]`
    - [ ] T4.12.1 Create `admin/floorplan/reports.html` template
    - [ ] T4.12.2 Implement date range picker for sales heatmap
    - [ ] T4.12.3 Implement heatmap mode toggle (Socket Coloring / Gradient / Both)

- [ ] T4.13 Heatmap Visualization - Socket Coloring `[component: frontend]` `[activity: component-development]`
    - [ ] T4.13.1 Create `public_html/js/admin/floorplan/heatmap-socket-coloring.js`
    - [ ] T4.13.2 Implement color scale calculation (cold→hot)
    - [ ] T4.13.3 Apply fill colors directly to SyncFusion diagram nodes
    - [ ] T4.13.4 Implement hover tooltip showing sales breakdown by subcategory

- [ ] T4.14 Heatmap Visualization - Gradient Overlay `[component: frontend]` `[activity: component-development]`
    - [ ] T4.14.1 Install heatmap.js library `[ref: solution-design.md; lines: 1553-1565]`
    - [ ] T4.14.2 Create `public_html/js/admin/floorplan/heatmap-gradient.js`
    - [ ] T4.14.3 Create heatmap container overlay positioned over SyncFusion canvas
    - [ ] T4.14.4 Implement data point generation from socket positions
    - [ ] T4.14.5 Synchronize pan/zoom with SyncFusion viewport

- [ ] T4.15 Heatmap Overlay Controller `[component: frontend]` `[activity: component-development]`
    - [ ] T4.15.1 Create `public_html/js/admin/floorplan/heatmap-overlay.js` - unified controller
    - [ ] T4.15.2 Implement mode switching (socket / gradient / both)
    - [ ] T4.15.3 Implement sales vs maintenance heatmap toggle
    - [ ] T4.15.4 Handle "insufficient data" state with message overlay

- [ ] T4.16 Workbook Panel - Rack Maintenance `[component: workbook]` `[activity: component-development]`
    - [ ] T4.16.1 Create `workspace/partials/maintenance-panel.html` template
    - [ ] T4.16.2 Create `public_html/js/workspace/modules/floorplan/maintenance-panel.js`
    - [ ] T4.16.3 Implement priority-sorted rack list with score badges
    - [ ] T4.16.4 Implement "Done" button for marking maintenance complete
    - [ ] T4.16.5 Implement "Done Today" collapsed section
    - [ ] T4.16.6 Create API endpoint GET /api/:typeNum/floor-plan/workbook/maintenance `[ref: solution-design.md; lines: 1334-1343]`
    - [ ] T4.16.7 Register panel in workbook with count badge

- [ ] T4.17 Validate Phase 3 `[activity: test-execution]`
    - [ ] T4.17.1 Run full test suite: `./test.sh`
    - [ ] T4.17.2 Verify PRD Feature 7: Sales Heatmap Report `[ref: product-requirements.md; lines: 262-278]`
    - [ ] T4.17.3 Verify PRD Feature 8: Rack Maintenance Tracking `[ref: product-requirements.md; lines: 280-290]`
    - [ ] T4.17.4 Verify PRD Feature 9: Maintenance Heatmap Report `[ref: product-requirements.md; lines: 292-299]`
    - [ ] T4.17.5 Verify PRD Feature 10: Workbook Floor Panel `[ref: product-requirements.md; lines: 301-310]`
    - [ ] T4.17.6 Verify PRD Feature 11: Workbook Rack Maintenance Panel `[ref: product-requirements.md; lines: 312-322]`
    - [ ] T4.17.7 Manual test: View sales heatmap with date range, toggle modes, mark racks as maintained
    - [ ] T4.17.8 Manual test: Export PNG with background image enabled (verify export succeeds and includes background)

---

### T5 Phase 4: Event Integration

**Goal**: Enable automated layout scheduling tied to store events.

**Deliverables**:
- Layouts can be linked to events
- Activation dates sync with event dates
- Cron job auto-activates scheduled layouts
- Full audit trail for compliance

**Dependency**: Phase 2 complete + Event Management system deployed

---

- [ ] T5.1 Prime Context `[activity: exploration]`
    - [ ] T5.1.1 Read SDD event integration design `[ref: solution-design.md; lines: 431-451]`
    - [ ] T5.1.2 Read SDD FloorPlanAdapter specification `[ref: solution-design.md; lines: 1502-1511]`
    - [ ] T5.1.3 Read existing AbstractAdapter implementation `[ref: userfrosting/src/BuyerKiosk/EventManagement/Adapters/AbstractAdapter.php]`
    - [ ] T5.1.4 Read existing IntegrationService pattern `[ref: userfrosting/src/BuyerKiosk/EventManagement/Services/IntegrationService.php]`
    - [ ] T5.1.5 Read PRD Feature 12 acceptance criteria `[ref: product-requirements.md; lines: 324-334]`
    - [ ] T5.1.6 Read PRD Feature 14: Audit Log Viewer `[ref: product-requirements.md; lines: 343-350]`

- [ ] T5.2 FloorPlanAdapter `[component: services]` `[activity: api-development]`
    - [ ] T5.2.1 Create `FloorPlanAdapter.php` extending AbstractAdapter `[ref: solution-design.md; line: 567]`
    - [ ] T5.2.2 Define TYPE_FLOORPLAN constant in EventIntegration model
    - [ ] T5.2.3 Implement onEventDateChange() - sync layout activation date
    - [ ] T5.2.4 Implement onEventBuildUp() - optionally auto-generate tasks
    - [ ] T5.2.5 Register adapter in IntegrationService

- [ ] T5.3 Scheduled Activation Cron `[component: services]` `[activity: deployment-automation]`
    - [ ] T5.3.1 Create scheduled task for layout activation check
    - [ ] T5.3.2 Query layouts where activationDate <= today AND status = scheduled
    - [ ] T5.3.3 Activate each layout (use existing activateLayout method)
    - [ ] T5.3.4 Auto-generate tasks if not already generated
    - [ ] T5.3.5 Log activation in fpAuditLog

- [ ] T5.4 Event Link UI `[component: frontend]` `[activity: component-development]`
    - [ ] T5.4.1 Add event dropdown to layout create/edit dialog
    - [ ] T5.4.2 Show linked event name on layout card
    - [ ] T5.4.3 Implement auto-sync indicator for activation date
    - [ ] T5.4.4 Add "Unlink Event" option

- [ ] T5.5 Audit Log Viewer `[component: frontend]` `[activity: component-development]`
    - [ ] T5.5.1 Create audit log section in admin floor plan dashboard
    - [ ] T5.5.2 Implement action type filter
    - [ ] T5.5.3 Implement date range filter
    - [ ] T5.5.4 Implement user filter
    - [ ] T5.5.5 Implement CSV export for audit log

- [ ] T5.6 Write Unit Tests - Event Integration `[component: tests]` `[activity: test-execution]`
    - [ ] T5.6.1 Test FloorPlanAdapter implements IntegrationAdapterInterface
    - [ ] T5.6.2 Test event date change syncs to layout activationDate
    - [ ] T5.6.3 Test unlinking event preserves layout activation date

- [ ] T5.7 Write Integration Tests - Scheduled Activation `[component: tests]` `[activity: test-execution]`
    - [ ] T5.7.1 Test cron activates scheduled layout on date
    - [ ] T5.7.2 Test multiple layouts scheduled for same date - first created wins
    - [ ] T5.7.3 Test activation proceeds regardless of incomplete tasks
    - [ ] T5.7.4 Test audit log entry created on activation

- [ ] T5.8 Print Feature `[component: frontend]` `[activity: component-development]`
    - [ ] T5.8.1 Add print button to designer toolbar
    - [ ] T5.8.2 Create print-optimized CSS stylesheet
    - [ ] T5.8.3 Implement print preview with heatmap toggle
    - [ ] T5.8.4 Add layout name/date header to print view
    - [ ] T5.8.5 Verify readable at 8.5x11" / A4

- [ ] T5.9 Validate Phase 4 `[activity: test-execution]`
    - [ ] T5.9.1 Run full test suite: `./test.sh`
    - [ ] T5.9.2 Verify PRD Feature 6: Scheduled Layout Activation `[ref: product-requirements.md; lines: 252-260]`
    - [ ] T5.9.3 Verify PRD Feature 12: Event System Integration `[ref: product-requirements.md; lines: 324-334]`
    - [ ] T5.9.4 Verify PRD Feature 13: Print-Optimized Floor Plan `[ref: product-requirements.md; lines: 336-342]`
    - [ ] T5.9.5 Verify PRD Feature 14: Audit Log Viewer `[ref: product-requirements.md; lines: 343-350]`
    - [ ] T5.9.6 Manual test: Link layout to event, change event date, verify activation date syncs

---

### T6 Integration & End-to-End Validation

**Goal**: Ensure all components work together and meet quality requirements.

---

- [ ] T6.1 All unit tests passing `[activity: test-execution]`
    - [ ] T6.1.1 FloorPlanService tests
    - [ ] T6.1.2 LayoutService tests
    - [ ] T6.1.3 LayoutDiffService tests
    - [ ] T6.1.4 HeatmapService tests
    - [ ] T6.1.5 MaintenanceService tests
    - [ ] T6.1.6 Model tests (all entities)

- [ ] T6.2 All integration tests passing `[activity: test-execution]`
    - [ ] T6.2.1 FloorPlanApiController tests
    - [ ] T6.2.2 LayoutApiController tests
    - [ ] T6.2.3 HeatmapApiController tests
    - [ ] T6.2.4 MaintenanceApiController tests
    - [ ] T6.2.5 Permission enforcement tests

- [ ] T6.3 End-to-end user flows `[activity: exploratory-testing]`
    - [ ] T6.3.1 Complete floor plan creation flow (owner persona) `[ref: product-requirements.md; lines: 110-122]`
    - [ ] T6.3.2 Layout planning and transition flow `[ref: product-requirements.md; lines: 124-131]`
    - [ ] T6.3.3 Daily rack maintenance flow (employee persona) `[ref: product-requirements.md; lines: 133-141]`
    - [ ] T6.3.4 Floor layout lookup flow (employee persona) `[ref: product-requirements.md; lines: 143-149]`

- [ ] T6.4 Performance validation `[ref: solution-design.md; lines: 2103-2116]` `[activity: performance-testing]`
    - [ ] T6.4.1 Floor plan load time < 500ms
    - [ ] T6.4.2 SyncFusion diagram init < 300ms
    - [ ] T6.4.3 API response times < 200ms
    - [ ] T6.4.4 Heatmap calculation < 2s for 30-day aggregation
    - [ ] T6.4.5 Canvas with 100 racks maintains > 30fps
    - [ ] T6.4.6 Validate request size limits: PHP `post_max_size`/`upload_max_filesize` allow diagramData + thumbnails and background image uploads (or handle failures with clear errors)

- [ ] T6.5 Security validation `[activity: quality-review]`
    - [ ] T6.5.1 All endpoints require session authentication
    - [ ] T6.5.2 Permission checks on all write endpoints
    - [ ] T6.5.3 CSRF token validation on mutations
    - [ ] T6.5.4 No cross-store data access possible
    - [ ] T6.5.5 Audit log captures all mutations with user attribution
    - [ ] T6.5.6 Verify background image upload validation (MIME sniffing, extension not trusted; disallow SVG)

- [ ] T6.6 PRD acceptance criteria verification `[activity: business-acceptance]`
    - [ ] T6.6.1 Feature 1: Professional Floor Plan Designer - all criteria met `[ref: product-requirements.md; lines: 155-169]`
    - [ ] T6.6.2 Feature 2: Symbol Palette - all criteria met `[ref: product-requirements.md; lines: 172-206]`
    - [ ] T6.6.3 Feature 3: Rack Sockets - all criteria met `[ref: product-requirements.md; lines: 208-220]`
    - [ ] T6.6.4 Feature 4: Layout Versioning - all criteria met `[ref: product-requirements.md; lines: 222-232]`
    - [ ] T6.6.5 Feature 5: Layout Diff - all criteria met `[ref: product-requirements.md; lines: 234-250]`
    - [ ] T6.6.6 Feature 6: Scheduled Activation - all criteria met `[ref: product-requirements.md; lines: 252-260]`
    - [ ] T6.6.7 Feature 7: Sales Heatmap - all criteria met `[ref: product-requirements.md; lines: 262-278]`
    - [ ] T6.6.8 Feature 8: Maintenance Tracking - all criteria met `[ref: product-requirements.md; lines: 280-290]`
    - [ ] T6.6.9 Feature 9: Maintenance Heatmap - all criteria met `[ref: product-requirements.md; lines: 292-299]`
    - [ ] T6.6.10 Feature 10: Workbook Floor Panel - all criteria met `[ref: product-requirements.md; lines: 301-310]`
    - [ ] T6.6.11 Feature 11: Workbook Maintenance Panel - all criteria met `[ref: product-requirements.md; lines: 312-322]`

- [ ] T6.7 Test coverage meets standards `[activity: test-execution]`
    - [ ] T6.7.1 Run coverage report: `./test.sh --coverage`
    - [ ] T6.7.2 Verify critical paths have > 80% coverage
    - [ ] T6.7.3 Document any intentional coverage gaps

- [ ] T6.8 Documentation updated `[activity: system-documentation]`
    - [ ] T6.8.1 API documentation reflects all endpoints
    - [ ] T6.8.2 SyncFusion integration pattern documented in docs/patterns/
    - [ ] T6.8.3 Database schema documented

- [ ] T6.9 Build and deployment verification `[activity: deployment-automation]`
    - [ ] T6.9.1 CSS build completes without errors
    - [ ] T6.9.2 PHPStan analysis passes
    - [ ] T6.9.3 Deployment script completes successfully: `./deploy.sh`

- [ ] T6.10 All PRD requirements implemented `[activity: business-acceptance]`
    - [ ] T6.10.1 Must Have features (1-11): Complete
    - [ ] T6.10.2 Should Have features (12-18): Complete (Phases 1b + 4)
    - [ ] T6.10.3 Won't Have features: Not implemented (verified exclusion)

- [ ] T6.11 Implementation follows SDD design `[activity: quality-review]`
    - [ ] T6.11.1 Directory structure matches SDD directory map
    - [ ] T6.11.2 Database schema matches SDD interface specifications
    - [ ] T6.11.3 API contracts match SDD endpoint definitions
    - [ ] T6.11.4 Error handling follows SDD error table
    - [ ] T6.11.5 No undocumented deviations from SDD

---

## Summary

| Phase | Goal | Key Tables | Key Endpoints | Estimated Tasks |
|-------|------|------------|---------------|-----------------|
| **Phase 1** | Foundation MVP | 8 core tables | Floor Plan CRUD, Socket Assignments | 55+ tasks |
| **Phase 1b** | Usability | - | Background, Draft/Publish, Export | 25+ tasks |
| **Phase 2** | Layout Planning | fpMoveTasks | Diff, Tasks, Activation | 30+ tasks |
| **Phase 3** | Heatmaps & Maintenance | fpMaintenanceLogs | Heatmap, Maintenance Queue | 40+ tasks |
| **Phase 4** | Event Integration | - | Event Adapter, Audit Log | 25+ tasks |
| **Final** | E2E Validation | - | - | 30+ tasks |

**Total**: ~200+ individual tasks across 6 phases

**Critical Path**: Phase 1 → Phase 2 → Phase 4 (for event-driven activation)
**Parallel Option**: Phase 3 can develop independently after Phase 1