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

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