Sprint 1: Foundation & Core Data Layer

Focus: Sprint 1 established the foundational infrastructure of FindMySpot. The goal was to get the core data pipeline working end-to-end: a camera detects a license plate, the AI processes it, the result is stored in the database, and a user can search for their vehicle and see its location. Everything downstream in Sprint 2 and Sprint 3 depends on this layer being reliable.

What Went Well

1. Observer pattern (parking_observer.py) implemented cleanly with 3 concrete observers and a working demo
2. Database schema is well-designed with proper foreign keys, indexes, and CASCADE behavior
3. Full pipeline works end-to-end: Python OCR → POST to backend → session in PostgreSQL → locate endpoint returns location
4. Three migration files created with both PowerShell and Node.js runner; good developer onboarding
5. Camera config file (camera_config.json) created with a clear structure mapping 10 cameras to floors/lots
6. Vehicle search falls back to the detected_plates table if no session exists; good resilience thinking
7. EasyOCR confidence filtering and blocked words list reduce false positive detections significantly

What Didn't Go Well

1. camera_config.json was created but never actually read by app.py — floor/lot are assigned randomly.randint(1,5) instead
2. cv2.VideoCapture(0) hardcoded in both app.py and ai-service/api/app.py — Multi-camera support is not wired up
3. Confidence score hardcoded to 0.98 in send_parking_checkin() — real EasyOCR confidence never passed to backend TR4. UNCATE TABLE parking_spots, parking_sessions CASCADE runs on Every server starts in db.js — all sessions wiped on restart
4. parking_sessions uses VARCHAR(16) for vehicle_plate but user_vehicles allows VARCHAR(20) — schema mismatch
5. window_detections list grows unbounded within each 5-second window despite deque being imported but unused
6. ROI extracted from grayscale frame But EasyOCR performs better on color input; detection quality unnecessarily reduced
7. No migration versioning table; migrations can be re-run, causing constraint errors

Start/ Stop/ Continue

Start

1. Reading camera_config.json at startup and using the actual floor/lot for each camera instance.
2. Passing real EasyOCR confidence to the backend instead of hardcoding 0.98.
3. Using color ROI for EasyOCR instead of grayscale.
4. Adding a separate reset-db.js script to initializeDatabase() never TRUNCATEs.
5. Using deque(maxlen=50) for window_detection -- its already imported.
6. Migration version tracking to prevent duplicate runs.

Stop

1. Randomly assigning floor and lot; this breaks the core product feature.
2. Running TRUNCATE inside initializeDatabase(); destroys all data on every server restart.
3. Hardcoding cv2.VideoCapture(0); ignores all other configured cameras.
4. Using VARCHAR(16) for plates in parking_sessions; inconsistent with user_vehicles VARCHAR (20)
5. Extracting ROI from a grayscale frame reduces OCR accuracy unnecessarily.

Continue

1. Well-structured MVC backend architecture --> routes, controllers, modules clearly separated.
2. Observer pattern design --> clean and reusable for future notifications.
3. Three- migration structure --> clean and maintainable schema evolution.
4. Vote consensus detection --> good noise-reduction for OCR results.
5. Detection fallback to detected_plates --> good resilience when the session is missing.
6. camera_config.json structure --> well-designed, just needs to be actually used.

Sprint 2

Focus: Sprint 2 built the user-facing layer on top of Sprint 1's data foundation. The focus shifted from internal data processing to interactive features: how users check in manually, how they receive feedback, how occupancy is tracked in real time, and how the system handles time. This sprint also introduced the mobile app UI and the notification banner system.

What Went Well

1. Full push notification pipeline working: camera detects plate → DB notification record created → mobile banner shows unread alert
2. Stale data fallback in getOccupancyStats(); returns last known stats when DB fails rather than crashing
3. Auto-checkout timer implemented in both controllers to prevent sessions from staying open indefinitely
4. Mobile app UI is clean and polished with a consistent design system (style.css shared across all pages)
5. Parking history page (history.html) merges backend data with local storage entries; good resilience
6. vehicles.html implements local + backend merge with deduplication via mergeVehicles()
7. Notification bell, unread badge, mark-as-read, and mark-all-read are all working correctly
8. sidenav navigation implemented consistently across all pages with a hamburger toggle
9. Local storage history capped at 500 entries with slice(0, 500) to prevent overflow

What Didn't Go Well

1. Manual check-in posts to /api/detection/record (camera endpoint) instead of /api/parking/checkin — wrong endpoint for user input
2. appendLocalParkingHistory() and parkingSet() called BEFORE the API request — failed check-ins appear as successful in history
3. Two separate autoCheckoutTimers objects in detectionController.js and parkingController.js — cross-controller Checkouts leave stale timers
4. No fetch timeout on findVehicle() — The loading spinner can stay forever if backend hangs
5. Notification banner has no auto-dismiss — cycles indefinitely during active camera testing
6. check_out_time is always stored as null in local history — history always shows 'Active session' even after checkout
7. stale: true flag returned from backend but never checked by any frontend code
8. clearMessages() does not clear textContent — stale toast text can reappear
9. The spot input form allows values 1–5, but camera_config.json only defines lots 1 and 2 per floor

Start/Stops/Continue

Start

