Suivi de la fusion en une seule application

• Bus ID Resto (bus_idresto.py) et IDRESTO.md ouverts restaurant
• Convention « onglet Ressources » actée pour les 4 back-office produits restaurant

Conception valable, réutilisée telle quelle après la fusion — rien à refaire ici.

• Modèle de données (9 tables) + mécanisme anti-fraude conçus idfid
• Document « modèle-socle » idresa
• Document « modèle-avantage-direct » idresa
• Document « ui-backoffice » idresa
• Pattern de jauge atomique promu convention d'univers idresa

Le SSO à jetons signés et le bundle partagé idresto-socle, envisagés le matin même (11h43), deviennent inutiles : une session, une base, un dépôt.

• Décision de fusion actée et diffusée sur le bus restaurant
• idresa stoppe tout code avant la bascule idresa
• docs/convention-modules.md écrit et poussé (commit 7839521) restaurant

La base dont tous les autres modules dépendent : personne d'autre ne peut démarrer son code avant qu'elle soit stable et poussée sur main.

• Squelette Symfony 7 (composer create-project symfony/skeleton) restaurant
• Doctrine épinglé : orm ~3.5.0, migrations ~3.8.0 (piège idfid évité) restaurant
• Arborescence des modules posée (src/Compte, Resa, Fidelite, Planning, Site, Vitrine, Partage) restaurant
• Entités Compte, Etablissement, CompteEtablissement, Abonnement restaurant
• Mapping Doctrine par module (config/packages/doctrine.yaml) restaurant
• Login (form_login), déconnexion, provider sur Compte restaurant
• Cookie de session sans Domain, Secure/HttpOnly/SameSite=Lax restaurant
• Colonnes 2FA en place sur Compte (activation réelle = tâche séparée, hors squelette) restaurant
• Filtre tenant central, TenantContext (src/Partage/Security) restaurant
• Gabarit de back-office aux couleurs icordis (templates/partage/base.html.twig) restaurant
• Base locale (MariaDB/MySQL) créée + première migration générée restaurant
• Serveur Symfony démarré, login + tableau de bord vérifiés à la main (1 bug trouvé et corrigé : Etablissement::aModuleActif()) restaurant
• Poussé sur main + annonce de fin sur le bus restaurant

Territoire commun annoncé AVANT d'y toucher (convention-modules.md §5, bien respecté) : 6 entités écrites, mapping Doctrine ajouté, migration générée/jouée/poussée (commit 29ac687), sauvegarde prise avant la migration avec app:sauvegarde:creer. Style réécrit en accesseurs privés + repositoryClass (maison), pas importé tel quel de l'ancien dépôt public-properties.

