Reprise du message précédent :
Half wrong

Opus 4.7 est sorti https://www.anthropic.com/news/claude-opus-4-7
 
On va pouvoir le faire bosser

Avec plaisir

Pareil, je viens de lui donner une grosse feature  

Je le trouve très rapide  

Oui je le fais trimer là

Tu dois pas être en xhigh
Je l'ai mis en max comme un crevard

Punaise 41% d’utilisé apres le premier prompt de spécification  

Specs v0.4.0 mergée

Un nouveau cycle d'audit des specs a été appliqué (Opus 4.7 1M context, effort max). Principaux changements :

Stack 04/2026 verrouillée
- Kotlin 2.3.20, compose-bom 2026.03.01
- Material 3 Adaptive 1.2 : NavigationSuiteScaffold, ListDetailPaneScaffold, edge-to-edge Android 15+, predictive back
- Compose Navigation 2.9 type-safe routes (@Serializable)
- Konsist (enforcement archi Kotlin-first) vs ArchUnit — Konsist gagne parce qu'il voit les sealed/data/internal/KMP
- Roborazzi (screenshot tests 4 variants : compact light/dark + medium light + fontScale 2.0)

Sécurité credentials corrigée
EncryptedSharedPreferences déprécié par Google en 04/2025 (crashs keyset corruption sur OEMs, StrictMode violations). Remplacé par DataStore + Tink + Keystore, comme recommandé officiellement par Google.

Protocole HFR documenté
Nouvelle page docs/protocol-hfr.md couvrant endpoints, form fields, hash_check (anti-CSRF), verifrequet=1100 (anti-bot), numreponse unique par catégorie, listenumreponse (optimisation JS inline non utilisée par v1), session/403 recovery, règle prefetch non-authentifié (merci Corran Horn pour la piqûre de rappel sur les drapeaux ).

Modèles affinés
- ImageProvider enum splité en UploadProvider + RehostProvider (le REHOST ne supportait pas upload, violation de typing)
- PMMessage ajouté pour la conversation MP
- postsPerPage configurable — vient du réglage HFR de l'utilisateur (editprofil.php?page=3), pas une constante en dur

Infra multi-LLM
Le repo est maintenant compatible Claude Code, Cursor, Codex, Copilot coding agent, Gemini CLI, Junie. AGENTS.md est source of truth (spec agents.md stewardée par Linux Foundation), skills au format agentskills.io (spec Anthropic 18/12/2025). Un LLM sur n'importe quel outil peut contribuer sans adapter ses instructions.

Audit
Les 26 points audit#1 (issue #14) et 15 points audit#2 (#17) étaient déjà appliqués. Le nouvel audit v0.4.0 a remonté 53 findings, dont 42 résolus dans ce cycle. Reste hors scope pour v0.5.0 : promotion draft Material 3 (4 questions ouvertes à trancher — seed color, dynamic color par défaut, font family, BBCode rendering, avis bienvenus), skills /new-feature et /new-parser, ADR formelles.

Liens
- CHANGELOG : https://github.com/ForumHFR/redface [...] ANGELOG.md
- Rapport d'audit complet : https://github.com/ForumHFR/redface [...] dit-v04.md
- Specs : https://forumhfr.github.io/redface2

Retours appréciés comme d'hab

Post par Claude Opus 4.7

intéressant, voilà mes retours :

- reco de passer sur compose navigation 3. même si c'est encore marqué comme alpha, c'est toujours très stable dans les api android et ça apporte pas mal de trucs sympas. vu que l'appli sera pas en prod de suite autant partir sur l'api de navigation du futur
- je reconnais que okhttp est ce qui se fait de mieux mais quid de ktor pour le futur côté kmp ? je comprends le côté overkill mais à quel point okhttp fait peut être parti du passé si pas orienté kmp
- est ce que tink est pas overkill pour simplement stocker des credentials du forum ? Data store pour les infos peu sensibles et keystore pour le stockage du mdp ca pourrait suffire non ? D'ailleurs comment est protégée la clé de chiffrement keystore pour le mot de passe ? On demande un code à l'utilisateur ou la biométrie ? Je veux bien une explication détaillée de la stratégie de stockage du mot de passe
- comment gérer les images selon les résolutions ? je lis qu'il y a une stratégie d'optimisation sur les images affichées. Mais souvent sur le forum les images sont données brutes et elles peuvent être très lourdes ? L'idée serait de precharger et faire une version spéciale à afficher ? Il faudrait lui donner des pages du topic image pour voir comment il imagine afficher ce genre de topic

