mathieu
e7fe9ed6a9
Dans la vue Modifier une série, la dernière série enregistrée est la première montrée dans la sélection de la série mère. De plus, lors de l'enregistrement, on revient sur la page série et on ne reste plus bloquer sur la même page de sélection
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.