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

Ouvrir le repo framework localement (clone séparé).
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).
Ouvrir une tracking issue par RFC sur le repo framework avec labels rfc + area:fediverse + corps = Summary de la RFC + lien vers le fichier.
Mettre à jour cet index avec le numéro upstream attribué et le lien tracking issue.
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.

	..
	0001-fediverse-remote-resource-shares.md	21 kB
	0002-fediverse-remote-personal-access-tokens.md	16 kB
	0003-fediverse-remote-team-memberships.md	17 kB
	README.md	4 kB

eric / rustwarden

README.md