instructions:
# Projet "Accueil / Hall" – Contexte pour Codex

Ce projet affiche une page d'accueil pour le hall d'immeuble avec :
- Horloge / date
- Horaires RATP (bus 310 + RER A)
- Bloc météo + nowcast + radar
- Bloc annonces / alertes (JSON)
- Une admin classique + une hyper admin de configuration

L'objectif est de **faire évoluer le code sans casser l'existant**, ni la disposition visuelle globale.

---

## 1. Techno & environnement

- Serveur local : WAMP64 sous Windows.
- Serveur cible : Apache/PHP (mutu OVH).
- Langage principal : **PHP 8+** (procédural + quelques helpers).
- Front : HTML / CSS / JavaScript vanilla (pas de framework JS lourd).
- Données : fichiers JSON dans `/data` (pas de base de données).

Ne pas introduire de framework type Laravel / Symfony / React / Vue sans demande explicite.

---

## 2. Architecture globale

### 2.1 Front principal

- `index.php`
  Page principale affichée sur l'écran du hall.
  Contient 4 zones logiques (même si ce n’est pas forcément nommé comme ça dans le code) :

  - **Z1 – Horloge / date**
    - Affiche l’heure en temps réel (Intl, timezone `Europe/Paris`).
    - Format 24h/12h piloté par configuration (Hyper Admin).

  - **Z2 – Transports**
    - **Bus 310 – La Haute Maison** : horaires RATP/IDFM via `ratp_proxy.php`.
    - **RER A – Noisy-Champs** (deux sens).
    - **RER A – Noisy-le-Grand Mont d’Est** (deux sens).
    - Nombre d’horaires affichés paramétrable via config (Hyper Admin).

  - **Z3 – Météo**
    - Données Open-Meteo (prévisions horaires).
    - Nowcast / radar (ex. Windy) intégrés dans un bloc météo.
    - Nombre de “pills” / heures affichées paramétrable via config.

  - **Z4 – Annonces / alertes**
    - Affichées à partir de `data/annonces.json`.
    - Mise en page via `data/ui.json` (template : `grid-2x2`, `grid-1plus2`, `grid-full`, etc.).
    - Thèmes de couleur via `annonces_theme.php` / config d’annonces.

- `front.js`
  JavaScript front principal, avec notamment :
  - Gestion de l’heure / date (Intl, timezone, locale).
  - Récupération et mise à jour des blocs RATP, météo, annonces.
  - Hot reload / rafraîchissement via endpoints d’admin (`admin/data_status.php`, `admin/annonces_widget.php?mode=fragment`, etc.).
  - Utilisation de la config Hyper Admin via `window.hyper` et `getConfig()`.

- `assets/`
  - CSS global (thèmes, layout, couleurs).
  - JS global (front, utilitaires).

### 2.2 Administration classique

- `annonces_admin.php`
  Interface d’administration des annonces :
  - Création / modification / suppression d’annonces.
  - Choix de la couleur (thème) via `annonces_theme.php` + chips couleurs.
  - Pinned / active, date de visibilité, etc.
  - Persistance dans `data/annonces.json`.

- `ui_admin.php`
  Interface d’administration de la mise en page des annonces :
  - Édite `data/ui.json`.
  - Gère :
    - `template` (ex : `grid-2x2`, `grid-1plus2`, `grid-full`, etc.),
    - `gap` (espacement),
    - `order` (ordre des annonces),
    - `takeover_id` (annonce plein écran),
    - `rowfull_id` (annonce full width sur une ligne),
    - `annonces_defaults` (ex : `maxlines`, `speed`, `pause`, etc.).
  - Ne touche pas au contenu des annonces ni aux thèmes de couleur.

- `config_annonces.php`
  Fichier central de config pour les annonces :
  - Définit les chemins (`ANN_PATH` vers `data/annonces.json`, etc.).
  - Configure des options globales (ex : tri, filtres par défaut).
  - Doit rester compatible avec les anciens JSON.

- `annonces_theme.php`
  Définit les thèmes de couleur pour les annonces :
  - `$ANN_THEME = ['neutral' => [...], 'info' => [...], 'warn' => [...], 'emph' => [...], ...]`
  - Utilisé à la fois en front et en admin.
  - Ne pas casser les clés existantes (risque de casser les couleurs des annonces existantes).

