feat: pivot to social media workflow app

AGENTS.md

@@ -3,9 +3,35 @@
 ## Purpose
 This document is a working guide for coding agents in this repository. It captures the current architecture, conventions, and safe execution workflow for making reliable changes.
 
+## Documentation-First Workflow
+Agents must treat repository documentation as the source of truth. Conversation history is secondary and may be incomplete, stale, or contradictory.
+
+Before making any substantial code change, agents must read the relevant docs first. At minimum, inspect:
+- `AGENTS.md`
+- `docs/LLM_DEVELOPMENT_WORKFLOW.md`
+- `docs/PRODUCT.md` when product behavior, UX, or user workflow may change
+- `docs/ARCHITECTURE.md` when structure, module boundaries, routing, data flow, or integration points may change
+- `docs/CONVENTIONS.md` when adding or modifying code patterns
+- `docs/DECISIONS.md` before revisiting architecture or product decisions
+- the active `docs/tasks/TASK-*.md` file when one exists
+
+If one of these files does not exist yet, do not invent broad behavior from chat history. State what is missing and proceed only with the narrowest safe interpretation of the current task.
+
+For non-trivial work, follow this sequence:
+1. Read the relevant docs and existing code.
+2. Restate the task in a short summary.
+3. Identify backend impact, frontend impact, data impact, and documentation impact.
+4. List files likely to change.
+5. Surface ambiguities or risky assumptions.
+6. Propose a minimal implementation plan.
+7. Implement only the approved or clearly requested scope.
+8. Validate with the relevant commands before finishing when possible.
+
+Do not use a long chat thread as the durable memory for the project. Durable decisions, conventions, and task requirements belong in repository docs.
+
 ## Pair Working Mode
 - Work as a pair with the repository owner, not as an isolated implementer.
-- Before substantial changes, restate the task briefly and inspect the existing code or docs first.
+- Before substantial changes, read the relevant docs first, then restate the task briefly and inspect the existing code.
 - Surface assumptions, tradeoffs, and blockers early instead of silently picking risky directions.
 - Prefer small, reviewable increments when the product direction is still being shaped.
 - When requirements are exploratory, help turn them into concrete workflows, domain language, and next implementation steps.
@@ -14,29 +40,34 @@ This document is a working guide for coding agents in this repository. It captur
 - When creating commits, use the Conventional Commits format, for example `docs: update product planning`.
 
 ## Repository Layout
-- `backend/`: ASP.NET Core (`net9.0`) API using FastEndpoints, EF Core (PostgreSQL), Stripe, Azure Blob Storage, and ASP.NET Identity.
+- `backend/`: ASP.NET Core (`net10.0`) API using FastEndpoints, EF Core (PostgreSQL), ASP.NET Identity, and modular bounded contexts for workflow data.
 - `frontend/`: Vue 3 + Vite + Vuetify + Pinia + Vue Router + Tailwind CSS SPA.
-- `.github/workflows/`: deploy pipelines for backend (Azure Web App) and frontend (Azure Static Web Apps).
+- `.github/workflows/`: build/deploy pipelines for backend (Azure Web App) and frontend (Azure Static Web Apps).
 
 ## Local Runbook
 ### Backend
-- Prereqs: .NET 9 SDK, Docker, PostgreSQL container.
+- Prereqs: .NET 10 SDK, Docker, PostgreSQL container.
 - Start database:
   - `cd backend`
   - `./scripts/start-infrastructure.sh`
 - Run API:
-  - `dotnet run` (from `backend/`)
+  - `dotnet run --project Socialize.Api.csproj` (from `backend/`)
+- Local API URL:
+  - `http://localhost:5000`
 - Swagger/OpenAPI UI in dev:
   - `/api`
 
 ### Frontend
-- Prereqs: Node/npm, local HTTPS cert files expected by Vite:
-  - `frontend/localhost-key.pem`
-  - `frontend/localhost.pem`
+- Prereqs: Node/npm.
+- Runtime configuration:
+  - frontend app config is loaded from `.env.development` and `.env.production`
+  - `frontend/src/config.js` is the single frontend source of truth for runtime env access
 - Commands:
   - `cd frontend && npm install`
   - `npm run dev`
   - `npm run build`
+- Local dev server:
+  - `http://localhost:5173`
 
 ## Backend Architecture
 ### Composition Root
@@ -44,7 +75,7 @@ This document is a working guide for coding agents in this repository. It captur
 - Registers:
   - Web services/auth (`backend/DependencyInjection.cs`)
   - Infrastructure services (`backend/Infrastructure/DependencyInjection.cs`)
