Modifier la documentation

La documentation est la source de verite du systeme. Une doc fausse est pire qu'aucune doc.

Qui peut modifier quoi

L'utilisateur

L'utilisateur peut tout modifier. C'est le proprietaire du systeme.

Le CEO

Les agents

Quand modifier

Modifier immediatement

• Erreur factuelle (chiffre faux, lien casse)
• Information obsolete (version, date)
• Typo ou formulation ambigue

Modifier apres validation

• Ajout d'une nouvelle section
• Changement de structure
• Modification d'un processus
• Ajout/suppression d'une regle

Ne jamais modifier

• Sans avoir lu le contenu actuel
• Sans comprendre l'impact
• Sous pression sans reflexion
• Plusieurs fichiers en meme temps sans plan

Comment modifier sans casser

Principe 1 : Lire avant d'ecrire

Toujours lire le fichier complet avant de le modifier. Comprendre le contexte, les liens, les dependances.

Principe 2 : Un changement a la fois

Une modification = un commit = un sujet. Pas de mega-commit qui change 15 fichiers.

Principe 3 : Verifier les liens

Si la modification change un titre, une URL, ou un concept :

• Chercher toutes les references dans la doc
• Mettre a jour les liens
• Verifier que rien n'est casse

# Chercher les references a un fichier
grep -r "daily-routine" content/docs/

Principe 4 : Tester la navigation

Apres modification, verifier que la doc se build correctement.

npm run build

Principe 5 : Documenter le changement

Chaque modification significative → entree dans le changelog.

Comment informer le CEO

Si un agent modifie la documentation, il doit informer le CEO.

Format de notification

Doc mise a jour : /docs/operate/costs.mdx
Raison : Mise a jour des estimations de cout apres 30 jours d'observation
Changements :
- Tokens CEO : 50K → 42K (reel observe)
- Cout mensuel total : $61.50 → $55
Impact : Aucun sur le fonctionnement. Estimations plus precises.

Le CEO inclut cette info dans le debrief.

Structure de la documentation

La doc suit une hierarchie logique.

docs/
├── getting-started/     # Premier contact
├── foundations/          # Philosophie, regles
├── system/              # Architecture technique
├── agents/              # Documentation des agents
├── tools/               # MCPs et outils
├── crons/               # Jobs planifies
├── operate/             # Operations quotidiennes
├── evolve/              # Faire evoluer le systeme
├── reference/           # Glossaire, index, use cases
├── adaptation/          # Apprentissage et evolution
├── skills-procs/        # Skills et procedures
└── methods/             # Methodes et patterns

Conventions de nommage

Frontmatter obligatoire

---
title: Titre de la page
description: "Description courte et precise."
---

Checklist modification

• Fichier lu en entier
• Raison de la modification claire
• Changement minimal et cible
• Liens verifies
• Build OK
• Changelog mis a jour
• CEO informe (si agent)

Lecture liee

• Modifier le systeme pour les changements techniques
• Auto-modification pour les limites du CEO
• Changelog pour l'historique