Revues de code

• Repos découverts : 32
• Repos avec commits dans les dernières 24h : 1
• Repo reviewé : impeccable (/home/ubuntu/.claude/plugins/marketplaces/impeccable)
• Total commits reviewés : 28
• Validation effectuée par le subagent : tests Node ciblés live passés (81 tests OK)
• Limite de validation : bun absent, donc bun run test et tests bun:test non exécutés.

---

• 9a5d0e7 fix(live): switch live-poll to execFileSync, validate ids strictly (#124)
• 7e0ce5e ci: add Tessl skill review on SKILL.md changes (#74)
• 18fa503 fix: normalize quoted user-invocable frontmatter (#87)
• 04709ea security: use JSON.stringify for selector escaping in devtools panel (#93)
• efedf2d Merge pull request #97 from Gujiassh/fix/community-section
• f67add2 Merge pull request #120 from vinaypokharkar/feature/qoder-support
• 6b507e0 Release impeccable skill v3.0.5
• c1e1104 Merge pull request #118 from pbakaus/feat/live-jsx-wrap-and-carbonize
• 1f760af fix(live): expandReplaceRange handles multi-line self-closing JSX <div />
• 8660d3a fix(live): wrap shape-of-output bugs from second Bugbot review
• 11dfad8 fix(live): CSP-meta patch+revert preserves space before self-closing /
• a701ee6 fix(live): wrap preserves relative indent of multi-line picked elements
• 99e6837 fix(live): JSX accept/discard restores at original indent (Bugbot review)
• fdb9e7c fix(live): screenshot overlay no longer flashes solid black during loading
• 9ec9043 fix(live): textContent disambiguation handles missing inter-element whitespace
• 54d9f05 fix(live): land valid TSX through wrap → preview → accept → carbonize
• 638af20 Document the release workflow in CLAUDE.md and AGENTS.md
• 5881a08 Thank @dergachoff for #113 in v3.0.4 changelog
• 27af49f Strip leading whitespace in release-notes markdown extraction
• bf2bc55 Fold v3.0.3 changelog into v3.0.4
• a923346 Add release tooling and bump CLI to 2.1.8
• c812d76 feat: wire qoder into the download API allowlist
• 7cfa775 fix: parseFrontmatter handles CRLF line endings
• 9a76c7b fix: include qoder in normalizeForHash provider regex
• c6ca721 docs: add Qoder to README install and supported-tools sections
• 4f66eb9 feat: add Qoder harness support (closes #76)
• 5f5e2b0 Release impeccable skill v3.0.4
• 54f6ccf codex in auto-review became way too autonomous - significantly harden craft/shape flows

---

1. Sécurité CI — critique moyen/haut : 7e0ce5e ajoute tesslio/skill-review@main avec pull-requests: write. Action tierce non pinée à un SHA/tag immuable → risque supply-chain. Recommandation : pinner à un SHA + Dependabot/Renovate.
2. Sécurité release tooling — moyen : a923346 construit plusieurs commandes shell via interpolation (git tag, gh release, branches/tags). Recommandation : valider strictement la version semver/tag et préférer execFileSync/argv.
3. Supply-chain / régression lockfile — moyen : 9a5d0e7 mélange un fix sécurité live avec une grosse régénération pnpm-lock.yaml ajoutant/actualisant beaucoup de dépendances. À séparer et auditer.
4. Live wrap — risque fonctionnel restant : les fallbacks “first match” quand --text est trop court/dynamique peuvent encore modifier le mauvais sibling, surtout sur composants répétés dynamiques.

• Positif : renforce fortement les gates produit/shape/image avant mutation, limite l’autonomie excessive des agents.
• Risque : instructions très strictes peuvent bloquer des harness sans outil question structuré ou image-gen.
• Suggestion : ajouter tests snapshot de transformation provider pour éviter divergence de wording entre harnesses.

• Positif : release cohérente avec versions/changelog.
• Risque faible : beaucoup de fichiers générés ; vérifier reproductibilité via bun run build.
• Tests manquants : non vérifiable ici sans Bun.

• Positif : intégration large : provider config, placeholders, CLI detection, docs, artefacts .qoder.
• Risque : énorme ajout généré (.qoder) difficile à reviewer manuellement ; le config_file: AGENTS.md mérite validation avec Qoder.
• Suggestion : ajouter test explicite provider Qoder + build snapshot minimal.

• Positif : docs alignées avec provider.
• Risque faible : uniquement documentation.

• Positif : corrige faux positifs “update available”.
• Amélioration : centraliser la liste providers pour éviter oublis entre PROVIDER_DIRS, regex hash, API download.

• Positif : vrai fix Windows ; évite double frontmatter.
• Risque : parser YAML maison reste limité.
• Tests : semble couvert par utils, mais non exécuté ici car Bun absent.

• Positif : API alignée avec nouveau provider + tests.
• Risque faible : mapping simple .qoder.

• Positif : release script utile : dirty tree, pushed HEAD, changelog, artifacts.
• Problème sécurité/robustesse : commandes shell interpolées depuis version/branch/tag. Même si usage maintainer, valider semver et utiliser execFileSync.
• Suggestion : tests unitaires htmlToMarkdown, dry-run, cas changelog absent, tag existant.

• Positif : simplifie changelog.
• Risque faible : docs uniquement.

• Positif : corrige rendu GitHub Release.
• Suggestion : ajouter test htmlToMarkdown pour éviter régression.

• Positif : attribution.
• Risque nul : contenu public uniquement.

• Positif : workflow release clarifié dans CLAUDE.md/AGENTS.md.
• Risque faible : docs seulement.

• Positif : gros fix structurel JSX/TSX : wrapper single-root, CSS template stripping, disambiguation --text, fixture E2E.
• Bonnes pratiques : tests unitaires + fixture Vite TSX.
• Risque : logique regex/ligne fragile pour JSX complexe ; fallback first-match peut encore toucher mauvais élément dynamique.
• Suggestion : envisager parse AST JSX à moyen terme.

• Positif : corrige cas réel textContent concaténé sans espace.
• Risque : comparaison compacte peut créer faux positifs sur textes proches.
• Tests : bon test ciblé.

• Positif : corrige piège rgba(0,0,0,0) truthy ; amélioration UX visible.
• Tests : static-source guard pragmatique.
• Amélioration : idéalement exposer helper testable plutôt que test regex source.

• Positif : corrige dérive d’indentation introduite par wrapper JSX interne.
• Tests : bons tests accept/discard.
• Risque faible : dépend toujours de regex ligne.

• Positif : fix complémentaire important ; évite corruption esthétique/syntaxique des sous-éléments.
• Qualité : bonne extraction minLeadingSpaces.
• Suggestion : couvrir tabs/mixed indentation si projets concernés.

• Positif : round-trip byte-for-byte préservé, important pour fichiers utilisateur.
• Tests : bons tests insertAfter + CSP self-closing.
• Risque faible : regex meta reste simple, mais suffisante pour cas ciblé.

• Positif : corrige sentinel short-text et endLine multi-ligne.
• Tests : deux tests bien ciblés.
• Risque : short-text fallback first-match reste dangereux mais volontaire.

• Positif : corrige bug de corruption sérieux dans expandReplaceRange.
• Tests : couvre sibling adjacent + self-closing multiline.
• Suggestion : parser JSX/HTML réel serait plus robuste que regex.

• Positif : merge cohérent des fixes live précédents.
• Risque : gros volume généré multi-provider ; vérifier build reproductible.
• Note : logique détaillée couverte dans 54d9f05 → 1f760af.

• Positif : release après fixes live, version/changelog.
• Risque faible : release générée ; dépend de build non vérifié ici faute de Bun.

• Positif : intègre Qoder après fixes allowlist/hash/CRLF.
• Risque : très gros ajout généré ; préférer review source + build artifact diff.
• Note : détails dans 4f66eb9, 9a76c7b, 7cfa775, c812d76.

• Positif : README enrichi.
• Risque faible : lien Twitter non cliquable si pas URL complète ; mineur.

• Positif sécurité : très bon fix contre injection JS via chrome.devtools.inspectedWindow.eval.
• Manque : aucun test ajouté pour selector malveillant.
• Suggestion : test statique ou unitaire garantissant usage document.querySelector(${JSON.stringify(...)}).

• Positif : corrige coercition booléenne ciblée sans casser les strings quotées.
• Risque faible : parser YAML maison ne gère pas tous les cas d’échappement.
• Tests : ajout pertinent, mais non exécutable ici sans Bun.

• Positif : améliore qualité PR sur SKILL.md.
• Problème critique : action tierce tesslio/skill-review@main non pinée avec permission pull-requests: write.
• Suggestion : pinner à un SHA/version, limiter permissions si possible, documenter confiance/action.

• Positif sécurité : remplace execSync(string) par execFileSync(argv), valide id et variantId. Très bonne correction.
• Tests : régressions shell metachar couvertes dans live-server.test.mjs.
• Risque : lockfile massif dans même commit brouille la review et modifie la surface supply-chain.
• Suggestion : utiliser process.execPath au lieu de 'node'; séparer lockfile en commit dédié.

---

• node --test tests/live-wrap.test.mjs tests/live-accept.test.mjs tests/live-inject.test.mjs tests/live-server.test.mjs tests/live-browser-regression.test.mjs → 81 tests OK.
• bun run test impossible : bun: command not found.
• tests/lib/utils.test.js non exécutable sous Node car dépend de bun:test.

Aucun fichier du repo reviewé n’a été modifié. Le présent rapport a été sauvegardé dans Obsidian.

• Repos actifs : 2
• Total commits : 8 (7 dans flatty, 1 dans funding-rates-dashboard)
• Tests : 592/592 passés dans flatty ✅

---

Hash	Message	Fichiers touchés
c05b8be	fix: scoring audit iteration 1/5 (template A)	criteria-validator.ts, criterion-scorers.ts, criterion-scorers-geo.test.ts
6e21cff	fix: scoring audit iteration 2/5 (template B)	criteria-validator.ts, prompt-parser-scenarios.test.ts
afc3c39	chore: swap OpenRouter default model to mistralai/mistral-small-2603	CLAUDE.md, parsing/eval/models.ts, parsing/providers/openrouter.ts, openrouter.test.ts
533db69	fix: scoring audit iteration 3/5 (template C)	criteria-validator.ts
dc67c39	fix: scoring audit iteration 4/5 (template D)	criteria-validator.ts
6c665b9	fix: scoring audit iteration 5/5 (template A revisit)	criteria-validator.ts
8542226	feat: Add embedding support for semantic search	.env.local.example, src/lib/embeddings/* (6 fichiers), criteria-validator.ts, eval/models.ts, criterion-scorers.ts, engine.ts, supabase/migrations/019_add_listings_embeddings.sql

c05b8be — scoring audit iteration 1/5 (template A)

Résumé : corrige deux bugs du pipeline de scoring : (a) la contrainte de temps de trajet maxMinutes était ignorée quand les données OTP/Google manquaient ; (b) un seuil DPE explicite dans le prompt ("pas en dessous de D") n'était pas respecté, provoquant un rejet injuste des biens au seuil.

Points positifs ✅

• Logique défensive bien documentée ; les commentaires justifient les constantes (0.35 km/min).
• Tests très complets sur le geo-scorer (scénario loin = score 0, scénario proche = score > 0.9).
• Le regex DPE est "gated" par un contexte lexical pour éviter les faux positifs sur "surface minimum 40m²".

Bugs potentiels / Risques ⚠️

• DPE_THRESHOLD_REGEX pourrait matcher "minimum B" dans un contexte scolaire si le prompt contient aussi "classe" (ex: "appartement classe minimum B" n'a pas de sens immobilier, mais le gating /\bclasse\b/ risque de passer). Très marginal.
• ESTIMATED_TRANSIT_KM_PER_MIN = 0.35 est hardcodé. En province (voiture obligatoire) ou à vélo, cette vitesse moyenne est inadéquate. Le paramètre pourrait être contextualisé par ville ou mode de transport.

Suggestions de refactoring 🔧

• Extraire detectDpeThresholdGrade et applyExplicitDpeThreshold dans un module dpe-parser.ts dédié. criteria-validator.ts dépasse les 750 lignes.
• Rendre ESTIMATED_TRANSIT_KM_PER_MIN configurable via une env var ou un paramètre par profil utilisateur.

---

6e21cff — scoring audit iteration 2/5 (template B)

Résumé : corrige trois problèmes de parsing : (a) transactionType mal classé "rent" sur des prompts d'achat ; (b) villes métropole absentes quand seuls les CP d'arrondissement sont présents ; (c) mots-clés dupliqués dans les critères texte.

Points positifs ✅

• La dual-gate budget+verbe est robuste et justifiée (un loyer de 400k n'existe pas en France).
• Les tests existants ont été mis à jour (scenarios 0, 1, 9) : on ne codifie pas les bugs.
• Le dédoublonnage est purement cosmétique mais améliore la lisibilité des critères exposés à l'utilisateur.

Bugs potentiels / Risques ⚠️

• Seuil SALE_BUDGET_MIN_THRESHOLD = 50_000 : un utilisateur cherchant une location de luxe à 45 000 €/mois (ultra-niche, Monaco/Paris 16e) serait basculé en "sale". Extrêmement marginal.
• deduplicateTextKeywords ne détecte pas les doublons sémantiques (ex: "calme" vs "tranquille"). Ce n'est pas son rôle, mais c'est une limite.

Suggestions de refactoring 🔧

• Le fichier criteria-validator.ts devient un "god object". Chaque fonction de normalisation devrait vivre dans son propre module sous parsing/validators/.

---

afc3c39 — swap OpenRouter default model

Résumé : changement du modèle par défaut OpenRouter de minimax/minimax-m2.7 vers mistralai/mistral-small-2603.

Points positifs ✅

• Changement de configuration propre : le modèle reste surchargeable via OPENROUTER_MODEL.
• La doc interne (CLAUDE.md) est maintenue à jour.
• Les tests du provider sont adaptés (pas de hardcodage ancien modèle laissé derrière).

Bugs potentiels / Risques ⚠️

• Aucun risque technique majeur. Le seul risque est opérationnel : Mistral Small 2603 est très récent ; si OpenRouter le retire ou change son API rate-limit, le système basculera automatiquement sur le fallback OpenRouter (si ALLOW_FALLBACKS=true).

Suggestions de refactoring 🔧

• Aucune. Commit trivial et bien exécuté.

---

533db69 — scoring audit iteration 3/5 (template C)

Résumé : applique les overrides de coordonnées POI canoniques pendant la validation (et non plus seulement au scoring), empêchant le pré-filtre SQL de tirer des candidats dans de mauvaises communes.

Points positifs ✅

• Defense-in-depth : l'override existe toujours dans geo-resolver.ts au scoring, mais ce commit corrige la cause racine en amont.
• Seuil de 1 km bien choisi : tolère les imprécisions légitimes sans laisser passer les hallucinations grossières.
• Logs explicites (POI override applied during validation) facilitant le debugging.

Bugs potentiels / Risques ⚠️

• approxDistanceKm réimplémente la formule haversine qui existe déjà dans criterion-scorers.ts (haversineKm). Risque de divergence si l'un est modifié et pas l'autre.
• Pas de tests unitaires pour cette fonction dans ce commit. Le comportement est testé indirectement via les scénarios d'intégration, mais un test unitaire sur applyPoiOverridesToNear manque.

Suggestions de refactoring 🔧

• Extraire approxDistanceKm (ou réutiliser haversineKm) dans un module lib/geo/distance.ts partagé.
• Ajouter un test unitaire couvrant le cas "drift > 1 km → override" et "drift ≤ 1 km → conserve".

---

dc67c39 — scoring audit iteration 4/5 (template D)

Résumé : supprime le text-negative "rez-de-chaussée" redondant quand un range structuré floor min >= 1 est déjà présent.

Points positifs ✅

• Comportement conservateur : le text-negative est préservé si le range structuré n'existe pas (fallback).
• Regex accent-insensible ([ée]) couvrant "rez-de-chaussée", "rez-de-chaussee", "RDC", "r.d.c.".

Bugs potentiels / Risques ⚠️

• Typo dans le nom de variable interne : hasFloorFloor au lieu de hasFloorRange. Pas fonctionnel mais gênant pour la lisibilité.
• Le regex \br.?d.?c.?\b pourrait matcher "rdc" dans un contexte non-immobilier (ex: abréviation d'entreprise), mais \b et le fait que ce soit dans negativeCriteria texte limitent le risque.

Suggestions de refactoring 🔧

• Corriger la typo hasFloorFloor → hasFloorRange.
• Regrouper dropRedundantFloorTextNegative et dropHallucinatedRenovationNegatives (commit suivant) dans un module negative-criteria-cleaner.ts.

---

6c665b9 — scoring audit iteration 5/5 (template A revisit)

Résumé : fusionne les critères range positifs sur le même champ, résolvant les contradictions émises par Mistral Small (ex: floor min=1 ET floor max=0 pour "pas de RDC").

Points positifs ✅

• Stratégie de résolution documentée et justifiée par l'analyse des prompts français.
• Le log permet d'auditer les cas où le LLM émet des ranges contradictoires.
• Amélioration quantitative confirmée en production (+6 points de match% sur les cas IDF T2 testés).

Bugs potentiels / Risques ⚠️

• maxWeight (max des poids des ranges fusionnés) est logique mais non documenté dans le JSDoc. Si un range a weight 8 (hard constraint) et l'autre weight 5 (souhait), le merge donne 8. C'est généralement souhaitable mais pourrait surprendre.
• Edge case : si deux ranges compatibles représentent des intentions distinctes (ex: surface min=50 et surface min=60 émis par deux clauses différentes du prompt), le merge en min=60 masque la nuance. Mais c'est un comportement acceptable car le LLM ne devrait pas émettre de tels doublons.

Suggestions de refactoring 🔧

• Documenter la règle du maxWeight dans le JSDoc.
• Envisager un pipeline de validation explicite avec des étapes nommées, car criteria-validator.ts approche les 900 lignes.

---

8542226 — feat: Add embedding support for semantic search

Résumé : ajoute l'infrastructure complète pour la recherche sémantique par embeddings (Gemini text-embedding-004, 768-dim) : provider, factory, tests, migration SQL HNSW, RPC match_listings_by_ids, OR-pair coalescing dans le scoring, déduplication cross-platform, et nettoyage des negatives travaux hallucinées.

A. Module src/lib/embeddings/ (nouveau)

• Pattern identique au module parsing/providers : types.ts, errors.ts, factory.ts, implémentation gemini.ts, tests unitaires exhaustifs.
• GeminiEmbeddingProvider gère RETRIEVAL_DOCUMENT vs RETRIEVAL_QUERY, valide la dimension, compte les tokens.
• EmbeddingError avec flag retryable (429, 5xx, network).

B. Migration SQL 019_add_listings_embeddings.sql

• Colonne vector(768) + embedding_model + embedded_at.
• Index HNSW vector_cosine_ops (standard).
• Index partiel WHERE embedding IS NULL AND is_active = TRUE pour le backfill futur.
• RPC match_listings_by_ids(query_embedding, listing_ids) : recherche sémantique scopée sur les candidats pré-filtrés (évite le full-scan).

C. Scoring

• OR-pair coalescing (criterion-scorers.ts) : hasBalcony/hasTerrace et hasParking/hasGarage exprimés avec même poids sont scorés comme OR (max(scoreA, scoreB)) au lieu d'AND. Corrige l'UX française "balcon ou terrasse".
• Deduplication cross-platform (engine.ts) : deduplicateScoredListings collapse les doublons PAP/BienIci/LogicImmo par signature title|price|surface|postalCode. Normalise les accents et les espaces.

D. Validation

• dropHallucinatedRenovationNegatives : supprime les text-negatives "travaux", "à rénover", etc. quand le prompt brut ne contient pas de cue phrase explicite. Évite la pénalisation silencieuse des annonces mentionnant des travaux anciens ou rénovations.

Points positifs ✅

• Architecture modulaire et cohérente avec le reste du codebase. Les tests couvrent 100% des chemins heureux et d'erreur du provider.
• La migration SQL est bien pensée : HNSW + index partiel + RPC scoped. C'est exactement la bonne façon d'intégrer pgvector dans un pipeline two-pass.
• L'OR-pair coalescing est un excellent exemple de domain-driven design appliqué au langage naturel français.
• La déduplication cross-platform résout un vrai problème utilisateur (même annonce sur 3 sites).
• Tous les tests passent (592/592).

Bugs potentiels / Risques ⚠️

• Migration pgvector : CREATE EXTENSION IF NOT EXISTS vector; requiert que l'extension soit installée sur l'hôte PostgreSQL. Sur Supabase hosted c'est OK, mais en self-hosted pur il faut une étape ops supplémentaire non documentée dans le commit.
• HNSW paramètres : m=16, ef_construction=64 sont les défauts pgvector. À grande échelle (> 1M annonces), la recall pourrait chuter. Il faudra surveiller et potentiellement augmenter ef_construction lors du build index.
• Deduplication : la signature title|price|surface|postal est fragile. Deux annonces pour le même appartement avec des titres légèrement différents ("Beau T3" vs "T3 lumineux") ne seront pas détectées. Une approche par hash de tokens triés ou distance Levenshtein améliorerait le recall.
• Eval models — prix estimés : models.ts ajoute 3 modèles avec notes: "Pricing estimated". Si ces prix sont utilisés pour du cost-capping ou du budget forecasting, des estimations erronées peuvent entraîner des surprises financières. Il faudrait un flag isPriceConfirmed ou une borne supérieure conservative.
• Missing backfill worker : le commit ajoute la colonne et le RPC, mais aucun script/cron pour générer les embeddings des annonces existantes. Le pipeline est incomplet jusqu'à l'arrivée de ce worker.
• criteria-validator.ts : encore une fonction ajoutée dans un fichier déjà trop gros (~800+ lignes). Le pipeline compte ~15 étapes séquentielles, difficiles à suivre.

Suggestions de refactoring 🔧

1. Découper criteria-validator.ts en modules thématiques : validators/dpe-fixes.ts, validators/geo-fixes.ts, validators/text-fixes.ts, validators/range-fixes.ts, validators/transaction-inference.ts, validators/pipeline.ts (orchestration des étapes).
2. Unifier la distance geo : approxDistanceKm (validator) et haversineKm (scorer) devraient partager le même utilitaire dans lib/geo/distance.ts.
3. Améliorer la dedup : au lieu de title brut, utiliser un fingerprint normalisé (normalizedTitle.split(/\s+/).filter(w => w.length > 2).sort().join(' ')).
4. Embedding backfill : prévoir un endpoint/cron POST /api/cron/embed qui consomme embedding IS NULL ORDER BY first_seen_at LIMIT N en respectant les rate-limits Gemini.

La série de commits est d'une excellente qualité technique. L'auteur adopte une méthodologie data-driven (audit itératif sur templates A/B/C/D, mesure du match%, correction ciblée, re-mesure) qui est exactement la bonne approche pour un système LLM+critères structurés. Le code est défensif, bien testé, et les commentaires expliquent le "pourquoi" derrière chaque choix métier.

Le principal point d'attention est la croissance incontrôlée de src/lib/parsing/criteria-validator.ts qui tend vers un god object de 900+ lignes. Un découpage modulaire du pipeline de validation devrait être la priorité technique suivante.

Aucun bug critique détecté ; tous les tests passent. Les risques identifiés sont des edge cases marginaux ou des améliorations architecturales futures.

---

Hash	Message
3252be1	disable evedex

3252be1 — disable evedex

Résumé : désactive l'exchange Evedex en commentant son entrée dans le tableau EXCHANGES de src/config/exchanges.ts. C'est un pattern cohérent avec d'autres exchanges déjà désactivés dans le même fichier (ostium, gmx).

Points positifs ✅

1. Approche non-destructive : L'exchange n'est pas supprimé, juste commenté. Facile à réactiver si Evedex revient en ligne.
2. Cohérence avec l'existant : Le même pattern /* ... */ est utilisé pour ostium et gmx, ce qui maintient l'uniformité du code.
3. Zero risk : Aucune logique métier modifiée, seulement une configuration statique. Aucun risque de régression.
4. Automatique : Le tableau étant typé as const, ExchangeKey et ExchangeConfig se mettent à jour automatiquement sans que evedex ne soit plus disponible.

Bugs potentiels / Risques ⚠️

• Problème de newline manquant : après le bloc commenté, il y a une ligne vide supplémentaire avant { key: "apex", ... }. C'est purement cosmétique mais Biome pourrait potentiellement formatter cela.
• Pas de raison documentée : le message de commit est "disable evedex" mais il n'y a aucun commentaire expliquant pourquoi (API down temporairement ? Arrêt définitif ? Problème de données ?).
• DEFAULT_ENABLED_EXCHANGES_COUNT inchangé : compteur resté à 15. Puisqu'on supprime un exchange du tableau (par commentaire), cela peut impacter les filtres par défaut si ce compteur était calibré sur la position dans le tableau. À vérifier : Evedex était-il dans les 15 premiers ? Non (position ~15, après Drift). Donc peu d'impact.
• Si un utilisateur avait Evedex dans ses favoris ou ses filtres persistés en localStorage, il pourrait y avoir un léger edge case où un composant tente d'accéder à une config inexistante. Cependant, le code semble gérer les exchanges inconnus gracieusement.

Suggestions de refactoring 🔧

1. Ajouter un commentaire explicatif : /* Disabled: API temporarily down (2026-04-21) */
2. Extraire les exchanges désactivés dans un tableau séparé (DISABLED_EXCHANGES) pour une meilleure traçabilité, au lieu de les commenter en ligne.
3. Feature flag : pour un projet de cette envergure (26+ exchanges), envisager un champ optionnel enabled: boolean dans l'interface Exchange plutôt que de commenter le code.

Verdict : Commit propre, minimal, et cohérent. Seule suggestion : documenter la raison du disable directement dans le code ou le message de commit.

---

Rapport généré automatiquement le 2026-04-22.

Repo	Dernier commit	Score
anniv-chalet-2026	2026-04-20 01:18 UTC	B+
flatty	2026-04-20 01:18 UTC	B+

---

Derniers commits (48h): 2 commits — 7e1449e et 3cb06a8

Fichiers: 23 fichiers, +418 / −220 lignes

✅ Points positifs

• Design system documenté (.impeccable.md) — excellent pour la cohérence
• Nouvelles animations CSS originales : breathe-tilt, tomato-tick, ink-scribble, draw-route
• Palette redesign vers un système "zine/paper/ink" cohérent et distinctif
• Suppression du carousel inutilisé (embla-carousel-react) — nettoyage de dead code
• Migration Supabase → PostgreSQL auto-hébergé (src/lib/db.ts)
• Countdown atomique avec animations animate-tomato-tick

⚠️ Améliorations possibles

1. Pool PostgreSQL global non nettoyé — jamais détruit proprement. Ajouter process.on('exit') ou closePool()
2. Animations CSS perpétuelles — animate-breathe-tilt sur chaque AmenityCard peut impacter les perf. mobiles
3. Suppression de embla-carousel-react — vérifier qu'aucun import résiduel ne traîne

🐛 Bugs potentiels

1. Hydration mismatch possible dans Countdown.tsx — le fix avec mounted state existe, mais vérifier en prod
2. Pool null-safety — si pool est null, les appels DB échouent silencieusement

🔧 Suggestions de refactoring

• Externaliser les ROTATION_CLASSES en objet typé
• Ajouter will-change: transform sur les éléments animés

---

Fichiers: 2 fichiers, +142 / −70 lignes

✅ Points positifs

• Componentisation de AmenityCard — excellent SRP, composant réutilisable
• API Amenity typée avec LucideIcon, accent, rotation
• Design "zine stickers" avec rotations variées et hover reveal
• Transitions refinées avec easing cubic-bezier(0.22, 1, 0.36, 1) — très pro
• Suppression du "Tu es invité·e à" du Hero — allège le clutter visuel

⚠️ Améliorations possibles

1. Rotation classes hardcodées — "rot-n1", "rot-1" en string arbitraire sans validation de type
2. Hover reset de rotation — whileHover={{ rotate: 0 }} annule l'intention de "rhythm" du design
3. Icon fallback — si amenity.icon est undefined, le render échoue silencieusement

🐛 Bugs potentiels

1. Index chit basé sur l'array order — si l'ordre change, la numérotation change
2. Pas de guard sur Icon component — risque de silent fail

🔧 Suggestions de refactoring

• Type-safe rotation : type RotationValue = -2 | -1 | 1 | 2
• Externaliser les ACCENT_STYLES en const

---

Dernier commit (24h): e1f2aaa — "Add quick filter functionality to prompt input"

Fichiers: src/components/search/prompt-input.tsx (+298/-50), src/components/listing/browse-page.tsx (+4/-0)

✅ Points positifs

• Section "Filtres rapides" avec toggle transactionType, chips type de bien, input ville
• Présélections de budget adaptatives (louer vs acheter)
• Refactoring UI avec flexbox au lieu de relative/absolute
• Excellente accessibilité : aria-pressed, aria-label, fieldset/legend
• Indicateurs clavier (⌘ Entrée / ⇧ Entrée) pour UX moderne
• useMemo pour le placeholder — optimisation，散
• Reset du budget lors du changement de transactionType — bien pensé

⚠️ Améliorations possibles

1. Validation absente sur ville — pas de geocoding ni validation de code postal
2. Debounce manquant sur quick.city — acceptable maintenant, mais faudra debounce si autocomplete ajoutée
3. Budget null → criteria vide — vérifier que le scoring engine tolère budget: { min: null, max: null }
4. applyQuickFilters unaire vs onSearch binaire — asymétrie d'API
5. Complex grid responsive — sm:grid-cols-[minmax(0,14rem)_minmax(0,1fr)] à tester sur mobile

🐛 Bugs potentiels

1. Race condition faible — early-return if (!hasQuickFilters || isLoading) return pourrait ne pas être respecté à cause du setState async (faible risque)

🔧 Suggestions de refactoring

• Extraire QuickFiltersSection en sous-composant dédié (+150 lignes)
• Externaliser BUDGET_PRESETS_RENT / BUDGET_PRESETS_SALE en constants
• Ajouter isValidQuickCriteria() pour valider avant envoi au scoring engine
• useMemo sur buildQuickCriteria

---

1. 🔴 anniv-chalet — Ajouter cleanup du pool PostgreSQL (process.on('exit'))
2. 🟡 flatty — Valider les critères快速 avant envoi au scoring engine
3. 🟢 flatty — Extraire QuickFiltersSection en composant séparé

---

Review généré automatiquement le 2026-04-21 à 06:31 UTC

Chemin: /home/ubuntu/anniv-chalet-2026
3 commits dans les dernières 24h

---

Fichier	Changements
.env.example, .env.local.example	Switch de Supabase → PostgreSQL (DATABASE_URL)
docker-compose.yml	Ajout service anniv-chalet-db PostgreSQL
docker/init.sql	Schéma table invitations
src/lib/supabase.ts	Supprimé — remplace par db.ts
src/lib/db.ts	Nouveau client Pool PostgreSQL
src/app/api/rsvp/route.ts	+65 lignes — endpoint RSVP PostgreSQL
src/components/rsvp/useRSVPForm.ts	Redirect vers /api/rsvp au lieu de Supabase

Points positifs:

• Migration de Supabase (SaaS) → PostgreSQL auto-hébergé = contrôle complet, coût réduit
• Utilisation d'un connection pool avec globalThis.__pgPool pour éviter les multi-instances en dev Next.js
• Parametric queries (SQL injection protégé)

⚠️ Bugs potentiels:

• pool n'a pas de gestion d'erreur robuste — si la connexion échoue au démarrage, l'application peut crash sans message clair
• isDbConfigured() ne vérifie que la présence de DATABASE_URL — pas un test de connectivité réel
• Pas de retry sur les queries échouées
• Le type Invitation est dupliqué dans db.ts

Suggestions:

// Valider la connexion au startup
export async function testConnection() {
  try {
    const client = await pool.connect();
    client.release();
    return true;
  } catch { return false; }
}

---

Fichier	Changements
.impeccable.md	+21 lignes — design context/aesthetic direction
src/app/globals.css	+109 lignes — nouvelles animations CSS
tailwind.config.ts	Refonte palette : paper, ink, tomato, poster
src/components/Countdown.tsx	Animation "tomato-tick" heartbeat
src/components/ui/*.tsx	Mise à jour styling composants

Points positifs:

• Documentation .impeccable.md excellent pour onboarding et cohérence d'équipe
• Design system cohérent avec palette "zine/poster/riso-print"
• Animations CSS bien pensées : ink-underline-focus, breathe-tilt, tomato-tick, draw-route, dot-pop
• Suppression du composant carousel.tsx (286 lignes) — réduction dette technique

⚠️ Bugs potentiels:

• Les fonts (Archivo Black, Space Grotesk, Caveat, JetBrains Mono) doivent être chargées — vérifier que @next/font ou Google Fonts est configuré
• Animations CSS comme breathe-tilt tournent en permanence — peut impacter les perfs sur mobile
• Le fichier globals.css a changé de 163 lignes à 272+ — croissance rapide

Suggestions:

• Extraire les animations dans un fichier src/styles/animations.css pour modularité

---

Fichier	Changements
src/components/ChaletInfo.tsx	+142 / -70 lignes — refonte avec AmenityCard
src/components/Hero.tsx	-21 / +11 lignes — allègement texte

Points positifs:

• Extraction de AmenityCard comme sous-composant — bonne encapsulation
• Interface Amenity typée avec LucideIcon pour les icônes
• Variations visuelles : 3 accents (tomato, ink, kraft) + rotations variées
• Animation hover bien dosée : y: -4, rotation, scale sur icône

⚠️ Bugs potentiels:

• rotation: "rot-n2" non défini en CSS (vu rot-2 mais pas rot-n2)
• Les rotations sur chaque élément peuvent créer du bruit visuel
• Suppression de "Tu es invité·e à" du Hero — vérifier que c'est bien intentional (impact messaging)

Suggestions:

const validRotations = ['rot-1', 'rot-n1', 'rot-2', 'rot-n2'] as const;

---

Synthèse anniv-chalet-2026:

Aspect	Évaluation
Architecture	✅ Bonne séparation : DB, API routes, composants UI
Design system	✅ Palette cohérente, documentation excellente
DX / Maintenabilité	✅ .impeccable.md, types stricts, composants modulaires
Résilience	⚠️ Pas de retry/gestion d'erreur visible sur le pool PostgreSQL
Performance	⚠️ Animations permanentes (breathe-tilt) à monitorer

---

Chemin: /home/ubuntu/flatty
4 commits dans les dernières 24h

---

Fichiers modifiés: src/components/listing/browse-page.tsx, src/components/search/prompt-input.tsx (+298 / -50 lignes)

Points positifs:

• Bonne idée d'ajouter des filtres rapides sans LLM pour les recherches déterministes
• Les chips sont bien.accessibles (aria-pressed, fieldset/legend)
• Le buildQuickCriteria est une fonction pure bien isolée
• Intégration propre dans le flux Redux existant (SEARCH_START)

⚠️ Bugs potentiels:

• Le state quick est local au composant — si l'utilisateur navigue et revient, l'état est perdu
• Risque de race condition: isLoading désactive le bouton, mais pas de feedback si l'utilisateur tape et clique simultanément

Suggestions:

• Extraire la section "Quick Filters" en sous-composant QuickFiltersSection
• Ajouter un hook useQuickFilters pour centraliser la logique d'état

---

Fichiers modifiés: 15 fichiers, +862 / -140 lignes (nouveau dossier providers/)

Points positifs:

• Excellent pattern d'abstraction — permet de changer de provider LLM sans modifier la logique métier
• Séparation claire des responsabilités: parsing logic vs. appel API
• Tests unitaires complets pour la factory et les providers
• Bon usage de TypeScript avec des interfaces typed

⚠️ Bugs potentiels:

• La factory utilise LLM_PROVIDER env var — pas de fallback si variable manquante (risque de crash)
• Les erreurs provider ne semblent pas avoir de fallback intégré

Suggestions:

• Ajouter un mode "mock" ou "fallback" dans la factory pour les tests
• Envisager une interface RateLimitHandler pour gérer proprement les limites de requêtes

---

Fichiers modifiés: counter.tsx, metrics-strip.tsx, metrics.ts, globals.css, theme-toggle.tsx, themes.ts (+80 / -196 lignes)

Points positifs:

• DRY: Counter encapsule maintenant le formatage, au lieu d'avoir formatCountFr séparé
• Simplification du code: moins de lignes, moins de concepts à retenir
• Suppression d'export inutile (LISTING_SOURCES_LABEL non utilisé ailleurs)

⚠️ Bugs potentiels:

• Le composant Counter doit gérer le cas value=null (placeholder "bientôt") — vérifier que le default props/format est robuste
• Si Counter a un bug de formatting, toute la landing page est impactée

---

Fichiers modifiés: 12 fichiers, +667 / -62 lignes

Points positifs:

• Scroll-driven animations avec @supports — bon fallback si non supporté
• MagneticLink bien implémenté avec requestAnimationFrame pour la performance
• prefers-reduced-motion bien géré

⚠️ Bugs potentiels:

• Cookies try/catch silencieux: cookieStore.set pourrait échouer silencieusement en Server Component
• Thème "haussmann": Les variables CSS utilisent oklch(0.15 0.02 250) — à vérifier le contrast ratio WCAG AA
• Classes .landing-* très génériques — risque de collision

Suggestions:

• Renommer les classes .landing-* en .flatty-landing-* pour éviter les collisions
• Ajouter des tests visuels (visual regression) pour les animations scroll-driven

---

Synthèse flatty:

Commit	Titre	Risque
e1f2aaa	Quick filter functionality	Moyen — état local non persistant
0fe27fd	Provider abstraction	Faible — bien testé
09eedbe	Theme/counter refactor	Faible
ed7a7a6	Animated landing elements	Moyen — animations scroll-driven, accessibilité thème

Recommandations prioritaires flatty:

1. Renommer les classes .landing-* → .flatty-landing-* pour éviter collisions
2. Vérifier le contrast ratio du thème "Haussmann" (oklch très sombre)
3. Ajouter un fallback dans la factory provider si LLM_PROVIDER est absent
4. Revoir le silent try/catch sur cookieStore.set — logger au moins en dev

---

Repo	Commits	Architecture	Design/UX	Résilience	Performance
anniv-chalet-2026	3	✅ Bonne	✅ Excellent	⚠️ Pool DB	⚠️ Animations
flatty	4	✅ Abstraction provider	✅ Animations	⚠️ Factory fallback	⚠️ CSS collisions

Actions recommandées:

1. anniv-chalet-2026: Ajouter testConnection() au startup DB + vérifier les rotations CSS (rot-n2)
2. flatty: Renommer .landing-* → .flatty-landing-* + fallback factory provider + contraste thème haussmann

Chemin : /home/ubuntu/git/too-many-cooks/web/funding-rates-dashboard-api Commits : 3 (tous de Navix)

---

Fichier : src/middleware/subscription.ts (+17 -5)

Ce qui change :

• Extrait getSubscriptionStatus(chatId) pour résoudre le tier ET le status de subscription séparément
• Le middleware requireExecutionCostAccess attache maintenant au request object le profile complet enrichi avec subscription_tier, subscription_status et subscription_period_end

Points positifs :

• Bonne séparation des responsabilités entre lecture du profil et résolution du status subscription
• Le request object porte maintenant toutes les infos nécessaires pour les middlewares en aval

Suggestions d'amélioration :

• getSubscriptionStatus est appelée avant getOrCreateProfile, ce qui fait 2 appels DB au lieu d'1. On pourrait chaîner : récupérer le profil via getSubscriptionStatus qui内部mente fait getOrCreateProfile, puis utiliser le résultat directement
• Pas de gestion d'erreur si getSubscriptionStatus échoue — le catch générique suffit mais un log explicite serait utile

Risques/Bugs :

• Aucun bug identifié — refactor propre

---

Fichier : src/middleware/subscription.ts (+8 -13)

Ce qui change :

• requireExecutionCostAccess ne appelle plus getSubscriptionStatus — il fait un simple lookup TIER_LIMITS[tier] via getOrCreateProfile
• Commentaire ajouté : les non-Stripe subscribers (crypto/manual) ne sont pas dégradés au tier free
• Suppression de l'enrichissement du profile avec les champs subscription_* (le profile brut suffit)

Points positifs :

• Simplification significative : 2 appels DB → 1 appel DB
• Le fix du comment "ignore subscription_status" est important — corrige un bug potentiel où un utilisateur avec payment externe mais sans subscription active serait considéré comme free
• Le middleware est plus rapide et plus simple à reasonner

Suggestions d'amélioration :

• La variable tier est dérivée de profile.subscription_tier qui lui-même vient de getOrCreateProfile. Si le profil n'a pas de subscription_tier (undefined/null), le fallback TIER_LIMITS.free s'applique — comportement correct mais un warning dans les logs ne nuirait pas
• On pourrait extraire cette logique "tier-only check" dans une fonction util pour reuse dans d'autres middlewares

Risques/Bugs :

• Risque mineure : si un jour subscription_tier dans la DB a une valeur non prévue (ex: "platinum"), TIER_LIMITS["platinum"] retourne undefined, le fallback TIER_LIMITS.free s'applique silencieusement. Envisager une validation du tier contre les clés de TIER_LIMITS

---

Fichier : src/services/chatService.ts (+7 -4)

Ce qui change :

• Modifie le prompt système du chatbot AI (chatService) :
  • Spot strategies : ajout de "Safer" à la fin de la description
  • Supprime la formule APR explicite "8-hour rate × 3 × 365 × 100"
  • Modifie l'exemple numérique : avant "12.45%" → après "0.1245 = "12.45%""

Points positifs :

• Nettoyage du prompt — la formule APR était redundante avec l'instruction "Show APR values as percentages with 2 decimal places"
• L'exemple "0.1245 = 12.45%" est plus clair pour le model LLM

Suggestions d'amélioration :

• Aucun — changement minime et ciblé

Risques/Bugs :

• Aucun

---

Repo	Commits	Fichiers	Verdict
funding-rates-dashboard-api	3	2	✅ Refactor propre, 1 suggestion mineure (validation tier)

• Subscription middleware : refactor en cours pour simplifier la vérification d'accès et corriger un edge case avec les non-Stripe subscribers
• Chatbot AI : allègement du prompt système

Valider la valeur de subscription_tier contre les clés de TIER_LIMITS dans requireExecutionCostAccess pour éviter un fallback silencieux vers le tier free si une valeur inattendue existe en DB.