# DEV

## Standards

On suit ces deux guides :

- [GUIDE.md](./dev/GUIDE.md) : conventions générales de rédaction et de structure
- [REDACTION.md](./dev/REDACTION.md) : règles de style, ton et formatage

---

## Philosophie de développement

### Power of Ten

Tout le code produit suit les principes du [NASA Power of Ten](https://en.wikipedia.org/wiki/The_Power_of_10:_Rules_for_Developing_Safety-Critical_Code) :

1. **Flux de contrôle simples** — pas de `goto`, pas de récursion non bornée, pas de pointeurs de fonctions imbriqués.
2. **Boucles bornées** — toute boucle doit avoir une limite maximale d'itérations statiquement vérifiable.
3. **Pas d'allocation dynamique après l'initialisation** — allouer les ressources en amont, libérer proprement.
4. **Fonctions courtes et ciblées** — une fonction = une responsabilité, tient sur un écran.
5. **Densité d'assertions élevée** — valider les préconditions, postconditions et invariants explicitement.
6. **Portée des données minimale** — déclarer les variables au plus près de leur utilisation, limiter l'exposition.
7. **Vérification systématique des retours** — chaque valeur de retour ou promesse rejetée doit être gérée.
8. **Préprocesseur minimal** — éviter la magie implicite ; préférer la clarté à la concision.
9. **Limiter les pointeurs** — une seule indirection par niveau ; pas d'aliasing caché.
10. **Warnings = erreurs** — le linter et le compilateur doivent passer sans avertissement.

### Sécurité

Chaque contribution doit intégrer la sécurité dès la conception (*security by design*) :

- **Validation des entrées** — toute donnée externe (utilisateur, API tierce, fichier) est considérée malveillante jusqu'à preuve du contraire. Valider côté serveur, jamais uniquement côté client.
- **Moindre privilège** — un module n'accède qu'aux ressources strictement nécessaires à sa fonction.
- **Pas de secrets dans le code** — tokens, clés API, mots de passe passent exclusivement par des variables d'environnement ou un gestionnaire de secrets.
- **Dépendances auditées** — lancer `npm audit` avant chaque publication ; ne pas introduire de dépendance avec des vulnérabilités connues non corrigées.
- **Gestion des erreurs opaque** — les messages d'erreur exposés à l'utilisateur ne révèlent pas de détails internes (stack trace, chemin de fichier, requête SQL…).
- **Protection contre les injections** — utiliser exclusivement des requêtes paramétrées ou des ORM éprouvés ; jamais de concaténation de chaînes SQL/shell.
- **Authentification et sessions** — tokens signés, durée de vie limitée, révocation possible, rotation des secrets régulière.
- **En-têtes HTTP de sécurité** — `Content-Security-Policy`, `X-Content-Type-Options`, `Strict-Transport-Security` configurés sur toutes les routes.

---

## Publier le package

Le package `@zen/core` est publié sur le registre npm à `https://git.hyko.cx`.

### 1. Configurer l'authentification

Créer un token d'accès dans Gitea (Settings → Applications → Generate Token), puis l'enregistrer localement :

```bash
npm config set //git.hyko.cx/api/packages/zen/npm/:_authToken TOKEN
```

Remplacer `TOKEN` par le token généré.

### 2. Build et publish

```bash
npm publish
```