🌊 Rapport d'analyse CodeWave

Tour 1 : Analyse initiale

• PROBLÈME DE SÉPARATION DES PRÉOCCUPATIONS: 90% du diff (+48/-46 lignes) est du reformatage cosmétique. Le correctif fonctionnel réel représente seulement +6/-6 lignes. Cela viole le principe de commit atomique et rend le rollback sélectif impossible.
• AUCUN TEST AUTOMATISÉ: La logique de filtrage GraphQL (setVisibilityFilter, setTypeFilter, regroupement name) est complexe et repose uniquement sur des tests manuels. Chaque modification future de ces filtres risque d'introduire des régressions non détectées.
• SÉCURITÉ: L'interpolation de chaînes dans les requêtes GraphQL (ex: {createdAt: {gte: "${filters.documentDate.start}T00:00:00.000Z"}}) est vulnérable à l'injection et devrait utiliser des variables GraphQL paramétrées.
• MANQUE DE MÉTRIQUES UTILISATEUR: Aucune donnée sur le nombre d'utilisateurs affectés par ce bug, la fréquence d'utilisation de la recherche avec exclusion, ou l'impact sur les opérations métier. Sans cela, la priorisation est arbitraire.
• FORMATAGE INCOHÉRENT: Le mélange espaces/tabulations et guillemets simples/doubles dans le code existant indique l'absence de configuration Prettier/ESLint uniforme. Ce correctif cosmétique partiel augmente la dette technique plutôt que de la réduire.

• Dette technique majeure (6h) : La construction de requêtes GraphQL par template literals avec ternaires imbriquées sur 3 niveaux est fragile, difficile à déboguer et source de régressions - une refactorisation vers des requêtes typées avec variables GraphQL est nécessaire
• Absence totale de tests automatisés (testCoverage: 2/10) sur allDocumentsQuery qui est le point d'entrée unique pour la recherche de documents - risque élevé de régression silencieuse
• Séparation des préoccupations insuffisante : les changements cosmétiques de formatage (~32 lignes) sont mélangés avec le correctif fonctionnel (~4 lignes), rendant l'identification du bug et le rollback plus difficiles

• Bug critique masqué par le reformatage : le regroupement des filtres `name` sous `or` est le seul changement fonctionnel (~6 lignes), mais le diff montre +54/-52 lignes principalement cosmétiques - séparer les commits est une pratique essentielle pour la traçabilité
• Risque d'injection dans `setVisibilityFilter` : l'interpolation `{in: [${coproRoles?.map((v) => `"${v}"`)}]}` ne valide pas les entrées - un rôle contenant des guillemets ou accolades corromprait la requête GraphQL
• Absence totale de tests pour `setVisibilityFilter` et `setTypeFilter` : ces fonctions contiennent des ternaires imbriqués et de la concaténation dynamique qui devraient être testées unitairement avec des cas limites (tableaux vides, valeurs nulles, caractères spéciaux)
• Complexité structurelle non gérée : 3 niveaux d'imbrication `and`/`or` construits par template literals rendent la validation syntaxique impossible avant l'exécution - une approche par construction d'objet avec variables GraphQL serait plus sûre et maintenable
• Le reformatage espaces→tabulations et guillemets simples→doubles sans valeur fonctionnelle pollue l'historique git et rend les `git blame` futurs moins utiles

• 0 test unitaire pour setVisibilityFilter - interpolation non paramétrée coproRoles permet injection GraphQL non validée
• 0 test unitaire pour setTypeFilter - construction dynamique GraphQL sans couverture
• 0 test d'intégration pour allDocumentsQuery - données financières/juridiques de copropriété exposées sans validation automatisée
• Vulnérabilité injection GraphQL : {in: [${coproRoles?.map((v) => `"${v}"`)}]} sans échappement - rôle malveillant corrompt la requête
• Edge cases non couverts : coproRoles=[], null, undefined génèrent des filtres GraphQL malformés

• Pattern string-based query building : setVisibilityFilter et setTypeFilter retournent des fragments GraphQL interpolés sans validation — une erreur d'accolade ou de guillemet provoque un crash à l'exécution uniquement
• Complexité cognitive des ternaires imbriqués : la construction conditionnelle de filtres via chaînes de ternaires rend le flux de données opaque et le débogage difficile
• Absence de typage TypeScript sur les paramètres filters et coproRoles — les propriétés attendues ne sont vérifiées qu'à l'exécution
• Aucun test unitaire pour setVisibilityFilter et setTypeFilter, fonctions critiques construisant des requêtes dynamiquement
• Le correctif de regroupement des filtres name traite le symptôme mais pas la cause racine : l'absence d'un query builder typé ou de fragments GraphQL dédiés

Tour 2 : Préoccupations et questions