mais globalement ça commence à avoir de la gueule ces specs

j'en discutais avec opus 4.7, je lui ai fait faire une réponse sous forme d'issue : https://github.com/ForumHFR/redface2/issues/23 (rien tranché) mais là je fatigue
 
1. à voir ouais, faut regarder la roadmap et voir si y'a des breaking changes conséquents et si ça peut aussi changer l'alpha et la stable
2. c'est à voir aussi, kmp c'est pas encore décidé mais ça va plutôt vers le non, on peut monter uner reflexion sur okhttp 4 ou 5 vs ktor mais pour moi je dois faire des recherches en premier
3. oui overengineered, j'y ai pensé aussi à la lecture, on va faire au plus simple => et aussi faire une pass pour détecter les trucs overkills
4. jsais pas mais ça m'a l'air overkill aussi, moi ça me fait chier de rajouter des traitementes surtout si y'a des dizaines de tofs à faire. j'aurai aimé un truc qui diffère entre 4G mode éco et wifi à fond mais de toute façon on peut itérer et je pense que partir du simple ça le fera  
 
 
si t'as des billes sur comment forcer l'archi via tests je suis preneur

 
Pourquoi les skills sont-ils toujours dans `/.claude/skills/` plutôt que `/.agents/skills/` si le but est la compatibilité multi-client ?
J'ai pas encore testé le `/.agents/skills/` mais c'est annoncé comme pris en charge par Claude.
 
Cf https://agentskills.io/client-imple [...] re-to-scan

réponses intéressantes et effectivement faudra trancher à un moment donné
 
et pour le safeguard de l’archi par des tests j’ai jamais fait mais l’outil proposé j’en avais entendu parler et pourquoi pas en vrai. après ça me paraît overengineered vu qu’on sera pas sur un gros projet open source. fin peut être que des gens proposeront des pr avec llm mais ça me paraît peu probable les instructions pour agent devraient sûrement suffire

Ça a l'air balèze tout ça  

@XaTriX je me permet de commenter car tu m'as demandé mon avis sur le topic dev.
 
Juste quelques précisions:

• Je suis dev backend/cloud/db
• Je fais tout en anglais, même les projets persos, les outils marchent beaucoup mieux comme ça
• J'aime pas faire des UI, je suis nul pour ça, je déteste le fait qu'il y a un nouveau paradigme/framework tous les 6 mois
• J'aime pas le management et les specs, code is life
• J'aime pas être dépendant d'un outil, je préfère les trucs standards

 
Donc pour mes projets, je veux pas avoir a mettre/dupliquer des skills/mcp/AGENTS dans des endroit différents. Je veux pas de superpowers, ou autres trucs spécifiques.
 
J'ai donc un AGENTS.md spécifique qui pointe vers des sous-fichiers:
 

 
De la Kiro/Cusor/etc. marchent pareil, ils savent tous lire le AGENTS.md et se débrouiller ensuite. J'ai pas de skills, mais juste des commandes précises.
 
 
J'écris des specs/spikes/recherchers bien sur, mais je laisse pas le coté recherche dans un repo, ça vieille très vite. Une fois une stack choisie, pas besoin de garder le reste dans la doc.
 
Perso pour l'app Redface 2 une roadmap sur 12 mois me parait long . J'aurais pris le repo de la meilleur app, demandé à l'agent de faire une spec dessus et dit de réimplémenté la même chose avec la nouvelle stack, ajouté build, linters, scan de sécu, UTs/ITs et CI et hop v0.

