Clément SAILLANT
da0d4aa806
Bring back the detailed README from 9734c88 with visual assets,
agent diagrams, literary references and contributor guide.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Kill_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.
« 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).Schaeffer : Les agents du pipeline écoutent le bruit des specs comme une symphonie de sons trouvés.
- 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/).
« 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
(Les particules font-elles l’amour ?)
✨ 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.
🖥️ 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[Déploiement multi-cible]
PR --> Agents[Agents (PM, Architecte, 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]
🗺️ 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
- OS : Linux, macOS, Windows (WSL)
- Python ≥ 3.8
- PlatformIO
- KiCad (hardware)
- Docker (optionnel)
Installation rapide
git clone https://github.com/electron-rare/Kill_LIFE.git
cd Kill_LIFE
bash install_kill_life.sh
Voir INSTALL.md pour les détails.
🤝 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 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.
🦾 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é. « Un evidence pack peut-il rêver de conformité ? »
- 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.
🚀 Conventions, contribution & cross-platform
RtFM : Parfois, le README résonne comme un drone, et tout le projet s’accorde. Toutes les conventions, instructions d’installation, sécurité, multi-agents, conformité, workflows et support multi-plateforme (Docker inclus) sont synthétisées. Architecture, étapes d’initialisation, fonctions clés, sécurité OpenClaw, 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.
Spec Generator — science-fiction automatisée.
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é ? »