# Feuille de route

Ce document liste ce qui a été volontairement laissé de côté pour la V1,
pourquoi, et ce qui pourrait venir ensuite — pas un engagement de
calendrier, juste une trace de l'état des décisions pour ne pas avoir à
re-débattre les mêmes questions plus tard. Voir [`DESIGN.md`](DESIGN.md)
pour le rationnel d'origine, et les entrées `## X.Y.Z` de
[`CHANGELOG.md`](CHANGELOG.md) pour ce qui a réellement été livré.

---

## 1. Rejeté, pas juste reporté

Ces points ont été explicitement discutés et écartés — les rouvrir
demande une vraie raison nouvelle, pas juste "ce serait bien d'avoir".

- **SSO / connexion fédérée pour l'interface web.** Le modèle d'identité
  de gitfed (certificats SSH courte durée, voir
  [`docs/HOW_IT_WORKS.md`](docs/HOW_IT_WORKS.md) §2) couvre déjà l'accès
  git ; ajouter du SSO pour le web ouvrirait une deuxième surface
  d'authentification fédérée à maintenir et à faire confiance, pour un
  gain limité puisque le mot de passe web n'ouvre déjà qu'une session
  opaque sans droit git (§4 du même document).
- **Authentification par jeton (PAT) pour le clone HTTPS.** Le clone HTTPS
  anonyme couvre déjà le seul cas légitime (lecture publique sans
  compte) ; un jeton ajouterait un deuxième mécanisme d'écriture par HTTP
  à côté de SSH, contraire au principe "une seule porte à surveiller"
  ([`docs/ARCHITECTURE.md`](docs/ARCHITECTURE.md) §6-7).
- **Annuaire / découverte publique d'instances fédérées.** Le modèle
  retenu est que chaque personne ajoute elle-même l'URL des instances
  auxquelles elle a accès — un annuaire centralisé recréerait exactement
  le point de couplage fort que la fédération pair-à-pair est censée
  éviter.

## 2. Reporté — complexité ou priorité, pas un refus de principe

- **Résolution de conflit dans le navigateur.** Les merge requests
  détectent les conflits et bloquent la fusion avec la liste précise des
  fichiers concernés, mais la résolution se fait en local (`git pull` +
  fusion + push) — un éditeur de conflit web est un morceau nettement
  plus gros, à faire seulement si le besoin se confirme à l'usage.
- **Commentaires de diff en ligne (par ligne).** Les merge requests n'ont
  qu'un fil de discussion général pour l'instant — des commentaires
  ancrés sur une ligne précise demandent de gérer leur position au fil
  des nouveaux push (rebase, force-push, etc.), volontairement pas fait
  dans la première version.
- **Stratégies de fusion alternatives (squash, rebase, fast-forward
  seul).** Le bouton "Fusionner" ne fait qu'un commit de fusion classique
  (`--no-ff`) systématiquement. Réévaluer si l'historique en devient trop
  bruyant en pratique.
- **Sauvegardes planifiées automatiquement.** `deploy/backup.sh` existe
  et fonctionne, mais rien ne le déclenche tout seul — c'est à
  l'opérateur de le brancher sur un cron/timer. Pas de stockage hors-site
  (S3 ou équivalent) prévu non plus pour l'instant.
- **`NetworkPolicy` réellement appliquée.** Le manifeste existe
  (`deploy/k8s/networkpolicy.yaml`) mais k3s + flannel (la configuration
  par défaut de ce cluster) ne l'applique pas — nécessiterait de changer
  de CNI (Cilium, Calico...), pas fait tant que ce cluster reste
  mono-tenant.
- **Minuterie de renouvellement pour `gitfed-renew-cert`.** L'outil existe
  côté client, mais aucun exemple de timer systemd/cron n'est fourni —
  chacun le met en place lui-même pour l'instant.

## 3. Candidats pour plus tard, sans priorité arrêtée

Des idées qui reviendraient naturellement si l'usage le justifie, mais
qui ne sont pas des manques identifiés aujourd'hui. Ratio effort/valeur
indicatif entre parenthèses, pour se souvenir pourquoi l'ordre est
celui-là la prochaine fois qu'on rouvre ce document.

### Recherche & découverte

- **Preview en direct dans la recherche** (debounce ~300ms, résultats
  affichés sous le champ sans changer de page) — la recherche actuelle
  ne fait que naviguer vers `/search`, aucun live-preview aujourd'hui.
  Nécessite un petit point d'entrée JSON en plus de la page existante.
  *(effort moyen)*. À ne pas confondre avec la recherche de code
  ci-dessous — celle-ci ne porterait que sur les dépôts déjà listés par
  nom/description, pas sur leur contenu.