- `admin.js`
  JavaScript générique pour les pages d’admin :
  - `initializeToggles()` : switches actifs/inactifs, pinned, etc.
  - `initializeColorChips()` : gestion des thèmes couleurs.
  - `initializeInlineToggles()` : bascule AJAX des statuts.
  - `initializeDateHandling()` : gestion des champs date (format, min/max, etc.).
  - Gestion du changement de template UI, etc.

### 2.3 Hyper Admin / Configuration avancée

- Hyper Admin (fichier PHP dédié, ex: `hyperadmin.php` ou équivalent) :
  - Permet de modifier une **config globale** (HYPER_CONFIG) avec surcharge des valeurs par défaut :
    - Formats d’heure / date.
    - Nombre d’horaires RER / bus affichés.
    - Nombre de “pills” météo.
    - Intervalles de rafraîchissement (RATP, météo, hot reload, etc.).
  - Utilise un JSON de configuration (ex : `data/hyper_config.json` ou similaire).

- Sur le front, `front.js` utilise :
  - `getConfig(path, defaultValue)` pour aller chercher les valeurs dans `window.hyper`.
  - `isEnabled(...)` pour les flags ON/OFF.
  - Toujours **préserver les valeurs par défaut** si la config Hyper Admin est absente ou incomplète.

### 2.4 Proxy et données externes

- `ratp_proxy.php`
  Proxy pour les API RATP / IDFM (PRIM) :
  - Gère plusieurs endpoints (stop-monitoring, general-message, etc.).
  - Utilise une clé PRIM_API_KEY.
  - Retourne du JSON simplifié pour le front.
  - Doit gérer les timeouts, erreurs réseau, et potentiellement un cache.

- Bloc météo :
  - Récupère les données via Open-Meteo (prévisions horaires).
  - Utilise latitude, longitude, et un nom de ville configurés.
  - Doit rester robuste face aux erreurs réseau ou à des réponses partielles.

---

## 3. Données & fichiers JSON

- `data/annonces.json`
  - Contient la liste des annonces (titre, contenu, dates, pinned, active, couleur, etc.).
  - Format existant **à respecter** (ne pas changer la structure sans migration explicite).

- `data/ui.json`
  - Contient la configuration de mise en page des annonces :
    - `annonces_layout.template`
    - `annonces_layout.gap`
    - `annonces_layout.order`
    - `annonces_layout.takeover_id`
    - `annonces_layout.rowfull_id`
    - `annonces_defaults.maxlines`, `speed`, `pause`, etc.
  - Utilisé à la fois par le front et par `ui_admin.php`.

- `data/...` (autres JSON)
  - Config de thème, hyper config, etc.
  - Toujours préserver la compatibilité avec les fichiers déjà générés.

---

## 4. Contraintes fortes (à respecter absolument)

### 4.1 Ne pas casser la baseline

- **Ne pas modifier la structure globale** de la page hall :
  - Toujours conserver les 4 zones principales (Z1/Z2/Z3/Z4).
  - Ne pas changer radicalement la disposition CSS.
- Ne pas supprimer les mécanismes existants :
  - Horloge/date (Intl, timezone).
  - Affichage RATP / RER.
  - Affichage météo.
  - Affichage des annonces.

### 4.2 Fichiers et noms

- Ne pas renommer :
  - `index.php`,
  - `ratp_proxy.php`,
  - `annonces_admin.php`,
  - `ui_admin.php`,
  - `config_annonces.php`,
  - `annonces_theme.php`,
  - `helpers.php` (s’il existe),
  - `admin.js`, `front.js`,
  - ni les fichiers JSON dans `/data`, sauf demande explicite.

- Ne pas déplacer ces fichiers dans une autre arborescence sans préserver les chemins existants.

### 4.3 Style et compatibilité

- Code PHP :
  - Procédural, clair, avec des fonctions utilitaires.
  - Commentaires en **français**.
  - Pas de dépendance à un framework PHP externe.

- JavaScript :
  - Vanilla JS.
  - Garder le code compatible avec les navigateurs ciblés par le projet.
  - Ne pas introduire de bundler lourd (Webpack, Vite…) sans demande.

- CSS :
  - Conserver le thème existant (couleurs, panels, badges “maj”, etc.).
  - Ne pas casser l’apparence ni la disposition globale.

---

## 5. Attentes sur les modifications

### 5.1 Ce que tu peux faire