-  - Modules: Identity, Creators, Contents, Memberships, Tipping, Messaging.
+  - Modules: Identity, Workspaces, Clients, Projects, ContentItems, Assets, Comments, Approvals, Notifications.
 - Each module has:
   - `Add{Module}Module(...)` to register DbContext/services.
   - `Use{Module}ModuleAsync()` to auto-run migrations at startup.
@@ -57,78 +88,102 @@ This document is a working guide for coding agents in this repository. It captur
 
 ### Data Boundaries
 - Separate DbContext per module:
-  - Identity, Creators, Contents, Memberships, Tipping, Messaging.
+  - Identity, Workspaces, Clients, Projects, ContentItems, Assets, Comments, Approvals, Notifications.
 - Migrations are module-scoped under each `Modules/*/Migrations` folder.
 
 ### Auth/Security
 - JWT is generated manually in `Infrastructure/Security/GenerateJwtToken.cs`.
 - Refresh-token flow is implemented in Identity handlers (`/api/users/login`, `/api/users/refresh`).
 - User claim helpers live in `Infrastructure/Security/ClaimsPrincipalExtensions.cs`.
+- Role-gated frontend routes currently use `Administrator` and `Manager` checks for settings access.
 
-### Payments/Stripe
-- Tip checkout: `Infrastructure/Payments/Stripe/Services/StripeTipProcessor.cs`.
-- Membership checkout: `Infrastructure/Payments/Stripe/Services/MembershipPaymentProcessor.cs`.
-- Webhook endpoint: `Modules/Memberships/Handlers/StripeWebhookEndpoint.cs`.
-- Creator onboarding/status/revoke Stripe:
-  - `/api/stripe/connect`
-  - `/api/stripe/check-status`
-  - `DELETE /api/stripe`
-
-### Blob Storage
-- `IBlobStorage` implemented by `AzureBlobStorage`.
-- Upload size/type checks are enforced there (10 MB max + content-type validation).
+### Current Domain Modules
+- `Identity`: authentication, refresh tokens, email verification, password reset, social login.
+- `Workspaces`: workspace membership, workspace settings, access scoping.
+- `Clients`: client records and primary contacts tied to workspaces.
+- `Projects`: project pipeline and client/project relationships.
+- `ContentItems`: reviewable content records tied to clients/projects.
+- `Assets`: linked asset metadata and revision history.
+- `Comments`: discussion threads on reviewable work.
+- `Approvals`: review decisions and workflow state transitions.
+- `Notifications`: activity feed and unread workflow notifications.
 
 ## Frontend Architecture
 ### Bootstrap
 - `frontend/src/main.js` wires Vue app + Pinia + Vuetify + Router + i18n + Google OAuth + Toasts.
+- `frontend/src/config.js` is the app-facing runtime configuration module. Do not scatter `import.meta.env` reads across the app.
 
 ### Routing
 - Defined in `frontend/src/router/router.js`.
 - Route guards enforce:
   - `meta.requiresAuth`
   - `meta.notAuthenticated`
-- Creator public route convention: `/@:creator`.
+  - optional `meta.roles`
+- Primary authenticated app routes live under `/app/*`.
 
 ### State Management
 - Pinia stores:
   - `authStore`: token lifecycle + refresh concurrency guard.
+  - `workspaceStore`: active workspace context.
+  - `clientsStore`: client list and creation flows.
+  - `projectsStore`: project list and creation flows.
+  - `contentItemsStore` and `contentItemDetailStore`: content item listing/detail flows.
+  - `reviewQueueStore`: pending review work.
+  - `notificationsStore`: workflow notifications.
   - `userProfileStore`: current user profile and account edits.
-  - `creatorProfileStore`: creator-owned profile actions.
-  - `brandingStore`: creator page branding fetched from slug route param.
 
 ### API Client
 - Axios client in `frontend/src/plugins/api.js`.
 - Injects bearer token, proactively refreshes near expiry, retries once on 401.
 
 ## High-Value Domains
