# Infra & DevOps : Docker, Podman, PostgreSQL, Gitea

## Docker / Podman

- Image de base : vérifier une version explicite et pinnée (pas de `latest` en prod/CI) → `latest` non pinné = 🟠.
- Utilisateur non-root dans le conteneur pour tout ce qui tourne en prod/CI — root par défaut sans justification = 🟠 (surface d'attaque).
- Multi-stage build pour limiter la taille de l'image finale (surtout pour du Java/Node buildé) — absence sur un build lourd = 🟡.
- `.dockerignore` présent et cohérent pour éviter d'embarquer des secrets/fichiers inutiles = vérifier systématiquement.
- Podman vs Docker : si rootless Podman est utilisé (cohérent avec le choix du studio d'éviter le daemon root), vérifier que les volumes/permissions UID/GID sont gérés correctement (mapping utilisateur) plutôt que de forcer du root.
- Secrets : jamais de secret en clair dans un `Dockerfile`/`docker-compose.yml`/`ENV` versionné = 🔴 systématique.

## PostgreSQL

- Migrations : toute modification de schéma doit passer par un outil de migration versionné (pas d'ALTER manuel non tracé) = 🟠 minimum, 🔴 si ça touche une table en prod sans rollback prévu.
- Index : vérifier la présence d'index sur les colonnes utilisées en `WHERE`/`JOIN` fréquents avant de valider une requête qui semble lente.
- Transactions : opérations multi-tables qui doivent être atomiques mais ne sont pas dans une transaction explicite = 🔴 potentiel (incohérence de données).
- Connexions : pooling de connexions plutôt que d'ouvrir une connexion par requête dans du code applicatif à fort volume.
- Types : privilégier les types PostgreSQL adaptés (`timestamptz` plutôt que `timestamp` sans fuseau, `numeric` pour les montants plutôt que `float`).

## Gitea (workflow & CI)

- Branch protection sur `main` : vérifier que le workflow proposé respecte la protection de branche déjà en place (cf. préférences de Benjamin sur la hygiène de clés/rotation et les accès agents IA).
- PR/Issue : cohérence avec la structure EPIC=Milestone / FEATURE=Issue / STORY=checklist item définie dans la skill `agile-master` — ne pas réinventer une autre convention de nommage dans une review.
- CI (Gitea Actions ou runner équivalent) : tout script de CI doit être idempotent et échouer explicitement (exit code non nul) en cas de problème plutôt que de continuer silencieusement.
- Clés/déploiement : pour tout ce qui touche l'accès Git d'un agent (SSH, PAT), rappeler la préférence du studio pour des deploy keys ou PAT fine-grained scopés (`Contents: write` + `Pull requests: write`) plutôt qu'un accès large — accès trop large proposé = 🟠.