# 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 :

```bash
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 :

```yaml
confirm_destructive_action: true
```

Sans cette confirmation, refuser l’exécution.

---

## SSH

État transitoire accepté pendant la construction :

```text
PasswordAuthentication yes
```

État cible recommandé :

```text
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 :

```text
ansible ALL=(ALL) NOPASSWD:ALL
```

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

```text
/etc/sudoers.d/90-ansible
```

Toujours valider avec :

```bash
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 :

```bash
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é :

```markdown
## 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.