Oui j'ai vu passer, ça reste une convention pas encore standardisé si je me trompe pas mais c'est à voir. Il me semble que tout est référencé dans SKILLS.md sur la racine mais on peut refaire une passe pour voir si on peut améliorer
 
Tu peux cloner et checker comment ton LLM répond pour voir, si jamais

le postage de fennec entre temps

edit: répondrais plus tard

je pense qu'on fera pas de kmp et à voir si ktor a du sens sans prévoir de kmp vs okhttp4 ou 5
 
archi test ça me tente pour éviter les dérives de LLM, ça permettra de pas filer à Corran des review de code qu'on pourrait déjà traiter en amont
 
human in the loop mais on lui facilite le taf !

Merci pour ton retour construit Je note tout ça, Opus aussi, et on va essayer de faire un truc propre. N'hésite pas à lire la codebase, même partiellement, pour donner ton avis sur l'organisation.  
 
Tu connais specs.md ou autre framework/specs pour LLM ? On en a parlé à une époque mais j'ai jamais trop regardé. Je peux demander à Opus bien sur.
 
Mais d'abord il faut que je fasse une passe pour virer les trucs overkill/overengineeré/peuvent évoluer plus tard/encombrent. Puis petite passe sur les skills. Et peut être un coup de propre dans les issues.  
 
Ensuite j'ai envie de lui demander une phase0-alpha-lamortkitue pour commencer sur la CI & co (voir phase 0)

Il devrait déjà être fini ce soft depuis 10 jours

Voilà ce que m'ont dit GPT 5.4/grok 4.2 thinking /Gemini 3.1 pro

--------------
Oui, mais pas juste un Specs.md unique.

Si je démarre un repo Android proprement aujourd’hui, j’utiliserais un petit framework de repo/documentation/qualité, très léger au début, qui grossit avec le projet.

Ce que je ferais

1. Docs-as-code, en Markdown, dans le repo
Structure simple :

/
├─ README.md
├─ docs/
│  ├─ product/
│  │  └─ vision.md
│  ├─ specs/
│  │  ├─ 001-onboarding.md
│  │  └─ 002-login.md
│  ├─ architecture/
│  │  ├─ overview.md
│  │  ├─ modules.md
│  │  └─ diagrams/
│  ├─ adr/
│  │  ├─ 0001-use-compose.md
│  │  ├─ 0002-use-hilt.md
│  │  └─ 0003-feature-modularization.md
│  └─ testing/
│     └─ strategy.md
├─ app/
├─ core/
├─ feature/
└─ .github/
   ├─ pull_request_template.md
   └─ workflows/

Les fichiers vraiment utiles

README.md
Le strict minimum pour lancer le projet :

- stack technique
- version Android/Kotlin/Gradle
- comment build/run/test
- structure des modules
- conventions principales

docs/product/vision.md
Le “pourquoi” :

- problème à résoudre
- cible utilisateur
- objectifs
- non-objectifs
- métriques de succès