- Refactoriser pour :
  - améliorer la lisibilité,
  - factoriser du code dupliqué,
  - sécuriser (vérifs sur les entrées, robustesse face aux erreurs API),
  - optimiser légèrement les performances.

- Ajouter de nouvelles fonctionnalités :
  - **en suivant les patterns existants** (helpers, JSON de config, etc.).
  - en exposant les nouveaux paramètres dans Hyper Admin (si logique).

- Améliorer l’admin :
  - ergonomie (sans enlever de fonctionnalités),
  - CSS responsive pour l’admin,
  - validation côté serveur et côté front.

### 5.2 Ce que tu ne dois pas faire

- Ne pas :
  - supprimer des champs dans `annonces.json` ou `ui.json` sans migration.
  - changer la structure JSON sans une gestion explicite des anciens fichiers.
  - introduire une base de données à la place des JSON.
  - ajouter des `var_dump`, `die`, `echo` de debug restants en production.
  - laisser des `console.log` bruyants côté front (sauf logs utiles et maîtrisés).

---

## 6. Debug & outils spécifiques

- Le projet utilise des options de debug front (par ex. `?debug=1` / `?debug=2`) :
  - Conserver ces options.
  - Si tu ajoutes des niveaux de debug, bien les documenter.

- Le hot reload doit continuer à fonctionner :
  - Fonctions JS type `hotReload()` dans `front.js`.
  - Respecter les intervalles de polling configurables (en secondes, clampés en JS).

---

## 7. Résumé pour Codex

Quand tu proposes des changements :

1. **Ne change pas les noms de fichiers ni la structure globale.**
2. **Préserve le comportement actuel** par défaut (même si tu ajoutes des options).
3. **Respecte la config Hyper Admin** : toujours prévoir des valeurs par défaut si la config est absente.
4. **Explique les changements** dans les commentaires quand tu touches à des parties sensibles (annonces, RATP, météo, hot reload).
5. Évite les réécritures massives : favorise les **évolutions incrémentales** et les refactors ciblés.

source: cli

model_provider: openai


type: message

role: user

text:
# AGENTS.md instructions for C:\wamp64\www\cssp2AI

<INSTRUCTIONS>
# Projet "Accueil / Hall" – Contexte pour Codex

Ce projet affiche une page d'accueil pour le hall d'immeuble avec :
- Horloge / date
- Horaires RATP (bus 310 + RER A)
- Bloc météo + nowcast + radar
- Bloc annonces / alertes (JSON)
- Une admin classique + une hyper admin de configuration

L'objectif est de **faire évoluer le code sans casser l'existant**, ni la disposition visuelle globale.

---

## 1. Techno & environnement

- Serveur local : WAMP64 sous Windows.
- Serveur cible : Apache/PHP (mutu OVH).
- Langage principal : **PHP 8+** (procédural + quelques helpers).
- Front : HTML / CSS / JavaScript vanilla (pas de framework JS lourd).
- Données : fichiers JSON dans `/data` (pas de base de données).

Ne pas introduire de framework type Laravel / Symfony / React / Vue sans demande explicite.

---

## 2. Architecture globale

### 2.1 Front principal

- `index.php`
  Page principale affichée sur l'écran du hall.
  Contient 4 zones logiques (même si ce n’est pas forcément nommé comme ça dans le code) :

  - **Z1 – Horloge / date**
    - Affiche l’heure en temps réel (Intl, timezone `Europe/Paris`).
    - Format 24h/12h piloté par configuration (Hyper Admin).

  - **Z2 – Transports**
    - **Bus 310 – La Haute Maison** : horaires RATP/IDFM via `ratp_proxy.php`.
    - **RER A – Noisy-Champs** (deux sens).
    - **RER A – Noisy-le-Grand Mont d’Est** (deux sens).
    - Nombre d’horaires affichés paramétrable via config (Hyper Admin).

  - **Z3 – Météo**
    - Données Open-Meteo (prévisions horaires).
    - Nowcast / radar (ex. Windy) intégrés dans un bloc météo.
    - Nombre de “pills” / heures affichées paramétrable via config.

  - **Z4 – Annonces / alertes**
    - Affichées à partir de `data/annonces.json`.
    - Mise en page via `data/ui.json` (template : `grid-2x2`, `grid-1plus2`, `grid-full`, etc.).
    - Thèmes de couleur via `annonces_theme.php` / config d’annonces.

