# Likwid Development Workflow

## Understanding the Architecture

```
┌─────────────────────────────────────────────────────────────┐
│                     SHARED CODEBASE                         │
│  backend/src/*    frontend/src/*    migrations/*            │
└─────────────────────────────────────────────────────────────┘
                            │
            ┌───────────────┴───────────────┐
            ▼                               ▼
┌─────────────────────┐         ┌─────────────────────┐
│   PRODUCTION DB     │         │     DEMO DB         │
│   (likwid_prod)     │         │   (likwid_demo)     │
│                     │         │                     │
│ - No demo users     │         │ - Demo users seeded │
│ - No seed data      │         │ - Full sample data  │
│ - DEMO_MODE=false   │         │ - DEMO_MODE=true    │
│ - Real user data    │         │ - Resettable        │
└─────────────────────┘         └─────────────────────┘
```

**Key insight**: Code changes affect both. Data is separate.

## Daily Development Workflow

### Your current setup IS the demo
Your local environment with `DEMO_MODE=true` and the seeded database is functionally equivalent to the demo deployment.

### Making code changes
1. Edit code normally
2. Backend auto-reloads (or `cargo run`)
3. Frontend hot-reloads (`npm run dev`)
4. Test with demo accounts

### Testing as different users
```
contributor / demo123  → Standard member experience
moderator / demo123    → Moderation features
observer / demo123     → Read-only experience
```

## When You Want a Fresh Demo

### Option 1: Reset database (quick)
```powershell
# Drop and recreate database
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run
```

### Option 2: Use the reset script (when using containers)
```powershell
.\scripts\demo-reset.ps1
```

## Deploying for Others

### For testers/curious users (Demo)
```bash
# Uses separate database on port 5433, backend on 3001, frontend on 4322
cp compose/.env.demo.example compose/.env.demo
podman-compose --env-file compose/.env.demo -f compose/demo.yml up -d
```

### For real users (Production)
```bash
# 1. Remove demo seed data
rm backend/migrations/20260127150000_demo_seed_data.sql

# 2. Configure production
cp compose/.env.production.example compose/.env.production
# Edit with secure passwords and your domain

# 3. Deploy
podman-compose --env-file compose/.env.production -f compose/production.yml up -d
```

## Common Tasks

### "I broke the demo data"
```powershell
cd backend
sqlx database drop -y && sqlx database create && sqlx migrate run
```

### "I want to test production-like (no demo data)"
```powershell
# Temporarily move the demo migration
mv backend/migrations/20260127150000_demo_seed_data.sql backend/migrations/20260127150000_demo_seed_data.sql.bak

# Reset database
sqlx database drop -y && sqlx database create && sqlx migrate run

# Set DEMO_MODE=false in .env
```

### "I want demo data back"
```powershell
# Restore migration
mv backend/migrations/20260127150000_demo_seed_data.sql.bak backend/migrations/20260127150000_demo_seed_data.sql

# Reset database
sqlx database drop -y && sqlx database create && sqlx migrate run

# Set DEMO_MODE=true in .env
```

### "I want to run both demo and production locally"
Use the container deployments - they use different ports:
- Demo: localhost:4322 (frontend), localhost:3001 (backend)
- Prod: localhost:4321 (frontend), localhost:3000 (backend)

## Summary

| Concern | Solution |
|---------|----------|
| Code changes affect demo? | Yes, same codebase. That's expected. |
| Data separation | Different databases (demo vs prod) |
| Reset demo | `sqlx database drop && create && migrate` |
| Test production locally | Remove demo migration, set DEMO_MODE=false |
| Deploy for others | Use compose files with separate DBs |