Clément SAILLANTKill_LIFE 🚀 — Modèle de Projet Embarqué IA-Natif
Sommaire
Bienvenue dans Kill_LIFE, le modèle open source pour systèmes embarqués IA où chaque étape est traçable, chaque evidence pack est rangé, et chaque agent suit un workflow sécurisé. Ce projet vise la reproductibilité, la conformité et l’automatisation pour l’embarqué IA multi-cibles.
🧩 Présentation
Kill_LIFE est un modèle agentique pour systèmes embarqués IA, orienté spec-first, sécurité et traçabilité. Il s’appuie sur des agents spécialisés, des workflows automatisés et une arborescence claire.
🧩 Workflows agentiques, gates et rituels
Le projet Kill_LIFE s’appuie sur une architecture agentique inspirée des approches spec-first (Spec Kit), des méthodes d’exécution orchestrée (Agent Zero) et des rituels d’industrialisation (Agent OS / BMAD), adaptée aux contraintes hardware : toolchains multiples, tests HIL, traçabilité et evidence packs reproductibles.
🧠 1) Les agents (qui fait quoi)
- PM / Spec Agent : transforme l’intention en specs testables (acceptance criteria, non-goals, risques).
- Architect Agent : découpe en modules, interfaces, contraintes (RTOS, mémoire, IO, latence).
- Firmware Agent : implémente, maintient la compatibilité multi-cibles, garantit les invariants.
- HW Agent : contraintes PCB / alimentation / signaux / bring-up, checklists hardware.
- QA / Test Agent : tests unitaires + intégration + smoke HIL, stabilise les reproductions.
- Doc Agent : docs “opérables” (runbooks), exemples, troubleshooting, changelog.
- Compliance / Release Agent : conformité (standards), SBOM, versions, evidence pack final.
Règle d’or : un agent = une responsabilité + des artefacts obligatoires. Pas d’action “magique”.
🧱 2) Les gates (les points de contrôle non négociables)
Chaque gate produit un ensemble d’artefacts et échoue si les preuves attendues ne sont pas présentes.
| Gate | Objectif | Output attendu (exemples) |
|---|---|---|
| G0 – Spec Freeze | specs claires, testables | spec.md, critères d’acceptation, risques |
| G1 – Design Freeze | arch & interfaces validées | ADRs, diagrammes, mapping IO, BOM/contraintes |
| G2 – Build Reproductible | build identique sur machines propres | logs build, versions toolchain, checksums |
| G3 – Tests Logiciels | unit + intégration stables | rapports tests, couverture (si dispo), logs |
| G4 – Smoke Hardware (HIL) | flash + test minimal sur cible | logs flash, preuve boot, tests IO/audio/etc. |
| G5 – Conformité & Sécurité | règles projet respectées | lint, scan secrets, licence/SBOM, checklist |
| G6 – Release Evidence Pack | paquet final auditable | bundle signé, changelog, preuves complètes |
“ultra simple” : garde 4 gates (Spec / Build / Test / Release) et ajoute HIL & conformité en “extensions”.
🕯️ 3) Les rituels (comment on avance sans dériver)
-
Spec Review (rituel hebdo / par feature)
On valide : objectifs, non-objectifs, critères d’acceptation, risques, contraintes HW. -
Design Review (avant implémentation)
On valide : interfaces, compromis (RAM/flash/latence), plan de test. -
RC (Release Candidate) ritual
On exécute la chaîne complète “clean” et on publie un RC live summary + evidence pack. -
Post-RC / Postmortem (si gate casse)
On documente la cause, la prévention, et on ajoute un test/guardrail.
Kill_LIFE privilégie les rituels “courts mais systématiques” : moins de réunions, plus de preuves.
📦 4) Evidence packs (la preuve comme produit)
Un evidence pack = tout ce qu’il faut pour refaire et vérifier :
- la spec
- l’archi / décisions (ADR)
- la build (versions + logs)
- les tests (rapports + logs)
- la preuve hardware (flash + smoke)
- la conformité (SBOM / licence / scans / checklists)
- le binaire final (+ hash)
Convention de rangement (simple et robuste) :
artifacts/<date_or_tag>/<target>/...logs/<gate>/...evidence/<release>/manifest.json(ou.md) listant quoi / où / hash
🔐 5) Sécurité & traçabilité (le “workflow sécurisé”)
- Least privilege : un agent n’a accès qu’aux dossiers/outils nécessaires.
- No secrets in prompts : jamais de tokens/keys dans les specs ou logs.
- Actions traçables : chaque exécution écrit un log + un manifeste.
- Dry-run first : par défaut, on peut simuler (build/test) avant de flasher.
Les liens entre agents, gates et rituels sont explicités dans les plans de chaque agent : chaque passage de gate implique des artefacts produits par les agents, chaque rituel s’appuie sur ces artefacts pour garantir la cohérence et la traçabilité.
L’ensemble du workflow est pensé comme une partition modulaire : chaque agent joue sa partie, les gates sont les mesures, les rituels les temps forts.
Kill_LIFE, c’est l’agentique… mais avec des gants : chaque action laisse une trace, chaque décision devient un artefact, chaque build est reproductible. Inspiré par les méthodes spec-first et l’orchestration multi-agents, le projet impose des gates, des rituels et des evidence packs pour que l’embarqué IA reste fiable, vérifiable, et industrialisable.
« Bienvenue dans le meilleur des mondes : ici, chaque commit est validé, chaque gate est passé, et chaque agent sait que la vraie liberté, c’est d’avoir un evidence pack bien rangé. » — Aldous Huxley, version CI/CD
🧩 Architecture & Principes
- Spec-first : Chaque évolution commence par une définition claire dans
specs/(Spec Generator FX). - Injection de standards : Standards versionnés et profils injectés (Agent OS).
- BMAD / BMAD-METHOD : Agents par rôles (PM, Architecte, Firmware, QA, Doc, HW), rituels, gates, handoffs (agents/, bmad/).
- Tool-first : Scripts reproductibles (tools/), evidence pack dans
artifacts/. - Pipeline hardware/firmware : Bulk edits, exports, tests, conformité, snapshots.
- Sécurité & conformité : Sanitisation, sorties sûres, sandboxing, scope guard, anti-prompt injection (OpenClaw Sandbox).
Schaeffer : Les agents du pipeline écoutent le bruit des specs comme une symphonie de sons trouvés.
🏅 Conformité & Couverture
Ce projet vise la conformité stricte avec les specs (RFC2119) et la traçabilité par evidence pack. Les badges ci-dessus indiquent :
- Conformité RFC2119 : respect des exigences formelles et validation par gates.
- Evidence Pack : traçabilité des artefacts produits à chaque étape.
- Test Coverage : taux de couverture des tests automatisés (rapport détaillé).
Pour toute question fréquente, consulte la FAQ.
« La réponse à la question ultime de la vie, de l’univers et du développement embarqué IA : 42 specs, 7 agents, et un pipeline qui ne panique jamais. » « Kill_LIFE, c’est l’open source embarqué version IA, mais aussi un clin d’œil à la fin du monde : ici, on ne craint ni l’apocalypse, ni les bugs, ni les injections de prompt. On rêve, on code, on documente, et on fait des bulk edits comme des réplicants en quête de conformité. »
— Le README qui ne panique jamais car qui sait si Les particules font l’amour ironique ?
✨ Fonctionnalités principales
- Développement guidé par la spec : User stories, contraintes, architecture, plans, backlog.
- Automatisation : Issue → PR avec tests unitaires, sanitisation, evidence pack.
- Multi-cibles : ESP32, STM32, Linux, tests natifs.
- Pipeline matériel : KiCad, exports SVG/ERC/DRC/BOM/netlist, bulk edits.
- Conformité : Profils injectés, validation automatique.
- OpenClaw : Labels & commentaires sanitisés, jamais de commit/push, sandbox obligatoire.
🖥️ Schéma agentique (Mermaid)
flowchart TD
Issue[Issue (label ai:*)] --> PR[Pull Request]
PR --> Gate[Gate (tests, conformité)]
Gate --> Evidence[Evidence Pack]
Evidence --> CI[CI/CD]
CI --> Deploy[Deploiement multi-cible]
PR --> Agents[Agents (PM, Architect, Firmware, QA, Doc, HW)]
Agents --> Specs[specs/]
Agents --> Firmware[firmware/]
Agents --> Hardware[hardware/]
Agents --> Docs[docs/]
Agents --> Compliance[compliance/]
Agents --> Tools[tools/]
Agents --> OpenClaw[openclaw/]
Specs --> Standards[standards/]
Firmware --> Tests[tests/]
Hardware --> Exports[exports/]
Compliance --> Evidence
OpenClaw --> Sandbox[Sandbox]
---
## 📋 Plan de suivi d’audit & amélioration continue
Ce dépôt fait l’objet d’un suivi régulier :
- Les axes d’amélioration sont listés dans [specs/04_tasks.md](specs/04_tasks.md) et suivis via issues labellisées `ai:qa` ou `ai:tasks`.
- Toute action corrective ou suggestion doit être documentée dans une PR dédiée, avec evidence pack associé.
- Les audits de sécurité, conformité et couverture de tests sont à planifier à chaque release majeure.
- Les contributeurs sont invités à consulter la checklist d’audit (en tête du README) avant toute contribution majeure.
- La traçabilité des actions est assurée par les evidence packs ([docs/evidence/](docs/evidence/)).
- Un audit badge complet est généré et publié à chaque release majeure : voir [docs/badges/audit_2026-02-19.md](docs/badges/audit_2026-02-19.md).
- Les guides badge sont accessibles dans [docs/badges/](docs/badges/) pour chaque badge.
Pour toute question ou suggestion, ouvrir une issue ou contacter l’équipe via [docs/FAQ.md](docs/FAQ.md).
Parmegiani : Un bulk edit, c’est une métamorphose électronique, un peu comme un pack d’évidence qui se transforme en nuage de sons. <
🗺️ Schéma de flux
Voir KIKIFOU/diagramme.md pour un diagramme complet du pipeline.
🧾 Table de mapping
Voir KIKIFOU/mapping.md pour une synthèse des dossiers et dépendances.
🚀 Installation & initialisation
Prérequis
Installation rapide
Pour démarrer sur Kill_LIFE :
- Créer et activer l’environnement virtuel Python
python3 -m venv .venv source .venv/bin/activate - Installer les dépendances principales
pip install -r requirements-mistral.txt pip install -r tools/compliance/requirements.txt - Vérifier l’installation
pip list pip-audit - Exécuter les scripts critiques
PYTHONPATH="$(pwd)" .venv/bin/python tools/compliance/use_profile.py prototype
Voir aussi : INSTALL.md, RUNBOOK.md, SECURITY.md
🤝 Contribuer
- Forke le dépôt et clone-le localement.
- Suis le guide d’onboarding (docs/index.md, RUNBOOK.md).
- Ajoute des exemples minimalistes pour chaque agent (voir agents/).
- Propose des blocks hardware, profils de conformité, tests.
- Documente tes scripts et contributions.
- Ouvre une PR, passe les gates, fournis un evidence pack.
- Respecte les conventions de commit et de labelling (
ai:*). - Vérifie la conformité et la sécurité (voir section Sécurité).
Pour toute question, consulte la [FAQ](docs/FAQ.md) ou ouvre une issue.
« Les particules rêvent-elles d’électron-ironique ? Peut-être font-elles l’amour dans le dossier hardware, pendant que les agents QA se demandent si la conformité est un rêve ou une réalité. » — Inspiré par Le Réplicant de K. Dick & Les particules font-elles l’amour « J’ai vu des evidence packs briller dans l’obscurité près des gates S1… »
🔗 Liens utiles
- Documentation complète
- RUNBOOK opérateur
- Guide d’installation
- Synthèse technique et recommandations
- Diagramme pipeline
- Mapping dossiers
- Gate Runner — passe les gates, évite les bugs.
🛡️ Sécurité & conformité
- OpenClaw : sandbox obligatoire, jamais d’accès aux secrets ou au code source.
- Workflows CI : validation, sanitisation, scope guard, anti-prompt injection.
- Evidence packs : tous les rapports dans
artifacts/<domaine>/<timestamp>/. - Tests hardware reproductibles via scripts documentés.
- Respect des conventions de labelling et de commit.
🛠️ Fonctions clés
- specs/ : Source de vérité, plans, backlog.
- standards/ : Standards globaux, profils injectés.
- bmad/ : Gates, rituels, templates.
- agents/ : Prompts pour chaque rôle.
- tools/ : Scripts IA, cockpit, conformité, watch.
- firmware/ : PlatformIO, tests Unity, multi-cibles.
- hardware/ : KiCad, bulk edits, exports.
- openclaw/ : Labels, commentaires, sandbox.
- .github/ : Workflows CI, scope guard, enforcement labels.
- licenses/ : MIT, CERN OHL v2, CC-BY 4.0.
🦾 Workflows agents
- Scope guard : Le label détermine les dossiers modifiables.
- Ouvre une issue avec le label
ai:spec. - L’agent PM/Architecte génère le plan et l’architecture.
- L’agent Firmware implémente le code dans
firmware/. - L’agent QA ajoute des tests Unity.
- Evidence pack généré automatiquement.
Générateur de phrases dystopiques pour motiver les contributeurs.
- Bulk Edit Hardware KiCad
- Documentation & Conformité
- Ouvre une issue avec le label
ai:docsouai:qa. - L’agent Doc met à jour
docs/et le README. - L’agent Conformité valide le profil et génère le rapport.
RtFM: Les agents QA écoutent le paysage du repo, à la recherche d’un bug caché dans le souffle. Trouve la phrase supprimée par le sanitizer, score affiché.
- Ouvre une issue avec le label
📝 Installation & Sécurité
Un guide d’installation détaillé (INSTALL.md) explique comment installer le projet, configurer les environnements, sécuriser OpenClaw, lancer les tests hardware, générer la documentation et utiliser Docker. Un script d’installation unique (install_kill_life.sh) automatise tout : dépendances, spec, profil de conformité, environnement Python, modules IA/hardware/firmware, tests, doc, Docker, et vérification de la sécurité OpenClaw.
Sécurité OpenClaw : sandbox obligatoire, jamais d’accès aux secrets ou au code source. Tests hardware reproductibles via scripts documentés.
🧬 Architecture agentique avancée
- Structure multi-agent (BMAD) : rôles PM, Architecte, Firmware, QA, Doc, HW, orchestrés par rituels, gates et handoffs.
- Développement spec-first : chaque évolution commence par une spécification, standards versionnés et profils injectés.
- Automatisation & sécurité : workflows CI, sanitisation, sorties sûres, scope guard, anti-prompt injection, OpenClaw sandbox.
- Multi-cibles & pipelines reproductibles : ESP32, STM32, Linux, tests natifs, bulk edits hardware KiCad, exports automatisés.
- Documentation claire & onboarding : README détaillé, FAQ, workflows, arborescence graphique, guides d’installation, politique de contribution.
❓ FAQ
Q : Comment démarrer rapidement ? R : Suis la section « Installation & initialisation » ou le guide INSTALL.md.
Q : Comment installer tout automatiquement ?
R : Utilise le script install_kill_life.sh.
Q : Comment sécuriser OpenClaw ? R : Sandbox obligatoire, jamais d’accès aux secrets ou au code source.
Q : Comment lancer les tests hardware ? R : Suis les scripts documentés dans le README et INSTALL.md.
Q : Comment contribuer ? R : Ajoute des profils, améliore les scripts, enrichis les standards, et respecte la politique anti-injection.
Q : Où trouver la documentation complète ? R : Voir docs/index.md, RUNBOOK.md, INSTALL.md.
🦾 Workflows détaillés
1. Spécification → Implémentation Firmware
- Rédige la spec dans
specs/. - Ouvre une issue avec le label
ai:spec. - L’agent PM/Architecte génère le plan et l’architecture.
- L’agent Firmware implémente le code dans
firmware/. - L’agent QA ajoute des tests Unity.
- Evidence pack généré automatiquement.
2. Bulk Edit Hardware KiCad
- Ouvre une issue avec le label
ai:hw. - L’agent HW effectue un bulk edit via
tools/hw/schops. - Exporte ERC/DRC, BOM, netlist.
- Snapshot avant/après dans
artifacts/hw/<timestamp>/.
3. Documentation & Conformité
- Ouvre une issue avec le label
ai:docsouai:qa. - L’agent Doc met à jour
docs/et le README. - L’agent Conformité valide le profil et génère le rapport.
RtFM: Les agents QA écoutent le paysage du repo, à la recherche d’un bug caché dans le souffle. Trouve la phrase supprimée par le sanitizer, score affiché. « Un evidence pack peut-il rêver de conformité ? »
This is the description of what the code block changes:
<changeDescription>
Ajout d'une section 'Installation rapide' au README pour faciliter l'onboarding et la maintenance.
</changeDescription>
This is the code block that represents the suggested code change:
````markdown
---
## 🚀 Installation rapide
Pour démarrer sur Kill_LIFE :
1. **Créer et activer l’environnement virtuel Python**
```bash
python3 -m venv .venv
source .venv/bin/activate
```
2. **Installer les dépendances principales**
```bash
pip install -r requirements-mistral.txt
pip install -r tools/compliance/requirements.txt
```
3. **Vérifier l’installation**
```bash
pip list
pip-audit
```
4. **Exécuter les scripts critiques**
```bash
PYTHONPATH="$(pwd)" .venv/bin/python tools/compliance/use_profile.py prototype
```
> Voir aussi : [INSTALL.md](docs/INSTALL.md), [RUNBOOK.md](docs/RUNBOOK.md), [SECURITY.md](docs/SECURITY.md)
---