Le vœu reste à sens unique en base (A choisit B sur sa fiche, B n'a rien à faire) mais si A souhaite B, B doit désormais profiter aussi de la présence de A — dans les deux sens : affecter A d'abord fait remonter B comme candidat, et affecter B d'abord fait remonter A, même si B n'a rien demandé. - Solveur (`loader.py`) : le vœu (A → B) alimente maintenant l'ensemble effectif des deux bénévoles (A et B), pas seulement celui du demandeur. Aucun changement dans `engine.py` : il ne fait que lire un ensemble déjà symétrisé. - Mock (`buildEffectiveCompanions`) et classement par défaut (`buildEffectiveCompanionIds` dans `lib/planning.ts`, utilisé par `AssignmentPanel.tsx`) : même symétrisation, pour rester cohérents avec le vrai solveur. - La fiche bénévole (vœux affichés/édités) n'est pas touchée : c'est le seul endroit qui reste à sens unique, par construction (la réciprocité n'est qu'une lecture, jamais une donnée enregistrée — sinon éditer sa propre liste risquerait d'effacer le vœu de quelqu'un d'autre). - Nouveau test d'intégration : le bénévole qui n'a rien demandé profite quand même de la présence de celui qui l'a choisi. - CLAUDE.md à jour. Vérifié : 193 tests backend pertinents (dont le nouveau), ruff, alembic check ; typecheck/lint/build/smoke frontend. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017uUsRg7XzopkCPWimwg9ZM
Backend — API de gestion des bénévoles
FastAPI · SQLModel · PostgreSQL · Alembic. Dépendances gérées par uv.
Développement
Toujours via Docker Compose depuis la racine du dépôt :
docker compose up --build # démarre db + backend (reload actif)
docker compose run --rm backend uv run pytest
docker compose run --rm backend uv run ruff check .
Migrations
docker compose run --rm backend uv run alembic revision --autogenerate -m "..."
docker compose run --rm backend uv run alembic upgrade head
Structure
| Chemin | Rôle |
|---|---|
app/main.py |
Instance FastAPI, middlewares, routers |
app/config.py |
Configuration (variables d'environnement) |
app/db.py |
Engine SQLAlchemy + dépendance de session |
app/api/ |
Routers HTTP |
app/models/ |
Tables SQLModel du domaine |
app/validation/ |
Moteur de règles d'affectation (cœur du produit) |
app/i18n/ |
t(key) + locales/fr.json — aucun texte en dur ailleurs |
app/migrations/ |
Alembic |
tests/ |
pytest, base de test PostgreSQL réelle |
Note
uv.lock est versionné (généré dans le conteneur). Le régénérer après toute
modification des dépendances : docker compose run --rm backend uv lock.