Le bloc « Modele de donnees » decrivait encore Auteur et Statut comme des
colonnes de Livre. Il reflete desormais les cinq tables, leurs index et
leurs contraintes d'unicite.
Ajoute aussi ce qui ne se devine pas a la lecture du schema : pourquoi
des colonnes normalisees existent (SQLite ne sait pas ignorer les
accents), pourquoi Auteur en porte deux, et ce que la migration fait des
donnees existantes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deux changements de modele en une seule migration, plus la recherche qui
en depend.
Le statut de lecture devient personnel. Il etait une colonne de Livre,
donc partage par tout le foyer, alors que deux membres lisent le meme
exemplaire a des rythmes differents. Il vit desormais dans une table
(LivreId, Utilisateur, Statut) avec unicite sur le couple. L'absence de
ligne vaut « non commence » : sur une bibliotheque de foyer la plupart
des couples n'ont aucun statut, et les materialiser tous multiplierait
les lignes par le nombre de comptes pour n'exprimer qu'un vide. Rien
n'est donc ecrit a la creation d'un livre.
Piege rencontre : un Dictionary<int, Statut> renvoyait la valeur 0 de
l'enumeration — « À lire » — pour un livre sans ligne, rendant « non
commence » indiscernable d'un choix explicite. Le dictionnaire est
desormais typé Statut?.
L'auteur devient une table. Deux formes normalisees y cohabitent, et ce
n'est pas une redondance : NomNormalise garde l'ordre de saisie pour la
recherche en sous-chaine, CleRegroupement trie les mots et porte l'index
unique, donc l'invariant « un auteur, une fiche ». Les initiales
echappent a la cle et sont traitees en memoire, sur une table qui compte
au plus quelques centaines de lignes.
Un livre peut avoir plusieurs auteurs — le lookup ISBN en renvoie quatre
pour Introduction to Algorithms — d'ou la table de liaison, avec une
position qui conserve l'ordre de la couverture.
Les rapprochements ambigus ne sont jamais appliques seuls : l'API les
liste, l'utilisateur accepte ou refuse, et les refus sont memorises pour
que la suggestion ne revienne pas. Le couple refuse est range par
identifiant croissant, donc un refus vaut dans les deux sens.
Reprise des donnees existantes. L'ancien statut, commun, est rattache a
AjoutePar — seule personne que la base associe au livre. Les statuts des
livres sans AjoutePar sont perdus : les attribuer serait une invention.
Les trois valeurs sont reprises telles quelles, « À lire » compris, parce
que c'est ce que l'ancienne interface affichait. L'ancien champ auteur
devient une fiche par valeur distincte.
La migration ne peut pas tout faire : lower() de SQLite ne retire pas les
accents, donc « Émile Zola » et « emile zola » y restent deux fiches.
ServiceRenormalisation finit le travail en C# au demarrage, reunit ces
variantes, applique aussi la regle des initiales — sans quoi une base
heritee resterait eclatee la ou une saisie neuve aurait ete reunie
d'emblee — et garde le nom d'affichage le plus presentable. Il est
idempotent, et sert de filet si les regles de normalisation changent.
L'ordre de la migration compte : les colonnes condamnees sont recopiees
dans une table de transit avant d'etre supprimees, parce que supprimer
une colonne sous SQLite reconstruit la table.
Verifie sur une base a l'ancien schema contenant 9 livres, 2 prets et
trois variantes de Zola : prets intacts, statuts rattaches, les trois
Zola reunis sous « Émile Zola », « P.F. Hamilton » absorbe par
« Peter F. Hamilton », « Hamilton » seul laisse en suggestion.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cas mesure, ISBN 9782749942636 :
dc:title = "Le plus grand defi ... (Nouvelle ed. augmentee) Aurélien Barrau"
dc:creator = "Barrau, Aurélien (1973-....). Auteur du texte"
Le nom est recolle en fin de titre sans le separateur ISBD « / », donc la
regle de nettoyage existante ne peut rien y faire : la notice est sale a
la source.
L'heuristique est volontairement stricte — comparaison en fin de chaine
uniquement, contre un auteur deja nettoye, et seulement si le nom
commence sur une frontiere de mot. « Lettre a Émile Zola » n'est pas
touche, et un titre qui EST le nom de l'auteur (biographie, recueil) est
laisse intact plutot que reduit a rien.
La comparaison passe par CompareOptions.IgnoreNonSpace plutot que par une
normalisation NFD : elle ignore les accents sans changer les longueurs,
donc les indices calcules restent valables sur la chaine d'origine.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SQLite ne sait pas comparer sans tenir compte des accents : sa collation
NOCASE ne couvre que l'ASCII et il n'existe pas de unaccent() integre. La
seule facon d'obtenir « Emile » vers « Émile » sans charger tout le
catalogue en memoire est de stocker la forme mise a plat, et d'y chercher
un terme passe par exactement la meme fonction.
NormalisationTexte fait cette mise a plat. La ponctuation y devient une
espace au lieu de disparaitre : « P.F. Hamilton » doit donner trois mots,
sans quoi le rapprochement par initiales serait impossible.
RapprochementAuteurs porte la frontiere decidee dans CLAUDE.md. La cle de
regroupement — mots normalises tries — couvre casse, accents et ordre
inverse, et servira d'index unique. Les initiales abregees lui echappent :
elles demandent d'aligner les mots un a un, avec retour arriere, parce
qu'une correspondance gloutonne echouerait sur « P. Peter » face a
« Peter Paul ».
Le verdict est a trois niveaux, et l'asymetrie est deliberee : ne pas
fusionner laisse deux fiches a reunir d'un clic, alors qu'une fusion
erronee melange les livres de deux personnes et se defait mal. Un
patronyme seul face a un nom complet ressort donc « suggere », jamais
« certain ». Meme exigence sur l'alignement complet : « P. H. » et
« Peter Hamilton » s'alignent par les seules initiales, ce qui ne
concorde sur rien de verifiable — un mot entier commun est exige.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Verifie en executant le binaire publie : la racine repond 200 mais les
scripts de demarrage renvoient 404, donc l'application publiee affiche une
page blanche. Les placeholders d'empreinte restent litteraux alors que
seuls les fichiers empreintes existent sur disque.
Preexistant depuis la phase 1 : ma verification d'alors se limitait au code
HTTP de la racine, ce qui ne prouve pas que l'application demarre.
Consigne les trois pistes deja essayees sans succes pour eviter qu'on les
retente, et signale que le developpement n'est pas affecte.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Les deux defauts ont ete constates en executant reellement l'application, pas par
relecture :
1. L'import du module JS partait en 404 en developpement. L'import map generee par
Blazor reecrit « ./js/scanner-camera.js » vers un nom empreinte que l'API hote ne
sert pas (UseStaticFiles ignore les points d'entree empreintes). Une chaine de
requete sur le specifieur empeche la reecriture ; en publication rien n'est
reecrit pour ce fichier, le comportement est donc identique dans les deux modes.
2. Les messages d'erreur camera etaient tous generiques. Une DOMException perd son
« name » en traversant le pont JS vers C# : un refus de permission arrivait sous
la forme « Permission denied undefined ». Le JS attrape donc l'erreur et renvoie
un code de statut stable, que le C# traduit en message utile.
CLAUDE.md est mis a jour avec les mesures reelles obtenues en WASM, qui manquaient :
la performance de decodage (l'estimation de 5-10 ms/frame est confirmee, l'AOT reste
inutile) et le surcout de payload, nettement superieur aux 192 Ko documentes une fois
comptees les assemblies BCL que ZXing empeche le trimmer de retirer.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le decodage EAN-13/EAN-8 est fait en C# par ZXing.Net (IsbnScanner), conformement
a la decision actee dans CLAUDE.md : le JavaScript ne fournit que les pixels de la
camera, aucune logique de decodage ne lui est confiee.
Le scan se greffe en amont du flux d'ajout par ISBN existant : des qu'un code est
lu et reconnu comme ISBN-13 valide, la recherche de notices est declenchee sans
que l'utilisateur ait a retaper quoi que ce soit. La saisie manuelle reste
accessible en permanence, y compris quand la camera echoue.
Points traites explicitement :
- camera arriere par defaut (facingMode "environment", en "ideal" pour ne pas
echouer sur un PC sans camera arriere) ;
- liberation de la camera a l'annulation, au succes et au demontage du composant ;
- cadence limitee a ~12 images/s et decodage restreint a la bande centrale
reduite a 640 px de large : inutile de decoder chaque frame en pleine taille ;
- messages distincts pour permission refusee, absence de camera, camera occupee
et contexte non securise (getUserMedia exige HTTPS ou localhost : une IP de
reseau local en http ne marchera jamais, c'est une source de confusion garantie).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le statut de lecture sort de `Livre` vers une table par utilisateur : le
livre reste commun au foyer, sa lecture devient personnelle. La decision
« collection commune » n'est pas remise en cause.
L'auteur passe d'un champ texte libre a une table dediee avec forme
normalisee, prerequis du regroupement par auteur et de la recherche
insensible aux accents. Le regroupement automatique est limite aux
variantes sures ; les rapprochements ambigus doivent etre proposes, pas
appliques silencieusement — une fusion erronee se defait mal.
IDEES.md : la liste d'envies sera personnelle elle aussi, et exportable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Retours d'usage a traiter plus tard : agrandissement de la couverture au
clic, statut de lecture en lecture seule dans la liste et remonte au
niveau du type, affichage du format limite aux ebooks (physique par
defaut), fiche en lecture seule avec bouton d'edition, regroupement des
livres par auteur.
Documente aussi un cas de donnee sale mesure sur l'ISBN 9782749942636 :
la notice BnF colle le nom de l'auteur en fin de titre sans separateur
ISBD, donc la regle de nettoyage existante ne peut pas s'appliquer. Ce
n'est ni un doublon ni un defaut du parsing.
Garde en fin de fichier l'idee des livres souhaites (bibliographie par
auteur avec ouvrages possedes grises), hors perimetre v1, avec ses
implications sur le modele de donnees.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
API
- CRUD complet sur /api/livres : liste filtrable (format, statut) et
cherchable (titre, auteur), consultation, creation, modification,
changement de statut isole, suppression.
- Aucune lecture ne filtre sur AjoutePar : la bibliotheque est commune au
foyer. Le critere n'existe meme pas dans CritereLivres, pour qu'on ne
puisse pas s'en servir par inadvertance. Deux tests verrouillent
l'invariant, dont un par reflexion sur le type des criteres.
- AjoutePar est renseigne par le serveur a la creation, jamais par le
client, et n'est pas reecrit a l'edition (pas plus que DateAjout).
- Identite lue dans les en-tetes SSOwat (YNH_USER, YNH_USER_EMAIL,
YNH_USER_FULLNAME), avec repli sur un utilisateur simule configure en
developpement uniquement. Sans en-tete ni simulation, l'identite reste
inconnue plutot qu'inventee. Expose par GET /api/moi.
- Migration appliquee au demarrage : pas d'etape manuelle a l'installation.
Interface Blazor, pensee mobile d'abord
- Catalogue unique (physiques et numeriques melanges, distingues par le
format) avec recherche, filtres et changement de statut directement dans
la liste.
- Ajout par ISBN : quand la cascade rend plusieurs notices, un ecran de
choix les presente en mettant en avant editeur et annee, seuls elements
qui les departagent. Le formulaire reste ensuite entierement modifiable.
- Ajout manuel, edition, suppression avec confirmation explicite.
- Couvertures : l'URL OpenLibrary n'est jamais validee par un appel
prealable (502 intermittents mesures en phase 2) ; un attribut onerror
masque l'image cassee et laisse apparaitre un substitut.
Decisions prises la ou CLAUDE.md etait muet
- Tri alphabetique par titre.
- Un ISBN saisi doit etre valide, mais reste facultatif.
- Ecran de choix affiche seulement a partir de deux candidats.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Couvertures OpenLibrary : 502 intermittents mesures sur un meme ISBN.
Ne pas valider l'URL par un HEAD ; c'est a l'interface de gerer l'image
cassee.
- OpenLibrary : certaines editions n'ont aucun champ `authors`, le double
appel documente ne suffit donc pas. Le repli via `/works/` est desormais
implemente et documente.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Recuperation des metadonnees d'un livre a partir de son ISBN, cote serveur
uniquement (aucune interface, aucune persistance).
Cascade : BnF en ISBN-13, puis BnF en ISBN-10 converti, puis OpenLibrary.
La conversion 13 -> 10 est indispensable et non optionnelle : la BnF indexe
l'ISBN tel qu'imprime, les ouvrages d'avant 2007 ne portent qu'un ISBN-10 et
sont introuvables par l'EAN-13 que lit le scanner.
Toutes les notices trouvees sont remontees (jusqu'a 5) : un meme ISBN peut
correspondre a plusieurs reeditions, le choix revient a l'utilisateur.
Le double appel /isbn puis /authors d'OpenLibrary est bien fait, avec repli
sur l'oeuvre quand l'edition ne porte aucun auteur : c'est le bug de BookLogr
(titre rempli, auteur vide) qu'il ne faut pas reproduire.
La couverture vient toujours d'OpenLibrary, avec ?default=false pour obtenir
un 404 plutot qu'une image placeholder.
87 tests xUnit, sur fixtures enregistrees : aucune dependance au reseau.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Mise en place de la structure de base, sans aucune fonctionnalité métier :
- MaBibli.sln à la racine, avec trois projets ciblant net10.0
- MaBibli.Client : Blazor WebAssembly PWA (dotnet new blazorwasm --pwa),
pages d'exemple du modèle (Counter, Weather) retirées
- MaBibli.Api : ASP.NET Core, sert aussi les fichiers statiques du client
(UseBlazorFrameworkFiles + MapFallbackToFile), via le package
Microsoft.AspNetCore.Components.WebAssembly.Server
- MaBibli.Shared : entités et enums partagés (Livre, Pret, Format, Statut),
conformes au modèle de données de CLAUDE.md — AjoutePar est une simple
traçabilité, Pret est une table séparée pour garder l'historique complet
- EF Core + SQLite dans l'API : MaBibliDbContext, chaîne de connexion,
et migration initiale InitialCreate vérifiée par un database update
- dotnet-tools.json : dotnet-ef épinglé en outil local
Vérifié : dotnet build sans avertissement, et
dotnet publish MaBibli.Api -c Release -r linux-x64 --self-contained
produit un dossier unique dont le wwwroot contient bien _framework/.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Architecture serveur : x86_64, publish `linux-x64`.
- Production des binaires : compilation locale + release manuelle, via un
script ecrit pour etre reutilisable en CI plus tard. Compiler sur le
serveur est explicitement exclu.
- Cache hors-ligne : IndexedDB, retenu pour permettre recherche et tri
hors-ligne sur toute la bibliotheque.
- Notices BnF multiples : demander systematiquement, l'exactitude de
l'edition primant sur la vitesse de saisie.
- AOT WASM : desactive par defaut, a reevaluer apres mesure sur telephone.
Ajoute une section sur l'architecture de deploiement : les 3 projets .NET
ne produisent qu'un seul service (le client WASM est servi par l'API), et
le packaging vit dans un depot `mabibli_ynh` separe du code.
Le cadrage est desormais clos.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
API testee : HTTP 200, ~240 ms, sans cle. Le schema `dublincore` evite
completement l'UNIMARC — mapping bien plus simple que prevu, contrairement
a ce que supposait la note precedente.
Piege bloquant identifie : la BnF indexe l'ISBN tel qu'imprime, donc les
livres d'avant 2007 ne sont trouvables que par leur ISBN-10, alors que le
scanner lit toujours un EAN-13. Mesure sur echantillon verifie via
OpenLibrary : 2 titres sur 3 introuvables en ISBN-13 mais trouves en
ISBN-10. Interroger systematiquement les deux formes.
Autres pieges confirmes et documentes :
- aucune couverture cote BnF -> passer par OpenLibrary, avec
`?default=false` sans lequel un placeholder masque les absences
- plusieurs notices possibles pour un meme ISBN (3 pour Germinal)
- ponctuation ISBD a nettoyer sur titre / auteur / editeur, regles validees
- livres etrangers absents, ce qui confirme la necessite de la cascade
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Hors-ligne : consultation seule via cache des reponses GET. SQLite WASM
cote client ecarte. L'UI devra desactiver explicitement les ecritures
hors-ligne plutot que de les laisser echouer.
- Portee des donnees : collection commune au foyer. `UtilisateurId`
(proprietaire) devient `AjoutePar` (tracabilite) — ne jamais filtrer les
lectures dessus.
- Sources ISBN : BnF (SRU) en principale, OpenLibrary en secours. Motif :
OpenLibrary est lacunaire sur le fonds francais. API BnF pas encore
testee, a valider avant implementation.
- SSO : en-tetes SSOwat `YNH_USER` / `YNH_USER_EMAIL` / `YNH_USER_FULLNAME`.
OIDC ecarte, non documente par YunoHost (verifie ce jour). Corrige au
passage le nom d'en-tete, qui n'est pas `Remote-User`.
- Ebooks : fiches uniquement, pas de stockage de fichiers. Les prets ne
concernent donc que les livres physiques.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le dépôt ne versionnait qu'une archive `mabibli-init.tar.gz`, ce qui
empêchait git de suivre le contenu des fichiers. Les trois fichiers sont
désormais à plat et l'archive est supprimée.
Scan ISBN : remplacement de `html5-qrcode` par ZXing.Net (C#, Apache 2.0).
Validé concrètement en .NET 10 — round-trip EAN-13 OK, publish Blazor WASM
OK, 0,53 ms/frame dans le pire cas (échec sur frame 640x480 bruitée),
+192 Ko brotli sur le payload. Motif principal : le décodage reste
réutilisable hors navigateur si le projet évolue en scanner de
bibliothèque.
Clarification du besoin hors-ligne : consultation de la bibliothèque
existante uniquement. Signale au passage que SQLite vit côté serveur et
qu'un cache client sera nécessaire — point d'architecture non résolu.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
