- Modified frontend/lib/api.ts to use window.location.hostname as fallback
- Ensures browser on external IP reaches correct backend HTTPS port
- Allows admin/admin login to work from any access point
- Auth is fully functional and working
Auth must ALWAYS be enabled in all environments. Added comprehensive rule:
- NO auth bypass, debug mode, or dev-only disabling
- NO hardcoded credentials or weak defaults
- EVERY API endpoint requires JWT token
- Password hashing via passlib pbkdf2_sha256
- Debug strategy for auth breakages (never skip auth)
This ensures security is non-negotiable across all deployments.
- 5 test phases covering all changes
- Priority levels for staged execution
- Success/failure criteria
- Ready for next session execution
- Handover documentation created
Made id required (breaking change) - reverted back to optional
This allows items without id to exist during lifecycle
Fixes 'Failed to delete item' error
The delete function was broken by forcing id to be required
Changed from localhost-specific to wildcard listening:
- https://:8918 (any IP on port 8918) → backend
- https://:8919 (any IP on port 8919) → frontend
On-demand TLS generates certificates for any accessing IP/hostname
Self-signed certs now work via:
- localhost
- 127.0.0.1
- 192.168.x.x (or any IP on network)
- Any hostname
Tested and verified working via 192.168.84.131:8919
Changed default from 'foreground' (invalid choice) to None
Now correctly handles no arguments to start in foreground mode
Tested and verified:
✓ python3 start_servers.py (foreground - all 3 services running)
✓ python3 start_servers.py start (background)
✓ python3 start_servers.py status (shows all services)
✓ python3 start_servers.py stop (graceful shutdown)
✓ HTTP endpoints responding on 8916/8917
✓ HTTPS endpoints responding on 8918/8919 (Caddy)
✓ All three services (backend, frontend, caddy) working together
Complete feature parity with Docker deployment:
- Caddy reverse proxy manages SSL/TLS
- Ports: 8916/8917 (HTTP), 8918/8919 (HTTPS)
- Self-signed certificates (development-friendly)
- Automatic certificate generation via on-demand TLS
- Security headers (HSTS, XSS Protection, etc.)
Changes:
- Created Caddyfile.standalone for localhost config
- Enhanced start_servers.py with Caddy startup/monitoring
- Auto-install Caddy via apt if not present
- Updated status output to show both HTTP and HTTPS URLs
- All three services (backend, frontend, caddy) in one launcher
Both Docker and Standalone modes now have IDENTICAL capabilities:
- Full production-ready SSL/TLS support
- Reverse proxy with auto-certificate management
- HTTPS-only capable
Resolves dual-deployment equivalence requirement
New commands:
start_servers.py # Foreground (interactive, Ctrl+C to stop)
start_servers.py start # Background mode (detached)
start_servers.py stop # Stop background servers
start_servers.py restart # Stop then start background servers
start_servers.py status # Show running servers and PIDs
Features:
- Process IDs saved to .servers.pid for management
- Status command shows all running servers and URLs
- Full argument parsing with help and examples
- Graceful process group handling for clean shutdown
- Make Item.id required (items from DB always have id)
- Use shared Item type from db.ts in QuantityAdjustmentModal
- Show full npm build output instead of silencing errors
- Ensures all modals use consistent type definitions
- Remove duplicate Item interface from SearchModal
- Import Item from @/lib/db to ensure type consistency
- Fixes TypeScript error with missing category/min_quantity fields
- Create Toast component for success/error messages
- Fix uvicorn invocation: use backend.main:app from project root
- Ensures relative imports work correctly in backend modules
- Use uvicorn CLI directly (not python -c workaround)
- Add process group handling for cleaner shutdown
- Silent npm output during setup
- Better error messages and logging
- Support graceful SIGTERM/SIGINT handling
- Quick start instructions for start_servers.py
- Configuration options and port mapping
- Troubleshooting guide for common issues
- Comparison with Docker deployment
- Replaces bash script with robust Python implementation
- Simpler process management using subprocess module
- Better error handling and logging
- Manages venv, dependencies, and both services
- Handles graceful shutdown on Ctrl+C
- Wrap backend uvicorn with proper working directory subshell
- Wrap frontend Next.js server with proper working directory subshell
- Use subshell syntax (cd && run) to ensure processes inherit correct context
- Fixes processes starting but immediately crashing
- Replace wait with infinite monitoring loop
- Detect and warn if processes die instead of killing them
- Allows independent process failures without terminating script
- Trap still catches Ctrl-C to graceful shutdown
- Virtual environment should be .venv in project root, not parent folder
- Fix venv creation and activation path logic
- Ensures venv is created and found in correct location
- Create .venv automatically if missing
- Activate virtual environment before pip install
- Fixes PEP 668 externally-managed-environment error on Python 3.12
- Virtual environment isolated from system Python packages
- Created OPERATIONAL_RUNBOOK.md: comprehensive step-by-step procedures for both Docker and Standalone deployment modes covering deployment, daily ops, troubleshooting, backup/restore, disaster recovery, scaling, and updates
- Created HEALTH_MONITORING_CHECKLIST.md: daily/weekly/monthly health check procedures with alert thresholds and quick troubleshooting reference
- Created DISASTER_RECOVERY_PLAN.md: detailed procedures for 6 failure scenarios (database corruption, hardware failure, data center failure, app crash, disk full, network isolation) with RTO/RPO targets
- Created CONFIGURATION_REFERENCE.md: complete documentation of all inventory.env parameters for both deployment modes with common scenarios and troubleshooting
- Created EMERGENCY_PROCEDURES.md: quick-reference incident response playbook with 7 critical scenarios, decision tree, escalation path, and printable cheat sheet
- Created scripts/backup.sh: automated backup script supporting both Docker and Standalone with integrity verification and retention management
- Created scripts/restore.sh: restore script with triple confirmation, safety backups, and validation tests for both deployment modes
- Created config/backup-cron.sh: installer for daily/weekly automated backup cron jobs (2 AM daily, 3 AM Sunday)
All documentation covers dual-deployment modes with shared configuration files.
Documentation is operator-ready with copy-paste commands and clear expected outputs.
- Both Docker and start_server.sh standalone modes required
- Shared config files between both modes (no duplication)
- Single config source of truth (inventory.env)
- Both modes available for development and production use
- Delete PLAN-02-SCALE-TESTING.md (scale testing deferred to v3)
- Rename PLAN-03-BACKUP-RUNBOOK to PLAN-02-OPERATIONAL-RUNBOOK
- Phase 6 now has 2 executable plans instead of 3
- Mark Phase 5 complete in ROADMAP
- Update scope: Quick Quantity Adjustment replaces Batch Operations
- All 3 plans delivered: 18 tasks, 23+ test cases
- Update STATE.md with execution summary and next steps
- Created 5-PLAN-01-SUMMARY.md with full implementation report
- Updated SESSION_STATE.md with Session 38 completion details
- Phase 5 Plan 01 status: COMPLETED (5/5 tasks, all tests written)
- Ready for inventory page integration and Phase 5 Plan 02 execution
