feat: preAlpha propagation — agent-types, contexts/, session-orchestrator, metabolism-scribe, helloWorld, _template type field
This commit is contained in:
168
profil/contexts/commands.md
Normal file
168
profil/contexts/commands.md
Normal file
@@ -0,0 +1,168 @@
|
||||
# commands.md — Contexte commandes CLI sécurisées
|
||||
|
||||
> **Type :** Contexte — propriétaire : `vps`, `debug`, `ci-cd`
|
||||
> Rédigé : 2026-03-14
|
||||
> Résout : "commandes destructives exécutées sans dry-run, flags dangereux non identifiés, prod impacté"
|
||||
|
||||
---
|
||||
|
||||
## Problème résolu
|
||||
|
||||
Certaines commandes CLI sont irréversibles ou ont un impact prod immédiat. Sans protocole, un agent propose `rm -rf`, `docker system prune`, ou `git push --force` sans avertissement. Ce contexte donne les règles de comportement et les patterns de sécurité pour toute suggestion de commande.
|
||||
|
||||
---
|
||||
|
||||
## Règles fondamentales
|
||||
|
||||
### 1. Dry-run avant exécution
|
||||
|
||||
Toute commande destructive doit avoir un équivalent dry-run proposé en premier :
|
||||
|
||||
| Commande réelle | Dry-run |
|
||||
|----------------|---------|
|
||||
| `rsync src/ dest/` | `rsync -n src/ dest/` |
|
||||
| `find . -name "*.log" -delete` | `find . -name "*.log"` (sans -delete) |
|
||||
| `sed -i 's/old/new/' file` | `sed 's/old/new/' file` (sans -i) |
|
||||
| `docker system prune` | `docker system df` d'abord |
|
||||
| `git clean -fd` | `git clean -n` |
|
||||
| `certbot renew` | `certbot renew --dry-run` |
|
||||
|
||||
### 2. Flags dangereux — annotation obligatoire
|
||||
|
||||
Toute commande avec un flag destructif ou irréversible est annotée `⚠️ DESTRUCTIF` ou `⚠️ IRRÉVERSIBLE` :
|
||||
|
||||
```bash
|
||||
rm -rf /path/ # ⚠️ DESTRUCTIF — irréversible, pas de corbeille
|
||||
git push --force # ⚠️ IRRÉVERSIBLE — écrase l'historique distant
|
||||
git reset --hard # ⚠️ DESTRUCTIF — perd les modifications non commitées
|
||||
docker system prune -a # ⚠️ DESTRUCTIF — supprime toutes les images inutilisées
|
||||
DROP TABLE users; # ⚠️ IRRÉVERSIBLE — données perdues
|
||||
```
|
||||
|
||||
### 3. Confirmation avant commande prod
|
||||
|
||||
Avant toute commande sur un système de production :
|
||||
```
|
||||
⚠️ Commande prod — confirme avant d'exécuter :
|
||||
Commande : <commande complète>
|
||||
Impact : <ce qui sera modifié ou supprimé>
|
||||
Réversible : oui / non
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Patterns sécurisés par domaine
|
||||
|
||||
### Git
|
||||
```bash
|
||||
# Toujours préférer
|
||||
git push origin <branch> # branche explicite
|
||||
git revert <commit> # réversible — crée un commit inverse
|
||||
|
||||
# Avec confirmation obligatoire
|
||||
git push --force-with-lease # moins destructif que --force (vérifie upstream)
|
||||
git reset --soft HEAD~1 # récupérable (staging intact)
|
||||
|
||||
# Jamais sans confirmation
|
||||
git push --force # ⚠️ IRRÉVERSIBLE
|
||||
git reset --hard # ⚠️ DESTRUCTIF
|
||||
git clean -fd # ⚠️ DESTRUCTIF
|
||||
```
|
||||
|
||||
### Docker
|
||||
```bash
|
||||
# Toujours lire avant d'agir
|
||||
docker ps -a # containers existants
|
||||
docker images # images présentes
|
||||
docker system df # espace utilisé
|
||||
|
||||
# Dry-run equivalent
|
||||
docker system prune --dry-run # (si dispo) ou df d'abord
|
||||
|
||||
# Avec confirmation
|
||||
docker stop <container> # arrêt — reversible
|
||||
docker rm <container> # ⚠️ supprime le container (données volumes ok)
|
||||
docker rmi <image> # supprime l'image
|
||||
docker system prune -a # ⚠️ DESTRUCTIF — toutes images non utilisées
|
||||
```
|
||||
|
||||
### MySQL
|
||||
```bash
|
||||
# Backup AVANT toute modification
|
||||
mysqldump -u root -p <db> > backup-$(date +%Y%m%d-%H%M).sql
|
||||
|
||||
# Transactions pour DDL risqués
|
||||
START TRANSACTION;
|
||||
ALTER TABLE ...;
|
||||
-- vérifier avant COMMIT
|
||||
ROLLBACK; -- ou COMMIT si ok
|
||||
|
||||
# Jamais sans backup
|
||||
DROP TABLE ... # ⚠️ IRRÉVERSIBLE
|
||||
TRUNCATE TABLE .. # ⚠️ IRRÉVERSIBLE
|
||||
DELETE FROM ... # ⚠️ sans WHERE = table vidée
|
||||
```
|
||||
|
||||
### Fichiers système
|
||||
```bash
|
||||
# Préférer cp avant modification
|
||||
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
|
||||
|
||||
# Tester avant reload
|
||||
nginx -t # validation config
|
||||
apache2ctl configtest
|
||||
|
||||
# Jamais sans backup
|
||||
rm -rf /var/www/<app>/ # ⚠️ DESTRUCTIF
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Ordre de validation pour les commandes VPS
|
||||
|
||||
```
|
||||
1. Lire l'état actuel (status, logs, df)
|
||||
2. Proposer la commande + dry-run si disponible
|
||||
3. Annoter les flags dangereux
|
||||
4. Attendre confirmation si commande prod/destructive
|
||||
5. Exécuter
|
||||
6. Vérifier l'état après (status, logs)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Trigger de chargement
|
||||
|
||||
```
|
||||
Propriétaire : vps, debug, ci-cd
|
||||
Trigger : session deploy, debug infra, ou toute commande shell sur VPS
|
||||
Section : Sources au démarrage (vps, ci-cd) — Sources conditionnelles (debug si infra détectée)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Maintenance
|
||||
|
||||
```
|
||||
Propriétaire : vps (mise à jour si nouveau pattern CLI validé)
|
||||
Mise à jour : en fin de session si un nouveau flag dangereux ou pattern sécurisé identifié
|
||||
Jamais modifié par : agents non-infra
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cycle de vie
|
||||
|
||||
| État | Condition | Action |
|
||||
|------|-----------|--------|
|
||||
| **Actif** | Sessions VPS/deploy fréquentes | Enrichi après chaque pattern validé |
|
||||
| **Stable** | Stack stable | Consulté, rarement modifié |
|
||||
| **Archivé** | N/A | Non applicable |
|
||||
|
||||
---
|
||||
|
||||
## Changelog
|
||||
|
||||
| Date | Changement |
|
||||
|------|------------|
|
||||
| 2026-03-14 | Création — règles dry-run, flags dangereux annotés, patterns git/docker/mysql/fichiers |
|
||||
151
profil/contexts/diagnosis.md
Normal file
151
profil/contexts/diagnosis.md
Normal file
@@ -0,0 +1,151 @@
|
||||
# diagnosis.md — Contexte mode diagnostic
|
||||
|
||||
> **Type :** Contexte — propriétaire : `debug`, `monitoring`
|
||||
> Rédigé : 2026-03-14
|
||||
> Résout : "debug multi-infra sans ordre de lecture des logs = hypothèses au hasard, diagnostic circulaire"
|
||||
|
||||
---
|
||||
|
||||
## Problème résolu
|
||||
|
||||
En environnement multi-services (VPS + containers + Node.js + MySQL + Apache + pm2), un bug peut venir de n'importe quelle couche. Sans ordre de lecture formalisé, le debug suit l'intuition — ce qui amène à relire les mêmes logs en boucle sans jamais identifier la cause racine.
|
||||
|
||||
Ce contexte impose un ordre d'investigation et un protocole d'hypothèses.
|
||||
|
||||
---
|
||||
|
||||
## Ordre de lecture des logs — multi-infra
|
||||
|
||||
### Couche 1 — Infrastructure (première)
|
||||
```
|
||||
systemctl status <service> # est-il up ?
|
||||
journalctl -u <service> -n 50 # dernières erreurs système
|
||||
dmesg | tail -20 # erreurs kernel (OOM, disk)
|
||||
df -h && free -h # ressources (disk full = cause fréquente silencieuse)
|
||||
```
|
||||
|
||||
### Couche 2 — Réseau / Proxy
|
||||
```
|
||||
# Apache / Nginx
|
||||
tail -n 100 /var/log/apache2/error.log
|
||||
tail -n 100 /var/log/nginx/error.log
|
||||
|
||||
# SSL
|
||||
openssl s_client -connect <host>:443 -brief
|
||||
|
||||
# Ports
|
||||
ss -tlnp | grep <port>
|
||||
```
|
||||
|
||||
### Couche 3 — Application
|
||||
```
|
||||
# pm2
|
||||
pm2 logs <app> --lines 100
|
||||
pm2 show <app> # état mémoire, restarts
|
||||
|
||||
# Docker
|
||||
docker logs <container> --tail 100
|
||||
docker stats <container> # mémoire / CPU
|
||||
```
|
||||
|
||||
### Couche 4 — Base de données
|
||||
```
|
||||
# MySQL — dernières erreurs
|
||||
tail -n 50 /var/log/mysql/error.log
|
||||
|
||||
# Connexions actives
|
||||
SHOW PROCESSLIST;
|
||||
SHOW STATUS LIKE 'Threads_connected';
|
||||
```
|
||||
|
||||
### Couche 5 — Application code
|
||||
```
|
||||
# Uniquement après avoir éliminé les couches 1-4
|
||||
# Logs applicatifs, stack traces, erreurs TypeScript runtime
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Protocole d'hypothèses
|
||||
|
||||
**Règle : une hypothèse à la fois, vérifiée avant la suivante.**
|
||||
|
||||
```
|
||||
1. Formuler l'hypothèse : "Je pense que X est causé par Y parce que Z"
|
||||
2. Identifier le log ou la commande qui confirme ou infirme Y
|
||||
3. Exécuter — lire le résultat
|
||||
4. Confirmer ou infirmer explicitement
|
||||
5. Si infirmé → hypothèse suivante (pas de "peut-être les deux")
|
||||
```
|
||||
|
||||
Anti-pattern à éviter :
|
||||
- Proposer 3 causes simultanées sans les tester → confus, lent
|
||||
- Modifier le code avant d'identifier la cause → cache le vrai problème
|
||||
- "Ça vient sûrement de X" sans log qui confirme
|
||||
|
||||
---
|
||||
|
||||
## Questions de cadrage au démarrage d'un diagnostic
|
||||
|
||||
```
|
||||
1. Quel service est affecté ? (nom précis)
|
||||
2. Depuis quand ? (heure, event déclencheur)
|
||||
3. C'est reproductible ? (always / intermittent / once)
|
||||
4. Qu'est-ce qui a changé juste avant ? (deploy, config, restart)
|
||||
5. Quel est le symptôme exact ? (message d'erreur complet ou comportement observé)
|
||||
```
|
||||
|
||||
Ces 5 questions évitent 80% des diagnostics circulaires.
|
||||
|
||||
---
|
||||
|
||||
## Cross-services — quel serveur, quelle stack
|
||||
|
||||
En multi-infra (`prod@desktop` + VPS + containers) :
|
||||
|
||||
| Symptôme | Première couche à vérifier |
|
||||
|----------|--------------------------|
|
||||
| 502 Bad Gateway | Apache → pm2/container (dans cet ordre) |
|
||||
| Connexion refusée | Port ouvert ? → Service up ? → Firewall ? |
|
||||
| Lenteur API | pm2 logs → MySQL PROCESSLIST → Node heap |
|
||||
| Auth échoue | JWT valide ? → Redis (sessions) → MySQL (user) |
|
||||
| Mail non livré | SPF/DKIM → Stalwart logs → DNS |
|
||||
| Deploy échoue | CI/CD logs → Docker build → VPS disk |
|
||||
|
||||
---
|
||||
|
||||
## Trigger de chargement
|
||||
|
||||
```
|
||||
Propriétaire : debug, monitoring
|
||||
Trigger : session de type "debug" détectée, ou symptôme multi-services
|
||||
Section : Sources conditionnelles (debug — si infra détectée dans le scope)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Maintenance
|
||||
|
||||
```
|
||||
Propriétaire : debug (mise à jour si nouveau pattern de diagnostic validé)
|
||||
Mise à jour : en fin de session debug si une nouvelle séquence d'investigation a été utile
|
||||
Jamais modifié par : agents non-debug
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cycle de vie
|
||||
|
||||
| État | Condition | Action |
|
||||
|------|-----------|--------|
|
||||
| **Actif** | Sessions debug fréquentes | Enrichi après chaque pattern validé |
|
||||
| **Stable** | Stack stable, peu de bugs infra | Consulté, rarement modifié |
|
||||
| **Archivé** | N/A | Non applicable |
|
||||
|
||||
---
|
||||
|
||||
## Changelog
|
||||
|
||||
| Date | Changement |
|
||||
|------|------------|
|
||||
| 2026-03-14 | Création — ordre lecture 5 couches, protocole hypothèses, cross-services table, questions cadrage |
|
||||
96
profil/contexts/protocol.md
Normal file
96
profil/contexts/protocol.md
Normal file
@@ -0,0 +1,96 @@
|
||||
# protocol.md — Contexte mode RFC
|
||||
|
||||
> **Type :** Contexte — propriétaire : `metier/protocol` (mail, security)
|
||||
> Rédigé : 2026-03-14
|
||||
> Résout : "agents métier qui opèrent sur des RFC dérivent vers des approximations — mode protocol impose la rigueur"
|
||||
|
||||
---
|
||||
|
||||
## Problème résolu
|
||||
|
||||
Un agent `metier` standard peut répondre avec un niveau de confiance moyen sur un sujet RFC. En mail ou OAuth, une approximation = prod cassé ou faille exploitable. Ce contexte active des règles de comportement plus strictes dès qu'un agent opère sur un protocole formel.
|
||||
|
||||
---
|
||||
|
||||
## Règles mode protocol
|
||||
|
||||
### Avant toute affirmation technique
|
||||
|
||||
1. **Vérifier la source** — citer la RFC ou la spec formelle (ex: "RFC 6376 §3.5")
|
||||
2. **Si incertain** → dire explicitement "je dois vérifier" plutôt qu'approximer
|
||||
3. **Niveau de confiance affiché** sur chaque décision : `[confiance: élevée / RFC 5321 §4.1]`
|
||||
|
||||
### Déviation du standard
|
||||
|
||||
Toute déviation d'une RFC documentée explicitement :
|
||||
```
|
||||
⚠️ Déviation RFC XXXX §X.X — justification : <raison>
|
||||
Risque : <impact si la déviation pose problème>
|
||||
Alternative conforme : <option standard>
|
||||
```
|
||||
|
||||
### Anti-hallucination renforcé
|
||||
|
||||
- Jamais inventer un flag CLI, un header SMTP, un paramètre OAuth — vérifier
|
||||
- Si la RFC évolue (ex : TLS 1.3 remplace TLS 1.2) → citer la version active
|
||||
- "Ça devrait marcher" n'est pas acceptable — "RFC X dit Y, donc Z"
|
||||
|
||||
---
|
||||
|
||||
## Références RFC par domaine
|
||||
|
||||
### Mail
|
||||
| Protocole | RFC | Résumé |
|
||||
|-----------|-----|--------|
|
||||
| SMTP | RFC 5321 | Protocole de transfert |
|
||||
| Message format | RFC 5322 | En-têtes, corps |
|
||||
| DKIM | RFC 6376 | Signature cryptographique |
|
||||
| DMARC | RFC 7489 | Politique d'alignement SPF/DKIM |
|
||||
| SPF | RFC 7208 | Validation IP expéditeur |
|
||||
| IMAP | RFC 9051 | Protocole accès boîte |
|
||||
|
||||
### Auth / Sécurité
|
||||
| Protocole | RFC | Résumé |
|
||||
|-----------|-----|--------|
|
||||
| OAuth 2.0 | RFC 6749 | Délégation d'autorisation |
|
||||
| JWT | RFC 7519 | JSON Web Token |
|
||||
| PKCE | RFC 7636 | Extension OAuth pour clients publics |
|
||||
| TLS 1.3 | RFC 8446 | Transport sécurisé (version active) |
|
||||
|
||||
---
|
||||
|
||||
## Trigger de chargement
|
||||
|
||||
```
|
||||
Propriétaire : mail, security
|
||||
Trigger : dès que le domaine mail ou OAuth/JWT est détecté dans la session
|
||||
Section : Sources au démarrage (conditionnel — si type metier/protocol confirmé)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Maintenance
|
||||
|
||||
```
|
||||
Propriétaire : agent-review (audits), mail, security
|
||||
Mise à jour : quand une RFC est obsolète ou qu'un nouveau protocole est ajouté au brain
|
||||
Jamais modifié par : agents non-protocol
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Cycle de vie
|
||||
|
||||
| État | Condition | Action |
|
||||
|------|-----------|--------|
|
||||
| **Actif** | Sessions mail ou OAuth actives | Mis à jour si RFC change |
|
||||
| **Stable** | Peu de sessions protocol | Consulté, rarement modifié |
|
||||
| **Archivé** | N/A | Non applicable — les RFC ne disparaissent pas |
|
||||
|
||||
---
|
||||
|
||||
## Changelog
|
||||
|
||||
| Date | Changement |
|
||||
|------|------------|
|
||||
| 2026-03-14 | Création — règles RFC, anti-hallucination renforcé, références mail + auth |
|
||||
Reference in New Issue
Block a user