Set-OPS/CLAUDE.md

CLAUDE.md — Set-OPS

Instruction principale

Claude Code doit lire et respecter AGENTS.md avant toute modification dans ce dépôt.

AGENTS.md est la source d’autorité principale pour :

• les principes Ansible ;
• la structure du dépôt ;
• les règles de sécurité ;
• les conventions de nommage ;
• la gestion du CHANGELOG.md ;
• les limites sur les actions destructives ;
• la règle : Codex ou Claude Code, jamais les deux en même temps.

En cas de contradiction entre CLAUDE.md et AGENTS.md, suivre AGENTS.md.

---

Règle d’or IA

Un seul agent IA travaille dans ce dépôt à la fois.

• Soit Codex.
• Soit Claude Code.
• Jamais les deux simultanément.

Avant de modifier quoi que ce soit, vérifier l’état du dépôt :

git status --short

Ne pas continuer si des changements non compris sont présents.

---

Comportement attendu de Claude Code

Avant de modifier :

1. Lire AGENTS.md.
2. Lire README.md, CHANGELOG.md et ansible.cfg s’ils existent.
3. Inspecter l’arborescence existante.
4. Identifier la portée exacte de la demande.
5. Proposer le plus petit changement utile.
6. Préserver les conventions existantes.
7. Ne pas réorganiser massivement le dépôt sans demande explicite.

Après modification :

1. Résumer les fichiers modifiés.
2. Indiquer les commandes de validation.
3. Signaler clairement ce qui n’a pas été testé.
4. Mettre à jour CHANGELOG.md si pertinent.

---

Limites de sécurité

Ne jamais commiter ou générer :

• mots de passe ;
• clés privées SSH ;
• tokens API ;
• secrets non chiffrés ;
• fichiers .env sensibles ;
• certificats privés ;
• backups réels ;
• exports de production non anonymisés ;
• fichiers contenant des informations confidentielles de Chezlepro Inc.

Toute variable sensible doit être gérée hors dépôt ou avec un mécanisme explicitement prévu, par exemple :

• Ansible Vault ;
• fichier local non versionné ;
• secret injecté hors dépôt.

---

Actions destructives

Toute action pouvant causer une perte d’accès, de données ou de disponibilité doit être protégée.

Exemples :

• suppression de paquets critiques ;
• modification SSH bloquante ;
• modification firewall ;
• redémarrage massif ;
• formatage disque ;
• modification de partitions ;
• suppression d’utilisateurs ;
• purge de données ;
• changement réseau pouvant couper l’accès.

Pour ces actions, exiger une confirmation explicite ou une variable du type :

confirm_destructive_action: true

Sans cette confirmation, refuser l’exécution.

---

SSH

État transitoire accepté pendant la construction :

PasswordAuthentication yes

État cible recommandé :

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Ne jamais désactiver l’authentification par mot de passe avant d’avoir confirmé que l’accès SSH par clé fonctionne.

---

Sudo

Le compte technique ansible peut être configuré avec sudo sans mot de passe lorsque c’est requis pour l’automatisation :

ansible ALL=(ALL) NOPASSWD:ALL

Cette règle doit être placée dans :

/etc/sudoers.d/90-ansible

Toujours valider avec :

visudo -cf /etc/sudoers.d/90-ansible

---

Ansible

Les playbooks doivent rester :

• idempotents ;
• lisibles ;
• sobres ;
• compatibles Debian 13 sauf exception documentée ;
• testables avec --check autant que possible ;
• exempts de dépendances SaaS ou cloud inutiles.

Préférer les modules ansible.builtin.*.

Éviter shell et command sauf nécessité réelle. Si une commande shell est utilisée, elle doit être encadrée avec les paramètres appropriés :

• changed_when
• failed_when
• creates
• removes

---

Validation minimale

Avant de considérer une modification comme terminée, tenter les validations pertinentes :

ansible-playbook --syntax-check playbooks/nom.yml
ansible-playbook -i inventories/lab/hosts.yml playbooks/nom.yml --check
ansible-lint

Si une commande de validation n’a pas été exécutée ou si un outil est absent, le signaler clairement.

---

CHANGELOG

Chaque modification significative doit être inscrite dans CHANGELOG.md.

Format recommandé :

## YYYY-MM-DD

### Ajouté
- ...

### Modifié
- ...

### Corrigé
- ...

---

Résumé opérationnel

Set-OPS est un dépôt d’exploitation réelle pour les serveurs de Chezlepro Inc.

Priorités :

• reproductibilité ;
• sobriété ;
• clarté ;
• sécurité ;
• maintenance ;
• autonomie ;
• résilience.

La complexité doit toujours être justifiée par un bénéfice opérationnel clair.