RFCs gitrust pour rustwarden-*

Ce dossier contient les propositions d'évolution upstream rédigées côté gitrust en tant que premier consommateur du framework. Le canonical lieu de vie d'une RFC est docs/rfcs/ dans le dépôt du framework ; les copies locales ici servent de tracking pour gitrust et de support de discussion avant push.

Toute RFC suit le template de docs/RUSTWARDEN_EVOLUTION_PROCESS.md §3 et est notée sur la grille §4 (min 25/35 pour acceptation).

Index

Numéro	Titre	Crate cible	Statut	Score	Pousse	Bloque
0001	RemoteResourceShareService (partages de ressources cross-instance)	rustwarden-fediverse	Implemented (upstream RFC 0029, livré + 11 tests)	33/35	Collaborateurs repo remote (gitrust)	Lot 5 du plan fédération
0002	RemotePersonalAccessTokenService (PAT pour identités remote)	rustwarden-fediverse	Implemented (upstream RFC 0030, livré + 20 tests)	34/35	git push HTTPS pour users remote (gitrust)	Lot 5 (partie HTTPS)
0003	RemoteTeamMembershipService (matérialisation des invites cross-instance)	rustwarden-fediverse	Rejected	18/35	—	Capacité déjà livrée par RFC framework 0009 (TeamService::add_member_identity) — duplication injustifiée. Détails : docs/plans/2026-05-15-rfcs-gitrust-evaluation.md

Principe directeur commun

Les 3 RFCs partagent la même approche architecturale (cf. critique utilisateur 2026-05-15) :

• Ne PAS étendre rustwarden-core::Principal ou les services core (ResourceService, TeamService, PersonalTokenService).
• Tout vit dans rustwarden-fediverse : tables fediverse_*, services dédiés, migrations trackées dans seaql_fediverse_migrations.
• Composition côté consommateur : un match sur Identity::{Local, Remote} dans le code applicatif appelle le service core ou le service fediverse selon l'identité présentée.
• Zéro impact sur les consommateurs qui n'activent pas la feature experimental-fediverse.

Ordre de push suggéré

Ordre	RFC	Justification
1️⃣	0001	Couvre le cas d'usage le plus large (collaboration cross-instance générique sur ressources arbitraires).
2️⃣	0002	Pair fonctionnel de 0001 pour l'auth HTTPS. Peut être livrée plus tard sans bloquer 0001.
❌	0003	Rejetée — la capacité team membership remote est déjà livrée par RFCs framework 0008/0009. TeamService::add_member_identity insère bien la row team_members avec remote_identity_id, et FediverseInviteService::accept (fediverse_invite_service.rs:103-145) le fait déjà aujourd'hui. Détails : docs/plans/2026-05-15-rfcs-gitrust-evaluation.md.

Les 2 RFCs restantes sont indépendantes entre elles côté implémentation — l'ordre n'est qu'une priorité d'attention upstream.

Workflow de push upstream

1. Ouvrir le repo framework localement (clone séparé).
2. Copier chaque RFC vers <framework>/docs/rfcs/NNNN-slug.md (renuméroter si conflit avec le numérotage upstream, cf. RFCs framework 0001-0028 déjà déposées — utiliser 0029, 0030, 0031 très probablement).
3. Ouvrir une tracking issue par RFC sur le repo framework avec labels rfc + area:fediverse + corps = Summary de la RFC + lien vers le fichier.
4. Mettre à jour cet index avec le numéro upstream attribué et le lien tracking issue.
5. Suivre la grille d'évaluation §4 : score min 25/35 → acceptation directe possible.

Statuts possibles

• Draft : rédigée côté gitrust, pas encore poussée upstream.
• Submitted : copie poussée upstream + tracking issue ouverte.
• Under Review : revue en cours par les mainteneurs framework.
• Accepted : acceptée, implémentation upstream démarrée ou livrée.
• Rejected : refusée, garder pour archive et raisonnement.
• Superseded by #MMMM : remplacée par une autre RFC.