# Linear Tasks Updated - Phase 3 Strategic Analysis
**Date:** 2025-10-12
**Context:** Corrected Event 123 → Event 1 throughout Phase 3 planning

---

## Summary of Updates

**Total Tasks Updated:** 5
**Linear Project:** Showprima (09-07)
**Phase:** 3 - Venue Architecture Refactor

---

## ✅ Task 09-385: 3.1 [Backend] Design venue separation architecture

**Status:** Backlog → **In Progress** ✅
**Duration:** 2 hours → **4 hours actual** (strategic analysis)

**Key Updates:**
- ❌ Event 123 (0 seats) → ✅ Event 1 (1,155 seats)
- Added Phase 1/2 interdependency analysis
- Documented VenueController refactoring requirements
- Revised 40-hour implementation timeline (was 25 hours)
- Created 2 comprehensive planning documents (800+ lines)

**Documents Created:**
1. `_docs/plans/venue-separation-architecture.md` (UPDATED)
2. `_docs/plans/phase-3-strategic-analysis.md` (NEW - 620 lines)

**Critical Findings:**
- VenueController already exists but treats events as venues
- Event creation wizard has NO venue selection
- AdminController::createEvent() needs venue_id parameter
- Breaking changes required in backend AND frontend

**Commit:** d94e0a5

---

## ✅ Task 09-388: 3.4 [Backend] Migrate Event 1 venue to venues table

**Status:** Backlog (description updated)
**Duration:** 1 hour → **2 hours** (revised)

**Title Updated:**
- Old: "3.4 [Backend] Migrate Event 123 venue to venues table"
- New: "3.4 [Backend] Migrate Event 1 venue to venues table" ✅

**Description Updates:**
- Event 123 (75 seats) → Event 1 (1,155 seats)
- Added critical data inventory:
  - 1,048 individual seats + 97 tables = 1,155 total
  - 6 sections
  - 78 reservations (71 booked + 7 ACTIVE holds)
  - 164 orders with payment history
- Added verification requirements
- Updated to create "Grand Theatre" as Venue 1

**Critical Notes:**
- 7 active "held" reservations must not be disrupted
- Migration during maintenance window (3am-4am recommended)
- Artisan command: `php artisan migrate:event-to-venue 1`

---

## ✅ Task 09-391: 3.7 [Backend] Migrate Event 1 to new venue structure

**Status:** Backlog (description updated)
**Duration:** 1.5 hours → **3 hours** (revised)

**Title Updated:**
- Old: "3.7 [Backend] Migrate Event 123 to new venue structure"
- New: "3.7 [Backend] Migrate Event 1 to new venue structure" ✅

**Description Updates:**
- Event 123 (75 seats) → Event 1 (1,155 seats)
- Added comprehensive verification queries:
  ```sql
  SELECT COUNT(*) FROM seats WHERE event_id = 1; -- Must be 1155
  SELECT COUNT(*) FROM seat_reservations WHERE event_id = 1; -- Must be 78
  SELECT COUNT(*) FROM orders WHERE event_id = 1; -- Must be 164
  ```
- Added rollback plan reference
- Added seat UUID verification requirement
- Added E2E booking test requirement

**Critical Verification:**
- All 1,155 seats must remain intact
- 78 reservations unchanged
- 164 orders intact
- Seat UUIDs match pre-migration snapshot

---

## ✅ Task 09-394: 3.10 [Backend] Create venue management API endpoints

**Status:** Backlog (description updated)
**Duration:** 3 hours → **8 hours** (MAJOR REVISION)

**Title:** Unchanged (but description completely rewritten)

**Description Updates:**
- ⚠️ **CRITICAL**: VenueController already exists from Phase 1/2
- Current implementation is "bridge solution" (events as venues)
- Task changed from "Create" to "Refactor"

**Current Bridge Implementation:**
```php
// VenueController.php line 81
'venue_type' => 'event'  // ⚠️ NOT A REAL VENUE!
```

**Refactoring Requirements:**
- FROM: `GET /api/venues` → Returns events
- TO: `GET /api/venues` → Returns actual venues table

**Breaking Changes Documented:**
- Frontend may be calling old endpoints (audit needed)
- AdminController::createEvent() needs venue_id parameter
- Event wizard needs venue selector component

**Dual Support Strategy:**
- Maintain backward compatibility for Event 1
- New events use new venue-based endpoints
- Feature flags for gradual rollout

