Merge pull request #97 from dcsil/dev-frontend

Dev frontend

Author: VoidDominator

architecture/ArchitectureDiagram.png

@@ -21,3 +21,4 @@ For any architectural/engineering decisions we make, we will create an ADR (Arch
 - [ADR 006: Postiz](./adr-006.md)
 - [ADR 007: Gemini](./adr-007.md)
 - [ADR 008: Azure Virtual Machine (Deployment)](./adr-008.md)
+- [ADR 009: Cloudinary](./adr-009.md)

architecture/adrs/README.md

@@ -0,0 +1,43 @@
+## ADR 009: Cloudinary
+
+## Context
+
+We need reliable cloud storage for media assets uploaded by users for social media posts. Our social media management workflow requires:
+- Secure storage for images and videos uploaded by musicians
+- Public URLs for media files that can be accessed by social media APIs
+- Integration with our Next.js backend and Postiz scheduling system
+- Separation of concerns between media storage and post scheduling
+
+### Options
+
+1) Self-hosted storage on our server
+2) AWS S3
+3) Cloudinary
+
+## Decision
+
+We will use Cloudinary for media asset storage and management.
+
+Reasons for choosing Cloudinary:
+1) Provides reliable cloud infrastructure with built-in CDN, ensuring consistent access to media files for social media APIs regardless of our server status.
+2) Offers straightforward Node.js SDK integration that works seamlessly with our Next.js backend.
+3) Generates public URLs automatically, simplifying the handoff between our upload flow and Postiz's scheduling system.
+
+Reasons for not choosing alternatives:
+1) Self-hosted storage couples media availability to our server uptime, which creates a single point of failure that could break scheduled posts if the server goes down.
+2) AWS S3 requires more configuration for public URL management and CDN setup. This adds complexity without significant benefit for our use case.
+3) Separating storage from our Postiz container improves system reliability, as Postiz can focus on scheduling while Cloudinary handles media delivery.
+
+
+## Status
+
+Accepted
+
+## Consequences
+
+Using Cloudinary decouples media storage from our application server, which improves reliability for scheduled social media posts. The managed service reduces operational burden and provides a CDN out of the box. However, we accept vendor lock-in to Cloudinary's platform and potential costs if usage exceeds the free tier. The separation of concerns between storage (Cloudinary) and scheduling (Postiz) creates a more resilient architecture where each component can operate independently.
+
+## Potential Backups
+
+- AWS S3 with CloudFront, if Cloudinary pricing becomes prohibitive or we need more storage control.
+- Self-hosted storage on the server, for complete data ownership and no vendor lock-in, though this would require additional infrastructure management.

architecture/adrs/adr-009.md

@@ -1,3 +1,3 @@
 The frontend is made possible by a React web app. It connects to Next.js in the backend. In the MVP, the setup is as allows: the backend connects to a social media management API, specifically Postiz, which allows management of multiple social media platforms. The LLM API is Gemini. For the database, Prisma ORM and SQLite are used. (Longer term features include billing and authentication, which will be enabled by APIs.)
 
-<img src="./diagram.png" width="1000">
+<img src="./ArchitectureDiagram.png" width="1000">

architecture/diagram.md

@@ -17,6 +17,7 @@
     "@prisma/studio": "^0.511.0",
     "bcryptjs": "^2.4.3",
     "class-variance-authority": "^0.7.1",
+    "cloudinary": "^2.8.0",
     "clsx": "^2.1.1",
     "jsonwebtoken": "^9.0.2",
     "lucide-react": "^0.545.0",
@@ -34,13 +35,15 @@
     "@eslint/eslintrc": "^3",
     "@tailwindcss/postcss": "^4",
     "@testing-library/dom": "^10.4.1",
+    "@testing-library/jest-dom": "^6.9.1",
     "@testing-library/react": "^16.3.0",
     "@types/bcryptjs": "^2.4.6",
     "@types/jsonwebtoken": "^9.0.7",
     "@types/node": "^20",
     "@types/react": "^19",
     "@types/react-dom": "^19",
     "@vitejs/plugin-react": "^5.0.4",
+    "@vitest/coverage-istanbul": "^3.2.4",
     "@vitest/coverage-v8": "^3.2.4",
     "eslint": "^9",
     "eslint-config-next": "15.5.4",

architecture/diagram.png architecture/diagram_old.pngarchitecture/diagram.png renamed to architecture/diagram_old.png

@@ -120,6 +120,7 @@ model User {
 
   // Relations
   preferences      UserPreference?
+  profile          UserProfile?
   authAccounts     AuthAccount[]
   refreshTokens    RefreshToken[]
   emailVerifications EmailVerificationToken[]
@@ -161,6 +162,24 @@ model UserPreference {
   updatedAt DateTime @updatedAt
 }
 
+// User onboarding profile
+model UserProfile {
+  id        String   @id @default(cuid())
+  userId    String   @unique
+  user      User     @relation(fields: [userId], references: [id], onDelete: Cascade)
+  
+  // Onboarding answers
+  hasReleasePlan      Boolean?  // Do they have a release plan?
+  releaseProgress     String?   // "not_started" | "planning" | "in_progress" | "ready_to_launch"
+  helpNeeded          String    @default("[]") // JSON array: ["project_planning", "time_management", "social_media_promotion", "networking"]
+  
+  // Track completion
+  onboardingCompleted Boolean   @default(false)
+  
+  createdAt DateTime @default(now())
+  updatedAt DateTime @updatedAt
+}
+
 // OAuth accounts for authentication (e.g., Google/Apple for sign-in)
 model AuthAccount {
   id                 String @id @default(cuid())