-- Identity and social login (`Modules/Identity/*`, `frontend/src/views/auth/*`).
-- Creator public profile and management (`Modules/Creators/*`, `frontend/src/views/creators/*`, `frontend/src/views/profile/*`).
-- Monetization:
-  - Tips (`Modules/Tipping/*`, creator donation UI)
-  - Memberships (`Modules/Memberships/*`, Stripe webhook orchestration)
-- Content albums/photo upload (`Modules/Contents/*`).
-- Messaging thread/replies (`Modules/Messaging/*`).
+- Identity and social login (`backend/Modules/Identity/*`, `frontend/src/views/auth/*`).
+- Workspace-scoped operations and role checks (`backend/Modules/Workspaces/*`, `frontend/src/stores/workspaceStore.js`, `frontend/src/router/router.js`).
+- Client and project workflow (`backend/Modules/Clients/*`, `backend/Modules/Projects/*`, `frontend/src/views/app/ClientsView.vue`, `frontend/src/views/app/ProjectsView.vue`).
+- Content review lifecycle (`backend/Modules/ContentItems/*`, `backend/Modules/Assets/*`, `backend/Modules/Comments/*`, `backend/Modules/Approvals/*`, `frontend/src/views/app/ContentItemsView.vue`, `frontend/src/views/app/ContentItemDetailView.vue`, `frontend/src/views/app/ReviewQueueView.vue`).
+- Notifications and workflow awareness (`backend/Modules/Notifications/*`, `frontend/src/stores/notificationsStore.js`).
+
+## Task-Driven Development With Agents
+Use `docs/tasks/TASK-*.md` files as LLM-friendly implementation tickets. A task file should be self-contained enough for a fresh agent to understand the desired change without relying on a long conversation.
+
+A good task file defines:
+- objective and product context
+- scope and out of scope
+- backend requirements, API contract, validation, data, authorization
+- frontend requirements, route/screen, components, state, API integration, UX states
+- files likely involved
+- acceptance criteria
+- validation plan
+- risks and open questions
+
+Features are fullstack by default unless the task explicitly says otherwise. Do not assume a feature is backend-only. For user-facing work, define both backend and frontend behavior before implementation.
+
+When an adjacent issue is discovered outside the task scope, do not fix it opportunistically. Report it as a suggested backlog item or add it to `docs/BACKLOG.md` if explicitly asked.
 
 ## Agent Working Rules For This Repo
 1. Keep module boundaries intact. Do not couple DbContexts across modules.
 2. When adding endpoints, follow existing FastEndpoints pattern with validator + explicit route + tag.
 3. If schema changes are needed, generate migration in the matching module only.
 4. Preserve token refresh behavior in frontend client/store; avoid introducing parallel refresh races.
-5. For file uploads, enforce content-type/size limits and reuse blob path conventions.
-6. Keep creator route contract stable (`/@slug`) because frontend and backend both depend on it.
-7. Do not commit secrets. Existing appsettings include sensitive-looking values; treat as legacy and avoid propagating.
+5. Keep frontend runtime configuration centralized in `frontend/src/config.js` and `.env.*`; do not introduce ad hoc env fallbacks.
+6. Preserve workspace scoping and route-role checks when editing app flows.
+7. Do not commit secrets. Existing appsettings and env files include sensitive-looking values; treat them as legacy and avoid propagating.
+8. For non-trivial features, prefer a `docs/tasks/TASK-*.md` file before implementation.
+9. Treat frontend behavior as part of the feature definition: route, components, Pinia store usage, API integration, loading/error/success states, and navigation must be explicit or derived from existing patterns.
+10. If requirements conflict with repository docs, stop and surface the conflict instead of silently choosing one.
 
 ## Validation Checklist Before Finishing
 - Backend:
-  - `cd backend && dotnet build`
-  - run affected endpoint flows if change touches handlers/auth/payments/storage
+  - `cd backend && dotnet build Socialize.Api.csproj`
+  - run affected endpoint flows if change touches handlers/auth/workspace scoping/data writes
 - Frontend:
   - `cd frontend && npm run build`
-  - validate affected route/store interactions in browser
+  - validate affected route/store interactions in browser when UI behavior changed
 - If migrations were changed:
   - ensure module context name/output directory remain consistent with `backend/scripts/add-migration.sh`.
 
 ## Notes / Known Sharp Edges
-- Frontend expects `VITE_API_URL` in API plugin; `src/config.js` uses `VITE_APP_API_URL` naming. Keep env usage consistent when editing.
-- `GetReceivedTips` currently resolves tipper with `tip.CreatorId` instead of `tip.CreatedBy`; verify intent before refactoring.
+- Frontend config should come through `.env.development` / `.env.production` and `frontend/src/config.js`; avoid direct `import.meta.env` reads in feature code.
+- Backend development now runs on HTTP locally (`http://localhost:5000`), while HTTPS redirection stays enabled outside development.
+- `frontend/.env.development` is currently checked in and points `VITE_API_URL` to `http://192.168.1.2:5000`; verify whether changes should target `localhost` or the LAN host before editing.
 - Some style/formatting is inconsistent across JS/Vue/C# files; minimize churn to touched lines.