- Affichage du contenu de Navigation.tsx avant modification
- Affichage complet après modification pour vérification
- Exit code 1 si la modification échoue
- Logs détaillés pour identifier le problème
- Utilisation de sed en premier (plus simple)
- Fallback avec Python si sed échoue
- Logs détaillés pour voir le contenu avant/après
- Affichage du contenu modifié pour vérification
- Ajout de /app/.techradar/public/ dans la recherche
- Logs détaillés avec pwd pour voir le répertoire actuel
- Vérification après copie pour confirmer le succès
- Meilleur diagnostic des chemins
- Vérification explicite que team.html existe dans public/ source
- Logs détaillés pour identifier où le fichier se trouve
- Vérification après copie dans .techradar/public/
- Recherche dans .techradar/public/
- Recherche dans /app/public/
- Recherche dans ../public/
- Logs détaillés pour diagnostic
- Copie de team-visualization-data.json également
- Installation de Python3 dans Dockerfile
- Logs détaillés pour diagnostic
- Vérification après modification
- set -e pour arrêter en cas d'erreur
- Vérification dans Dockerfile que le script a réussi
- Utilisation de Python au lieu de sed/awk pour modification précise
- Insertion correcte du lien Équipe après Overview
- Page team.tsx avec iframe pour charger team.html
- Script create-team-page.sh pour créer team.tsx et modifier Navigation
- Page Next.js qui charge team.html dynamiquement
- Lien Équipe ajouté directement dans le composant Navigation React
- Plus fiable que l'injection JavaScript
- Vérification de l'existence de team.html dans out/ au démarrage
- Copie automatique depuis public/ si absent
- Ajout de --single à serve pour gérer les routes SPA (peut aider pour les fichiers HTML)
- Utilisation de MutationObserver pour détecter quand le header est ajouté au DOM
- Timeout de sécurité après 5 secondes
- Amélioration de la logique d'initialisation pour éviter les exécutions multiples
- Logs détaillés pour diagnostic
- Logs dans initWhenReady() pour voir si le header est trouvé
- Logs dans addLinksToHeader() pour voir si la fonction est appelée
- Retry avec limite de 10 tentatives pour trouver le header
- Logs pour vérifier l'ajout du lien Équipe
- Logs détaillés pour voir ce qui est copié dans out/
- Vérification du contenu de out/ avant et après copie
- Diagnostic amélioré pour identifier le problème
- Amélioration de la copie de team.html avec vérifications et logs
- Fonction initWhenReady() pour attendre que le header soit disponible
- Logs de debug pour vérifier l'ajout du lien Équipe
- Vérification de l'existence des fichiers avant copie dans out/
- Correction logique addLinksToHeader() pour éviter retour prématuré
- Utilisation d'un conteneur dédié pour les liens de navigation
- Copie explicite de team.html et team-visualization-data.json dans out/ après build
- Le lien Équipe s'affiche maintenant correctement dans le header
- Création de guide-page-equipe.md avec documentation complète
- Description des 3 visualisations (graphe réseau, matrice congestion, équipe genèse)
- Instructions pour régénérer les données
- Guide de personnalisation et cas d'usage
- Mise à jour du README avec lien vers la nouvelle documentation
- Création du script generate-team-visualization-data.js pour générer les données JSON
- Page /team.html avec 3 visualisations :
* Graphe réseau (Cytoscape.js) : technologies ↔ membres
* Matrice de congestion : technologies core et disponibilité
* Équipe de genèse MVP : sélection automatique pour MVP 2 mois
- Ajout du lien '👥 Équipe' dans le header du radar
- Données JSON générées pour visualisations interactives
- Identification des congestions et technologies non couvertes
- Création de 12 fichiers de profils individuels dans docs/data/team/
- Chaque profil contient métadonnées YAML complètes (compétences, projets, soft skills)
- Correction du script extract-technologies.js pour charger toutes les compétences depuis les fichiers
- Mise à jour des blips radar avec les données d'équipe correctes
- Suppression des anciens fichiers dans radar/ (remplacés par radar-business/)
- 58 compétences au total chargées depuis les fichiers individuels
- Légende remontée de bottom: 220px à bottom: 320px
- Plus d'espace entre la légende et le quadrant 4
- La légende est maintenant bien plus haute à droite
- Quadrant 4 descendu à bottom: 10px (tout en bas)
- Légende remontée à bottom: 220px (en haut à droite)
- La légende prend maintenant la place qu'occupait le quadrant 4
- Le quadrant 4 est maintenant en bas à droite
- Largeur des labels augmentée à 180px (au lieu de 160px)
- Tailles de police augmentées : titre 15px, description 12px
- Labels positionnés à 10px des bords (extrêmes coins)
- Quadrant 4 remonté à 240px du bas (très haut)
- Légende positionnée à 10px du bas à droite (coin extrême)
- Espacement maximal entre tous les éléments
- Utilisation de sélecteurs basés sur la structure réelle du DOM
- Réduction de la largeur des labels à 160px
- Réduction de toutes les tailles de police (titre 14px, description 11px)
- Labels positionnés à 60px des bords
- Quadrant 4 remonté à 160px du bas pour la légende
- Légende positionnée à 60px du bas à droite
- Z-index 100 pour la légende
- Sélecteurs ciblant directement [class*='Radar_radar'] [class*='Label_label']
- Approche simplifiée avec sélecteurs plus génériques
- Marges augmentées à 50px pour tous les quadrants
- Quadrant 4 repositionné à 200px du bas
- Légende repositionnée à 50px du bas à droite
- Z-index augmenté pour la légende
- Suppression des sélecteurs trop spécifiques qui ne fonctionnaient pas
- Tous les quadrants maintenant à 40px des bords (au lieu de 30px)
- Quadrant 4 repositionné à 220px du bas (au lieu de 180px) pour plus d'espace
- Légende repositionnée à 40px du bas à droite
- Espacement maximal pour éviter tout chevauchement
- Augmentation des marges à 30px pour tous les quadrants
- Quadrant 4 repositionné à 180px du bas (au lieu de 120px)
- Légende repositionnée à 30px du bas à droite
- Réduction de la taille des labels (170px au lieu de 180px)
- Réduction de la taille de la police pour économiser l'espace
- Z-index augmenté pour la légende pour s'assurer qu'elle est au-dessus
- Position absolute explicite pour la légende
- Augmentation des marges des 4 quadrants à 20px des bords
- Repositionnement du quadrant 4 à 120px du bas pour laisser de la place à la légende
- Repositionnement de la légende en bas à droite à 20px des bords
- La légende ne chevauche plus le quadrant 4
- Réduction de la largeur des labels à 180px
- Positionnement à 10px des bords (au lieu de 30px) pour être vraiment en dehors des cercles
- Les labels sont maintenant complètement en dehors de la zone des cercles (rayon max 400px)
- Ajustement de la légende avec position fixe en bas à droite
- Ajout de box-shadow pour améliorer la visibilité
- Sélecteurs CSS plus spécifiques pour garantir l'application des styles
- Retrait de no_cache (non supporté dans docker-compose)
- Ajustement précis des positions pour les 4 quadrants (30px des bords)
- Les labels ne chevauchent plus les cercles du radar
- Amélioration de l'invalidation du cache dans Dockerfile
- Documentation pour utiliser 'No cache' dans Portainer
- Ajout de marges et padding pour éviter le chevauchement avec les cercles du radar
- Ajustement spécifique pour le quadrant 2 (Technologies de Commodité)
- Ajustement de la position de la légende en bas à droite
- Ajout d'un fond semi-transparent avec blur pour améliorer la lisibilité
- Z-index pour s'assurer que les éléments sont au-dessus des cercles
- Activation de no_cache: true pour forcer le rebuild sans cache
- Utilisation de nanosecondes (date +%s%N) pour CACHE_BUST afin de garantir l'unicité
- Cela devrait résoudre le problème de cache Docker dans Portainer
- Plus besoin de supprimer manuellement l'image avant chaque rebuild
- Ajout d'un build arg CACHE_BUST avec timestamp pour invalider le cache
- Ajout d'une instruction RUN tôt dans le Dockerfile pour forcer l'invalidation
- Amélioration de la documentation avec guide détaillé pour forcer le rebuild
- Explication du problème de cache Docker et solutions multiples
- Instructions pour utiliser --no-cache dans Portainer
- Ajout de styles CSS pour rendre les icônes SVG plus visibles
- Force la couleur #2ecc71 pour les icônes de navigation
- Améliore la visibilité des liens dans la navigation
- S'assure que l'icône '?' est toujours visible
- Ajout d'une introduction plus détaillée sur le radar
- Explication complète de chaque anneau (Adopt, Trial, Assess, Hold)
- Exemples concrets de technologies pour chaque anneau
- Explications de quand utiliser chaque anneau
- Documentation des quadrants avec descriptions détaillées
- Formatage amélioré pour une meilleure lisibilité
- Ajout de 'pull: true' dans docker-compose pour forcer le pull de l'image de base
- Ajout de build args (BUILD_DATE, BUILD_VERSION) pour invalider le cache
- Ajout de labels dans Dockerfile pour tracer les builds
- Cela évite d'avoir à supprimer manuellement l'image avant chaque rebuild
- Portainer utilisera maintenant toujours la dernière version du code
- Création d'un fichier about.md adapté pour le radar Laplank
- Légende détaillée en français pour chaque anneau avec exemples
- Amélioration des descriptions des anneaux dans config-business.json
- Explications claires de quand utiliser chaque anneau
- Documentation des quadrants également incluse
- Next.js avec output: export génère des fichiers statiques dans out/
- next start ne fonctionne pas avec output: export
- Utilisation de npx serve@latest out pour servir les fichiers statiques
- Cela correspond à la recommandation de Next.js pour les exports statiques
- Ajout de --include=dev pour installer tsx nécessaire à build:data
- Le script build:data utilise tsx qui est dans devDependencies
- Cela devrait résoudre l'erreur exit code 127 pour build:data
- Utilisation de WORKDIR pour changer de répertoire de manière fiable
- Cela évite les problèmes avec cd qui peuvent échouer silencieusement
- WORKDIR garantit que npm est disponible dans le bon contexte
- Retour à /app après le build
- Vérification que npm est disponible
- Vérification du répertoire de travail
- Séparation des commandes build:data et build pour identifier quelle étape échoue
- Cela devrait aider à identifier pourquoi exit code 127
- Copie de radar, public, config.json, about.md, custom.css dans .techradar
- Exécution de build:data avant build pour générer les données
- Cela reproduit ce que fait techradar.js automatiquement
- Le build devrait maintenant fonctionner correctement
- Ajout de vérifications pour voir si npm est disponible
- Affichage du package.json en cas d'échec pour déboguer
- Cela devrait aider à identifier pourquoi npm run build échoue
- Séparation de la commande de création du hash en une commande RUN distincte
- Utilisation de fs.writeFileSync au lieu de echo pour éviter les problèmes d'échappement
- Cela devrait résoudre l'erreur exit code 2
- Le script techradar.js ne prend pas 'install' comme paramètre
- Création manuelle de .techradar en copiant depuis node_modules/aoe_technology_radar
- Création du fichier hash pour éviter la recréation à chaque fois
- Cela évite les problèmes avec la commande 'install' qui n'existe pas
- Utilisation de 'node node_modules/aoe_technology_radar/bin/techradar.js install'
- Ajout d'une vérification pour voir si le binaire existe
- Cela évite les problèmes avec les permissions ou le chemin du binaire
