sdeg — le noyau en un coup d'œil
un système de développement logiciel génératif • lecture herméneutique du besoin
Une intuition → un minimum utile entre les mains d'un utilisateur, vite, puis re-lire la réalité pour ajuster l'idée.
Écrire du code et écrire l'intention : la même boucle.
Règle d'or
- Un enfant ne peut avancer si son parent n'est pas prêt.
- Les artefacts « analysés » deviennent COLD (gelés).
- Tout le reste est LIVING (modifiable, versionné).
Les portes ⛩ sont les moments où le noyau demande des preuves avant de laisser avancer.
pass
warn
fail
skip
Règles du jeu
- L'IA produit le contenu (markdown, frontmatter).
- Le noyau ne produit rien — il décide si l'on peut avancer.
- Seul
sdlc movemodifie l'état officiel. - Chaque événement part dans
.product/.events/.
Check mental : si je triche en jouant sur un artefact COLD,
le noyau ne re-scelle pas l'histoire → c'est visible.
le noyau ne re-scelle pas l'histoire → c'est visible.
Trois invariants à se rappeler
schema.js = vérité des portes
validators.js = preuves pures, pas d'effets de bord
sdlc.js = seul à écrire dans le registre
Zéro dépendance externe. Juste Node ≥ 18.
Tout est lisible en 3 fichiers de ~500 lignes.
Ce que le noyau fait bien
- Forcer à écrire avant d'avancer.
- Geler ce qui a été décidé (COLD) = anti-palimpseste.
- Distinguer preuve vérifiable / jugement humain.
- Journaliser : on peut relire l'histoire vraie.
Les tensions à regarder
- Lexique hérité (COMEX, EHS, OKR…) : corporate ≠ herméneutique.
- 10+ transitions avant la 1re livraison : long.
- 14 / 42 portes automatisées : humain encore très sollicité.
- IA produit… mais ne challenge pas l'hypothèse.
- COLD irréversible → pivots coûteux.
Prochaine question vivante : peut-on fusionner idée → livraison en ≤ 3 portes
sans perdre la capacité d'auditer ?