Charte et Règles de Contribution aux Buckets de `erable`

Navigation : Documentation > Chartes de Contribution
Concept associé : Concept : Contribution & Gouvernance

Sommaire

Bucket	Vocation	Niveau d'Audit & Critères	Document de Référence
`core`	Outils CLI / TUI essentiels et majeurs (FOSS)	Stricte : Minimum 500 étoiles GitHub/GitLab, maintenance active, multiplateforme, tests passants obligatoires.	01. Règles du Bucket Core
`gui`	Applications fenêtrées graphiques (FOSS)	Élevée : Intégration bureau vérifiée (`shortcuts.toml`), décompression propre.	02. Règles du Bucket GUI
`community`	Outils émergents, utilitaires de niche	Automatisée : Linter AST anti-exfiltration obligatoire, validation TOML stricte.	03. Règles du Bucket Community
`commercial`	Logiciels propriétaires, freewares, sous licence commerciale	Légale & Stricte : Pas de redistribution illégale d'archive, consentement obligatoire de licence (`--accept-license`).	04. Règles du Bucket Commercial

Format Découpé Obligatoire : Tout paquet doit être soumis dans son propre répertoire packages/<initiale>/<nom_paquet>/ avec le dossier modulaire parts/.
Immutabilité des Binaires : Les paquets ne doivent jamais tenter d'écrire ou de modifier des fichiers en dehors de leur dossier d'installation assigné $ctx.paths.install.
Respect du Confinement Local & Zero Egress : Les scripts de cycle de vie (pre_install.nu, post_install.nu, pre_uninstall.nu, post_uninstall.nu) ne doivent réaliser aucune communication réseau ni accès aux secrets sous peine de rejet bloquant immédiat par l'audit CI (scripts/ci/audit_package_scripts.py).
Sanity Checks Obligatoires : Tout paquet doit obligatoirement définir des tests sanitaires dans parts/verification.toml (check_version et check_help), exécutés et validés par les runners CI sur les OS cibles.