senke/veza
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
veza/docs/FRUGALITY.md
senke ad60247f33 feat: global update including storybook setup and backend fixes 
- Web: Setup Storybook, added addons, configured Tailwind, added stories for UI components.
- Backend: Updated API router, database, workers, and auth in common.
- Stream Server: Removed SQLx queries and updated auth.
- Docs & Scripts: Updated documentation and recovery scripts.
2026-02-02 19:34:14 +01:00

2.2 KiB
Raw Blame 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 n’est 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 n’est 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.