- **Recherche de code** (pas seulement par nom de dépôt/sujet).
  *(effort élevé — indexation à construire, faible valeur tant que le
  nombre de dépôts reste petit)*.

### Fédération & import

- **Mirroring continu** depuis un dépôt externe (re-fetch périodique,
  gestion de credentials vers l'externe, conflits si quelqu'un pousse
  localement sur un miroir censé être lecture seule) — explicitement
  distinct de l'import ponctuel (voir §5), nettement plus lourd, pas
  retenu pour l'instant.
- **Webhooks sortants** sur push ou fusion de MR (appel HTTP vers une
  URL configurée). *(effort moyen, valeur moyenne-élevée si un usage CI
  ou notifications externes se confirme)*.

### Organisation à plus grande échelle

- **ACL par équipe/organisation**, en plus de l'ACL par personne
  actuelle. *(effort élevé — nouveau modèle de données, faible valeur
  tant que l'instance reste utilisée par peu de monde)*.

### À discuter avant de s'engager (tension avec le principe du §6)

- **Section latérale d'informations complémentaires** sur la page repo
  (nombre de commits, licence détectée, lien vers la doc — façon
  GitHub/GitLab "About"). Pas un gros morceau technique une fois les
  briques ci-dessus faites (licence, nombre de commits), mais c'est un
  vrai changement de layout (la page repo est mono-colonne aujourd'hui)
  et exactement le genre d'ajout que le §6 dit vouloir éviter par
  défaut. À faire si l'usage le justifie vraiment, pas par défaut.
- **Mode « site web » pour un dossier `docs/`** — navigation générée
  depuis l'arborescence, rendu en pages persistantes plutôt qu'en
  explorateur de fichiers, switch de langue intégré (voir la preview
  README ci-dessus). De loin le plus gros morceau de cette liste : plus
  proche d'un mini générateur de site de documentation que d'une
  fonctionnalité de forge git. Pas un refus, mais à traiter comme un
  projet à part entière si retenu un jour, pas comme une ligne de
  roadmap parmi d'autres.
- **Explorer élargi aux dépôts publics des instances de confiance** —
  afficher dans `/explore` non seulement les dépôts de cette instance
  mais aussi ceux des instances déjà présentes dans la trust store.
  Différent de l'annuaire fédéré rejeté au §1 (pas de découverte de
  nouvelles instances, seulement celles déjà approuvées pour d'autres
  raisons), mais un vrai changement architectural quand même : la
  confiance ne sert aujourd'hui qu'à valider des certificats, jamais à
  aller chercher des données chez l'instance distante. Nécessiterait un
  appel sortant vers chaque instance de confiance, une stratégie de
  cache/fraîcheur (pas d'appel réseau à chaque chargement d'Explorer),
  et la question du consentement de l'instance distante à être ainsi
  agrégée. À concevoir avant d'être une ligne de roadmap ordinaire.

## 4. Pages de profil (livré, v1.1.0)

Page publique `/u/<username>` façon GitLab : bio en markdown éditée
depuis les paramètres du compte, liste des dépôts publics de
l'utilisateur, date d'inscription et activité récente. Accessible sans
compte, comme `/explore`. Le fingerprint de clé SSH sur cette page est
volontairement laissé pour plus tard (voir §3).

## 5. Import ponctuel depuis un dépôt externe (livré, v1.2.0)

Un formulaire dans le tableau de bord où l'on colle l'URL HTTPS du dépôt
source (GitHub, etc.) et un nom local : `git clone --mirror` déclenché
une fois côté serveur, l'`origin` retiré juste après pour qu'il ne
retente jamais un fetch tout seul, puis le dépôt devient un dépôt gitfed
normal — mêmes règles d'espace de noms et de quota que la création
classique. Restreint aux URL `https://` sans identifiants embarqués,
avec résolution DNS vérifiée contre les adresses privées/locales avant
le clone (même garde-fou anti-SSRF que la découverte fédérée). Le
mirroring continu reste volontairement hors scope (voir §3).

## 6. Ce qui ne changera probablement jamais

Rappel du principe directeur (voir les deux README) : **gitfed n'essaie
pas de rivaliser avec GitHub ou GitLab sur le nombre de fonctionnalités.**
Le modèle d'identité fédérée est le sujet ; l'interface web existe pour le
rendre utilisable au quotidien, pas pour cocher toutes les cases d'un
forge complet. Un fork inter-dépôts (pull request cross-repo façon
GitHub) n'est notamment pas prévu : le modèle actuel est un dépôt partagé
avec des collaborateurs à accès explicite, pas un graphe de forks — ça
resterait vrai même si des organisations/équipes étaient ajoutées un
jour.