> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cel-eleague.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Documentation CEL

> Point d’entrée de la documentation technique et métier de CEL.

# Documentation CEL

Bienvenue dans la documentation source de vérité de **CEL — Cameroon E-sport League**.

Cette documentation sert à comprendre rapidement :

* l’architecture technique de l’application ;
* les domaines fonctionnels déjà présents dans le repo ;
* les règles métier réellement vérifiées dans le code ;
* le modèle de données Convex ;
* les runbooks d’exploitation ;
* les intégrations comme EA FC, Algolia, Stripe, notifications et emails.

## Pour qui ?

Cette documentation s’adresse principalement :

* aux développeurs qui travaillent sur CEL ;
* aux admins techniques qui doivent comprendre les workflows ;
* aux futurs contributeurs qui ont besoin d’une vue claire du projet ;
* à toute personne qui doit vérifier une règle métier avant de modifier le code.

## Comment lire la doc ?

Commence par ces pages :

* **Architecture technique** pour comprendre la stack et l’exploitation.
* **Domaines fonctionnels** pour avoir la carte produit de CEL.
* **Surfaces Web et administration** pour l’inventaire des 77 routes de page.
* **API HTTP Convex** pour les endpoints et frontières de sécurité.
* **Règles métier vérifiées** pour voir les règles déjà confirmées dans le code.
* **Modèle de données Convex** pour le catalogue des 71 tables effectives.

Ensuite, va dans le module qui t’intéresse : matchs, clubs, transferts, sanctions, notifications, intégrations ou runbook.

## Cartographie produit/front (au travers des audits)

La navigation ci-dessous est alignée avec les routes Next.js vérifiées dans le code :

* `web/src/app/(app)` pour 28 pages application et contenu ;
* `web/src/app/(auth)` pour l’identité (`login`, `signup`, `forgot-password`, `verify-email`, `reset-password`, `onboarding`).
* `web/src/app/admin` pour 33 pages d’administration ;
* `web/src/app/design-system` pour 8 pages de référence UI ;
* `/search` et `/offline` comme routes autonomes.

Navigation recommandée dans le contexte produit/front :

* [index](./index) : point d’entrée de la doc
* [domaines-fonctionnels](./domaines-fonctionnels) : cartographie produit/front
* [surfaces-web-et-administration](./surfaces-web-et-administration) : routes publiques, auth, admin et design system
* [api-http](./api-http) : API HTTP Convex
* [palmarès](./palmares) : récompenses, honneurs, TOTS et MVP
* [architecture](./architecture) et [modele-donnees](./modele-donnees) : base technique
* [mintlify](./mintlify) : structure documentaire et liens d’exploitation

## Principe important

Une règle doit être documentée comme acquise uniquement si elle est vérifiable dans :

* le code ;
* le schéma Convex ;
* les tests ;
* les scripts du dépôt ;
* les workflows de déploiement.

La documentation ne doit pas inventer de comportement produit.

Quand une assertion n’est que partiellement couverte par les fichiers passés en revue, elle est explicitement signalée comme `non vérifié`.

## État de publication

La validation Mintlify et les liens sont contrôlés en CI. Le domaine public et la
configuration du projet Mintlify restent pilotés hors du dépôt et sont donc
documentés comme état externe.