likwid/WORKFLOW.md

# 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 local setup can behave like the demo
Your local environment is functionally equivalent to the demo deployment when `DEMO_MODE=true` and demo seed migrations have been applied (from `backend/migrations_demo`).

### 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

# If you want demo seed data, also run:
sqlx migrate run --source migrations_demo
```

### 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. Configure production
cp compose/.env.production.example compose/.env.production
# Edit with secure passwords and your domain

# 2. 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
# Set DEMO_MODE=false in .env

# Reset database (core migrations only)
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run
```

### "I want demo data back"
```powershell
# Set DEMO_MODE=true in .env

# Reset database + re-seed demo
cd backend
sqlx database drop -y
sqlx database create
sqlx migrate run
sqlx migrate run --source migrations_demo
```

### "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; sqlx database create; sqlx migrate run; sqlx migrate run --source migrations_demo` |
| Test production locally | Set DEMO_MODE=false and run only core migrations (skip `migrations_demo`) |
| Deploy for others | Use compose files with separate DBs |