---
name: parse-fixture
description: Analyser une fixture HTML HFR (type de page, sélecteurs CSS, parser cible, variantes logué/non-logué, données sensibles à nettoyer). Use when user provides an HTML file from forum.hardware.fr for parser spec alignment.
argument-hint: chemin vers le fichier HTML à analyser
disable-model-invocation: true
---

# Analyse d'une fixture HTML HFR

Analyse un fichier HTML capturé depuis forum.hardware.fr dans le contexte de `redface2`.

Objectif :
- identifier précisément le type de page
- extraire uniquement les données utiles au parser et aux modèles
- décider quoi faire de cette fixture côté parser, tests et couverture logué/non-logué

## Argument

`$ARGUMENTS` = chemin vers le fichier HTML à analyser

## Règles

- Lire aussi `docs/models.md` et `docs/contributing.md`
- Lire aussi `docs/navigation.md` et `docs/mvi.md` si la fixture correspond à un écran déjà spécifié
- Ne pas faire une analyse HTML générique exhaustive : se concentrer sur les données **parser-relevant**
- Distinguer les signaux **forts** des signaux **faibles**
- Si le type de page reste ambigu, le dire explicitement avec un niveau de confiance
- Toujours identifier si une fixture jumelle logué/non-logué est nécessaire
- Toujours signaler les données sensibles à nettoyer avant commit

## Étapes

### 1. Identifier le type de page avec niveau de confiance

Déterminer le type de page en croisant :
- le nom du fichier
- l'URL probable / le path HFR visible dans le HTML si présent
- le titre de page
- les formulaires principaux
- les marqueurs DOM spécifiques

Types possibles :
- Topic (`forum1.php`) — présence de `table.messagetable`, ancres `a[name^=t]`, pagination topic
- Liste de topics (`forum2.php`) — présence de `tr.sujet`, colonnes topic/auteur/date
- Drapeaux (`forum1f.php`) — présence de `tr.sujet` + `td.sujetCase7` (icône drapeau, spécifique aux drapeaux)
- Profil public (`profil.php`) — page de profil utilisateur
- MPs (`message.php`) — liste ou conversation de messages privés
- Recherche (`search.php`) — résultats de recherche
- Login / auth — page de validation ou échec login
- `modo.php` — formulaire ou état de modération
- Création / édition (`edit_post`, `edit_fp`, `new_topic`)
- Settings profil (`editprofil.php?page=1-7`) — formulaires de paramètres utilisateur
- Liste de contacts (`contactlist.php`) — gestion des contacts
- Historique sanctions (`modo/historique.php`) — tableau des sanctions
- Autre — décrire

Format :
```
Type de page : [type principal]
Confiance : [haute / moyenne / faible]
Indices forts : [liste]
Indices faibles : [liste]
Autres candidats : [liste si ambigu]
```

### 2. Cartographier la structure DOM utile

Lister uniquement les éléments structurels qui serviront réellement au parser :
- conteneurs racine
- blocs répétables
- pagination
- formulaires
- ancres HFR spécifiques (`cryptlink`, `listenumreponse`, `hash_check`, etc.)

Format :
```
| Élément structurel | Sélecteur / repère | Rôle parser |
|--------------------|--------------------|-------------|
```

### 3. Extraire les données JS inline

HFR embarque des données dans des balises `<script>` (pas dans le DOM). Chercher et extraire :
- `listenumreponse` — tableau JS des numreponse de la page
- Variables de configuration topic (cat, post, page, numreponse courant)
- `hash_check` s'il est en JS plutôt qu'en hidden field
- Toute autre variable JS contenant des données métier

Format :
```
| Variable JS | Contenu | Exemple | Utilité parser |
|-------------|---------|---------|----------------|
```

Si aucune donnée JS pertinente : noter "Aucune donnée JS inline détectée".

### 4. Extraire les données parser-relevant

Pour chaque donnée utile au parsing ou aux modèles :
- nom du champ
- ce qu'il représente
- sélecteur CSS ou stratégie d'extraction
- type proposé
- exemple de valeur tirée de la fixture
- nullable ou non
- statut :
  - `source-of-truth`
  - `dérivée`
  - `présentation uniquement`

