mathieu
42dec0dbd1
- Cataloguer en rafale — nouvel écran /ajout/rafale : on scanne une pile de livres à la suite dans une zone de texte, chaque code est traité (BnF puis OpenLibrary), les doublons connus sont passés automatiquement. La collecte marche même hors-ligne. Le compte rendu liste maintenant les livres créés, en lien vers leur fiche, et reste consultable en revenant sur l'écran même après une rafale entièrement réussie. Le catalogue reconnaît un ISBN dans sa barre de recherche (13 ou 10 chiffres, avec ou sans tirets) : scanner un livre en main ouvre directement sa fiche s'il n'y en a qu'un. Un bouton « Scanner » l'alimente, actif hors-ligne. - Ajouter un tome à une série accepte aussi un ISBN dans le champ manuel : le catalogue est cherché d'abord (rattachement direct si un seul exemplaire), sinon la BnF prend le relais. Séries et sagas - Numéro de tome distinct de la position de lecture : on peut indiquer « c'est le tome 7 » même si on ne possède pas les six premiers ; l'ordre de lecture reste un réglage séparé (utile pour les préquelles). - Tri par numéro en plus du tri par ordre de lecture quand des tomes en portent un. - Panneau « Ajouter » regroupé et repliable sur la fiche d'une série (manuellement / en rafale / depuis le catalogue / depuis les envies), au lieu de quatre formulaires ouverts en permanence. - Filtre catalogue « sans couverture » pour repérer les livres à illustrer. Le catalogue groupe les tomes d'une même série sous un bloc repliable, avec un décompte plus clair (affichés / possédés / total). - Corrections directes sur la fiche - Effacer un prêt saisi par erreur (bouton ✕ sur chaque ligne, avec confirmation), sans passer par « rendre ». - Corriger une couverture manquante ou cassée en cliquant dessus : le champ d'adresse s'ouvre focalisé, Entrée enregistre. Étendu aux numéros de revue dans la dernière modification. - Les thèmes déjà utilisés dans la bibliothèque sont proposés à la frappe. - La recherche d'un livre à rattacher montre des suggestions dès le focus, sans attendre de taper. - Visuel : un rendu manquant après une écriture asynchrone dans le formulaire de livre, une bascule de rôle cassée, des débordements à 320 px, et le style d'un bouton-lien qui restait souligné.
MaBibli
Gestion de bibliothèque personnelle, auto-hébergée, pensée pour un foyer. Catalogue, prêts, scan de code-barres, consultation hors-ligne.
- Catalogue des livres physiques et des ebooks — fiches uniquement, aucun fichier n'est hébergé. Revues et séries ont leurs propres fiches.
- Prêts — à qui, depuis quand, et l'historique complet.
- Scan ISBN au code-barres depuis le téléphone, ou saisie manuelle, avec pré-remplissage du titre, de l'auteur, de l'éditeur et de la couverture.
- Statuts de lecture personnels — chacun sa progression, sur une collection commune.
- Liste d'envies personnelle, exportable en
.txtet.csv. - Consultation hors-ligne — PWA installable ; la bibliothèque reste consultable et cherchable sans réseau.
Les métadonnées viennent de la BnF puis d'OpenLibrary, deux sources libres et sans clé d'API. Aucune dépendance à Google Books.
Documentation
| Document | Répond à | Pour qui |
|---|---|---|
| docs/installer.md | Comment je l'héberge ? | qui installe, sur YunoHost ou ailleurs |
| docs/publier-une-version.md | Comment je sors une version ? | qui maintient le projet |
| docs/architecture.md | Pourquoi le code est ainsi ? | qui veut comprendre ou contribuer |
mabibli_ynh/doc/ADMIN.md |
Où sont les données, qui a accès ? | l'administrateur, après installation |
CLAUDE.md porte le contexte de travail : le périmètre de la V1, les invariants à ne pas
casser, et les pistes non actées qui restent ouvertes.
En bref
Trois projets .NET, un seul processus en production : le client Blazor WebAssembly est compilé en fichiers statiques que l'API sert elle-même.
MaBibli.Client ─┐
MaBibli.Shared ─┼──► dotnet publish MaBibli.Api ──► un service systemd
MaBibli.Api ─┘ (self-contained) sur 127.0.0.1
| Backend | C# / ASP.NET Core, .NET 10 |
| Frontend | Blazor WebAssembly, en PWA |
| Base | SQLite + EF Core |
| Scan | zbar compilé en WebAssembly (LGPL-2.1) |
| Authentification | SSO YunoHost, via les en-têtes SSOwat — pas d'auth propre |
| Hébergement | YunoHost, installation native (sans Docker) |
Deux contraintes ne se négocient pas, et toutes deux portent sur le serveur : HTTPS (sans quoi le scan caméra ne s'ouvre jamais) et un domaine entier, pas un sous-chemin. Le pourquoi est dans docs/architecture.md.
L'architecture, elle, n'en est plus une : amd64 et arm64 sont publiées à chaque version, et YunoHost choisit la bonne. ⚠️ L'architecture de la machine qui compile est indifférente de son côté — le publish est croisé, et le SDK télécharge le runtime pack de la cible.
Démarrer
dotnet build && dotnet test
dotnet run --project MaBibli.Api
L'API sert aussi le client compilé : une seule commande suffit.
L'URL du dépôt
La documentation porte une URL de démonstration, forge.example.org. Deux valeurs
seulement portent la vraie : depot_code, en tête de mabibli_ynh/build/publier.sh, qui
commande toutes les URL dérivées, et amd64.url dans manifest.toml, que publier.sh
réécrit à chaque publication et qui ne se change jamais à la main.
Pour tirer de ce dépôt une copie publique destinée à des tiers, la marche à suivre est dans docs/publier-une-version.md.
Licence
AGPL v3 — voir LICENSE. L'AGPL attend que les utilisateurs d'un service en réseau puissent en obtenir la source : le lien vers le dépôt affiché dans la page « À propos » de l'application n'est pas un ornement.