Discipline relative à la confidentialité et aux données personnelles
Les artefacts ZeroClaw sont publics : l’historique git, les versions publiées, les fixtures, les snapshots, le livre de documentation, chaque locale rendue. Tout ce que vous commitez est livré avec le projet pour toujours. Traitez la confidentialité comme une condition de merge, pas comme un effort de bonne volonté.
Ne jamais valider aucun de ces fichiers.
Dans le code, la documentation, les tests, les fixtures, les instantanés (snapshots), les journaux (logs), les exemples, les messages d’erreur ou les messages de commit :
- Noms réels
- Adresses e-mail personnelles
- Numéros de téléphone, adresses
- Jetons d’accès, clés API, identifiants
- Les identifiants de compte, les identifiants de session, tout ce qui permet d’identifier une personne réelle ou un compte.
- URLs privées (noms d’hôte internes, URLs signées S3, tout ce qui n’est pas destiné à être public)
Cette liste n’est pas exhaustive. Le principe : si cela permet d’identifier une personne réelle ou d’accéder à quelque chose, cela ne doit pas figurer dans le dépôt.
Utilisez des espaces réservés neutres
Les fixtures de test, les exemples, les messages d’erreur et les instantanés utilisent des espaces réservés génériques spécifiques au projet au lieu de données d’identité réelles. Palette recommandée :
| **Cas d’utilisation | Exemples |
|---|---|
| Étiquettes d’acteur | zeroclaw_user, zeroclaw_operator, zeroclaw_maintainer, test_user, user_a, project_bot |
| Étiquettes de service / d’exécution | zeroclaw_bot, zeroclaw_service, zeroclaw_runtime, zeroclaw_node |
| Étiquettes d’environnement | zeroclaw_project, zeroclaw_workspace, zeroclaw_channel |
| Noms d’hôte | example.com, host.invalid, 192.0.2.x (plage de documentation RFC 5737) |
| Adresses e-mail | user@example.com, bot@zeroclaw.invalid |
Les noms de tests, les messages d’assertion et le contenu des fixtures restent impersonnels et centrés sur le système : évitez le langage à la première personne et les formulations liées à une identité spécifique.
Lorsque vous devez faire référence à une identité
Si un test ou une doc nécessite réellement une identité de type rôle, utilisez uniquement des rôles à portée ZeroClaw : ZeroClawAgent, ZeroClawOperator, ZeroClawMaintainer. N’empruntez pas de vrais noms, même des pseudonymes : les pseudonymes finissent par redevenir réels avec le temps.
Les @-mentions GitHub dans les commentaires de PR/issue sont différentes : s’adresser à un contributeur par son pseudonyme est la façon de parler aux gens sur GitHub, et @WareWolf-MoonWall n’est pas une violation de la vie privée. La règle concerne le contenu stocké dans le dépôt (code, tests, fixtures, docs), pas les conversations dans les fils de discussion de PR/issue.
Reproduire des incidents externes
Si vous capturez une trace d’incident, un payload de journalisation ou une réponse externe dans un jeu de tests : redigez et anonymisez avant de valider. Les vrais identifiants de session, les vrais identifiants utilisateur, les vrais noms d’hôte et les vrais jetons d’authentification doivent tous passer par une étape de nettoyage. La version redigée est celle qui est livrée ; l’original reste hors du dépôt git.
Liste de contrôle avant le push
Avant de pousser, analysez le diff en attente spécifiquement pour détecter toute fuite d’identité :
sh
git diff --cached
Les formes à rechercher : tout ce qui ressemble à une adresse e-mail, une URL avec un nom d’hôte non public, une longue chaîne aléatoire qui pourrait être un jeton, ou un nom qui n’est pas le vôtre et qui ne provient pas d’un espace réservé spécifique à un projet.
Si une exécution CI a capturé une valeur réelle (un véritable ID de session dans un instantané, une vraie chaîne user agent contenant des informations d’identification, etc.) et qu’elle a été commitée, il s’agit d’un incident de confidentialité : ouvrez un ticket, nettoyez les données, effectuez un force-push si le commit vient d’arriver, et contactez les mainteneurs s’il a atterri sur master.
Pourquoi est-ce strict ?
La dernière catégorie, le fait de committer accidentellement une identité réelle, est difficile à annuler. Une fois qu’un vrai nom ou une vraie adresse e-mail atterrit sur master, il se propage immédiatement à travers les forks, les miroirs et les clones. Faire un squash ou un force-push corrige la branche publique mais n’atteint pas les copies. Le correctif le moins coûteux est l’analyse pre-commit ; tout ce qui vient après n’est que de la réduction des dégâts.