veza/docs/FRUGALITY.md

49 lines
2.2 KiB
Markdown
Raw Normal View History

# VEZA FRUGALITY MANIFESTO
> **"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."** — Antoine de Saint-Exupéry
This document is the **Supreme Law** of the Veza codebase.
It supersedes all other documentation, feature requests, or developer preferences.
## 1. The Prohibitions (Non-Negotiable)
These are not guidelines. These are **interdictions**.
* 🔴 **Un test lent nest pas un test vital.**
* Si un test prend plus de quelques secondes, il doit être déplacé dans `legacy` ou supprimé.
* Le pipeline Vital doit être instantané.
* 🔴 **Un warning Rust ou Go est un défaut de conception.**
* Il n'y a pas de "petit warning". Le code bruyant cache les vrais problèmes.
* Tout warning bloque le merge.
* 🔴 **Une dépendance frontend non justifiée est un bug.**
* Ajouter une librairie de 50KB pour éviter d'écrire 10 lignes de CSS est une faute professionnelle.
* Tout ajout à `package.json` doit être défendu par écrit.
* 🔴 **Un dépassement de budget nest pas “temporaire”.**
* On n'augmente pas la RAM "juste pour le MVP".
* Si ça ne rentre pas, on simplifie la feature, on ne demande pas plus de ressources.
## 2. Invariants Matériels
Veza est conçu pour le **tiers-monde numérique**, pas pour la Silicon Valley.
* **CPU**: 1 Core. Pas de multithreading gratuit.
* **RAM**: 1 Go pour l'ensemble du stack (Backend + DB + Services).
* **GPU**: 0. Le logiciel doit fonctionner en rendu software pur (`LIBGL_ALWAYS_SOFTWARE=1`).
* **Réseau**: Doit survivre à 3G H+ et aux coupures intermittentes.
## 3. La Règle du Frontend
**Aucun nouveau test frontend n'est VITAL par défaut.**
* Le frontend est volatile. Le tester excessivement crée de la rigidité, pas de la robustesse.
* Un test frontend n'entre dans `plans/vital.fmf` que s'il prouve qu'il protège un invariant critique (ex: "L'app démarre", "Le chat s'affiche").
* Tout le reste va dans `plans/legacy.fmf` ou n'existe pas.
## 4. Modification de la Loi
Ce document peut être amendé, mais seulement après un **débat explicite**.
On ne change pas la constitution en douce dans une PR de feature.