**File Location:** `app/Http/Controllers/API/VenueController.php` (REFACTOR EXISTING)

---

## ✅ Task 09-395: 3.11 [Frontend] Update venue selection in event form

**Status:** Backlog (description updated)
**Duration:** 3 hours → **6 hours** (revised)

**Title:** Unchanged

**Description Updates:**
- ⚠️ **CRITICAL**: Event wizard has NO venue selection currently
- LocationStep collects address directly (must be replaced)

**Current Wizard Flow (Phase 2):**
1. BasicInfoStep
2. ScheduleStep
3. **LocationStep - Address input** ⚠️
4. TicketingStep
5. PublishingStep
6. ReviewStep

**New Wizard Flow (Phase 3):**
1. BasicInfoStep (unchanged)
2. ScheduleStep (unchanged)
3. **VenueStep - Venue selector** ✅ NEW
4. TicketingStep (unchanged)
5. PublishingStep (unchanged)
6. ReviewStep - with venue_id ✅ UPDATED

**Components to Create:**
- VenueSelector component
  - Fetch venues from GET /api/venues
  - Display venue options (Venue 1 "Grand Theatre", etc.)
  - Template version selector
  - Preview venue capacity/layout
  - "Create New Venue" button

**Form Schema Changes:**
- Remove: address, city, state fields
- Add: venue_id, venue_template_id

**API Integration Updates:**
- POST /api/admin/events with venue_id (not address)
- Handle validation errors

**Location:** `/Users/charlie/code/showprima-frontend/apps/admin/`

---

## Revised Phase 3 Timeline

**Original Estimate:** 25 hours
**Revised Estimate:** 40 hours (+60%)

**Reason for Increase:**
- VenueController complete refactor (not new endpoints)
- Event wizard major update (venue selector integration)
- Frontend audit and breaking changes
- More comprehensive testing (Event 1 has real orders)
- Coordination between backend and frontend teams

**Task Breakdown:**
- 3.2 Schema & Models: 6 hours
- 3.3 Event 1 Migration Script: 4 hours
- 3.4 Backend API Refactor: 8 hours (VenueController)
- 3.5 Frontend Venue Selector: 6 hours
- 3.6 Wizard Integration: 4 hours
- 3.7 Testing: 6 hours
- 3.8 Deployment: 4 hours

**Total:** 40 hours (2 weeks with proper coordination)

---

## Critical Event 1 Data

**Event ID:** 1
**Event Name:** "Test Event"

**Seat Inventory:**
- 1,048 individual seats
- 97 tables
- **1,155 total seats**
- 6 sections

**Reservations:**
- 71 booked
- **7 held (ACTIVE - must not disrupt!)**
- **78 total reservations**

**Orders:**
- **164 orders** with payment history

**Venue Template:**
- 6 sections
- Complex layout (tables + individual seats)
- One of **3 reusable venues** for future events

---

## Decision Points Required

Before starting Task 3.2 implementation:

### 1. Venue Naming
**Question:** What should Event 1's venue be called?
- **Option A:** "Grand Theatre" (generic, reusable)
- **Option B:** "Test Event Venue" (descriptive but not reusable)
- **Option C:** Extract from Event 1 address field

**Recommendation:** Option A - future-proof naming

### 2. Legacy Events (123, 124)
**Question:** Keep or delete empty test events?
- Event 123: "Test Concert 2025" - 0 seats
- Event 124: "24234234" - 0 seats

**Options:**
- **Option A:** Delete (clean slate)
- **Option B:** Keep for reference

**Recommendation:** Option B - Keep until Phase 3 complete

### 3. Backward Compatibility Timeline
**Question:** How long support dual architecture?
- **Option A:** 1 month (aggressive deprecation)
- **Option B:** 3 months (safer transition)
- **Option C:** Forever (maximum flexibility)

**Recommendation:** Option B - 3 months gives time to migrate remaining events

---

## Next Steps

### Immediate (This Week)

1. **Review Strategic Analysis**
   ```bash
   open _docs/plans/phase-3-strategic-analysis.md
   # Read Sections 1-5 minimum
   ```

2. **Create Backup NOW**
   ```bash
   cd /Users/charlie/code/showprima
   ./scripts/backup-db.sh
   # Verify: 1,155 seats, 78 reservations, 164 orders
   ```

3. **Make Decisions**
   - Venue 1 name?
   - Event 123/124 handling?
   - Backward compatibility timeline?