- `front.js`
  JavaScript front principal, avec notamment :
  - Gestion de l’heure / date (Intl, timezone, locale).
  - Récupération et mise à jour des blocs RATP, météo, annonces.
  - Hot reload / rafraîchissement via endpoints d’admin (`admin/data_status.php`, `admin/annonces_widget.php?mode=fragment`, etc.).
  - Utilisation de la config Hyper Admin via `window.hyper` et `getConfig()`.

- `assets/`
  - CSS global (thèmes, layout, couleurs).
  - JS global (front, utilitaires).

### 2.2 Administration classique

- `annonces_admin.php`
  Interface d’administration des annonces :
  - Création / modification / suppression d’annonces.
  - Choix de la couleur (thème) via `annonces_theme.php` + chips couleurs.
  - Pinned / active, date de visibilité, etc.
  - Persistance dans `data/annonces.json`.

- `ui_admin.php`
  Interface d’administration de la mise en page des annonces :
  - Édite `data/ui.json`.
  - Gère :
    - `template` (ex : `grid-2x2`, `grid-1plus2`, `grid-full`, etc.),
    - `gap` (espacement),
    - `order` (ordre des annonces),
    - `takeover_id` (annonce plein écran),
    - `rowfull_id` (annonce full width sur une ligne),
    - `annonces_defaults` (ex : `maxlines`, `speed`, `pause`, etc.).
  - Ne touche pas au contenu des annonces ni aux thèmes de couleur.

- `config_annonces.php`
  Fichier central de config pour les annonces :
  - Définit les chemins (`ANN_PATH` vers `data/annonces.json`, etc.).
  - Configure des options globales (ex : tri, filtres par défaut).
  - Doit rester compatible avec les anciens JSON.

- `annonces_theme.php`
  Définit les thèmes de couleur pour les annonces :
  - `$ANN_THEME = ['neutral' => [...], 'info' => [...], 'warn' => [...], 'emph' => [...], ...]`
  - Utilisé à la fois en front et en admin.
  - Ne pas casser les clés existantes (risque de casser les couleurs des annonces existantes).

- `admin.js`
  JavaScript générique pour les pages d’admin :
  - `initializeToggles()` : switches actifs/inactifs, pinned, etc.
  - `initializeColorChips()` : gestion des thèmes couleurs.
  - `initializeInlineToggles()` : bascule AJAX des statuts.
  - `initializeDateHandling()` : gestion des champs date (format, min/max, etc.).
  - Gestion du changement de template UI, etc.

### 2.3 Hyper Admin / Configuration avancée

- Hyper Admin (fichier PHP dédié, ex: `hyperadmin.php` ou équivalent) :
  - Permet de modifier une **config globale** (HYPER_CONFIG) avec surcharge des valeurs par défaut :
    - Formats d’heure / date.
    - Nombre d’horaires RER / bus affichés.
    - Nombre de “pills” météo.
    - Intervalles de rafraîchissement (RATP, météo, hot reload, etc.).
  - Utilise un JSON de configuration (ex : `data/hyper_config.json` ou similaire).

- Sur le front, `front.js` utilise :
  - `getConfig(path, defaultValue)` pour aller chercher les valeurs dans `window.hyper`.
  - `isEnabled(...)` pour les flags ON/OFF.
  - Toujours **préserver les valeurs par défaut** si la config Hyper Admin est absente ou incomplète.

### 2.4 Proxy et données externes

- `ratp_proxy.php`
  Proxy pour les API RATP / IDFM (PRIM) :
  - Gère plusieurs endpoints (stop-monitoring, general-message, etc.).
  - Utilise une clé PRIM_API_KEY.
  - Retourne du JSON simplifié pour le front.
  - Doit gérer les timeouts, erreurs réseau, et potentiellement un cache.

- Bloc météo :
  - Récupère les données via Open-Meteo (prévisions horaires).
  - Utilise latitude, longitude, et un nom de ville configurés.
  - Doit rester robuste face aux erreurs réseau ou à des réponses partielles.

---

## 3. Données & fichiers JSON

- `data/annonces.json`
  - Contient la liste des annonces (titre, contenu, dates, pinned, active, couleur, etc.).
  - Format existant **à respecter** (ne pas changer la structure sans migration explicite).

- `data/ui.json`
  - Contient la configuration de mise en page des annonces :
    - `annonces_layout.template`
    - `annonces_layout.gap`
    - `annonces_layout.order`
    - `annonces_layout.takeover_id`
    - `annonces_layout.rowfull_id`
    - `annonces_defaults.maxlines`, `speed`, `pause`, etc.
  - Utilisé à la fois par le front et par `ui_admin.php`.

