chore: update gitignore for ai area

.gitignore

@@ -25,4 +25,7 @@ Thumbs.db
 .env.*.local
 
 # Local SSL certificates
-*.pem
+*.pem
+
+# Ai
+.codex

AGENTS.md

@@ -3,6 +3,15 @@
 ## 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.
 
+## 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.
+- 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.
+- Do not rewrite broad areas of the codebase without clear justification from the current task.
+- Preserve user changes in the worktree and treat uncommitted files as active collaboration unless told otherwise.
+
 ## Repository Layout
 - `backend/`: ASP.NET Core (`net9.0`) API using FastEndpoints, EF Core (PostgreSQL), Stripe, Azure Blob Storage, and ASP.NET Identity.
 - `frontend/`: Vue 3 + Vite + Vuetify + Pinia + Vue Router + Tailwind CSS SPA.

PLAN.md

@@ -0,0 +1,429 @@
+# PLAN
+
+## Purpose
+
+This document defines the build plan to close the gap between the current codebase and the target product described in [SOCIALIZE.md](/home/jbourdon/repos/social-media/SOCIALIZE.md).
+
+The current repository is a dead `Hutopy` codebase. The target product, temporarily named `Socialize`, is a workflow application for social media content review, revision, approval, and readiness for publication.
+
+This is a full product pivot, not a gradual feature expansion.
+
+## Goal
+
+Build a product that becomes the system of workflow for:
+
+- internal content review
+- provider collaboration
+- client approval
+- version tracking
+- audit trail
+- notification-driven progress
+- publication readiness handoff
+
+The first version should solve the approval pain cleanly before deeper integrations or scheduling features are added.
+
+## Gap Summary
+
+### Current Codebase
+
+The current repository contains:
+
+- backend modular structure with FastEndpoints and Entity Framework Core
+- authentication and infrastructure foundations
+- file storage patterns
+- frontend Vue application shell
+- legacy business modules centered on creators, tipping, memberships, and creator-facing experiences
+
+### Target Product
+
+The target product needs:
+
+- workspace and client management
+- provider and internal team collaboration
+- content item lifecycle management
+- asset and revision tracking
+- comments and approval workflow
+- workflow events and notifications
+- client-facing review portal
+- Google Drive-centered asset ownership
+- billing readiness for a future Software as a Service offering
+
+### Core Gap
+
+The codebase has technical scaffolding that can be reused, but the business domain is largely wrong for the target product.
+
+The main gap is not infrastructure. The main gap is domain shape, frontend surface, and workflow behavior.
+
+## Build Principles
+
+1. Reuse technical foundations when they help, but do not keep old business concepts for convenience.
+2. Keep the modular backend structure.
+3. Prefer clean domain language from day one over transitional naming.
+4. Build around Google Drive ownership first, not direct-upload-first assumptions.
+5. Deliver one vertical workflow before broad integrations.
+6. Remove legacy Hutopy product concepts early to reduce semantic drag.
+7. Keep changes reviewable and validate each phase before widening scope.
+
+## Keep, Replace, Remove
+
+### Keep
+
+- ASP.NET Core backend shell
+- FastEndpoints setup
+- modular registration pattern
+- Entity Framework Core with per-module context where useful
+- infrastructure wiring
+- authentication foundation if it can be adapted cleanly
+- payment infrastructure patterns and Stripe integration capability for future billing
+- blob or file-handling patterns that still apply
+- Vue, Vite, Pinia, router, and API client shell
+- deployment workflows if still useful for the new product
+
+### Replace
+
+- domain module set
+- route design
+- data model
+- frontend information architecture
+- user flows
+- branding and product language
+
+### Remove
+
+- creator domain concepts
+- creator public profile features
+- creator monetization flows
+- Hutopy naming across code and frontend copy
+- dead UI components and stores tied only to the old product
+
+### Retire And Rebuild
+
+- old tipping business flows
+- old membership business flows
+- creator-specific Stripe onboarding flows
+- payment routes and models that are tightly coupled to the dead Hutopy business model
+
+Keep the underlying payment capability, but rebuild the business-facing billing model around the new product when pricing and subscription design are ready.
+
+## Target Product Scope For Version 1
+
+Version 1 should own this workflow:
+
+1. Internal team creates a content item.
+2. Assets are linked from Google Drive.
+3. Publication message and metadata are attached.
+4. Internal reviewer or provider receives a request.
+5. Comments and revisions happen in one place.
+6. Client receives a review request.
+7. Client approves, rejects, or requests changes.
+8. Item becomes ready for publishing handoff.
+
+Not version 1:
+
+- full scheduling engine
+- full social publishing
+- advanced third-party synchronization
+- analytics suite
+- full digital asset management platform
+- full creative production tooling
+- customer billing and subscription management user flows
+
+## Target Backend Module Map
+
+Recommended backend modules:
+
+- `Identity`
+  - users, authentication, internal roles
+- `Workspaces`
+  - agencies or operating teams
+- `Clients`
+  - brands, creators, businesses served by a workspace
+- `Providers`
+  - external production partners
+- `Projects`
+  - grouped bodies of work for a client, which may later contain campaign concepts if needed
+- `ContentItems`
+  - reviewable units with metadata, copy, due dates, and status
+- `Assets`
+  - asset references, Google Drive linkage, versions, previews
+- `Approvals`
+  - review requests, approvers, decisions, status transitions
+- `Comments`
+  - threads, replies, resolution state, contextual discussion
+- `Notifications`
+  - workflow events, reminders, delivery preferences
+
+Possible later modules:
+
+- `Campaigns`
+- `Calendars`
+- `Integrations`
+- `Publishing`
+- `Analytics`
+- `Billing`
+
+## Target Frontend Surface
+
+Recommended frontend areas:
+
+- authentication
+- workspace switcher or workspace context
+- client list
+- project list
+- review queue dashboard
+- content item detail page
+- revision and comment timeline
+- approval status panel
+- notification center
+- external client review portal
+
+Later frontend areas:
+
+- calendar view
+- integration settings
+- publishing handoff dashboard
+- workflow analytics
+
+## Proposed Data Backbone
+
+### Content Item
+
+A content item should carry:
+
+- title
+- publication message
+- notes
+- project
+- client
+- creator or brand context where relevant
+- publication targets
+- publication dates by network when relevant
+- due date
+- current status
+- current active revision set
+
+### Asset
+
+An asset should carry:
+
+- asset type
+- source type
+- Google Drive file reference
+- preview metadata
+- current version
+- version history
+
+### Approval Request
+
+An approval request should carry:
+
+- target content item
+- requested reviewers
+- stage type
+- sent at
+- due at
+- decision state
+- decision history
+
+### Notification Event
+
+A notification event should carry:
+
+- event type
+- triggered by
+- target entity
+- recipients
+- delivery status
+- timestamps
+
+## Execution Strategy
+
+### Phase 0: Freeze Product Direction
+
+Deliverables:
+
+- validated worksheet in English
+- optional French mirror of the worksheet
+- agreed module map
+- agreed version 1 scope and anti-scope
+
+Exit criteria:
+
+- no ambiguity about the first workflow to build
+- no unresolved disagreement about Google Drive ownership
+
+### Phase 1: Remove Legacy Product Surface
+
+Goals:
+
+- reduce confusion from Hutopy concepts
+- make the codebase ready for the new domain
+
+Work:
+
+- remove or retire legacy frontend views tied to creators, tipping, and memberships
+- remove legacy backend modules that are clearly dead
+- rename product-facing strings, assets, and configuration references
+- identify infrastructure pieces that stay
+- preserve Stripe and payment infrastructure that can support future Software as a Service billing
+- identify backend modules that should be replaced instead of adapted
+
+Exit criteria:
+
+- codebase no longer communicates the old product direction
+- remaining code clearly supports reuse or is queued for replacement
+
+### Phase 2: Establish New Domain Skeleton
+
+Goals:
+
+- introduce the new product vocabulary into code
+- prepare clean module boundaries
+
+Work:
+
+- create new backend modules
+- define initial entities and contexts
+- wire modules in `Program.cs`
+- define route namespaces and tags
+- create frontend route skeleton for the new product
+- define new stores for auth, workspace context, review queue, and content items
+
+Exit criteria:
+
+- application compiles with the new module map in place
+- legacy domain is no longer the center of the app
+
+### Phase 3: Build The First Vertical Slice
+
+Vertical slice:
+
+- create content item
+- link Google Drive asset
+- add publication message and publication target data
+- request internal review
+- comment on item
+- request changes
+- upload or register a new revision
+- request client review
+- approve from client portal
+- mark ready to publish
+
+Backend work:
+
+- commands and queries for content item creation and retrieval
+- asset linkage and versioning
+- comment creation and retrieval
+- approval request and decision endpoints
+- status transition logic
+- workflow event emission
+
+Frontend work:
+
+- content item creation flow
+- content item detail view
+- comments panel
+- approval action UI
+- status timeline
+- simple client review page
+
+Exit criteria:
+
+- one item can move end-to-end from draft to approved
+- all actions are traceable in one place
+
+### Phase 4: Add Notification Backbone
+
+Goals:
+
+- make workflow movement visible without manual follow-up
+
+Work:
+
+- define notification event types
+- trigger events on comments, revisions, requests, and decisions
+- add email notifications
+- add in-app notification center or lightweight feed
+- add reminder jobs for pending reviews
+
+Exit criteria:
+
+- users are informed when workflow events occur
+- delayed approvals can be followed without manual chasing
+
+### Phase 5: Harden Version 1 For Real Usage
+
+Goals:
+
+- make the workflow usable for the first real client
+
+Work:
+
+- permissions and role hardening
+- validation and error handling
+- audit trail review
+- filtering and dashboard improvements
+- comment resolution
+- required approver logic if needed
+- publication dates by network support
+- quality pass on mobile review experience
+
+Exit criteria:
+
+- the first client can run a real approval cycle in the product
+
+### Phase 6: Evaluate Phase 2 Expansion
+
+Candidates:
+
+- calendar visibility
+- Google Drive sync improvements
+- Canva linkage
+- MailChimp approval path
+- scheduler handoff integrations
+- billing and subscription management for the Software as a Service offer
+
+Rule:
+
+Only start these after version 1 workflow is demonstrably useful.
+
+## Immediate Technical Tasks
+
+Recommended next implementation tasks:
+
+1. Rename the product and remove visible Hutopy branding.
+2. Inventory which backend modules are deleted versus replaced.
+3. Define the new backend module directories and initial project structure.
+4. Replace the frontend router with the new application surface.
+5. Model `ContentItem`, `Asset`, `AssetVersion`, `ApprovalRequest`, `ApprovalDecision`, `CommentThread`, and `NotificationEvent`.
+6. Implement the first vertical slice end to end.
+
+## Risks
+
+- scope creep into scheduling and publishing too early
+- forcing the new domain into old creator-centric structures
+- under-designing workflow status and revision semantics
+- overbuilding integrations before the core workflow is proven
+- making external review too heavy for clients
+
+## Validation Checklist
+
+Before claiming version 1 readiness:
+
+- a workspace can manage at least one client
+- a content item can include publication message and publication targets
+- assets can be linked from Google Drive
+- internal review can request changes
+- client review can approve or reject
+- status history is visible
+- notification events are triggered
+- the latest approved state is clear
+
+## Working Note
+
+This plan should be updated as soon as the first implementation decisions are made, especially:
+
+- exact module names
+- exact database boundaries
+- whether `Providers` stands alone or is modeled as a participant role
+- whether notifications are their own module or an infrastructure concern