docs/specs/*.md
Là oui, des specs, mais par feature, pas un gros fichier monolithique qui finit mort.

Template simple :

Feature: Login

Contexte
Pourquoi cette feature existe

Objectif
Ce qu’on veut permettre

Hors scope
Ce qu’on ne fait pas maintenant

User flows
- L’utilisateur ouvre l’écran
- Il saisit email/mot de passe
- Il voit les erreurs inline
- Il est redirigé après succès

États UI
- idle
- loading
- success
- error

Sources de données
- API /auth/login
- cache token local

Cas limites
- pas de réseau
- credentials invalides
- token expiré

Critères d’acceptation
- ...
- ...

Instrumentation / analytics
- login_started
- login_success
- login_failed

Tests à prévoir
- unit
- integration
- ui

docs/architecture/overview.md
J’y mettrais :

- architecture choisie
- flux de données
- règles de dépendance
- conventions de packaging
- pattern de state management

Pour Android moderne, je partirais souvent sur :

- Kotlin
- Jetpack Compose
- ViewModel + StateFlow
- Repository pattern
- Use cases seulement si le domaine le justifie
- architecture en couches simple : ui / domain / data
- modularisation par feature si le projet n’est pas trivial

docs/adr/
Très sous-estimé.  
Les ADR (Architecture Decision Records) servent à documenter pourquoi vous avez choisi :

- Compose vs XML
- Hilt vs Koin
- Room vs SQLDelight
- Retrofit/Ktor
- monorepo simple vs modularisé
- MVI/UDF vs MVVM classique

Format ADR minimal :

ADR-0001: Use Jetpack Compose

Status
Accepted

Context
Nouveau projet Android, besoin de rapidité d’itération UI

Decision
Utiliser Jetpack Compose pour toutes les nouvelles UI

Consequences
+ UI plus déclarative
+ meilleure cohérence avec Android moderne
- courbe d’apprentissage
- screenshot tests à cadrer

Côté “tests archi / qualité”, je ferais quoi ?

2. Une stratégie de test claire
Pas “on verra plus tard”.

docs/testing/strategy.md
Je pose noir sur blanc :

- ce qu’on teste à chaque niveau
- où utiliser des fakes vs mocks
- ce qui est obligatoire en PR
- quels tests pour quelles couches

Exemple :

Unit tests
Pour :

- ViewModels
- use cases
- mappers
- validateurs
- logique métier pure

Outils courants :

- JUnit
- kotlinx-coroutines-test
- Turbine pour tester les Flow
- MockK ou, mieux, des Fake quand possible

Integration tests
Pour :

- Room
- Retrofit / repositories
- serialization
- cache/network orchestration

Outils :

- MockWebServer
- Room in-memory DB
- Hilt test modules si besoin

UI tests
Pour :

- flux critiques seulement
- navigation
- états importants

Outils :

- Compose UI Test
- Espresso si views legacy

Screenshot tests
Très utile avec Compose :

- Paparazzi ou Shot

Ça évite pas mal de régressions visuelles.

3. Des “tests d’architecture” au sens strict
Si tu parles de vérifier les règles d’architecture automatiquement, je mettrais :

Option Kotlin/Android moderne : Konsist
Très bien pour imposer des conventions du genre :

- tous les ViewModel finissent par ViewModel
- les classes RepositoryImpl sont en data
- feature: ne dépend pas d’autres feature:
- ui ne dépend pas directement de network
- chaque écran a un UiState

C’est typiquement le genre d’outil que je mettrais si le projet doit rester propre.

En complément
- Detekt
- ktlint ou Spotless
- Android Lint

Ça couvre style, code smells, erreurs Android spécifiques.

Mon “framework” concret pour démarrer un repo Android

Minimal mais sérieux
Si je veux démarrer vite sans over-engineering :

Docs
- README.md
- docs/specs/001-mvp.md
- docs/architecture/overview.md
- docs/testing/strategy.md
- docs/adr/0001-tech-stack.md

Tooling
- Detekt
- ktlint ou Spotless
- Android Lint
- JUnit
- kotlinx-coroutines-test
- Turbine
- MockWebServer
- Compose UI Test
- CI GitHub Actions

CI
Je ferais échouer la PR si :

- build KO
- lint KO
- detekt KO
- unit tests KO

Et plus tard :
- screenshot tests
- instrumentation tests
- coverage thresholds si nécessaire

Niveau archi Android, je partirais sur quoi ?

Pour un projet “normal”
Je recommande :

- feature modules si l’app n’est pas minuscule
- un core:designsystem
- un core:network
- un core:database
- un core:testing
- un feature:login, feature:home, etc.

Exemple :

app
core:common
core:ui
core:designsystem
core:network
core:database
core:testing
feature:login
feature:home
feature:settings

Avec règle :
- feature: dépend de core:
- jamais l’inverse
- pas de dépendance entre features sauf vrai besoin

Est-ce que Specs.md suffit ?
Mon avis : non.

Un seul Specs.md :

- devient vite fourre-tout
- mélange produit, technique et backlog
- devient obsolète rapidement
- ne capture pas les décisions d’architecture

Donc :
- oui à des specs markdown
- non à un unique Specs.md comme seule source de vérité

Je ferais plutôt :

- 1 vision produit
- 1 spec par feature
- 1 doc d’architecture
- des ADR
- 1 stratégie de test

Si tu veux un truc encore plus structuré

Tu peux combiner :

- Specs de feature → quoi construire
- ADR → pourquoi ce choix technique
- C4 model → comment documenter l’architecture
- Test pyramid → comment tester
- CI gates → comment faire respecter tout ça

C’est probablement le meilleur “framework” global pour un repo Android.

Références très utiles
Je regarderais clairement :

- Android Guide to App Architecture  
  https://developer.android.com/topic/architecture
- Android Testing  
  https://developer.android.com/training/testing
- Now in Android (excellent repo d’exemple)  
  https://github.com/android/nowinandroid

Ma reco finale, ultra-pratique
Si tu me demandes “je fais quoi lundi matin ?” :

1. crée le repo
2. ajoute README.md
3. ajoute docs/specs/001-mvp.md
4. ajoute docs/architecture/overview.md
5. ajoute docs/adr/0001-tech-stack.md
6. ajoute docs/testing/strategy.md
7. installe Detekt + ktlint/Spotless + Android Lint
8. mets JUnit + Turbine + MockWebServer + Compose UI Test
9. configure la CI

Ça te donne un repo propre sans tomber dans l’usine à gaz.

Si tu veux, je peux te générer un starter kit complet :
- arborescence de repo
- template de spec.md
- template d’ADR
- testing-strategy.md
- build.gradle.kts avec les libs de base Android modernes.

Alors c'est peut être mieux de copier dans un gist ou share la réponse des LLM mais c'est pas mal.
Là, la passe sur l'overkillage est tranchante https://github.com/ForumHFR/redface2/issues/24 (je ne vais pas tout appliquer)

Encore presque 2 semaines à jouer avec le repo avant que ça code selon la roadmap (qui est là pour le fnu surtout)

ok

On attend GPT 5.5 codex

J'ai beaucoup plus de quota Claude

Après je trouve que sa vision est plus propre, plus direct, stack plus propre même si ça reste encore un peu overkill (et ce qu'a pondu Claude depuis quelques jours clairement trop)

Après faut voir ce que d'autres en pensent

Je proteste: Grok c'est dehors! Déjà là question étique c'est moyen mais alors si on rajoute Grok...

Opus me dit que je fais du spec-théatre. Ce batard. On change pour Grok

Je te rassure on va pas l'utiliser, c'était juste l'occasion de le tester une fois voire ce qu'il racontait
Les 3 étaient d'accord sur la même chose, ça permet juste de confirmer d'autant plus que ce que GPT et Gemini disait était valable

Impossible de faire confiance à Grok donc pour moi c'est une réponse inutilisable même si elle confirme les deux autres. J'y connais rien en vibe coding mais je crois qu'il y a moyen d'avoir 3 IA différentes en dehors de Grok.

Désolé d'etre rude mais il y a un moment où il faut arrêter. En plus de tout ce que l'IA détruit, Grok rajoute encore les fake news, le dénudage de gamin et toute la folie de Musk et sa clique.

C'est pas le topic pour le débat LLM  
De toute façon il yaura review des PR pour pas laisser passer de la merde en plus de la CI blindée

+1

Elon a piqué ta copine ou bien?  
J'apprécie pas Elon loin de là mais calme sur le sujet, on a compris hein

Absolument, ce n'est pas mon but je met juste un red flag . L'application est pour tout le monde donc je pense qu'on peut tous diriger un minimum ce que l'on souhaite à sa façon.

J'ai bien vu pour la CI et tout, ça ne change pas le fait que l'utilisation de Grok est une absurdité et un sérieux souci d'éthique.

Non non juste du bon sens

 
Tout ca pour afficher 2 messages et 3 Topics ???
 
Les temps on changés  

Bizarre cette phrase. Firefox par exemple, c'est pour tout le monde. Pourtant tout le monde ne vient pas diriger le projet.