Roadmap

Phases de développement, de la fondation au polish.

Vue d’ensemble

Les phases sont des ÉPICS THÉMATIQUES, pas une chronologie. Elles regroupent le travail par thème (lecture, écriture, messages, extensions, polish), pas par ordre de livraison. Le « quand » est porté par les releases — l’historique réel des livraisons se lit dans les CHANGELOG.md (racine + app/CHANGELOG.md) et les versionName des bêtas/prod, pas dans la numérotation des phases. Une feature peut donc être livrée « en avance » sur sa phase (ex. la Blacklist, thème Phase 4, shippée en bêta 0.15.0 avant l’ouverture formelle de la Phase 4).

Corollaire : « Polish & UX » (ex-Phase 5) n’est pas une étape finale mais un backlog continu alimenté tout au long du projet. Le milestone GitHub correspondant a été renommé en ce sens (« Polish & UX (backlog continu) »), et le label phase-5 est devenu polish.

Les phases gardent un ordre de dépendances techniques (on ne livre pas l’écriture avant la lecture), pas un calendrier. Le rythme réel dépend des contributeurs et des dépendances externes. Cohérent avec la méthodologie triple-hybride (prototype-driven).

Pour la liste des capabilities et des non-goals, voir le scope fonctionnel.

Dashboard des phases

