원클릭으로 Manus에서 모든 스킬 실행

diagnostic-donnees-perimees

스타3

포크1

업데이트2026년 7월 9일 17:43

Diagnostique pourquoi une section du site Vitrine (treemap des enjeux, partis, etc.) affiche des données périmées ou erronées, en distinguant un bug de transformation frontend d'un problème de raffineur/backend. À utiliser quand on signale des données « périmées », « pas à jour », « figées » ou « erronées » dans un module, ou qu'un onglet jour/semaine/mois semble incorrect. Déclencheurs : « données périmées », « pas à jour », « le treemap montre du vieux », « trouve pourquoi ».

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

ellipse-science

ellipse-science/vitrine-showcase.github.io

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

관련 직업SOC

SOC 직업 분류 기준

소프트웨어 개발자컴퓨터 및 수학직·SOC 15-1252

SKILL.md

readonly

이 저장소의 다른 Skills

같은 저장소

redaction-editoriale

ellipse-science/vitrine-showcase.github.io

Règles de rédaction de TOUT texte public de la Vitrine — libellés de modules, phrases éditoriales (générées ou non), infobulles, page Méthodologie, billets, textes d'interface. À charger AVANT d'écrire ou de modifier le moindre texte affiché sur le site, y compris dans une maquette destinée à devenir le site.

2026-07-143

verification-responsive

ellipse-science/vitrine-showcase.github.io

Vérifier le rendu responsive AVANT de pousser toute modification frontend (composant, CSS, layout, template de section). À utiliser dès qu'une PR touche `components/`, `app/**/*.css`, `app/page.tsx` ou une page statique de `public/` : dérouler la checklist des viewports (desktop cibles, frontières de breakpoints, mobile 375), tester le débordement horizontal et TOUS les états dynamiques du composant, puis remplir la case « Vérification responsive » du template de PR. Déclencheurs : « vérifie le mobile », « responsive », « breakpoint », « ça déborde », toute retouche de globals.css ou d'un composant de section.

2026-07-123

redaction-methodologie

ellipse-science/vitrine-showcase.github.io

Rédiger ou réviser la page Méthodologie PUBLIQUE (public/methodologie/index.html) au bon registre : pour le grand public, transparente et scientifique, mais SANS jargon interne (noms de raffineurs, de tables, de colonnes) ni détails qui exposeraient la propriété intellectuelle ou les droits des médias. À utiliser dès qu'on écrit, simplifie ou révise une section de la métho, ou qu'un passage est jugé « trop technique », « trop interne » ou « pas pour le public ». Complète synchro-methodologie (qui dit QUOI/QUAND mettre à jour ; celui-ci dit COMMENT l'écrire). Déclencheurs : « rédige la métho », « simplifie la métho », « c'est trop technique », « vulgarise cette section », « la métho parle aux devs ».

2026-07-113

synchro-methodologie

ellipse-science/vitrine-showcase.github.io

Garder la page Méthodologie (public/methodologie/index.html) ET les docs vivantes du pipeline (public/docs/horaire-refiners-2026.html, workflow-vitrine-2025-swimlanes.html) TOUJOURS synchronisées avec le comportement réel du pipeline. À utiliser pour toute PR (vitrine, aws-refiners, aws-infra) qui touche un calcul, un seuil, un horaire, la collecte, une représentation graphique ou un raffineur — déterminer les sections/docs impactées et proposer la mise à jour. Aussi : remplir la section « Impact méthodologie » du template de PR, et vérifier la véracité des déclarations des collègues avant tout merge.

2026-07-103

gestion-horaires-raffineurs

ellipse-science/vitrine-showcase.github.io

Change l'horaire (cron / fréquence) d'un raffineur du pipeline radar. À utiliser quand on demande de modifier QUAND ou à quelle FRÉQUENCE un raffineur tourne (ex. « fais tourner radar-issues-score à 8h »). Le changement se fait dans le repo aws-infra, PAS dans vitrine-showcase. Déclencheurs : « change l'horaire du raffineur », « fais tourner à Xh », « fréquence de rafraîchissement », « modifie le cron », « planifie le raffineur ».

2026-07-083

ajout-section-data-bound

ellipse-science/vitrine-showcase.github.io

Ajoute une nouvelle section data-bound au site Vitrine (afficher une table Athena sur la page). À utiliser quand on demande d'ajouter ou d'afficher une section, un module ou un bloc alimenté par des données (scores de partis, enjeux, etc.), de brancher une nouvelle table, ou d'activer une table dormante de scripts/tables.json. Déclencheurs : « ajoute une section », « affiche la table X », « nouveau module data », « branche les données ».

2026-07-083

name

diagnostic-donnees-perimees

description

Diagnostic : données périmées (frontend vs backend)

Procédure complète : docs/reference/procedures.md (§ « Diagnosing frontend vs backend problems »). Les données sont hydratées au build, pas au runtime — aucun fetch client à suspecter.

Ordre de vérification

Es-tu sur une branche/commit à jour ? git status, puis git fetch et compare à origin/main (ex. git rev-list --count main..origin/main). Une branche en retard affiche de vieilles données alors que le site déployé est frais — c'est fréquent, et ce n'est pas un bug.
Fraîcheur du JSON local : cat public/data/meta.json (generatedAt) et ls -la public/data/refined/day/ ; regarde le date_utc/tag le plus récent dans issues_score_day.json.
Pipeline de refresh : historique du workflow refresh-data.yml (onglet Actions) ou git log -- public/data/.
Athena en direct (pour vérifier la source) : snippet R dans docs/reference/aws-backend.md. Nom de table DEV entre guillemets (à cause du tiret) : SELECT * FROM "vitrine_datamart-issues_score_day" LIMIT 10.
Bug de transform frontend ? lib/data/headlineEvents.ts : latestIssueRow() (choix de la dernière ligne) et buildPeriodData() (agrégation jour/semaine/mois).

Cas particulier : la Une des Unes / Deux solitudes (headline-events.json)

Chaîne réelle (validée dans le code 2026-07-09 — ignorer toute doc qui dit autre chose) : glue r-media-headlines (:03) → radar-data-preparation (:06, stepper 1 bloc 4h/run) → salient-objects (:16) → salient-index (:42) → radar-event-salience (:51, 6×/jour) → table headline_events_4h → fetch du site (HH:00). Ce n'est PAS radar-headlines-issues ni headline-of-headlines (plus consommés par le site).

Retard « normal » connu : la grille de blocs du code est 00-04/04-08/… alors que le plan de réforme visait 3-7/7-11/… → à 8 h le site montre le bloc 0-4 h, qui reste affiché jusqu'à 16 h. Une Une « en retard de 4-12 h » le matin n'est donc pas une panne tant que ce chantier n'est pas livré : aws-refiners#195 (phase A = grille ; phases B/C = suivi 24 h par storyline, union des médias, pic de saillance). L'indicateur « Dernière mise à jour du module » à l'écran reflète le bloc réellement affiché.

Vraie panne si : le bloc affiché a > 12 h, OU meta.json.generatedAt est vieux (fetch cassé), OU les runs d'event-salience/salient-index échouent (CloudWatch). Bug date connu : bloc 20-24 daté +1 jour, corrigé par aws-refiners PR #197 — si observé, vérifier que #197 est déployée.

Gotcha à considérer avant de conclure à un bug

Avec peu de jours de données, les onglets jour / semaine / mois peuvent sembler identiques — c'est attendu ; la divergence apparaît à mesure que l'historique s'accumule. Ne conclus pas trop vite à un bug.