4. **Frontend Audit**
   ```bash
   cd /Users/charlie/code/showprima-frontend
   grep -r "/api/venues" apps/admin/ apps/ticketing/
   # Document all VenueController API calls
   ```

### Week 1 (Backend)

**Day 1-2: Task 3.2 (Schema & Models)**
- Create `venues` table migration
- Create `event_venues` join table migration
- Add `venue_id` to `venue_templates` (nullable)
- Create Venue and EventVenue models

**Day 3: Task 3.3 (Event 1 Migration Script)**
- Artisan command: `php artisan migrate:event-to-venue 1`
- Automated verification (1,155 seats check)
- Test on staging first

**Day 4-5: Task 3.4 (Backend API Refactor)**
- Refactor VenueController to use `venues` table
- Update AdminController::createEvent() for `venue_id`
- Maintain backward compatibility for Event 1

### Week 2 (Frontend + Testing)

**Day 1-2: Task 3.5 (Frontend Venue Selector)**
- Create VenueSelector component
- Integrate with event wizard
- Update form schema

**Day 3: Task 3.6 (Wizard Integration)**
- Replace LocationStep with VenueStep
- Update API calls to createEvent
- Update validation rules

**Day 4: Task 3.7 (Testing)**
- Unit tests for new models
- Integration tests for venue APIs
- E2E test: Create event with venue selection
- E2E test: Event 1 booking still works

**Day 5: Task 3.8 (Documentation & Deployment)**
- API documentation updates
- Migration runbook
- Deploy to staging
- Smoke tests

---

## Risk Mitigation

### High Risk: Event 1 Data Loss
**Probability:** Low (with proper backups)
**Impact:** CATASTROPHIC (1,155 seats, 78 reservations, 164 orders)

**Mitigation:**
1. Backup before ANY changes (`./scripts/backup-db.sh`)
2. Automated verification after migration
3. Transaction wrapping
4. Rollback tested on staging first
5. Monitor seat count in real-time

### High Risk: Active Reservations During Migration
**Probability:** Medium (7 held seats on Event 1)
**Impact:** HIGH (booking failures, customer complaints)

**Mitigation:**
1. Schedule maintenance window (3am-4am)
2. Extend hold expiration times before migration
3. Disable new bookings during migration
4. Migration should take <5 minutes

### High Risk: Frontend Breaking Changes
**Probability:** High (VenueController refactor)
**Impact:** HIGH (event creation broken)

**Mitigation:**
1. Feature flags for new vs old APIs
2. Dual API support during transition
3. Frontend can fallback to old flow
4. Phased rollout (staging → 10% prod → 100%)

---

## Success Criteria

### Data Integrity
- ✅ Event 1 has exactly 1,155 seats (unchanged)
- ✅ Event 1 has exactly 78 seat reservations
- ✅ Event 1 has exactly 164 orders (unchanged)
- ✅ All seat UUIDs match pre-migration snapshot
- ✅ All order_line_items intact
- ✅ price_snapshot data unchanged

### Functionality
- ✅ Event 1 booking flow works (E2E test passes)
- ✅ New events can be created with venue selection
- ✅ Venue templates can be reused across events
- ✅ VenueController returns real venues (not events)
- ✅ Event wizard includes venue selector

### Performance
- ✅ Venue template queries < 200ms
- ✅ Event listing with venues < 300ms
- ✅ Seat availability query unchanged performance
- ✅ No N+1 queries detected

---

## Links & References

**Linear Project:** https://linear.app/09-07/project/showprima
**Strategic Analysis:** `/Users/charlie/code/showprima/_docs/plans/phase-3-strategic-analysis.md`
**Architecture Doc:** `/Users/charlie/code/showprima/_docs/plans/venue-separation-architecture.md`
**Git Commit:** d94e0a5

**Updated Tasks:**
- [09-385](https://linear.app/09-07/issue/09-385) - Task 3.1 Design (In Progress)
- [09-388](https://linear.app/09-07/issue/09-388) - Task 3.4 Migrate Event 1
- [09-391](https://linear.app/09-07/issue/09-391) - Task 3.7 Migrate to structure
- [09-394](https://linear.app/09-07/issue/09-394) - Task 3.10 Refactor VenueController
- [09-395](https://linear.app/09-07/issue/09-395) - Task 3.11 Frontend wizard

---

**Last Updated:** 2025-10-12
**Next Review:** Before starting Task 3.2 implementation