## 2026-05-04 14:34:37 — Back office MVP structure en place **Objectif** Acter l’état du back office RenoValid MVP dans le workspace. **Actions** - Création du dossier reno-app/backoffice - Création des fichiers Python FastAPI - Création des routes référentiels, codes postaux, projets et statistiques - Création des CSV d’exemple - Adaptation du projet pour Python 3.7 et retrait de pandas **Résultat** Structure MVP du back office en place. Les dépendances restent à installer côté serveur pour rendre l’API exécutable, mais l’état de travail est considéré comme OK pour poursuivre la conception fonctionnelle. **Prochaines étapes** - Préparer la première interface admin simple - Définir les écrans back office prioritaires - Ajouter authentification admin et journal d’audit --- ## 2026-05-05 — Nettoyage du périmètre mobile-lite Le dossier projet a été nettoyé de façon réversible. Périmètre actif conservé : - `reno-app/mobile-lite/` : application mobile MVP active - `reno-app/backoffice/` : back office MVP Éléments sortis du périmètre actif et déplacés dans l’archive : - `reno-app/mobile/` - `reno-app/data/` - `reno-app/assets/` - `reno-app/tools/` - `reno-app/index.html` - `reno-app/script.js` - `reno-app/style.css` Archive créée : - `reno-app/_archive_unused/2026-05-05/` Raison : ces éléments concernent l’ancienne app web, une app mobile secondaire ou des outils ponctuels. Ils ne sont pas nécessaires au MVP mobile-lite actuel. Aucune suppression définitive n’a été faite. ## 2026-05-05 — Visualisation et raccord mobile-lite Corrections effectuées : - La documentation `VISUALISER.md` ne pointe plus vers l’ancienne app web. - L’écran admin `backoffice/admin/index.html` ne renvoie plus vers `index.html` archivé. - Ajout d’un fichier de contrôle mobile : `mobile-lite/src/data/backoffice-control.js`. - Raccord initial de `mobile-lite/src/data/pricing-catalog.js` au contrôle back office. - Raccord initial de `mobile-lite/src/data/region-profiles.js` au contrôle back office. État du pilotage : partiel mais réel. Le back office peut maintenant influencer le catalogue de prix et les multiplicateurs régionaux via `backoffice-control.js`. Le moteur complet `project-estimate.js` contient encore des prix en dur à externaliser ensuite. ## 2026-05-05 — Externalisation du moteur d’estimation mobile-lite Objectif : rendre le moteur de calcul `mobile-lite` pilotable par le back office. Fichiers créés / modifiés : - Créé : `mobile-lite/src/data/estimate-rates.js` - Modifié : `mobile-lite/src/data/backoffice-control.js` - Modifié : `mobile-lite/src/utils/project-estimate.js` - Créé : `backoffice/MOBILE_PILOTAGE.md` Résultat : - Les multiplicateurs d’état et de finition sont externalisés. - Les frais par défaut sont externalisés. - Les postes curage, toiture, façade, chauffage, équipements, division, second œuvre, finitions, extension, création/suppression de pièces et aléas utilisent maintenant `ESTIMATE_RATES`. - Le fichier `backoffice-control.js` expose `estimateRateOverrides`, qui permettra au back office de surcharger les taux publiés. État : le pilotage du calcul mobile-lite est maintenant fonctionnel au niveau référentiel code. Il reste à construire l’écran admin éditable pour modifier ces valeurs sans toucher au code. ## 2026-05-05 — Écran Tarifs & Barèmes détaillé Objectif : ne plus limiter l’interface back office au multiplicateur global. Fichiers modifiés : - `backoffice/admin/index.html` - `backoffice/admin/style.css` - `backoffice/admin/rates.js` Résultat : L’écran admin affiche désormais les principaux paramètres pilotables du moteur mobile-lite : - multiplicateurs état / finition - préparation et démolition - toiture et façade - équipements et réseaux - second œuvre et finitions - extension et pièces créées - frais et aléas L’interface génère un bloc JSON d’overrides destiné à `mobile-lite/src/data/backoffice-control.js`. État : édition visuelle disponible côté back office MVP. La sauvegarde automatique directe dans le fichier ou via API reste à ajouter. ## 2026-05-05 — Publication vers mobile-lite Objectif : permettre à l’écran back office de publier les overrides vers l’app mobile MVP. Fichiers créés / modifiés : - Créé : `backoffice/admin/publish-control.php` - Créé : `backoffice/admin/publish.js` - Modifié : `backoffice/admin/index.html` - Modifié : `backoffice/admin/style.css` Résultat : L’écran admin contient maintenant un bouton `Publier vers mobile-lite`. Ce bouton envoie le JSON généré à `publish-control.php`, qui écrit dans : - `mobile-lite/src/data/backoffice-control.js` Le script crée aussi une sauvegarde préalable dans : - `backoffice/data/publication-backups/` État : publication MVP disponible côté interface. À tester depuis le navigateur, car le POST dépend de l’accès HTTP réel au fichier PHP. ## 2026-05-05 — Publication back office confirmée La publication depuis l’interface admin vers `mobile-lite` fonctionne. Version publiée confirmée : - `mobile-lite-mvp-20260505-110349` Fichier publié vérifié : - `reno-app/mobile-lite/src/data/backoffice-control.js` Le fichier contient bien les overrides générés depuis l’écran `Tarifs & Barèmes`, notamment les paramètres du moteur d’estimation dans `estimateRateOverrides`. État : le bouton `Publier vers mobile-lite` est opérationnel. ## 2026-05-05 — Page Codes postaux / communes Objectif : ajouter une page back office pour piloter le référentiel de communes consommé par `mobile-lite`. Fichiers créés / modifiés : - Créé : `backoffice/admin/postal-codes.html` - Créé : `backoffice/admin/postal-codes.js` - Créé : `backoffice/admin/publish-postal-codes.php` - Modifié : `backoffice/admin/index.html` - Modifié : `backoffice/admin/style.css` - Modifié : `mobile-lite/src/data/postal-codes.js` Résultat : Le référentiel mobile `postal-codes.js` fusionne maintenant les codes postaux de base avec les overrides publiés dans `backoffice-control.js`. L’interface admin permet de saisir un CSV simple `postal_code,commune`, de prévisualiser les overrides et de publier vers `mobile-lite`. État : page Codes postaux / communes disponible et raccordée au mécanisme de publication MVP. ## 2026-05-05 09:14:04 — Recherche source base codes postaux communes **Objectif** Identifier les sources fiables pour alimenter une base complète codes postaux / communes dans le back office RenoValid. **Actions** - Recommander les sources publiques officielles françaises - Préparer les options d’intégration future dans la page Codes postaux / communes **Résultat** À documenter côté réponse utilisateur : privilégier data.gouv.fr / Base officielle des codes postaux La Poste, COG INSEE, BAN pour adresses plus fines. **Prochaines étapes** - Ajouter un import CSV complet dans le back office - Prévoir mapping postal_code, commune, insee_code, department_code, region --- ## 2026-05-05 09:21:47 — Clarification format codes postaux **Objectif** Acter la règle de formatage des codes postaux français dans le back office et mobile-lite. **Actions** - Confirmer que les codes postaux doivent être conservés sur 5 caractères - Rappeler que les codes commençant par 0 doivent rester en texte et non en nombre **Résultat** Règle retenue : toujours stocker et publier les codes postaux comme chaînes de 5 caractères, par exemple 01140 et 02380. **Prochaines étapes** - Vérifier que les imports CSV conservent les zéros initiaux - Ajouter une normalisation padStart(5, '0') dans les écrans/imports si nécessaire --- ## 2026-05-05 09:38:26 — Base codes postaux complétée **Objectif** Acter la validation de la publication du référentiel codes postaux / communes vers mobile-lite. **Actions** - Validation utilisateur de la publication codes postaux - Confirmation que la base de données codes postaux / communes a été complétée - Rappel de la règle de stockage des codes postaux sur 5 caractères **Résultat** La page back office Codes postaux / communes est opérationnelle et la base a été complétée côté utilisateur. La publication vers mobile-lite fonctionne. **Prochaines étapes** - Créer la page back office de suivi des simulations et projets enregistrés - Prévoir ensuite statistiques de saisie terrain --- ## 2026-05-05 09:41:43 — Page projets simulations créée **Objectif** Ajouter au back office une page de suivi des simulations, brouillons et projets enregistrés par mobile-lite. **Actions** - Lecture du stockage mobile-lite dans src/storage/projects.js - Création de backoffice/admin/projects.html - Création de backoffice/admin/projects.js - Ajout du lien depuis l’accueil admin - Ajout des styles KPI et tableau **Résultat** La page Projets / simulations est disponible. Elle lit localStorage avec la clé renovalid.projects.v1 quand accessible et accepte aussi un import JSON manuel. **Prochaines étapes** - Tester depuis le navigateur avec des projets sauvegardés dans mobile-lite - Prévoir une synchronisation API native pour les projets mobile si nécessaire - Créer ensuite la page Statistiques terrain --- ## 2026-05-05 09:45:50 — Clarification domaine back office mobile-lite **Objectif** Expliquer pourquoi le back office et mobile-lite peuvent ou non partager le même stockage navigateur. **Actions** - Clarifier la différence entre fichiers sur le même serveur et origine navigateur - Identifier les cas où localStorage est partagé - Identifier les cas où l’app native Expo ne partage pas le localStorage du back office **Résultat** Le back office et mobile-lite partagent localStorage uniquement s’ils sont ouverts dans le même navigateur avec exactement la même origine protocole + domaine + port. Une app mobile native Expo ne partagera pas ce localStorage avec une page back office web. **Prochaines étapes** - Prévoir une synchronisation API des projets mobile-lite vers le back office - Conserver l’import JSON comme solution MVP temporaire --- ## 2026-05-05 10:04:14 — Base multi-utilisateurs et synchronisation projets **Objectif** Préparer le back office RenoValid à centraliser les données de plusieurs utilisateurs mobile-lite. **Actions** - Ajout des modèles UserAccount, ApiSession et PasswordResetToken - Ajout de user_id et device_id sur les projets sauvegardés - Création des routes /auth pour inscription, connexion, profil, mot de passe oublié et reset mot de passe - Création de /sync/projects pour synchroniser les projets mobile-lite vers la base centrale - Ajout des services mobile-lite backoffice-api.js et project-sync.js - Branchement de la synchronisation après saveProjectSnapshot - Ajout de la documentation MULTI_USER_SYNC.md **Résultat** La structure multi-utilisateurs et synchronisation est en place côté code. Les projets peuvent désormais être rattachés à un utilisateur et synchronisés via API avec token Bearer. Le reset mot de passe est prévu avec envoi SMTP ou fallback dans email-outbox. **Prochaines étapes** - Créer les écrans mobile-lite inscription / connexion / mot de passe oublié - Configurer l’URL réelle de l’API back office dans mobile-lite - Mettre à jour la page back office Projets pour lire directement l’API centrale - Configurer SMTP pour les emails de réinitialisation --- ## 2026-05-05 10:12:25 — Écrans mobile-lite compte utilisateur **Objectif** Créer les écrans mobile-lite nécessaires pour connecter chaque utilisateur à son espace et permettre la synchronisation des projets vers le back office. **Actions** - Ajout de app/account/login.js - Ajout de app/account/register.js - Ajout de app/account/forgot-password.js - Déclaration des écrans dans app/_layout.js - Ajout d’un accès Connexion / compte depuis l’accueil mobile - Enrichissement du service backoffice-api.js avec inscription, profil et déconnexion locale **Résultat** Les écrans mobiles de connexion, inscription et mot de passe oublié sont créés. La connexion et l’inscription stockent le token utilisateur puis déclenchent une synchronisation des projets locaux vers le back office. **Prochaines étapes** - Configurer l’URL réelle du back office dans mobile-lite/src/services/backoffice-api.js - Tester register/login depuis l’app mobile - Créer un écran de profil / état de synchronisation - Brancher la page admin Projets sur l’API centrale --- ## 2026-05-05 10:28:48 — Correction UX mobile compte et accueil **Objectif** Corriger l’approche mobile-lite pour séparer accueil, compte utilisateur et historique des simulations. **Actions** - Suppression de l’historique des projets de la page d’accueil mobile - Refonte de l’accueil mobile en écran compact orienté action - Ajout de l’option Rester connecté sur connexion et inscription - Mise à jour du stockage de token pour gérer session persistante ou session mémoire - Documentation des décisions UX dans MOBILE_UX_ACCOUNT.md **Résultat** L’accueil mobile ne liste plus les simulations. Les écrans connexion et inscription proposent maintenant de rester connecté sur l’appareil. Les projets restent sauvegardés localement et seront synchronisés après connexion, mais l’historique devra être placé sur un écran dédié ultérieur. **Prochaines étapes** - Créer un écran dédié historique/projets utilisateur - Tester les écrans sur format mobile réel ou simulateur - Configurer l’URL réelle de l’API back office --- ## 2026-05-05 — Compte obligatoire pour utiliser mobile-lite Décision produit confirmée : aucune simulation ne doit être possible sans compte utilisateur connecté. Corrections effectuées : - L’accueil mobile ne propose plus `Nouvelle simulation` si aucun token utilisateur n’est présent. - L’accueil affiche uniquement `Se connecter` et `Créer un compte` quand l’utilisateur n’est pas connecté. - Les textes visibles ont été reformulés pour éviter le tutoiement dans l’environnement de l’app. - L’écran `visits/new.js` redirige vers `/account/login` si aucun token n’est présent, afin d’éviter l’accès direct à la première étape de simulation. Point de vigilance : il faudra appliquer la même garde d’authentification à toutes les étapes profondes du parcours (`configure`, `rooms`, `summary`, etc.) pour éviter l’accès direct par URL ou navigation interne. ## 2026-05-05 13:02:44 — Correction reconnaissance utilisateur après création de compte **Objectif** Corriger le flux mobile-lite après création de compte pour que l’utilisateur soit reconnu immédiatement et ne soit pas renvoyé vers la connexion. **Actions** - Stockage du token aussi dans globalThis.__RENOVALID_AUTH_TOKEN__ - Séparation entre création/connexion réussie et synchronisation projets différée - Accueil mobile modifié pour relire l’état de connexion via useFocusEffect - Lien Mon compte corrigé vers account/profile au lieu de account/login - Création de l’écran account/profile.js - Déclaration de account/profile dans app/_layout.js **Résultat** Après création de compte ou connexion, l’accueil doit reconnaître la session et afficher Nouvelle simulation. Le bouton Mon compte ouvre maintenant une vraie page profil avec informations utilisateur, synchronisation manuelle et déconnexion. **Prochaines étapes** - Tester une création de compte depuis mobile-lite - Si l’utilisateur n’est toujours pas reconnu, vérifier le retour exact de /auth/register et l’URL API effective - Protéger ensuite toutes les routes visits profondes --- ## 2026-05-05 — Diagnostic visible création / connexion mobile-lite Problème utilisateur : la création de compte ne fonctionnait pas et aucun message n’était affiché dans l’app. Corrections appliquées : - `mobile-lite/src/services/backoffice-api.js` affiche maintenant une erreur explicite si l’API est injoignable, avec l’URL appelée. - `mobile-lite/app/account/register.js` affiche maintenant une alerte native en cas de succès ou d’échec. - `mobile-lite/app/account/login.js` affiche maintenant une alerte native en cas de succès ou d’échec. - Les écrans connexion / création affichent aussi un encadré de statut toujours visible. Objectif : si la création échoue encore, l’utilisateur doit maintenant voir le message exact : API injoignable, email déjà utilisé, mot de passe trop court, erreur serveur, etc. ## Diagnostic centralisation utilisateurs / simulations Constat : l’authentification mobile fonctionne, mais le back office admin n’affiche pas encore les utilisateurs ni les projets issus de l’API PHP centrale. Action en cours : raccorder les pages admin aux fichiers centraux `backoffice/data/api-store/users.json`, `sessions.json` et `projects.json`, puis vérifier le moment exact où mobile-lite déclenche la synchronisation des simulations. ## 2026-05-06 10:04:09 — Ajout tableau de bord utilisateur mobile-lite **Objectif** Corriger le flux mobile après connexion pour afficher un espace utilisateur intermédiaire au lieu de lancer directement une nouvelle simulation. **Actions** - Création de mobile-lite/app/account/dashboard.js - Modification de login.js pour afficher le dashboard après connexion réussie - Modification de register.js pour afficher le dashboard après création de compte - Suppression du contournement qui rendait directement NewVisitScreen - Déclaration de account/dashboard dans app/_layout.js - Documentation dans MOBILE_DASHBOARD_FLOW.md **Résultat** Après connexion ou création de compte, l’utilisateur voit maintenant un tableau de bord avec Nouvelle simulation, Mes projets et Mon compte. L’écran intermédiaire manquant est en place. **Prochaines étapes** - Tester le flux connexion → tableau de bord → Mes projets - Tester le flux tableau de bord → Nouvelle simulation - Vérifier la synchronisation des projets avec le back office après enregistrement --- ## 2026-05-06 12:57:22 — Diagnostic communication mobile back office **Objectif** Mettre en place un test explicite et visible de communication entre mobile-lite et le back office. **Actions** - Ajout des endpoints API /diagnostics/ping en GET et POST dans backoffice/api/index.php - Création du service mobile src/services/diagnostics-api.js - Ajout d’un bouton Tester la communication back office dans mobile-lite/app/account/dashboard.js - Création de la page backoffice/admin/diagnostics.html - Création de backoffice/admin/diagnostics.js - Ajout de la carte Diagnostic API sur l’accueil back office **Résultat** L’app mobile peut maintenant envoyer un ping authentifié au back office. Le back office peut afficher les derniers pings reçus, le nombre d’utilisateurs, le nombre de projets et le répertoire de stockage API. Cela permet de vérifier objectivement si la communication réelle fonctionne. **Prochaines étapes** - Tester depuis le tableau de bord mobile le bouton Tester la communication back office - Ouvrir le back office puis Diagnostic API et vérifier que le ping apparaît - Si aucun ping n’apparaît, corriger l’URL API utilisée par mobile-lite --- ## 2026-05-06 13:35:53 — Correction affichage session tableau de bord mobile **Objectif** Corriger le message Session non reconnue sur le tableau de bord mobile alors que la connexion et le ping back office fonctionnent. **Actions** - Modification de mobile-lite/app/account/dashboard.js - Ajout d’un fallback sur getCurrentAuthUser() et getAuthToken() - Le tableau de bord ne déclare plus la session invalide uniquement parce que /auth/me échoue - Tentative de correction PHP pour token de secours, non appliquée car le bloc exact n’a pas été trouvé **Résultat** Le tableau de bord mobile doit maintenant afficher Espace utilisateur actif si un utilisateur local est reconnu, ou Session locale active si un token existe mais que la vérification serveur reste incertaine. **Prochaines étapes** - Relire le bloc get_bearer_token dans backoffice/api/index.php - Ajouter un fallback serveur X-RenoValid-Token ou access_token si nécessaire - Tester Diagnostic API pour confirmer user_email sur le ping --- ## 2026-05-06 13:59:37 — Correction MVP espace membre sécurisé **Objectif** Retirer la synchronisation manuelle et empêcher l’affichage de projets d’un autre compte dans l’espace membre mobile. **Actions** - Suppression du fallback local dans mobile-lite/app/account/projects.js - Mes projets lit désormais uniquement GET /projects côté back office - Si le back office ne renvoie aucun projet, l’écran reste vide - Si le back office est indisponible, aucun projet local n’est affiché - Suppression du bouton Synchroniser les projets dans mobile-lite/app/account/profile.js - Documentation dans MVP_SECURITY_FIX.md **Résultat** L’espace membre est simplifié et sécurisé pour le MVP. Le bouton manuel Synchroniser est retiré. Mes projets n’affiche plus de cache local susceptible de contenir des projets d’un autre compte ; le back office est la seule source d’affichage de l’espace membre. **Prochaines étapes** - Tester avec un compte neuf que Mes projets est vide - Créer une simulation et vérifier si GET /projects reçoit le projet - Si le back office reste vide, corriger le moment d’enregistrement automatique de la simulation --- ## 2026-05-07 06:53:37 — Correction session non reconnue tableau de bord **Objectif** Supprimer le faux message de session non reconnue dans le tableau de bord mobile alors qu’un token local existe. **Actions** - Modification de mobile-lite/src/services/backoffice-api.js - getCurrentBackofficeUser() ne supprime plus automatiquement le token local si /auth/me échoue - Fallback sur getCurrentAuthUser() quand la vérification serveur échoue - Modification du message dans mobile-lite/app/account/dashboard.js - Le tableau de bord affiche désormais Connexion requise seulement si aucun token n’est présent **Résultat** Une erreur ponctuelle de /auth/me ne détruit plus la session locale. Le tableau de bord ne doit plus afficher Session non reconnue si l’utilisateur vient de se connecter ou possède un token local. **Prochaines étapes** - Retester le tableau de bord après connexion - Si le message persiste, vérifier que loginToBackoffice reçoit bien result.user et result.access_token - Corriger ensuite côté PHP la lecture Authorization si /auth/me ne retrouve toujours pas la session serveur --- ## 2026-05-07 07:17:34 — Transmission utilisateur au tableau de bord mobile **Objectif** Corriger le message Connexion requise sur le tableau de bord mobile après connexion réussie. **Actions** - Modification de mobile-lite/app/account/dashboard.js pour accepter initialUser et forceConnected - Modification de mobile-lite/app/account/login.js pour conserver authResult.user et le transmettre au dashboard - Modification de mobile-lite/app/account/register.js pour conserver authResult.user et le transmettre au dashboard - Correction précédente conservée : getCurrentBackofficeUser ne supprime plus le token si /auth/me échoue **Résultat** Après connexion ou création de compte, le tableau de bord reçoit directement l’utilisateur de la réponse API. Il ne dépend plus uniquement du stockage local ou de /auth/me pour afficher un espace utilisateur actif. **Prochaines étapes** - Retester connexion puis tableau de bord - Vérifier que le message Connexion requise disparaît - Si l’utilisateur n’apparaît toujours pas, inspecter la réponse exacte /auth/login pour vérifier la présence de user et access_token --- ## 2026-05-07 07:56:34 — Correction session et fin de projet mobile-lite **Objectif** Corriger la perte apparente de session sur le tableau de bord et empêcher la déconnexion apparente après avoir terminé un projet. **Actions** - Modification de mobile-lite/app/account/dashboard.js pour conserver initialUser au lieu de l’écraser avec une valeur locale vide - forceConnected est maintenant pris en compte comme présence de session - Modification de mobile-lite/app/visits/export.js pour renvoyer vers /account/dashboard après Terminer au lieu de / - Réécriture précédente de backoffice-api.js conservée avec état global de session et access_token en URL **Résultat** Après connexion, le tableau de bord doit conserver l’utilisateur reçu par l’API et ne plus afficher Connexion requise. Après Terminer, l’utilisateur revient au tableau de bord au lieu de sembler déconnecté. **Prochaines étapes** - Retester connexion puis tableau de bord - Créer un projet puis cliquer Terminer - Vérifier si le retour se fait vers le tableau de bord - Si les projets ne remontent toujours pas, corriger côté PHP get_bearer_token pour accepter access_token en fallback --- ## 2026-05-07 08:44:06 — Correction disparition des projets dans Mes projets **Objectif** Empêcher la page Mes projets de supprimer les projets locaux lorsque le back office répond vide ou indisponible. **Actions** - Réécriture de mobile-lite/app/account/projects.js - Suppression de replaceSavedProjects([]) en cas de réponse serveur vide - Fusion des projets locaux et des projets serveur - Affichage d’un statut En attente back office pour les projets locaux non confirmés - Lancement automatique de syncProjectsToBackoffice(localProjects) quand des projets locaux existent mais que le serveur est vide **Résultat** Cliquer sur Mes projets ne doit plus faire disparaître le projet enregistré localement depuis le tableau de bord. Les projets locaux restent visibles jusqu’à confirmation back office. **Prochaines étapes** - Tester Terminer un projet puis Mes projets - Vérifier que le projet reste visible avec le statut En attente back office - Vérifier ensuite si le projet apparaît dans le back office après synchronisation automatique --- ## 2026-05-07 09:38:32 — Correction écran Mes projets vide **Objectif** Corriger le cas où Mes projets affichait vide malgré un projet visible dans le tableau de bord après Terminer. **Actions** - Inspection de mobile-lite/app/account/projects.js - Détection d'une double déclaration de localProjects dans loadProjects - Correction du cas sans token : l'écran affiche maintenant les projets locaux au lieu de setProjects([]) - Suppression implicite du second const localProjects par remplacement du bloc fautif **Résultat** Mes projets ne doit plus afficher vide uniquement parce que le token back office est absent ou non reconnu. Les projets locaux doivent rester visibles avec un statut local/en attente back office. **Prochaines étapes** - Créer un projet puis cliquer Terminer - Ouvrir Mes projets - Vérifier que le projet apparaît au minimum en local - Si l'écran est toujours vide, vérifier si saveProjectSnapshot écrit dans le même store que listSavedProjects --- ## 2026-05-07 11:40:03 — Reset MVP source unique back office **Objectif** Revenir à un flux MVP cohérent après réapparition des mêmes projets entre comptes, sessions non reconnues et absence de données back office. **Actions** - Mes projets a été remis en source unique back office dans mobile-lite/app/account/projects.js - Le tableau de bord compte maintenant uniquement les projets du back office dans mobile-lite/app/account/dashboard.js - La connexion et la création de compte ne synchronisent plus automatiquement les anciens projets locaux dans login.js et register.js - La fin de projet vérifie la présence d’un token et tente explicitement syncProjectToBackoffice(project) avant retour au tableau de bord - project-sync.js expose maintenant syncProjectToBackoffice(project) pour envoyer un seul projet **Résultat** Le cache local ne doit plus servir à afficher l’espace membre ni à rattacher automatiquement des projets à un nouveau compte. Un projet n’est considéré visible dans Mes projets que s’il est confirmé par le back office du compte connecté. **Prochaines étapes** - Tester une reconnexion complète - Créer un projet et cliquer Terminer - Si Terminer affiche une erreur back office, corriger la lecture du token côté PHP get_bearer_token - Vérifier ensuite backoffice/admin/projects.html --- ## 2026-05-07 14:17:45 — Correction affichage session tableau de bord mobile **Objectif** Corriger le message Session non reconnue sur le tableau de bord mobile alors que la connexion et le ping back office fonctionnent. **Actions** - Modification de mobile-lite/app/account/dashboard.js - Ajout d’un fallback sur getCurrentAuthUser() et getAuthToken() - Le tableau de bord ne déclare plus la session invalide uniquement parce que /auth/me échoue - Tentative de correction PHP pour token de secours, non appliquée car le bloc exact n’a pas été trouvé **Résultat** Le tableau de bord mobile doit maintenant afficher Espace utilisateur actif si un utilisateur local est reconnu, ou Session locale active si un token existe mais que la vérification serveur reste incertaine. **Prochaines étapes** - Relire le bloc get_bearer_token dans backoffice/api/index.php - Ajouter un fallback serveur X-RenoValid-Token ou access_token si nécessaire - Tester Diagnostic API pour confirmer user_email sur le ping --- ## 2026-05-12 08:49:46 — Correction session non reconnue tableau de bord **Objectif** Supprimer le faux message de session non reconnue dans le tableau de bord mobile alors qu’un token local existe. **Actions** - Modification de mobile-lite/src/services/backoffice-api.js - getCurrentBackofficeUser() ne supprime plus automatiquement le token local si /auth/me échoue - Fallback sur getCurrentAuthUser() quand la vérification serveur échoue - Modification du message dans mobile-lite/app/account/dashboard.js - Le tableau de bord affiche désormais Connexion requise seulement si aucun token n’est présent **Résultat** Une erreur ponctuelle de /auth/me ne détruit plus la session locale. Le tableau de bord ne doit plus afficher Session non reconnue si l’utilisateur vient de se connecter ou possède un token local. **Prochaines étapes** - Retester le tableau de bord après connexion - Si le message persiste, vérifier que loginToBackoffice reçoit bien result.user et result.access_token - Corriger ensuite côté PHP la lecture Authorization si /auth/me ne retrouve toujours pas la session serveur --- ## 2026-05-12 08:56:58 — Transmission utilisateur au tableau de bord mobile **Objectif** Corriger le message Connexion requise sur le tableau de bord mobile après connexion réussie. **Actions** - Modification de mobile-lite/app/account/dashboard.js pour accepter initialUser et forceConnected - Modification de mobile-lite/app/account/login.js pour conserver authResult.user et le transmettre au dashboard - Modification de mobile-lite/app/account/register.js pour conserver authResult.user et le transmettre au dashboard - Correction précédente conservée : getCurrentBackofficeUser ne supprime plus le token si /auth/me échoue **Résultat** Après connexion ou création de compte, le tableau de bord reçoit directement l’utilisateur de la réponse API. Il ne dépend plus uniquement du stockage local ou de /auth/me pour afficher un espace utilisateur actif. **Prochaines étapes** - Retester connexion puis tableau de bord - Vérifier que le message Connexion requise disparaît - Si l’utilisateur n’apparaît toujours pas, inspecter la réponse exacte /auth/login pour vérifier la présence de user et access_token ---