SOCIALIZE.fr.md

@@ -0,0 +1,328 @@
+# Flux d'approbation pour les contenus de medias sociaux
+
+Nom temporaire du produit : `Socialize`
+
+## Intention du projet
+
+Construire `Socialize`, une application qui remplace le processus actuel d'approbation base sur Google Drive, les appels telephoniques, les courriels et les feuilles de calcul.
+
+Le produit n'est pas un reseau social public. C'est un outil de flux de travail interne/externe pour la revision de contenu, la collecte de commentaires, l'approbation et la preparation a la publication.
+
+## Vocabulaire partage
+
+- Flux d'approbation : le processus complet entre la creation d'un brouillon et l'approbation finale.
+- Element de contenu : l'unite a reviser qui regroupe les fichiers, le message de publication ou le texte, les dates et les canaux cibles.
+- Ressource : un fichier rattache a un element de contenu, par exemple une video, une image ou un document.
+- Revision : une nouvelle version d'une ressource ou d'un texte apres commentaires.
+- Reviseur externe : un client ou un partenaire qui revise du contenu sans faire partie de l'equipe interne.
+- Fournisseur : un partenaire de production externe, par exemple une equipe video, un photographe, un monteur ou un designer, qui peut livrer des brouillons et recevoir des demandes de modifications.
+- Software as a Service (SaaS) / logiciel en tant que service : un produit en ligne utilise via le web, comme Canva, MailChimp, HootSuite ou Metricool.
+- Minimum Viable Product (MVP) / produit minimum viable : la plus petite version du produit qui regle suffisamment bien le probleme principal pour valider le marche.
+- Service Level Agreement (SLA) / accord de niveau de service : une cible de service convenue, par exemple une date limite de revision ou un seuil d'escalade.
+
+## Enonce du probleme
+
+Les gestionnaires de medias sociaux et les equipes de production gerent actuellement les approbations de contenu de facon manuelle :
+
+- Les ressources sont stockees dans Google Drive.
+- Le gestionnaire de medias sociaux fait souvent des allers-retours autant avec les fournisseurs qu'avec les clients.
+- Les commentaires circulent par telephone, courriel, message et feuille de calcul.
+- L'historique des versions est flou.
+- Il est difficile de savoir quel fichier est le plus recent.
+- Les commentaires sont disperses sur plusieurs canaux.
+- Les approbations internes et celles des clients suivent des logiques semblables mais ne sont pas centralisees.
+- Les suivis sont manuels, ce qui retarde les approbations.
+
+Resultat : trop d'allers-retours, peu de tracabilite, des delais evitables et un risque de publier le mauvais fichier ou une version de texte perimee.
+
+## Outils observes actuellement
+
+- Google Drive pour les videos, images, calendriers et documents
+- Google Sheets ou equivalent pour suivre les commentaires et les statuts
+- Telephone et courriel pour les conversations de revision et d'approbation
+- HootSuite
+- Metricool
+- Canva
+- MailChimp
+
+## Utilisateurs principaux
+
+- Gestionnaire de medias sociaux
+- Gestionnaire de compte / service client
+- Approbateur cote client
+- Fournisseur externe / partenaire de production
+- Producteur interne
+- Employe interne / contributeur au contenu
+- Administrateur
+
+## Cas d'utilisation principaux
+
+### 1. Flux d'approbation client
+
+Un gestionnaire de medias sociaux prepare du contenu pour un client et le soumet pour approbation.
+
+Le client doit pouvoir :
+
+- consulter le lot de contenu
+- previsualiser les fichiers
+- lire les legendes, descriptions et notes de projet
+- laisser des commentaires
+- demander des modifications
+- approuver ou rejeter
+
+L'equipe doit pouvoir :
+
+- voir le statut d'approbation en temps reel
+- repondre aux commentaires dans leur contexte
+- televerser des versions revisees
+- conserver une piste d'audit claire indiquant qui a dit quoi et quand
+- savoir exactement quelle version est approuvee
+
+### 2. Flux de production interne
+
+Le meme flux doit fonctionner a l'interne pour les producteurs, employes et partenaires de production externes avant que le contenu soit montre au client ou planifie pour publication.
+
+Exemple :
+
+- un contributeur televerse un brouillon
+- un fournisseur externe peut televerser un brouillon ou une version revisee
+- un producteur revise et demande des modifications
+- un gestionnaire approuve pour la revision client
+- le client approuve
+- le contenu est marque pret pour la publication
+
+### 3. Revision d'un lot de contenu
+
+L'approbation ne doit pas se limiter a un seul fichier. Un element a reviser peut inclure :
+
+- video
+- image
+- document
+- message de publication / legende / texte
+- mots-clics
+- liens
+- dates de publication
+- canaux cibles ou reseaux sociaux
+
+## Resume du flux actuel
+
+Flux actuel typique :
+
+1. L'equipe cree les ressources media.
+2. Les fichiers sont places dans Google Drive par l'equipe ou par des fournisseurs externes.
+3. Un gestionnaire envoie les liens par courriel ou message aux fournisseurs, aux intervenants internes ou aux clients.
+4. Les commentaires reviennent par telephone, courriel, feuille de calcul ou clavardage.
+5. L'equipe consolide manuellement les commentaires provenant des fournisseurs et des clients.
+6. Une version revisee est televersee.
+7. Le cycle se repete jusqu'a ce que quelqu'un dise que c'est approuve.
+8. Le statut d'approbation est suivi manuellement ailleurs.
+
+Principaux points d'echec :
+
+- aucune source de verite unique
+- aucun etat d'approbation structure
+- aucun fil de commentaires centralise
+- aucun rappel d'echeance
+- aucune piste d'audit fiable
+- aucune barriere d'approbation avant publication
+
+## Flux cible
+
+1. Creer un projet et l'associer a un client.
+2. Creer un element de revision ou une demande d'approbation.
+3. Joindre des ressources ou les importer depuis Google Drive.
+4. Ajouter des metadonnees :
+   - titre
+   - message de publication / legende / texte
+   - plateforme cible ou reseau social
+   - dates de publication par reseau lorsque pertinent
+   - date d'echeance
+   - reviseur(s)
+5. Envoyer la demande de revision.
+6. Les reviseurs commentent directement sur l'element.
+7. L'equipe ou le fournisseur televerse une revision ou repond aux commentaires.
+8. Le systeme suit les versions, les changements de statut et les evenements du flux.
+9. Le reviseur approuve, rejette ou demande des modifications.
+10. Une fois toutes les approbations requises obtenues, l'element devient pret pour la planification ou la publication.
+
+## Objets de domaine principaux
+
+- Espace de travail : la frontiere principale du compte pour une agence ou une equipe operationnelle.
+- Client : l'entreprise, le createur ou la marque qui recoit le service et approuve le contenu.
+- Membre d'equipe : un utilisateur interne qui travaille sur le contenu, les revisions ou la coordination.
+- Reviseur : toute personne a qui l'on demande de reviser et d'approuver, qu'elle soit interne ou externe.
+- Fournisseur : un contributeur de production externe, comme un photographe, videaste, monteur ou designer.
+- Projet : le principal conteneur de travail pour un client, qui regroupe des elements de contenu, des notes, des participants et des echeances.
+- Element de contenu : l'unite a reviser qui contient les ressources, le message de publication, les canaux cibles, les dates d'echeance et l'etat d'approbation.
+- Ressource : un fichier joint, comme une video, une image ou un document, reference depuis Google Drive ou stocke directement.
+- Version de ressource : une revision precise d'une ressource, avec tracabilite de la personne qui l'a televersee et du moment.
+- Fil de commentaires : une discussion contextuelle rattachee a un element de contenu, une ressource ou une revision.
+- Demande d'approbation : l'action de demander a un ou plusieurs reviseurs de reviser une version precise.
+- Decision d'approbation : le resultat d'une demande de revision, par exemple approuve, rejete ou modifications demandees.
+- Historique des statuts : la piste d'audit des etats et transitions du flux dans le temps.
+- Cible de publication : la destination prevue pour la publication, par exemple Instagram, Facebook, LinkedIn ou une infolettre.
+- Evenement de notification : un evenement du flux qui informe les utilisateurs qu'un commentaire, une revision, une demande ou une approbation vient d'avoir lieu.
+
+## Modele de statuts suggere
+
+- Brouillon
+- En revision interne
+- Modifications demandees a l'interne
+- Modifications internes en cours
+- Pret pour revision client
+- En revision client
+- Modifications demandees par le client
+- Modifications client en cours
+- Approuve
+- Rejete
+- Pret a publier
+- Publie
+- Archive
+
+## Portee du Minimum Viable Product (MVP) / produit minimum viable
+
+La premiere version doit se concentrer sur le flux d'approbation, et non sur la publication directe.
+
+### Fonctionnalites MVP
+
+- authentification et roles utilisateurs
+- structure espace de travail / client / projet
+- creation d'un element de contenu avec metadonnees
+- televersement de ressources ou ajout de liens Google Drive tout en gardant Google Drive comme source de verite lorsque le client l'exige
+- suivi des versions pour les fichiers et les textes
+- commentaires centralises
+- decisions d'approbation : approuver, rejeter, demander des modifications
+- chronologie d'activite / piste d'audit
+- tableau de bord par client, projet et date d'echeance
+- notifications et rappels lorsque des actions sont completees ou que des evenements du flux surviennent
+- portail simple d'approbation pour les clients externes
+
+### Fonctionnalites candidates fortes pour le MVP
+
+- approbateurs obligatoires
+- date limite d'approbation
+- dates d'echeance par cible de publication ou reseau social
+- comparaison entre version courante et version precedente
+- indicateur de la "derniere version approuvee"
+- resolution des commentaires
+- filtres par statut, client, responsable et date d'echeance
+
+## Possibilites pour la phase 2
+
+- integration Google Drive avec synchronisation ou import de fichiers
+- export ou transfert vers HootSuite / Metricool
+- liaison avec les ressources Canva
+- flux d'approbation MailChimp pour les infolettres
+- integration calendrier pour la visibilite sur la planification des publications
+- commentaires annotes sur images ou sur horodatages video
+- modeles de flux d'approbation reutilisables par type de contenu
+- rappels et escalades bases sur les Service Level Agreements (SLA) / accords de niveau de service
+- analyses sur les temps de traitement et les goulots d'etranglement
+- approbation par lien recu par courriel
+- regles d'approbation a plusieurs etapes selon le client
+
+## Possibilites d'automatisation importantes
+
+- demander automatiquement une approbation lorsqu'un element atteint une etape definie
+- envoyer automatiquement des notifications lorsqu'une action est completee ou qu'un evenement du flux survient
+- envoyer automatiquement des rappels avant les echeances
+- escalader automatiquement lorsqu'une approbation est en retard
+- etiqueter automatiquement les versions
+- passer automatiquement a l'etat "pret a publier" lorsque toutes les approbations sont completees
+- conserver automatiquement une piste d'audit de chaque televersement, commentaire et decision
+- generer automatiquement un lien de revision cote client
+- notifier automatiquement lorsqu'une nouvelle revision repond aux modifications demandees
+
+## Decisions produit importantes
+
+### 1. Systeme de reference pour les ressources
+
+Options :
+
+- garder Google Drive comme stockage de fichiers et construire le flux autour
+- televerser les fichiers directement dans la nouvelle application
+- supporter les deux
+
+Premiere hypothese recommandee :
+
+Garder Google Drive comme source de verite lorsque le client exige d'en conserver la propriete, et supporter plus tard les televersements directs comme option. La premiere version doit fonctionner proprement avec les liens Drive et les metadonnees importees avant d'envisager une synchronisation plus poussee.
+
+### 2. Experience du reviseur externe
+
+Options :
+
+- compte reviseur obligatoire
+- acces par lien magique sans compte complet
+- les deux
+
+Premiere hypothese recommandee :
+
+Utiliser l'acces par lien magique pour les clients afin de reduire la friction.
+
+### 3. Granularite de l'approbation
+
+Unites d'approbation possibles :
+
+- element de contenu complet
+- par ressource
+- par legende / texte
+- par variation de canal
+
+Premiere hypothese recommandee :
+
+Approuver au niveau de l'element de contenu dans le Minimum Viable Product (MVP), avec des commentaires rattaches aux ressources et au texte.
+
+## Regles d'affaires a confirmer
+
+Ces points ne bloquent pas le cadrage initial, mais il faut les documenter tot pour que le comportement du produit corresponde bien au vrai processus d'approbation.
+
+- Un client peut-il approuver s'il reste des commentaires non resolus ?
+- L'approbation exige-t-elle un seul reviseur ou plusieurs reviseurs ?
+- L'approbation interne et l'approbation client peuvent-elles se faire en parallele ?
+- L'approbation est-elle valide seulement pour la version la plus recente ?
+- Un element approuve peut-il etre modifie sans rouvrir la revision ?
+- Des clients differents ont-ils besoin de flux differents ?
+- Les videos, images et documents sont-ils tous aussi importants des le jour 1 ?
+- La planification ou publication fait-elle partie de la portee, ou seulement le passage a l'etat "pret a publier" ?
+
+## Questions ouvertes pour la prochaine entrevue
+
+- Qui est l'acheteur : agence, travailleur autonome ou equipe marketing interne ?
+- Le premier marche cible est-il l'approbation agence-client, l'approbation interne ou les deux ?
+- Quels types de contenu sont prioritaires : video, image, documents, legende, infolettres ?
+- A quelle frequence les clients demandent-ils des modifications apres une approbation verbale ?
+- Quelle est aujourd'hui l'etape la plus douloureuse ?
+- Quels outils doivent absolument rester en place au lancement ?
+- Quelles approbations exigent une tracabilite legale ou de conformite ?
+- Combien de reviseurs participent habituellement a chaque element ?
+- Le bilinguisme est-il requis ?
+- La revision mobile est-elle importante au jour 1 ?
+
+## Criteres de succes du Minimum Viable Product (MVP) / produit minimum viable
+
+- reduire le temps necessaire pour obtenir une approbation
+- reduire les allers-retours entre courriels, telephone et feuilles de calcul
+- fournir une source de verite claire pour la derniere version et le statut courant
+- permettre a un client d'approuver sans formation
+- permettre a l'equipe de voir instantanement les elements bloques
+
+## Positionnement du produit
+
+Ce produit devrait etre positionne comme suit :
+
+"Un flux de revision et d'approbation pour le contenu de medias sociaux, et non un autre outil de creation de contenu."
+
+La valeur se trouve dans la coordination, la tracabilite et l'acceleration des cycles d'approbation.
+
+## Recommandation pour la premiere version
+
+Construire la premiere version autour de ce flux etroit :
+
+1. l'equipe cree un element de contenu
+2. l'equipe televerse les fichiers et le texte
+3. un reviseur interne commente et demande des modifications
+4. l'equipe soumet l'element au client
+5. le client commente et approuve via un lien simple
+6. l'element devient pret pour le transfert vers la publication
+
+Si ce flux fonctionne proprement, les integrations et la planification pourront etre ajoutees ensuite.

