memory: log task worker session - due dates, subtasks, task page

skills/app-builder/references/deploy.md

@@ -0,0 +1,66 @@
+# Dokploy Deployment Guide
+
+## Prerequisites
+- Dokploy server at 191.101.0.153 (Hostinger KVM2)
+- Dokploy API key in Bitwarden ("dokploy api key")
+- Gitea repos created at git.infra.nkode.tech
+
+## Compose File Structure
+
+Every app uses `docker-compose.dokploy.yml`:
+
+```yaml
+services:
+  api:
+    build:
+      context: ./apps/api  # or ./api, ./backend
+      dockerfile: Dockerfile
+    restart: unless-stopped
+    ports:
+      - 3001
+    environment:
+      - DATABASE_URL=${DATABASE_URL}
+      - PORT=3001
+      - NODE_ENV=production
+      - APP_URL=${APP_URL}
+      - ALLOWED_ORIGINS=${ALLOWED_ORIGINS}
+      - BETTER_AUTH_SECRET=${BETTER_AUTH_SECRET}
+      - HAMMER_API_KEY=${HAMMER_API_KEY}
+    command: sh -c 'bun run db:push && bun run src/index.ts'
+
+  web:
+    build:
+      context: ./apps/web  # or ./web, ./frontend
+      dockerfile: Dockerfile
+    restart: unless-stopped
+    ports:
+      - 80
+    depends_on:
+      - api
+```
+
+## Deployment Steps
+
+1. Push code to Gitea
+2. Create compose in Dokploy:
+   - Source type: raw compose with git URL
+   - Set env vars in Dokploy UI
+3. Configure domains in Dokploy:
+   - API: `api.<app>.donovankelly.xyz` → api service port
+   - Web: `app.<app>.donovankelly.xyz` → web service port
+4. Enable HTTPS (Dokploy handles Let's Encrypt)
+5. Deploy and verify health check
+
+## Domain Pattern
+
+- Test: `test-<app>.donovankelly.xyz`
+- Production: `<app>.donovankelly.xyz`
+- API: `api.<app>.donovankelly.xyz` (or `api.todo.donovankelly.xyz`)
+- Frontend: `app.<app>.donovankelly.xyz` (or `app.todo.donovankelly.xyz`)
+
+## Environment Variables
+
+Set in Dokploy compose env (not in docker-compose file):
+- All `${VAR}` references resolve from Dokploy env settings
+- Generate secrets with `openssl rand -hex 32`
+- Store everything in Bitwarden immediately after creating

skills/app-builder/references/legal-payments.md

@@ -0,0 +1,47 @@
+# Legal Protection & Payments
+
+## Legal (Lean Approach)
+
+### What Pieter Levels Uses
+Pieter Levels (maker of Nomad List, Remote OK, Photo AI) keeps it minimal:
+- Simple Terms of Service page
+- Simple Privacy Policy page
+- Generated with free/cheap tools, not expensive services like Termly
+
+### Recommended Approach
+1. **Terms of Service** — Use a free generator (TermsFeed free tier, GetTerms.io) or write a simple one
+2. **Privacy Policy** — Required if collecting any user data. Free generators available
+3. **Cookie Banner** — Only needed if using analytics/tracking cookies
+4. **Business Entity** — LLC ($50-150 depending on state) for liability protection
+5. **Don't over-engineer** — Until you have paying users, simple legal pages are fine
+
+### When to Upgrade
+- Taking payments → need proper ToS with refund policy
+- Handling health data → HIPAA considerations
+- EU users → GDPR compliance (data export, deletion rights)
+- Enterprise clients → may need SOC 2, BAA agreements
+
+## Payments
+
+### Options (Easiest to Hardest)
+
+| Service | Fees | Best For | Setup Time |
+|---------|------|----------|------------|
+| Lemon Squeezy | 5% + $0.50 | Merchant of record, handles tax/VAT | 1 day |
+| Paddle | 5% + $0.50 | Same as Lemon Squeezy, more established | 1 day |
+| Stripe | 2.9% + $0.30 | Full control, most flexible | 2-3 days |
+| Gumroad | 10% | Digital products, simplest | Hours |
+
+### Recommendation
+- **Start with Lemon Squeezy or Paddle** — they handle sales tax, VAT, and act as merchant of record (you don't need a business entity)
+- **Move to Stripe** when you need more control or lower fees at scale
+- Both have simple JS SDKs and webhook integrations
+
+### Integration Pattern
+```
+User clicks "Subscribe" → Redirect to payment provider checkout
+→ Provider handles payment → Webhook to your API
+→ API updates user subscription status in DB
+```
+
+Keep payment logic out of your app. Let the provider handle checkout, invoicing, and tax.

skills/app-builder/references/migrations.md

@@ -0,0 +1,49 @@
+# Database Migration Strategy
+
+## Drizzle ORM Migrations
+
+### Development (Local / Test)
+Use `db:push` for rapid iteration:
+```bash
+bun run db:push
+```
+This syncs schema directly — fast but destructive. Fine for dev/test.
+
+### Production
+Use `db:migrate` with generated migration files:
+```bash
+bun run db:generate  # creates SQL migration file
+bun run db:migrate   # applies migration
+```
+
+### Workflow
+1. Change schema in `src/db/schema.ts`
+2. Run `bun run db:generate` — creates migration in `drizzle/`
+3. Review the generated SQL
+4. Write rollback SQL in `drizzle/rollback/` (same filename)
+5. Test migration on staging
+6. Apply to production
+
+## Safe Migration Practices
+
+### Adding columns
+- Always add as nullable or with a default value
+- Never add non-nullable columns without defaults to tables with existing data
+
+### Removing columns
+- First deploy: stop reading/writing the column in code
+- Second deploy: remove the column from schema
+- Two-phase approach prevents errors during rolling deploys
+
+### Renaming columns
+- Don't rename directly — add new column, migrate data, remove old column
+
+### Adding indexes
+- Use `CREATE INDEX CONCURRENTLY` for large tables (avoids locks)
+- Drizzle may not generate concurrent indexes — check generated SQL
+
+## Backup Before Migration
+Always backup before production migrations:
+```bash
+pg_dump -Fc $DATABASE_URL > backup-$(date +%Y%m%d-%H%M%S).dump
+```

skills/app-builder/references/rollback.md

@@ -0,0 +1,43 @@
+# Rollback & Recovery
+
+## Levels of Rollback
+
+### 1. Code Rollback (Most Common)
+- Dokploy keeps previous builds
+- Redeploy previous compose version from Dokploy UI
+- Or: `git revert` the breaking commit, push, redeploy
+
+### 2. Database Rollback
+- Drizzle doesn't auto-generate down migrations
+- For schema changes, write explicit rollback SQL before deploying
+- Keep a `migrations/rollback/` directory with undo scripts
+- For data issues: restore from Dokploy Postgres backup
+
+### 3. Full Rollback
+- Dokploy allows complete service redeployment from any previous state
+- Database: restore from backup
+- Last resort: rebuild from Gitea source at known-good commit
+
+## Pre-Deploy Checklist
+
+Before any production deployment:
+- [ ] Feature works in test environment
+- [ ] User has approved in test
+- [ ] DB migration tested (if schema changed)
+- [ ] Rollback SQL written (if schema changed)
+- [ ] Health check passes after deploy
+
+## Staging Environment
+
+- Staging should mirror production schema
+- Periodically sync staging DB schema with prod
+- Never sync prod DATA to staging (privacy)
+- Test migrations on staging before prod
+
+## If Something Breaks in Prod
+
+1. **Assess severity** — is the app down or is it a bug?
+2. **If app is down** — redeploy previous Dokploy build immediately
+3. **If it's a bug** — fix in dev, test, deploy fix
+4. **If DB is corrupted** — restore from backup, investigate cause
+5. **Notify user** with what happened and what was done