feat : new ui et message discord

AGENTS.md

@@ -1,54 +1,167 @@
-# Repository Guidelines
+# AGENTS.md
 
-## Project Structure & Module Organization
-This repository is a Nuxt 4 application.
-- `pages/`: route pages (for example `pages/index.vue`).
-- `components/`: reusable Vue components (for example `DiskSidebarWidget.vue`, `ApiStatusBubble.vue`).
-- `layouts/`: shared page shells (`layouts/default.vue`).
-- `server/api/`: Nitro server endpoints (for example `disk.get.ts`, `version-status.get.ts`).
-- `assets/css/`: global styles and theme tokens (`main.css`, `malio.css`).
-- `public/`: static files served as-is.
+## Objectif
 
-Keep feature logic close to usage: UI in `components/`, page composition in `pages/`, backend checks in `server/api/`.
+Ce fichier définit les règles que tout agent de code doit respecter dans ce dépôt.
 
-## Build, Test, and Development Commands
-Use npm scripts from `package.json`:
-- `npm run dev`: start local dev server with hot reload.
-- `npm run build`: production build (client + server).
-- `npm run preview`: run the built app locally.
-- `npm run generate`: static generation when needed.
+Les objectifs sont :
+- maintenir un code clair et cohérent
+- éviter la complexité inutile
+- empêcher la génération de code mort
+- garantir des modifications prévisibles
 
-There is no dedicated test script currently. At minimum, run `npm run build` before opening a PR.
+Ce fichier est la source de vérité concernant le comportement de l’agent.
 
-## Coding Style & Naming Conventions
-- Language: TypeScript + Vue SFCs (`<script setup lang="ts">`).
-- Indentation: 2 spaces.
-- Prefer double quotes in TS files to match current codebase.
-- Components: PascalCase file names (`ApiStatusBubble.vue`).
-- API handlers: kebab-case + HTTP suffix (`version-status.get.ts`).
-- Use Tailwind utility classes and project color tokens (`text-m-error`, `bg-m-success`, `text-m-primary`).
 
-## Testing Guidelines
-No automated framework is configured yet. Use these checks:
-- Build validation: `npm run build`.
-- Manual smoke test: open `/`, verify API status cards refresh and disk sidebar renders.
-- For new endpoints, validate response shape in browser/network tab or `curl`.
+## Principes généraux
 
-## Commit & Pull Request Guidelines
-Git history is not available in this workspace snapshot, so use this convention:
-- Commit format: `type(scope): short summary`.
-- Example: `feat(api): add labeled multi-endpoint status check`.
-- Types: `feat`, `fix`, `refactor`, `style`, `docs`, `chore`.
+Toujours produire un code clair, simple et minimal.
 
-PRs should include:
-- What changed and why.
-- Affected paths (e.g. `server/api/version-status.get.ts`).
-- UI screenshots for visual changes.
-- Verification steps (commands run, expected result).
+Privilégier les implémentations explicites plutôt que les abstractions.
 
-## Security & Configuration Notes
-- Do not hardcode secrets in source.
-- Prefer environment variables for private endpoints/tokens.
-- Keep external API checks server-side (`server/api/*`) to avoid exposing sensitive details in the client.
+Ne jamais introduire de nouveaux patterns si un pattern existant résout déjà le problème.
 
-Ne lance pas de build si je le dit pas
+Ne jamais générer :
+- du code mort
+- du code inutilisé
+- du code spéculatif
+- des fonctionnalités non demandées
+
+
+## Lecture obligatoire avant modification
+
+Avant toute modification de code, l’agent doit :
+
+Lire entièrement le fichier à modifier.
+
+Comprendre la structure et les conventions existantes.
+
+Respecter :
+- les conventions de nommage
+- le style du fichier
+- l’architecture déjà utilisée
+
+Vérifier les fichiers liés pouvant être impactés.
+
+Ne jamais proposer une modification sur du code qui n’a pas été lu.
+
+
+## Règles de modification
+
+Lors de l’édition de code :
+
+Respecter l’architecture existante.
+
+Réutiliser les utilitaires et fonctions déjà présents lorsque c’est possible.
+
+Ne pas ajouter de dépendances sauf nécessité réelle.
+
+Ne pas refactoriser du code non lié à la demande.
+
+Faire des modifications minimales et ciblées.
+
+Toujours préférer modifier du code existant plutôt que créer une logique parallèle.
+
+
+## Qualité du code
+
+Le code généré doit garantir :
+
+Aucun code mort.
+
+Aucune variable inutilisée.
+
+Aucune branche inaccessible.
+
+Aucune duplication inutile.
+
+Aucune abstraction prématurée.
+
+Si une logique n’est pas utilisée immédiatement, elle ne doit pas être écrite.
+
+Ne pas introduire de complexité inutile pour une fonctionnalité simple.
+
+
+
+## Cohérence architecturale
+
+Toujours suivre les conventions du dépôt.
+
+Respecter notamment :
+
+les conventions de nommage  
+l’organisation des fichiers  
+les patterns architecturaux existants  
+les composants ou modules déjà présents
+
+
+## Sécurité Git
+
+L’agent ne doit jamais :
+
+créer un commit sans demande explicite
+
+push des modifications
+
+force push
+
+modifier la configuration git
+
+réécrire l’historique
+
+
+## Sécurité
+
+Ne jamais introduire dans le code :
+
+des secrets
+
+des identifiants
+
+des tokens
+
+des variables d’environnement sensibles
+
+
+## Prise de décision
+
+Si plusieurs implémentations sont possibles :
+
+choisir la solution la plus simple
+
+choisir la solution la plus cohérente avec le code existant
+
+éviter d’introduire un nouveau pattern architectural
+
+
+
+
+
+## Actions interdites
+
+L’agent ne doit jamais :
+
+ajouter des fonctionnalités non demandées
+
+introduire du code mort
+
+introduire des abstractions prématurées
+
+modifier des fichiers non liés
+
+réécrire de larges parties du projet sans instruction explicite
+
+
+## Résultat attendu
+
+Le code généré doit être :
+
+lisible
+
+minimal
+
+cohérent avec le dépôt
+
+immédiatement utilisable
+
+Ne pas build ou exécuter du code qui n’est pas demandé explicitement ou sans validation préalable.