Phase	Objectif	Taille	Dépend de	Statut
0 — Bootstrap	Squelette qui compile, CI, thème, navigation	S	—	✅ Livrée
1 — Core	Lecture du forum (drapeaux, topics, forum, deep links)	XL	Phase 0	✅ Livrée (AAB `0.1.0-phase1.7` / `app-v38` / specs v0.8.4)
2 — Écriture	Post / edit / quote / create topic / recherche / proxy alpha	L	Phase 1	✅ Livrée
3 — Messages	MPs classiques + MultiMPs (lecture + écriture + DT + sync de position)	M	Phase 2	✅ Livrée (clôture #598 ; sync MPStorage bidirectionnelle complète + cache Room reportés → #6, Phase 4)
4 — Extensions + refonte UI pré-1.0	Bookmarks, Qualitay, Redflag + refonte Drapeaux (#603) / Topic (#604) + hygiène repo (#605) ; Blacklist déjà livrée	L	Phase 3 + hfr-redflag Worker	🚧 En cours
Polish & UX	Animations, offline, thème dynamique, Play Store, raffinements UX	—	continu	♾️ Backlog continu (pas une étape finale)

Taille : S = petit sous-chantier, M = quelques composants, L = plusieurs features indépendantes, XL = écran majeur + parseurs + cache (ex. PostRenderer natif).

Graphe des dépendances

flowchart LR
    P0["Phase 0<br/>Bootstrap"]
    P1["Phase 1<br/>Core lecture"]
    P2["Phase 2<br/>Écriture"]
    P3["Phase 3<br/>Messages"]
    P4["Phase 4<br/>Extensions + refonte UI"]
    POL["Polish & UX<br/>(backlog continu)"]

    MPS[("MPStorage2<br/>hfr-redkit")]
    RFL[("hfr-redflag<br/>CF Worker")]

    P0 --> P1 --> P2 --> P3 --> P4
    MPS -.prérequis.-> P4
    RFL -.prérequis.-> P4
    P2 -.alimente.-> POL
    P3 -.alimente.-> POL
    P4 -.alimente.-> POL

    classDef external fill:#fef3c7,stroke:#d97706
    classDef continuous fill:#ede9fe,stroke:#7c3aed
    class MPS,RFL external
    class POL continuous

Les dépôts en cylindre (MPStorage2, hfr-redflag) sont des dépendances externes hors de ce repo — leur état bloque le démarrage de la phase qui les consomme. Note : la lecture MPStorage (positions DT) est livrée en Phase 3 sans dépendre de MPStorage2 (l’enveloppe v0.1 de facto a été adoptée, cf. ADR-014) ; le prérequis MPStorage2 ne pèse plus que sur la sync complète de Phase 4 (#6). « Polish & UX » n’est pas une phase terminale : c’est un backlog continu alimenté par toutes les phases.

Phase 0 — Bootstrap ✅ livrée

Objectif : un squelette d’app qui compile, avec CI, thème et navigation.

Structure Gradle multi-modules (8 core + 8 features base déclarés ; certains modules conservent un build.gradle.kts vide en attente de leur cycle, cf. ADR-001)
CI GitHub Actions (detektAll, lintDebug, test, testDebugUnitTest, :app:assembleDebug)
Thème Material 3 dans :core:ui (clair, sombre, AMOLED — Material You + HFR Classique différés Phase 5)
Navigation graph Compose Navigation 3 (bottom nav 4 onglets + back stacks par onglet, cf. navigation.md)
Hilt wiring (build-logic convention plugins, KSP, @HiltAndroidApp)
Design system de base (typographie, couleurs, composants thème)
Build signed AAB — pipeline --init-script + stamping redface2-v<vc>-<YYYYMMDD>-<sha>.aab

Livrable : une app qui démarre, affiche la bottom nav et navigue entre les écrans Phase 1 (drapeaux placeholder Phase 0 ; remplacé par la liste réelle en Phase 1B.4 ; forum/search/messages placeholder, topic fixe, éditeur placeholder).

Phase 1 — Core (lecture seule) ✅ livrée

Objectif : lire le forum. C’est 80% du use case.

Livrable : une app utilisable pour lire le forum au quotidien. Pas encore de possibilité d’écrire.

PostRenderer — le sous-chantier critique

Le rendu natif Compose du contenu HFR est le composant le plus complexe de toute l’app. Il doit gérer :

Élément	Complexité
Texte formaté (gras, italique, souligné, couleur, taille)	Moyenne
Citations imbriquées	Élevée
Blocs de code	Faible
Images inline	Moyenne
Smileys HFR	Moyenne (cache + mapping)
URLs cliquables	Faible
Spoilers (clic pour révéler)	Moyenne
Listes	Faible

Le PostRenderer sera développé de manière incrémentale : texte brut d’abord, puis formatage, puis citations, puis images.

Phase 2 — Écriture

Objectif : interagir avec le forum.

Livrable : une app complète pour lire ET écrire sur le forum.

Phase 3 — Messages

Objectif : les messages privés, classiques et multi.

Livrable : gestion complète des MPs, y compris les MultiMPs (lecture, écriture, membres) et la reprise de position de lecture DT.

Statut (2026-06-20) — Phase 3 ✅ Livrée (clôture #598). L’épic Messages est livré et shippé : MP lecture (#298), reply/quote MP (#301), nouveau MP + nouveau MultiMP, gestion des membres MultiMP via newdest (#606/#612), onglet DT + reprise de position MPStorage, recherche intra-topic (#546), plein écran (#518), parité des gestes de lecture topic↔MP (#351 a/b/c), et le déclencheur de synchronisation de position de lecture DT (#597, UPDATE-ONLY opt-in OFF).

Reste explicitement reporté (hors clôture Phase 3) :

Synchronisation MPStorage bidirectionnelle complète + activation opt-in par défaut + cache Room → umbrella #6, requalifié Phase 4 (questions de fond non tranchées : fréquence, conflits, format v1/v2, clé write-back).

#531 (réconcilier le lu/non-lu serveur des MP, re-unread best-effort) — polish, pas du fonctionnel manquant ; suivi en backlog Polish & UX, pas dans la clôture.

Lancer /spec-reality pour figer l’alignement specs↔code avant un bump de version specs.

Phase 4 — Extensions communautaires + refonte UI pré-1.0 🚧 en cours

Objectif : les features inspirées des userscripts HFR et la refonte UI avant la 1.0.

Extensions communautaires :

Architecture d’extensions (PostDecorator, TopicToolbarContributor) — prospective, :core:extension est encore une coquille vide (cf. extensions.md)
Bookmarks — sauvegarder des posts
Blacklist — masquer des utilisateurs — ✅ livrée par anticipation (bêta 0.15.0, #509), hors module d’extension dédié (DataStore JSON + :feature:settings, cf. extensions.md)
Alertes Qualitay — signaler un post remarquable
Redflag — alertes intelligentes sur topics suivis (dépend du Worker hfr-redflag)

Synchronisation MPStorage (suite Phase 3, requalifiée ici) :

Activation de l’écriture MPStorage opt-in par défaut + clé write-back tranchée (#597 reste OFF en attendant) — umbrella #6 / #577
Cache Room du contenu MP (opt-in, ADR-013 étage 3) + synchronisation bidirectionnelle

Refonte UI pré-1.0

Mandat de refonte des écrans chauds avant la 1.0 (post HFR XaTriX 2788560) :

Refonte de la vue Drapeaux — #603
Refonte de la vue Topic — #604
Hygiène repo / audit des dérives — #605 (cadrage + audit + purge des branches feature/* obsolètes ; à démarrer en premier)

Livrable : les features communautaires les plus demandées + une UI refondue prête pour la 1.0.

Polish & UX — backlog continu ♾️

Pas une étape finale. Anciennement « Phase 5 ». Le milestone GitHub est renommé « Polish & UX (backlog continu) » et le label phase-5 est devenu polish. Les raffinements sont livrés en continu tout au long du projet — beaucoup le sont déjà (thème AMOLED #286, transitions, swipe de pages, ascenseur, etc.). L’historique de livraison se lit dans les CHANGELOG.md (racine + app/CHANGELOG.md), pas ici.

Objectif : l’expérience utilisateur raffinée, en continu.

Animations et transitions (raffinements continus)
Mode offline complet (lecture + file d’attente d’écriture)
Notifications push configurables
Thème dynamique (Material You)
Thème “HFR classique”
Widgets Android
Tests de performance (scroll, cold start, mémoire)
Release automation — pipeline bêta/prod live (Play open testing + F-Droid, signed AAB via --init-script, guard CI versionName)

Livrable : une app continuellement raffinée pour le grand public.

Participation

Chaque phase sera trackée via les issues GitHub et des milestones. Les contributions sont les bienvenues à partir de la Phase 1.

Pour contribuer :

Choisir une issue non assignée
Commenter pour signaler qu’on la prend
Ouvrir une PR sur une branche feature
Review par un mainteneur