- `data/...` (autres JSON)
  - Config de thème, hyper config, etc.
  - Toujours préserver la compatibilité avec les fichiers déjà générés.

---

## 4. Contraintes fortes (à respecter absolument)

### 4.1 Ne pas casser la baseline

- **Ne pas modifier la structure globale** de la page hall :
  - Toujours conserver les 4 zones principales (Z1/Z2/Z3/Z4).
  - Ne pas changer radicalement la disposition CSS.
- Ne pas supprimer les mécanismes existants :
  - Horloge/date (Intl, timezone).
  - Affichage RATP / RER.
  - Affichage météo.
  - Affichage des annonces.

### 4.2 Fichiers et noms

- Ne pas renommer :
  - `index.php`,
  - `ratp_proxy.php`,
  - `annonces_admin.php`,
  - `ui_admin.php`,
  - `config_annonces.php`,
  - `annonces_theme.php`,
  - `helpers.php` (s’il existe),
  - `admin.js`, `front.js`,
  - ni les fichiers JSON dans `/data`, sauf demande explicite.

- Ne pas déplacer ces fichiers dans une autre arborescence sans préserver les chemins existants.

### 4.3 Style et compatibilité

- Code PHP :
  - Procédural, clair, avec des fonctions utilitaires.
  - Commentaires en **français**.
  - Pas de dépendance à un framework PHP externe.

- JavaScript :
  - Vanilla JS.
  - Garder le code compatible avec les navigateurs ciblés par le projet.
  - Ne pas introduire de bundler lourd (Webpack, Vite…) sans demande.

- CSS :
  - Conserver le thème existant (couleurs, panels, badges “maj”, etc.).
  - Ne pas casser l’apparence ni la disposition globale.

---

## 5. Attentes sur les modifications

### 5.1 Ce que tu peux faire

- Refactoriser pour :
  - améliorer la lisibilité,
  - factoriser du code dupliqué,
  - sécuriser (vérifs sur les entrées, robustesse face aux erreurs API),
  - optimiser légèrement les performances.

- Ajouter de nouvelles fonctionnalités :
  - **en suivant les patterns existants** (helpers, JSON de config, etc.).
  - en exposant les nouveaux paramètres dans Hyper Admin (si logique).

- Améliorer l’admin :
  - ergonomie (sans enlever de fonctionnalités),
  - CSS responsive pour l’admin,
  - validation côté serveur et côté front.

### 5.2 Ce que tu ne dois pas faire

- Ne pas :
  - supprimer des champs dans `annonces.json` ou `ui.json` sans migration.
  - changer la structure JSON sans une gestion explicite des anciens fichiers.
  - introduire une base de données à la place des JSON.
  - ajouter des `var_dump`, `die`, `echo` de debug restants en production.
  - laisser des `console.log` bruyants côté front (sauf logs utiles et maîtrisés).

---

## 6. Debug & outils spécifiques

- Le projet utilise des options de debug front (par ex. `?debug=1` / `?debug=2`) :
  - Conserver ces options.
  - Si tu ajoutes des niveaux de debug, bien les documenter.

- Le hot reload doit continuer à fonctionner :
  - Fonctions JS type `hotReload()` dans `front.js`.
  - Respecter les intervalles de polling configurables (en secondes, clampés en JS).

---

## 7. Résumé pour Codex

Quand tu proposes des changements :

1. **Ne change pas les noms de fichiers ni la structure globale.**
2. **Préserve le comportement actuel** par défaut (même si tu ajoutes des options).
3. **Respecte la config Hyper Admin** : toujours prévoir des valeurs par défaut si la config est absente.
4. **Explique les changements** dans les commentaires quand tu touches à des parties sensibles (annonces, RATP, météo, hot reload).
5. Évite les réécritures massives : favorise les **évolutions incrémentales** et les refactors ciblés.

</INSTRUCTIONS>


text:
<environment_context>
  <cwd>C:\wamp64\www\cssp2AI</cwd>
  <approval_policy>on-request</approval_policy>
  <sandbox_mode>read-only</sandbox_mode>
  <network_access>restricted</network_access>
  <shell>powershell</shell>
</environment_context>


text: codex login


codex login


approval_policy: on-request

type: read-only

effort: medium

summary: auto