# 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 `.txt` et `.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](docs/installer.md)** | Comment je l'héberge ? | qui installe, sur YunoHost ou ailleurs |
| **[docs/publier-une-version.md](docs/publier-une-version.md)** | Comment je sors une version ? | qui maintient le projet |
| **[docs/architecture.md](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](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

```bash
dotnet build && dotnet test
```

```bash
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](docs/publier-une-version.md).

## Licence

**AGPL v3** — voir [LICENSE](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.