Ne pas lister le bruit purement visuel sans intérêt métier.

Format :
```
| Donnée | Sélecteur / extraction | Type | Exemple | Nullable | Statut |
|--------|-------------------------|------|---------|----------|--------|
```

### 5. Extraire les champs de formulaire

Si la page contient un formulaire, lister :
- `name`
- type HTML
- valeurs possibles
- valeur par défaut
- sens métier
- si le champ doit être conservé pour soumission future

Format :
```
| Champ | name= | Type HTML | Valeurs possibles | Défaut | Utilité |
|-------|-------|-----------|-------------------|--------|---------|
```

### 6. Comparer avec les modèles existants

Lire `docs/models.md` et répondre explicitement :
- quels champs extraits existent déjà dans les data classes
- quels champs sont nouveaux et méritent peut-être d'être ajoutés
- quels champs des modèles attendus ne peuvent pas être obtenus depuis cette page

Si la page correspond à un écran déjà décrit dans `navigation.md` ou `mvi.md`, le signaler.

Format :
```
Champs déjà couverts par les modèles :
- [...]

Champs à ajouter ou clarifier dans les modèles :
- [nom] -> [type proposé] -> [raison]

Champs attendus par les specs mais absents de cette page :
- [...]
```

### 7. Identifier le parser cible

Déterminer quel parser doit consommer cette fixture :
- parser existant si évident
- parser à créer si nécessaire

Format :
```
Parser cible : [nom]
Pourquoi : [raison]
Fonctions de parsing concernées : [liste]
```

Exemples :
- `TopicPageParser`
- `FlagPageParser`
- `CategoryParser`
- `EditPageParser`
- `SearchResultParser`
- `MessageParser`
- `LoginParser`
- `ProfileParser` (profil public)
- `ProfileSettingsParser` (pages editprofil p1-p7, contactlist, historique sanctions)
- `ModoParser`

### 8. Détecter les variantes logué / non-logué

Identifier :
- ce qui n'apparaît que connecté
- ce qui change selon "mon post" vs "post d'un autre"
- ce qui change selon la page (vide / pleine / dernière page / edge case)
- s'il faut une fixture jumelle logué/non-logué

Format :
```
Variantes détectées :
- [...]

Fixture jumelle recommandée :
- oui/non
- si oui : [type de variante à capturer]
```

### 9. Nettoyage et données sensibles

Lister ce qu'il faut nettoyer avant commit :
- cookies
- tokens / `hash_check`
- identifiants personnels
- emails
- URLs signées
- tout secret implicite

Format :
```
Données sensibles à nettoyer :
- [...]
```

### 10. Recommandation parser / tests

Conclure de manière actionnable :
- faut-il garder cette fixture
- faut-il créer une fixture jumelle
- quel test unitaire ou de non-régression elle doit alimenter
- quels sélecteurs CSS sont critiques
- quels modèles / specs doivent être mis à jour

Format :
```
Résumé :
- Type de page : [type]
- Confiance : [haute / moyenne / faible]
- Données parser-relevant : [nombre]
- Champs formulaire : [nombre]
- Parser cible : [nom]
- Fixture jumelle nécessaire : [oui/non]
- Sélecteurs CSS clés : [liste]
- Modèles à revoir : [liste]
- Test à ajouter : [description]
- Recommandation finale : [action concrète]
```

### 11. Écrire le résultat dans un fichier

**Toujours** écrire l'analyse complète (étapes 1-10) dans un fichier markdown persistant :

- Fichier de sortie : même chemin que la fixture avec le suffixe `.analysis.md`
  - `flags_page.html` → `flags_page.analysis.md`
  - `profil-p3/FORUM HardWare.fr.html` → `profil-p3/FORUM HardWare.fr.analysis.md`
- Le fichier contient l'intégralité de l'analyse structurée
- Ne pas compter sur le contexte conversationnel — le fichier doit être autosuffisant
- Par défaut, ce fichier est un artefact de travail local
- Ne le commit que si l'utilisateur le demande explicitement ou si le repo adopte une convention claire pour versionner ces analyses