• Correctif fonctionnel (~6 lignes) noyé dans 48 lignes de reformatage - viole le commit atomique, rend le rollback sélectif impossible et pollue l'historique git.
• Vulnérabilité d'injection GraphQL dans setVisibilityFilter : interpolation non paramétrée de coproRoles exposant des données financières/juridiques de copropriété.
• Absence totale de tests sur allDocumentsQuery (point d'entrée unique recherche documents) et fonctions setVisibilityFilter/setTypeFilter - risque de régression silencieuse.
• Complexité structurelle excessive : ternaires imbriqués 3 niveaux construisant des chaînes GraphQL rendent la logique opaque et le débogage difficile.
• Aucune métrique utilisateur pour prioriser ce bug - nombre d'utilisateurs affectés et fréquence d'utilisation de la recherche avec exclusion non documentés.

• Commit non-atomique dans copro/stores/documents/data.ts : correctif fonctionnel (~6 lignes, regroupement or des filtres name) noyé dans reformatage cosmétique (~48 lignes) - git blame et rollback sélectif impossibles
• Injection GraphQL via interpolation non échappée : {in: [${coproRoles?.map((v) => "${v}"`)}]} - un rôle contenant guillemets ou accolades corrompt la requête, risque de crash et fuite de données
• Absence totale de tests pour setVisibilityFilter, setTypeFilter et allDocumentsQuery - ternaires imbriqués sur 3 niveaux sans couverture unitaire (cas limites : tableaux vides, null, caractères spéciaux)
• Complexité structurelle excessive : 3 niveaux and/or construits par template literals avec ternaires - cyclomatic complexity ~8+, erreur d'accolade détectable uniquement à l'exécution
• Reformatage partiel sans config Prettier/ESLint documentée - standardisation ponctuelle qui sera écrasée par le prochain développeur sans outil différent

• Template literals interpolés pour construction GraphQL (ex: `{createdAt: {gte: "${filters.documentDate.start}"}}`) — fragile, sans validation syntaxique pré-exécution, risque d'injection dans setVisibilityFilter via interpolation de coproRoles
• Ternaires imbriquées sur 3 niveaux dans la construction de filtres and/or — complexité cognitive élevée (NPATH > 8), flux de données opaque, débogage difficile
• Absence de typage TypeScript sur `filters` et `coproRoles` — contrat d'interface implicite, erreurs de propriétés non détectées à la compilation
• Violation du commit atomique — reformatage cosmétique (+48/-46 lignes) mélangé au correctif fonctionnel (~6 lignes), rendant git blame et rollback sélectif impossibles
• Zéro test unitaire pour setVisibilityFilter et setTypeFilter — fonctions critiques construisant des requêtes dynamiques sans validation automatisée, risque élevé de régression silencieuse

Tour 3 : Validation

• Correctif 6 lignes noyé dans 48 lignes reformatage dans copro/stores/documents/data.ts - commit non-atomique empêche rollback sélectif et pollue historique git
• Injection GraphQL dans setVisibilityFilter : interpolation {in: [${coproRoles?.map(v => `"${v}"`)}]} sans échappement - risque exposition données financières/juridiques copropriété
• Zéro test unitaire sur allDocumentsQuery, setVisibilityFilter, setTypeFilter - régression silencieuse probable sur recherche documentaire
• Aucune métrique utilisateur pour quantifier impact bug - nombre utilisateurs affectés et fréquence recherche avec exclusion non documentés
• Complexité NPATH>8 : ternaires 3 niveaux + template literals GraphQL dans copro/stores/documents/data.ts rendent débogage coûteux

• Reformatage nécessaire vs cosmétique : l'indentation incohérente masquait les 3 niveaux d'imbrication and/or, rendant le bug de regroupement OR structurellement invisible - la réindentation était un prérequis de diagnostic, pas un choix esthétique
• Risque d'injection GraphQL surévalué : coproRoles est dérivé de claims JWT décodés côté serveur dans un composant 'use server' (ligne 1), les valeurs sont des rôles prédéfinis ('syndic', 'coproprietaire'), pas des entrées utilisateur libres
• Dette de tests préexistante : l'absence de tests pour setVisibilityFilter/setTypeFilter/allDocumentsQuery existait avant ce PR et devrait être adressée dans un PR dédié, pas bloquer ce correctif de bug

• Commit non-atomique : 48 lignes cosmétiques mélangées à 6 lignes fonctionnelles dans copro/stores/documents/data.ts - git blame pollué, rollback sélectif impossible
• Injection GraphQL : {in: [${coproRoles?.map((v) => `"${v}"`)}]}} interpole valeurs sans paramétrage - risque modéré (source auth) mais anti-pattern fragile causant crash si rôle malformé
• Absence totale de tests pour setVisibilityFilter, setTypeFilter, allDocumentsQuery - cas limites non couverts (tableaux vides, null, caractères spéciaux)
• Complexité cognitive excessive : ternaires imbriqués 3 niveaux, NPATH>8, template literals construisant requêtes GraphQL dynamiques
• Absence de typage TypeScript sur paramètres destructurés {token, ppeId, coproId, coproRoles, filters, pageCount, search} - erreurs compilation non détectées

• Commit non-atomique dans copro/stores/documents/data.ts : correctif fonctionnel (~6 lignes, regroupement or des filtres name) mélangé au reformatage cosmétique (~48 lignes, guillemets et indentation) — git blame et rollback sélectif impossibles
• Vulnérabilité d'injection GraphQL dans setVisibilityFilter (~ligne 82) : interpolation non paramétrée de coproRoles dans `{in: [${coproRoles?.map((v) => `"${v}"`)}]}` — un rôle contenant guillemets ou accolades corrompt la requête, risque de crash runtime et fuite de données financières/juridiques
• Complexité structurelle excessive (lignes 73-95) : ternaires imbriquées sur 3 niveaux construisant des chaînes GraphQL par template literals — NPATH > 8, complexité cyclomatique ~8+, erreurs d'accolades détectables uniquement à l'exécution, aucune validation syntaxique pré-exécution
• Absence de typage TypeScript sur les paramètres filters, coproRoles et search (lignes 8-15) — propriétés comme filters.documentShareType.private non vérifiées à la compilation, fautes de frappe passant silencieusement
• Zéro test unitaire pour setVisibilityFilter, setTypeFilter et allDocumentsQuery — fonctions critiques construisant des requêtes dynamiques sans validation automatisée, cas limites non couverts (tableaux vides, null, caractères spéciaux)