1. Posting manual check-in to /api/parking/checkin instead of /api/detection/record
2. Writing to local storage only AFTER a confirmed API success response
3. Centralizing autoCheckoutTimers into a shared timerService.js module
4. Adding AbortController with 10-second timeout to findVehicle() fetch calls
5. Checking the stale: true flag in the frontend and showing a 'Data may be outdated' warning
6. Auto-dismissing the notification banner after 15 seconds
7. Updating check_out_time in local history when backend checkout succeeds
8. Restricting spot input to lots 1–2 to match camera_config.json

Stop

1. Using the camera detection endpoint for user-initiated manual check-ins
2. Writing optimistic local state before API confirmation — creates phantom sessions
3. Silently ignoring the stale: true flag from the backend
4. Leaving toast textContent populated after clearMessages() — stale text resurfaces
5. Running unbounded notification polling with no rate limiting during active detection

Continue

1. Clean mobile-first UI design system in style.css; consistent and polished
2. Merging backend and local storage data for vehicles and history; good offline resilience
3. Notification system architecture; the pipeline from detection to bell icon works well
4. Auto-checkout timer concept; right idea, needs centralization
5. Stale data fallback for occupancy; correct defensive pattern
6. Shared sidenav navigation across all mobile-app pages
7. Local storage capping at 500 history entries

Sprint 3

Focus: Sprint 3 completed the feature set with analytics reporting, security flagging, cross-platform data sync, and the full parking session lifecycle. It also covered submission preparation — ensuring the repo was correctly set up, documentation was complete, and the system could be demonstrated end-to-end. This was also the sprint where the majority of bug documentation was completed.

What Went Well

1. Analytics report endpoint returns total sessions, completed sessions, average duration, peak hours, and live occupancy snapshot in one response
2. SecurityFlag.createIfMissing() pattern prevents duplicate flags for the same session, correctly using OPEN status check 3.isExitEvent() handles both explicit eventType='EXIT' and location-string detection — two layers of exit detection
3. Auto-checkout timer gives sessions a maximum 10- minute lifespan — prevents indefinitely open sessions in demo environments 5.test_system.py is a comprehensive integration test covering auth, vehicle registration, detection, history, and notifications
4. README has complete installation instructions covering Node.js backend, Python AI service, database setup, and mobile app
5. Security flag scan correctly joins parking_sessions with user_vehicles to detect unregistered vehicles
6. parking_observer.py delivered a clean, standalone Observer pattern demo with three distinct observer types

What Didn't Go Well

1. Security scan endpoint (POST /api/parking/security/scan) has no authentication middleware — anyone can trigger it
2. OPEN security flags never resolved when a vehicle checks out — flags accumulate indefinitely
3. AUTHORIZATION_DATA_MISSING flag created for every anonymous check-in, including all test/demo vehicles — floods security dashboard
4. hours Back cap at 720 hours is silent — no requested Hours field in response to indicate truncation occurred
5. averageParkingDurationMinutes returns null when no completed sessions exist, instead of defaulting to 0
6. occupancySnapshot in the usage report reflects the current live state, not the historical state for the requested window
7. EXIT detection relies on a location string containing 'EXIT' — 'Departure Lane' or 'Gate Out Ramp' would be missed
8. closeByExitDetection() returns 201 success even when no active session was found to close
9. fms_parking in localStorage never learned on vehicle checkout — stale location shown in offline mode after checkout
10. root index.html and mobile-app use completely different localStorage schemas — cross-interface sync not complete
11. setup-database.ps1 only runs migrations 001 and 002 — 003_security_flags.sql never referenced in the setup scripts

Start/Stop/Continue

Start

1. Adding auth middleware to all admin-only routes (/security/scan, /security/flags, /reports/usage)
2. Auto-resolving OPEN security flags in ParkingSession.checkout() when a session ends
3. Adding requestedHours to getUsageReport() response so callers know if data was capped
4. Defaulting averageParkingDurationMinutes to 0 instead of null when no completed sessions exist
5. Deleting fms_parking[plate] from localStorage on confirmed checkout success
6. Adding 003_security_flags.sql to setup-database.ps1 so it runs as part of the standard setup
7. Writing unit tests with Jest for parking.js model methods (create, checkout, locateVehicle)
8. Using INTERVAL '1 hour' * $1 instead of ($1::text || 'hours')::interval for safer SQL
9. Unifying the localStorage schema between root index.html and mobile-app into a single shared structure

Stop

1. Creating AUTHORIZATION_DATA_MISSING flags for every anonymous check-in — use a time threshold (e.g., parked > 2 hours) instead
2. Returning 201 success from closeByExitDetection() when no session was actually closed — use 200 with sessionClosed: false
3. Silently capping hours back without informing the caller
4. Relying solely on location string keywords for EXIT detection — this is fragile for non-standard camera labels
5. Leaving the security scan endpoint completely open without any authentication
6. Keeping root index.html as a parallel interface with its own incompatible localStorage schema

Continue

1. Analytics report endpoint structure — comprehensive response with metrics, peak hours, and occupancy snapshot
2. SecurityFlag.createIfMissing() deduplication pattern — prevents duplicate flags cleanly
3. test_system.py integration test suite — run it after every major change
4. Safe input bounding with Math.min/Math.max for query parameters
5. Two-layer EXIT detection (eventType + location string) — good defense-in-depth, just needs better keywords
6. README quality — installation instructions are thorough and cover all components
7. Auto-checkout concept via setTimeout — correct approach, centralize the timer map in Sprint 2 fixes