• 6 entités dans src/Fidelite/Entity : Personne, Client, Programme, Carte, Recompense, Ecriture idfid
• Contraintes uniques vérifiées EN BASE, pas seulement écrites (téléphone E.164, (établissement, personne), code_court, reference_externe pour l'idempotence) idfid
• Mapping Doctrine + migration générée, jouée, poussée (commit 29ac687) idfid
• Commercant/Utilisateur réconciliés : place à Etablissement/Compte, compteCentralId devient une vraie FK idfid
• App\Fidelite\Service\CreditPassage (le point d'entrée que Resa appellera — annoncé, pas encore poussé) idfid
• Firewall séparé + routes/gabarit templates/fidelite/client/ pour la PWA sur idfid.icordia.fr (décision §8.8 approuvée, reste à câbler) idfid

Conception révisée (pas recopiée) et déplacée dans idresto/docs/resa/ (commit 13182f2) ; ancien dépôt icordisagency/idresa réduit à un README pointeur, sans doublon. Bloqué pour écrire des entités testables pour de vrai — pas pour écrire du code.

• Conception révisée pour la fusion (Etablissement/Compte, filtre tenant de Partage, plus d'API/oracle/portail) idresa
• Statuts v1 corrigés : attendu → arrivé → no-show auto en fin de service, annulable (décision Musa 12h17 intégrée) idresa
• Représentation du temps approuvée : UTC + fuseau porté par l'établissement + date_service figée à l'écriture (IDRESTO.md §8.9) idresa
• 🔴 BLOQUANT — capacité en couverts midi/soir : demandé à bischtrot, en attente idresa
• 🔴 BLOQUANT — durée d'occupation d'une table par taille de groupe (2/4/6) : demandé à bischtrot, en attente idresa
• Premières entités src/Resa/Entity, préfixe resa_ — écrivables sans les 2 chiffres, mais rien de testable pour de vrai sans eux idresa

• Périmètre v1 cadré avec Musa idplanning
• Premières entités src/Planning/Entity, préfixe plan_ idplanning

Base de design déposée par Musa le 12/08 : gabarit HTML/CSS acheté (« Appilo », page d'atterrissage app SaaS — sections hero, fonctionnalités, comment ça marche, captures d'écran, intégrations, tarifs, témoignages, blog). Sert de STRUCTURE et d'inspiration de mise en page, pas à copier tel quel : ses couleurs (rose #d43396 / violet #6541c1, Bootstrap par défaut) n'ont rien à voir avec la palette icordis (#FF9100) déjà posée dans le back-office, et tout le contenu est un placeholder du vendeur du template.

• Gabarit source archivé : idresto/Design frontend Musa/appilo-app-landing-page-html-template-2023-11-27-05-07-47-utc.zip restaurant
• Recoloration aux couleurs icordis (remplacer rose/violet par #FF9100 + palette déjà en place) idresto
• Contenu placeholder remplacé par le vrai texte ID Resto (offre Résa/Fidélité/Planning, tarifs, démonstration, prise de contact) idresto
• Converti en Twig dans src/Vitrine (routes publiques, hors /admin) idresto

JetBackup et le Backup natif cPanel sont indisponibles sur le compte hébergeur (vérifié par SSH le 12/08) — pas d'API de sauvegarde à consommer côté O2switch. On reproduit le motif déjà éprouvé par app.icordia.fr (app:backup:create) plutôt que d'en inventer un autre.

• app:sauvegarde:creer : mysqldump + rotation locale (src/Partage/Command) restaurant
• Dump chiffré AES-256/openssl avant d'écrire sur disque (clé jamais à côté du fichier) restaurant
• app:sauvegarde:restaurer écrite ET testée pour de vrai en local (ligne insérée → sauvegardée → supprimée → restaurée → revenue identique) restaurant
• Bug trouvé et corrigé pendant le test : mysqldump sans --set-gtid-purged=OFF rendait la restauration impossible sur MySQL/MariaDB avec GTID actif restaurant
• Copie hors site (Google Drive) — bloqué, identifiants GOOGLE_DRIVE_CLIENT_ID/SECRET à obtenir (voir phase squelette) restaurant
• Rétention affinée ≥ 7 quotidiennes + 4 hebdomadaires (aujourd'hui : rotation simple, garde les N plus récentes) restaurant
• Cron de production (app:sauvegarde:creer quotidien) — à poser au premier vrai déploiement restaurant
• Clé de chiffrement de PRODUCTION générée séparément (pas la clé de test locale) et consignée dans ACCES-SERVEURS.md en plus de .env.local — sinon un incident serveur emporte à la fois la base ET la capacité de lire les copies qu'on en a faites restaurant

Hors fusion, dépôt séparé. Le flux Instagram (cron + fichier local, jamais d'appel API pendant une requête visiteur) est déjà livré et documenté comme brique réutilisable pour qui en aura besoin.

• Flux Instagram figé en cron (ClientInstagram, DepotInstagram, RafraichirInstagramCommand), partagé sur le bus bischtrot

Demande de Musa du 12/08 : tests automatiques avant déploiement + monitoring après déploiement. Le staging (environnement de préproduction séparé) est explicitement DIFFÉRÉ jusqu'à la vente à un premier client — seule la plomberie est documentée ici, rien n'est provisionné.

• CI GitHub Actions (.github/workflows/ci.yml) : install, versions Doctrine, mapping (statique + contre vraie base MariaDB de service), PHPUnit restaurant
• 2 bugs réels trouvés en faisant tourner la CI pour de vrai (pas en la lisant) : src/Partage/Entity/ jamais suivi par git (dossier vide), composer show qui n'accepte qu'un paquet à la fois restaurant
• 3 premiers tests fonctionnels (connexion, /admin et /admin/ressources exigent une authentification) restaurant
• Monitoring : alerte mail sur toute erreur prod (Monolog fingers_crossed + symfony_mailer, canal séparé du log JSON stderr) — déclenchement vérifié en local, pas seulement lu restaurant
• Pas de branch protection posée sur main — la CI signale un push cassé, elle ne bloque pas encore le merge. Décision à prendre séparément restaurant
• Cron réel de app:sauvegarde:creer + MAILER_DSN/MAILER_ALERTE_* réels — au premier vrai déploiement, pas avant restaurant

🟡 Staging DIFFÉRÉ (décision Musa 12/08) : quand un premier client paie, ajouter un bloc when@staging: dans les fichiers config/packages/*.yaml concernés (calqué sur when@prod:) + APP_ENV=staging sur un sous-domaine dédié. Symfony gère nativement n'importe quel nom d'environnement : il n'y a rien à préparer en plus tant que ce n'est pas activé.