Une photo HEIC (marques heic, heix, mif1, msf1, heim, heis) était typée video/mp4. Elle est maintenant image/heic,
et AVIF image/avif. Elles restent refusées à l'envoi (invalid_media_mime_type), comme avant : sharp ne décode
que l'AVIF en entrée HEIF, pas le HEVC des HEIC. La marque hevc n'est une photo que si l'envoi se déclare photo,
pour qu'une vidéo HEVC en MP4 reste acceptée. Les vignettes Immich ne sont servies que pour les types image
autorisés.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Suppression de compte : un compte qui avait un mot de passe mais qui est relié à OIDC, sur une instance avec
PASSWORD_LOGIN=false, ne pouvait plus se supprimer (le mot de passe ne sert plus). Il se confirme désormais par
son email après une connexion récente, comme un compte né du fournisseur. /me et l'échange OIDC renvoient
hasPassword=false dans ce cas, pour que l'écran demande l'email : aucun changement d'interface.
Identité OIDC : un email vérifié déjà relié à une autre identité (un autre sujet) n'est plus repris par un
nouveau sujet (oidc_email_taken). La connexion d'une identité déjà reliée reste faite par émetteur et sujet,
jamais par email.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET et OIDC_REDIRECT_URI
ajoutent « Se connecter avec … » à l'écran de connexion. Tout le protocole
passe par openid-client 6 : découverte, PKCE S256, state et nonce, échange
du code, vérification de l'ID token (signature, émetteur, audience, dates).
State, nonce et vérificateur PKCE vivent dans un cookie signé, httpOnly,
SameSite=Lax, qui lie le retour au navigateur qui a commencé la connexion.
Le compte est trouvé par (émetteur, sub), sinon relié par email vérifié,
sinon créé sans mot de passe si ALLOW_REGISTRATION le permet (instance
vide comprise). Retour vers l'app par un jeton de passage de 60 s, à usage
unique, dans le fragment, échangé contre une session.
PASSWORD_LOGIN=false retire les mots de passe Parenthèse. Un compte sans
mot de passe se supprime en retapant son email, dans les 15 minutes qui
suivent une connexion. Code OIDC masqué dans les journaux.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Sexe : Femme, Homme, Autre, Non précisé. Autre est enregistré « other »,
refusé en 400 comme toute valeur inconnue, et prend les formes neutres ou
doubles pour nommer un lien.
- GEDCOM : import SEX X (GEDCOM 7) → other, SEX U → non précisé ; export
other → SEX X, non précisé sans ligne SEX. Aller-retour testé.
- « Ajouter quelqu'un » : « Je ne connais pas son prénom » sort de la colonne
Prénom et tient sur une ligne (sous les deux champs sur ordinateur, sous
Prénom sur téléphone) ; les quatre choix du sexe tiennent sur une ligne.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Champ Sexe (femme, homme, non précisé) dans la fiche en modification, à l'ajout
d'une personne et dans une proposition de la famille ; relu « Sexe » dans les
propositions à relire.
- Valeurs ramenées à male / female / null à l'écriture et à la lecture (anciennes
valeurs M/F relues sans migration), valeur inconnue refusée (400). Export GEDCOM
inchangé dans sa forme.
- Lien au survol genré quand le sexe est connu (Père, Tante, Cousine germaine,
Belle-mère…), forme double sinon. Nommage déplacé dans utils/kinship : une
fonction par langue reçoit le chemin complet (pas, personnes, sexe, année de
naissance), pour brancher d'autres langues.
- Anglais : beau-parent distingué de parent par alliance selon l'ordre du chemin
(Stepmother / Mother-in-law).
- Propositions à relire : le nom de la personne modifiée vient de l'avant lu en
base quand la modification ne porte que le champ changé.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
À false, POST /auth/register répond 403 registration_closed et l'app ne
propose plus de créer un compte (accueil, connexion, porte d'un arbre
partagé, menu du visiteur). Les comptes existants se connectent et créent
leurs arbres, le partage par lien et mot de passe ne change pas.
Une instance sans aucun compte accepte quand même le premier, sous un
verrou de transaction PostgreSQL (deux inscriptions simultanées n'en
créent qu'un). GET /auth/options expose l'état à l'écran d'accueil.
Défaut true : rien ne change pour les instances existantes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le cadre suivait le format de la photo : une photo couchee donnait toujours un
cadre couche. Le recadrage propose maintenant les cinq formes de l'arbre, en
dessin, et la forme choisie est gardee avec le cadrage (avatarCrop.shape, sans
migration). L'arbre la respecte ; sans choix, rien ne change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
La purge des visites de plus d'un an ne passait qu'a l'ouverture de l'onglet
Visites par un administrateur : un arbre jamais consulte gardait tout. Elle
passe aussi a l'enregistrement d'une visite, au plus une fois par heure, pour
tous les arbres.
A la suppression d'un compte, ses visites d'autres arbres gardaient son
identifiant dans la cle du visiteur : elles restent comptees, sous une cle
anonyme.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un fichier dont chaque fiche cite une note ou une source enorme faisait relire
ce texte pour chaque personne : environ 35 min de calcul pour 20 000 fiches,
0,1 s maintenant (memo par noeud, pour la duree de l'import).
- La lecture des medias ne descend que dans les branches qui menent a un
fichier, avec un budget par personne et une profondeur bornee.
- Les niveaux au-dela de 99 (limite de la norme) sont ignores : une chaine de
sources faisait deborder la pile.
- Les notes ne sont calculees que pour une personne creee, pas reutilisee.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Le cadrage (centre et zoom) est stocké dans Person.avatarCrop (JSON, nullable),
l'original reste sur disque et le cadrage s'applique à l'affichage (canevas et fiche).
Route PUT /trees/:id/persons/:personId/avatar/crop, réservée aux administrateurs.
La suppression et le nouvel envoi remettent le cadrage à zéro.
Migration additive (colonne nullable, sans défaut), testée sur base vide et sur base avec données.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
- Nom de famille facultatif : une personne garde au moins un prénom ou un nom
(API, contributions, fiche, formulaire). Contributions : seule une personne
sans aucun nom est ignorée.
- Case « Je ne connais pas son prénom » visible seulement si le prénom est vide
(ou cochée), placée sous le champ Prénom.
- Panneau d'ajout : sans sur-titres en capitales.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
Sinon « vers 1879 » restait colle a la date saisie ensuite, et l'export l'aurait ecrite.
Personne, union, et voie contribution.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
GET /trees/:id/persons/:personId/life rend la précision des dates, le lieu
de décès, le surnom, les unions avec leur lieu de mariage, et les
événements de la personne et de ses couples. Chargée à l'ouverture de la
fiche, pas dans le graphe. Les droits de lecture du graphe sont factorisés
(resolveReadAccess) et servent aux deux. Supprimer une personne supprime
aussi ses événements et ceux de ses unions.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nouvelle table life_events (baptême, résidence, métiers, études, service
militaire, inhumation, divorce, événements libres…) avec date, précision,
lieu, description, notes et sources. Personne : précision et borne des
dates de naissance et de décès, lieu de décès, surnom. Union : lieu et
précision du mariage. Naissance, décès et mariage gardent leur date et leur
lieu sur la personne ou l'union ; leur ligne d'événement ne porte que les
sources et les notes. Migration additive.
L'import lit tous ces événements (balises de la norme, variantes Gramps,
Heredis, RootsMagic), les adresses complètes, et les adoptions déclarées
par PEDI. Une personne ou une union déjà présente ne reçoit rien en double.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Dates : « vers », « avant », « après », « entre … et … », dates juliennes,
calendrier républicain converti en grégorien, doubles années (1700/01).
« BET 1794 AND 1796 » ou « @#DFRENCH R@ 18 BRUM 8 » étaient perdues, « ABT
1900 » devient au moins 1900. La précision est déjà lue pour la suite.
Notes : notes partagées (« 1 NOTE @N1@ »), plusieurs notes, RTF nettoyé. Le
lecteur garde la valeur brute de chaque ligne : une note coupée en CONC se
recolle avec ses espaces (« pendant trente-cinq ans », plus « pendanttrente »).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
En plus du portrait, l'import renvoie mediaRefs : les fichiers cités pour
chaque personne créée, où qu'ils soient accrochés (sous la personne, un
événement, une source citée, la fiche de la source, ou la famille pour les
actes de mariage), avec leur titre et leur source. Comme Gramps : adresses
web écartées, un fichier cité deux fois gardé une fois. Particularités
gérées : titre dans la note (Heredis, RTF compris), _PHOTO pour le portrait
(Family Tree Maker), chemins file:// (GEDCOM 7). Pour #59.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sans ordre fourni, un lien parent-enfant créé (route, contribution, import
GEDCOM) prend l'ordre suivant celui de la fratrie, pour qu'un enfant ajouté
après un réordonnancement ne passe pas devant les autres.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Vignette lue en flux : au-delà de 5 Mo (ou sans taille annoncée), la lecture
s'arrête sans charger le reste.
- Vignette servie seulement si les octets sont une image, avec
X-Content-Type-Options: nosniff (plus de repli sur image/jpeg).
- Liste des personnes : délai global de 30 s sur toutes les pages.
- Corps JSON illisible ou flux interrompu : 503 immich_unreachable, au lieu
d'une erreur serveur.
- Retirer le portrait à la main (DELETE avatar) ou supprimer une personne
efface aussi son identifiant Immich, sinon l'association reste invisible.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
L'API ne renvoie plus les adresses brutes d'Immich à un administrateur
d'arbre : la liste IMMICH_ALLOWED_API_URLS devient des instances nommées
(« Libellé=https://adresse », libellé facultatif, nom d'hôte par défaut).
Chaque instance a un identifiant opaque dérivé de son adresse, donc stable
même si l'opérateur réordonne la liste. Le PUT accepte cet identifiant et
stocke l'adresse canonique de la liste. Deux instances au même nom d'hôte
sans libellé sont refusées au démarrage avec un avertissement.
Les variables d'exemple documentent le format, la liste reste compatible
avec les adresses seules.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
new URL(chemin, base) effaçait le sous-chemin d'une instance derrière un
proxy (https://hote/immich devenait https://hote/api/...). L'adresse se
concatène désormais. Une adresse avec identifiants, requête ou fragment est
refusée, et le client reçoit l'adresse autorisée normalisée, jamais la
valeur brute de la base. Tests : sous-chemin, domaine préfixe, userinfo.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
fetch suivait les redirections par défaut : une instance autorisée qui
répond 3xx pouvait recevoir x-api-key sur une autre adresse. Les appels
passent en redirect: 'error' (remontée en immich_unreachable), avec un test
qui le prouve.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- avatarFromImmich (fichier préfixé « immich- ») remplace immichPersonId
côté front : le panneau ne propose le retrait que si le portrait vient
d'Immich, et le bouton de la fiche retrouve son libellé distinctif
- helper isImmichAvatarPath partagé entre le payload du graphe et la route
unassign, qui testaient le préfixe chacun de son côté
- tests : origine du portrait dans le payload (vrai/faux/null)
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Nouvelle table tree_immich_configs (adresse + clé d'API chiffrée AES-256-GCM,
clé dérivée de JWT_SECRET) et routes GET/PUT/DELETE /trees/:id/immich/config
réservées aux administrateurs de l'arbre ; journal d'audit sans secret
(adresse et « clé changée » uniquement).
- Fin des variables d'env IMMICH_ENABLED / IMMICH_API_URL / IMMICH_API_KEY :
l'adresse se choisit parmi IMMICH_ALLOWED_API_URLS, la liste établie par
l'opérateur du serveur. Elle filtre l'enregistrement ET chaque requête :
retirer une adresse coupe aussitôt les connexions qui l'utilisent.
- Changer d'instance exige une nouvelle clé : l'ancienne est écrasée et ne
voyage jamais vers le nouveau serveur.
- Le désassignement reste possible sans connexion : purement local, il nettoie
association et portrait stocké même après suppression de la connexion ; le
panneau affiche « Retirer l'association » dans tous les états.
- Onglet Immich dans Paramètres de l'arbre : menu des instances autorisées,
test de connexion, suppression avec confirmation ; i18n anglais des nouveaux
messages.
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Le 404 de la vignette ne distingue pas une personne inexistante d'une
vignette manquante : l'association pouvait donc être enregistrée pour
une personne Immich qui n'existe pas.
- ImmichClient.getPerson() : GET /api/people/{id} (200 | 404), qui
établit l'existence de la personne et annonce sa vignette.
- La route d'association rejette une personne inexistante (404
immich_person_not_found) ; un refus d'authentification (502) ou une
erreur serveur (503) n'est jamais pris pour une absence.
- La vignette n'est demandée que si Immich en annonce une ; une vignette
manquante chez une personne existante associe toujours sans portrait.
- Tests : personne inexistante refusée sans toucher base, audit ni
fichiers ; vignette disparue entre les deux appels ; échec
d'authentification pendant l'association sans changement en base.
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
Reprise de upstream (IliesAllali/main) dans la branche Immich. Seul
conflit : l'import des icônes dans PersonCard.jsx — les deux lignes
sont gardées (ImagePlus pour le portrait vide de « Premières photos »,
Sparkles pour le bouton « Depuis Immich »). Tout le reste fusionne
automatiquement ; l'intégration Immich (routes, exports de media.ts,
mapping immichPersonId, panneau) est inchangée.
Vérifié après la fusion : tests Immich (16), tests backend focalisés
gedcom-photos (4), build tsc, eslint et les 107 tests du front. Seul
« rate-limits login endpoint » dépasse son délai de 5 s, déjà le cas
sur main avant la fusion (bcrypt, machine lente).
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Colonne persons.immichPersonId (schéma + migration 20261012_001) et
exposition dans le graphe pour l'afficher côté fiche.
- Client Immich (src/lib/immich.ts) sur le contrat OpenAPI v3.1.0 :
ping, /api/people paginé, vignette par personne ; erreurs distinctes
entre injoignable, clé refusée et introuvable, identifiants validés
comme UUID v4.
- Routes /trees/:id/immich/* (status, people, thumbnail, assign,
unassign), réservées aux administrateurs de l'arbre ; l'adresse et la
clé d'Immich ne quittent jamais le backend.
- La vignette passe par le pipeline des portraits (type lu dans les
octets, métadonnées retirées, quota de l'arbre) : le fichier est écrit
avant la transaction (personne + journal immich_assign) et l'ancien
portrait est supprimé après ; un échec du nettoyage est journalisé
sans faire échouer la requête. Le désassignement retire le portrait
seulement s'il vient d'Immich (préfixe immich-) et préserve un
portrait envoyé à la main.
- Côté front : bouton « Depuis Immich » sur la fiche en édition, panneau
de sélection avec aperçu et retrait de l'association, traductions
anglaises, messages d'erreur distincts.
- Tests : 16 tests backend (succès, 400/401/403/404/413/502/503, quota,
échec de transaction, préservation du portrait manuel, serveur
désactivé) et le mapping immichPersonId côté front.
Generated by Mistral Vibe.
Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
- Création d'arbre : « J'ai déjà un arbre » importe le .ged sans fiche « vous » en double.
- Import GEDCOM : lit les photos citées (OBJE / FILE, en ligne ou par renvoi, _PRIM d'abord)
et renvoie leur chemin ; rien n'est gardé côté serveur.
- Fenêtre « Il manque les visages » après un import : dossier des photos apparié par nom de
fichier, cinq visages à demander (famille de « Moi », sinon les plus jeunes).
- Portrait vide chez le propriétaire : cadre cliquable sur la fiche hors édition, « + photo »
au survol sur l'arbre.
- Photos de plus de 5 Mo réduites à 2000 px avant l'envoi ; portraits à 120 envois par minute.
- PostHog : gedcom_imported, portraits_bulk_placed, portrait_added (effectifs arrondis).
- Corrigé : une union à un seul parent connu relie ses enfants à ce parent, sous un seul
« Inconnu », au lieu de les laisser sans lien.
- Corrigé : réimporter un GEDCOM reprend les personnes, unions et liens déjà présents au lieu
de tout doubler.
Recette locale (vraie API, vraie base) : 29/29 sur le parcours photos, 47/47 sur la recette
de non-régression des parcours. Tests 123 serveur, 107 app, lint et build propres.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Vidéo piégée : l'expression régulière de position était quadratique, un faux MP4 de 2 Mo figeait l'API (bornée, linéaire)
- Sessions émises avant le 01/10/2026 refusées (SESSIONS_NOT_BEFORE) : des sessions ont fuité dans les annotations et les journaux jusqu'à la 1.0
- Contributions : l'« avant » montré au propriétaire vient de la base ; une suppression approuvée part en cascade (unions, liens, souvenirs, portrait, fichiers)
- Mot de passe de partage : essai compté avant bcrypt, comparaisons une par une, changement et rattachement dans une transaction
- Quota mesuré sur le disque, 10 arbres par compte, corps à 1 Mo hors envois, bornes sur annotations, contributions et GEDCOM
- GIF réencodés ; anciennes propositions d'annotation sans adresse stockée ; clé d'exemple refusée sans NODE_ENV
- Déploiement du commit validé par la CI, clé d'hôte obligatoire ; nginx : X-Forwarded-For écrasé, version masquée, journal sans query string
- PostHog verrouillé dans le code, sans script externe ; CSP sans *.posthog.com ; sauvegardes hors serveur chiffrées par défaut
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Les annotations se lisaient avec n'importe quel compte, et une annotation photo enregistrait l'adresse de l'image avec la session de son auteur. Accès vérifié, adresse retirée à l'écriture comme à la lecture. Les images portent un jeton de lecture des médias (12 h, un arbre) au lieu de la session du compte. trustProxy ne croit plus que nginx (TRUST_PROXY), l'API peut n'écouter que la boucle locale (HOST), plafond de 30 échecs par arbre sur le mot de passe de partage, changer ce mot de passe coupe les comptes rattachés, connexion à durée constante, secrets d'exemple refusés en production.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Un SVG ou du HTML déclaré « photo » passait et s'exécutait sur app.parenthese.io à l'ouverture (vol de session du propriétaire). Le type vient maintenant des premiers octets, les photos sont réencodées par sharp (rotation appliquée, EXIF et GPS retirés), les vidéos de téléphone perdent leur position, et chaque fichier est servi avec nosniff et une CSP sandbox (téléchargement pour tout ce qui n'est pas image, son, vidéo ou PDF). Fichiers supprimés effacés du disque, quota par arbre, limite de débit sur les envois.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Visites : chaque ouverture de l'arbre est notée (prénom facultatif demandé avec le mot de passe, appareil, compte), sans adresse IP, effacée après un an ; onglet Visites dans les paramètres, réservé aux administrateurs
- Recherche : un résultat choisi recentre l'arbre sur la personne, la liste se replie
- Écran de compte ouvert depuis l'arbre : croix pour y revenir
- Enfant presque sous l'union : trait direct au lieu d'un petit S
- Page vie privée : paragraphe sur les visites
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Le panneau du propriétaire affichait la copie gardée par le navigateur où le
mot de passe avait été défini : changé depuis un autre appareil, il montrait
l'ancien. Le serveur garde maintenant le mot de passe de partage chiffré
(AES-256-GCM, clé dérivée de JWT_SECRET) dans une table à part, pour ne pas
toucher la version des accès déjà ouverts.
- GET /trees/:id/access/passwords : le mot de passe en vigueur, admin seulement
- POST .../remember : arbres d'avant, le propriétaire saisit celui déjà donné,
vérifié contre les hash, retenu sans rien changer aux accès
- rotation à deux mots de passe distincts : plus de valeur lisible
- anciennes copies locales effacées à l'ouverture du panneau
- message d'invitation (lien, mot de passe, une phrase) modifiable et à copier
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
- Prénom demandé à l'envoi d'une contribution et d'un souvenir, retenu
sur l'appareil pour la fois suivante (submittedByLabel). Le propriétaire
lit « par Camille » au lieu de « par Contributeur ».
- Mot d'accompagnement enregistré (ContributionSession.comment, migration
additive) et affiché à la relecture.
- Une personne ajoutée par la famille garde ses liens : identifiant
provisoire « tmp:… » remplacé par le vrai id à l'application ; un lien
vers une personne refusée est écarté au lieu de faire échouer la
relecture. Frère ou sœur : parents calculés aussi pour la famille.
- Soumission et relecture en transaction, appliquées dans l'ordre
personnes, unions, liens : tout ou rien.
- Bouton « Ajouter une personne » pour la famille sur ordinateur ; après
l'ajout, le panneau se ferme et un message confirme que la personne est
dans les modifications ; il ne réapparaît plus au retour en édition.
- Relecture : les liens se lisent « Léon, enfant de Marc ».
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Un membre de la famille (lien de partage ou membre non administrateur)
peut maintenant envoyer une photo, une vidéo, une voix ou une citation.
Le serveur la stocke « en attente » et crée une contribution d'une ligne,
qui arrive dans « Propositions à relire » avec l'aperçu de la photo.
Accepter la rend visible, refuser la masque. En mode « application
immédiate », elle est visible tout de suite.
- Migration additive : MediaItem.status (approved par défaut, tout
l'existant reste visible), MediaItem.contributionSessionId, valeur
« media » dans ContributionEntityType.
- Graphe, statistiques, ordre des souvenirs : souvenirs acceptés seuls.
- Relecture d'une session contenant un dessin : ne plante plus
(l'annotation tombait dans la branche des liens).
- App : message « Merci, c'est envoyé » après un envoi en attente ;
réordonner, supprimer et changer la photo de profil réservés au
propriétaire (le serveur les refuse aux autres).
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Utilisateurs
- Suppression de compte depuis l'écran « Votre compte », confirmée par mot de passe :
arbres possédés et médias effacés, email retiré des contributions, sessions fermées partout.
- Suppression d'arbre définitive, en base et sur le disque.
- Ajout d'un frère ou d'une sœur relié aux parents existants ; relations parent et enfant
corrigées en mode démo.
- Liste d'attente retirée (route, envoi d'emails, dépendance Resend).
Projet ouvert
- CI : front, landing, backend avec vérification des migrations, test Docker de bout en bout.
- Déploiement lancé seulement après une CI réussie sur main.
- Image API : CLI Prisma installée à part pour que les migrations tournent au démarrage.
- SECURITY.md, CONTRIBUTING.md, modèles d'issue et de pull request.
- Migration renommée avec un nom descriptif, contenu identique.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Galaxie familiale : personnes, unions et filiations, photos, vidéos et voix sur chaque personne,
partage par lien avec consultation sans compte et contributions validées par le propriétaire.
Auto-hébergeable avec Docker. Licence PolyForm Noncommercial 1.0.0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