SOCIALIZE.md

@@ -0,0 +1,328 @@
+# Social Media Approval Workflow
+
+Temporary product name: `Socialize`
+
+## Project Intent
+
+Build `Socialize`, an application that replaces the current approval process based on Google Drive, phone calls, emails, and spreadsheets.
+
+The product is not a public social network. It is an internal/external workflow tool for content review, feedback, approval, and publication readiness.
+
+## Shared Vocabulary
+
+- Approval workflow: the end-to-end process from draft creation to final approval.
+- Content item: the reviewable unit that bundles assets, publication message or copy, dates, and channel targets.
+- Asset: a file attached to a content item, such as a video, image, or document.
+- Revision: a new version of an asset or copy after feedback.
+- External reviewer: a client or partner who reviews content without being part of the internal team.
+- Provider: an external production partner, such as a film crew, photographer, editor, or designer, who may deliver drafts and receive change requests.
+- Software as a Service (SaaS): a cloud-based product used through the web, such as Canva, MailChimp, HootSuite, or Metricool.
+- Minimum Viable Product (MVP): the smallest product version that solves the main pain point well enough to validate the market.
+- Service Level Agreement (SLA): an agreed service target, such as a review deadline or escalation threshold.
+
+## Problem Statement
+
+Social media managers and production teams currently manage content approvals manually:
+
+- Assets are stored in Google Drive.
+- The social media manager may have back-and-forth with both upstream providers and downstream clients.
+- Feedback is exchanged by phone, email, messages, and spreadsheets.
+- Version history is unclear.
+- It is hard to know which file is the latest one.
+- Comments are scattered across multiple channels.
+- Internal approvals and client approvals follow similar patterns but are not centralized.
+- Follow-ups are manual, so approvals get delayed.
+
+Result: too much back-and-forth, poor traceability, avoidable delays, and risk of publishing the wrong asset or outdated copy.
+
+## Existing Tools Observed
+
+- Google Drive for videos, images, calendars, and documents
+- Google Sheets or similar for tracking comments and status
+- Phone and email for review/approval conversations
+- HootSuite
+- Metricool
+- Canva
+- MailChimp
+
+## Primary Users
+
+- Social media manager
+- Account manager / customer success
+- Client approver
+- External provider / production partner
+- Internal producer
+- Internal employee / content contributor
+- Administrator
+
+## Core Use Cases
+
+### 1. Client Approval Workflow
+
+A social media manager prepares content for a client and sends it for approval.
+
+The client should be able to:
+
+- view the content package
+- preview files
+- read captions, descriptions, and project notes
+- leave comments
+- request changes
+- approve or reject
+
+The team should be able to:
+
+- see approval status in real time
+- answer comments in context
+- upload revised versions
+- keep a clear audit trail of who said what and when
+- know exactly which version is approved
+
+### 2. Internal Production Workflow
+
+The same workflow should work internally for producers, employees, and external production partners before the content is shown to the client or scheduled for publishing.
+
+Example:
+
+- contributor uploads draft
+- external provider can upload draft or revised media
+- producer reviews and requests changes
+- manager approves for client review
+- client approves
+- content is marked ready to publish
+
+### 3. Content Package Review
+
+Approval should not be limited to a single file. A review item may include:
+
+- video
+- image
+- document
+- publication message / caption / copy
+- hashtags
+- links
+- publication dates
+- target channels or social networks
+
+## Current Workflow Summary
+
+Typical current flow:
+
+1. Team creates media assets.
+2. Files are placed in Google Drive by the team or by external providers.
+3. A manager sends links by email or message to providers, internal stakeholders, or clients.
+4. Feedback comes back by phone, email, spreadsheet, or chat.
+5. Team manually consolidates comments across provider feedback and client feedback.
+6. A revised version is uploaded.
+7. The cycle repeats until someone says it is approved.
+8. Approval status is manually tracked elsewhere.
+
+Main failure points:
+
+- no single source of truth
+- no structured approval states
+- no centralized threaded comments
+- no deadline reminders
+- no reliable audit trail
+- no approval gate before publishing
+
+## Target Workflow
+
+1. Create a project and associate it with a client.
+2. Create a review item or approval request.
+3. Attach assets or import them from Google Drive.
+4. Add metadata:
+   - title
+   - publication message / caption / copy
+   - target platform or social network
+   - publication dates by network when relevant
+   - due date
+   - reviewer(s)
+5. Send review request.
+6. Reviewers comment directly on the item.
+7. Team or provider uploads a revision or responds to comments.
+8. System tracks versions, status changes, and workflow events.
+9. Reviewer approves, rejects, or requests changes.
+10. Once all required approvals are complete, item becomes ready for scheduling/publishing.
+
+## Core Domain Objects
+
+- Workspace: the top-level account boundary for one agency or one operating team.
+- Client: the business, creator, or brand receiving the service and approving content.
+- Team member: an internal user working on content, reviews, or coordination.
+- Reviewer: any person asked to review and approve, whether internal or external.
+- Provider: an external production contributor such as a photographer, videographer, editor, or designer.
+- Project: the main work container for a client, grouping related content items, notes, participants, and timelines.
+- Content item: the reviewable unit that contains assets, publication message, channel targets, due dates, and approval state.
+- Asset: an attached file, such as a video, image, or document, referenced from Google Drive or stored directly.
+- Asset version: a specific revision of an asset, with traceability to who uploaded it and when.
+- Comment thread: a contextual discussion attached to a content item, asset, or revision.
+- Approval request: the act of asking one or more reviewers to review a specific version.
+- Approval decision: the outcome of a review request, such as approved, rejected, or changes requested.
+- Status history: the audit trail of workflow states and transitions over time.
+- Publication target: the intended destination for publication, such as Instagram, Facebook, LinkedIn, or a newsletter.
+- Notification event: a workflow event that informs users something changed, such as a new comment, revision, request, or approval.
+
+## Suggested Status Model
+
+- Draft
+- In internal review
+- Changes requested internally
+- Internal changes in progress
+- Ready for client review
+- In client review
+- Changes requested by client
+- Client changes in progress
+- Approved
+- Rejected
+- Ready to publish
+- Published
+- Archived
+
+## Minimum Viable Product (MVP) Scope
+
+The first version should focus on approval workflow, not direct publishing.
+
+### MVP Features
+
+- authentication and user roles
+- workspace/client/project structure
+- create a content item with metadata
+- upload assets or attach Google Drive links while keeping Google Drive as the source of truth when required by the client
+- version tracking for files and copy
+- centralized comments
+- approval decisions: approve, reject, request changes
+- activity timeline / audit trail
+- status dashboard by client, project, and due date
+- notifications and reminders when actions are completed or workflow events occur
+- simple approval portal for external clients
+
+### Strong MVP Candidate Features
+
+- required approvers
+- approval deadline
+- due dates per publication target or social network
+- compare current version vs previous version
+- "latest approved version" indicator
+- comment resolution
+- filtering by status, client, assignee, due date
+
+## Phase 2 Opportunities
+
+- Google Drive integration with file sync/import
+- HootSuite / Metricool export or handoff
+- Canva asset linking
+- MailChimp approval workflow for newsletters
+- calendar integration for publication planning visibility
+- annotated comments on images or video timestamps
+- reusable approval templates by content type
+- Service Level Agreement (SLA) reminders and escalations
+- analytics on turnaround time and bottlenecks
+- approval by email link
+- multi-stage approval rules per client
+
+## Key Automation Opportunities
+
+- auto-request approval when a content item reaches a defined stage
+- automatic notifications when a workflow action is completed or a workflow event occurs
+- automatic reminders before approval deadlines
+- automatic escalation when approval is overdue
+- automatic version labeling
+- automatic "ready to publish" state when all approvals are complete
+- automatic audit trail for every upload, comment, and decision
+- automatic client-facing review link generation
+- automatic notification when a new revision addresses requested changes
+
+## Important Product Decisions
+
+### 1. System of record for assets
+
+Options:
+
+- keep Google Drive as file storage and build workflow around it
+- upload files directly into this new application
+- support both
+
+Recommended first assumption:
+
+Keep Google Drive as the source of truth when the client requires ownership there, and support direct uploads later as an option. The first version should work cleanly with Drive links and imported metadata before deeper synchronization is considered.
+
+### 2. External reviewer experience
+
+Options:
+
+- reviewer account required
+- magic-link access without full account
+- both
+
+Recommended first assumption:
+
+Use magic-link review access for clients to reduce friction.
+
+### 3. Approval granularity
+
+Possible approval units:
+
+- entire content item
+- per asset
+- per caption/copy
+- per channel variation
+
+Recommended first assumption:
+
+Approve at the content item level in the Minimum Viable Product (MVP), with comments attached to assets and copy.
+
+## Business Rules To Confirm
+
+These do not block initial scoping, but we should capture them early so the product behavior matches the real approval process.
+
+- Can a client approve with unresolved comments?
+- Does approval require one reviewer or multiple reviewers?
+- Can internal approval and client approval happen in parallel?
+- Is approval valid only for the latest version?
+- Can an approved item be edited without reopening review?
+- Do different clients require different workflows?
+- Are videos, images, and documents all equally important on day one?
+- Is scheduling/publishing inside scope, or only "approval-ready" handoff?
+
+## Open Questions For Next Interview
+
+- Who is the buyer: agency, freelancer, or in-house marketing team?
+- Is the first target market agency-to-client approval, internal team approval, or both?
+- What content types are highest priority: video, image, documents, captions, newsletters?
+- How often do clients request changes after verbal approval?
+- What is the most painful step today?
+- What tools must remain in place at launch?
+- What approvals need legal or compliance traceability?
+- How many reviewers usually participate per item?
+- Is bilingual support required?
+- Is mobile review important on day one?
+
+## Minimum Viable Product (MVP) Success Criteria
+
+- reduce approval turnaround time
+- reduce back-and-forth across email/phone/spreadsheets
+- give one clear source of truth for latest version and current status
+- let a client approve without training
+- let the team see blocked items instantly
+
+## Product Positioning
+
+This product should be positioned as:
+
+"A review and approval workflow for social media content, not another content creation tool."
+
+The value is coordination, traceability, and faster approval cycles.
+
+## First Build Recommendation
+
+Build the first release around this narrow flow:
+
+1. team creates content item
+2. team uploads files and copy
+3. internal reviewer comments and requests changes
+4. team submits to client
+5. client comments and approves via simple link
+6. item becomes ready for publishing handoff
+
+If this flow works cleanly, integrations and scheduling can be added later.