diff --git a/README.md b/README.md index 3c9f798..25eef46 100644 --- a/README.md +++ b/README.md @@ -1,490 +1,119 @@ -# Kill_LIFE 🚀 — ModĂšle de Projet EmbarquĂ© IA-Natif +# Kill_LIFE - - -[//]: # (Badges dynamiques via shields.io) +Template de projet embarque IA-natif. Architecture agentique spec-first avec gates de qualite, evidence packs et tracabilite complete. [![CI](https://img.shields.io/github/actions/workflow/status/electron-rare/Kill_LIFE/ci.yml?branch=main&label=CI)](https://github.com/electron-rare/Kill_LIFE/actions) [![License: MIT](https://img.shields.io/badge/license-MIT-blue)](licenses/MIT.txt) -[![RFC2119](https://img.shields.io/badge/conformitĂ©-RFC2119-blueviolet)](docs/COMPLIANCE.md) -[![Evidence Pack](https://img.shields.io/badge/evidence-pack-green)](docs/evidence/) -[![Test Coverage](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/coverage-summary.json&cacheSeconds=300)](docs/coverage_report.html) -[![CI Audit](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/ci-audit-badge.json&cacheSeconds=300)](docs/ci-audit-summary.json) - -[![Security](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/security-summary.json&cacheSeconds=300)](docs/SECURITY.md) -[![SBOM](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/sbom-summary.json&cacheSeconds=300)](docs/SBOM.md) -[![Doc Coverage](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/doc-summary.json&cacheSeconds=300)](docs/DOC.md) -[![Quality](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/quality-summary.json&cacheSeconds=300)](docs/QUALITY.md) -[![Community](https://img.shields.io/endpoint?url=https://raw.githubusercontent.com/electron-rare/Kill_LIFE/main/docs/community-summary.json&cacheSeconds=300)](docs/COMMUNITY.md) - - - ---- - -## 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. - -
- BanniĂšre Kill_LIFE -
- -## đŸ§© 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///...` -- `logs//...` -- `evidence//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](https://www.youtube.com/watch?v=9bZkp7q19f0)). -- **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/](agents/), [bmad/](bmad/)). -- **Tool-first** : Scripts reproductibles ([tools/](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](https://openclaw.ai/)). - >Schaeffer : Les agents du pipeline Ă©coutent le bruit des specs comme une symphonie de sons trouvĂ©s. - -
- Schéma des agents BMAD -
- - -## 🏅 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Ă©](docs/coverage_report.html)). - -Pour toute question frĂ©quente, consulte la [FAQ](docs/FAQ.md). - -> « 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 ?](https://lelectron-fou.bandcamp.com/album/les-particules-font-elles-l-amour-la-physique) - ---- - -## ✹ 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) - -```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](KIKIFOU/diagramme.md) pour un diagramme complet du pipeline. - -## đŸ§Ÿ Table de mapping - -Voir [KIKIFOU/mapping.md](KIKIFOU/mapping.md) pour une synthĂšse des dossiers et dĂ©pendances. - ---- - -## 🚀 Installation & initialisation - -### PrĂ©requis - - -### 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) - ---- - -## đŸ€ Contribuer - - - - -1. Forke le dĂ©pĂŽt et clone-le localement. -2. Suis le guide d’onboarding ([docs/index.md](docs/index.md), [RUNBOOK.md](RUNBOOK.md)). -3. Ajoute des exemples minimalistes pour chaque agent (voir [agents/](agents/)). -4. Propose des blocks hardware, profils de conformitĂ©, tests. -5. Documente tes scripts et contributions. -6. Ouvre une PR, passe les gates, fournis un evidence pack. -7. Respecte les conventions de commit et de labelling (`ai:*`). -8. 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](docs/index.md) -- [RUNBOOK opĂ©rateur](RUNBOOK.md) -- [Guide d’installation](INSTALL.md) -- [SynthĂšse technique et recommandations](KIKIFOU/synthese.md) -- [Diagramme pipeline](KIKIFOU/diagramme.md) -- [Mapping dossiers](KIKIFOU/mapping.md) -- [Gate Runner](https://gate-runner.com) — 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///`. -- 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Ă©** - 1. Ouvre une issue avec le label `ai:docs` ou `ai:qa`. - 2. L’agent Doc met Ă  jour `docs/` et le README. - 3. 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Ă©. - -
- Arborescence du projet Kill_LIFE -
---- - > _« Un evidence pack peut-il rĂȘver de conformitĂ© ? »_ - ---- - -## 📝 Installation & SĂ©curitĂ© - -Un guide d’installation dĂ©taillĂ© ([INSTALL.md](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](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. - -
- Gate Validation -
-> _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](docs/index.md), [RUNBOOK.md](RUNBOOK.md), [INSTALL.md](INSTALL.md). - ---- - -## đŸŠŸ Workflows dĂ©taillĂ©s - - - -### 1. SpĂ©cification → ImplĂ©mentation Firmware - -1. RĂ©dige la spec dans `specs/`. -2. Ouvre une issue avec le label `ai:spec`. -3. L’agent PM/Architecte gĂ©nĂšre le plan et l’architecture. -4. L’agent Firmware implĂ©mente le code dans `firmware/`. -5. L’agent QA ajoute des tests Unity. -6. Evidence pack gĂ©nĂ©rĂ© automatiquement. - - [Spec Generator](https://www.websynths.com/grooves/) - -### 2. Bulk Edit Hardware KiCad - -1. Ouvre une issue avec le label `ai:hw`. -2. L’agent HW effectue un bulk edit via `tools/hw/schops`. -3. Exporte ERC/DRC, BOM, netlist. -4. Snapshot avant/aprĂšs dans `artifacts/hw//`. - -### 3. Documentation & ConformitĂ© - -1. Ouvre une issue avec le label `ai:docs` ou `ai:qa`. -2. L’agent Doc met Ă  jour `docs/` et le README. -3. 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: - -Ajout d'une section 'Installation rapide' au README pour faciliter l'onboarding et la maintenance. - - -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) - ---- -```` - - +## Principe + +Kill_LIFE structure un projet embarque autour de **7 agents specialises** et **7 gates de qualite**. Chaque etape produit des artefacts verifiables (evidence packs). Le workflow est concu pour l'embarque multi-cibles (ESP32, STM32, Linux) avec tracabilite et conformite integrees. + +## Agents + +| Agent | Responsabilite | +|-------|---------------| +| **PM / Spec** | Intention -> specs testables (acceptance criteria, risques) | +| **Architect** | Decoupe modules, interfaces, contraintes (RTOS, memoire, IO) | +| **Firmware** | Implementation multi-cibles, invariants | +| **HW** | Contraintes PCB / alimentation / signaux, checklists hardware | +| **QA / Test** | Tests unitaires + integration + smoke HIL | +| **Doc** | Runbooks, troubleshooting, changelog | +| **Compliance** | Standards, SBOM, versions, evidence pack final | + +## Gates + +| Gate | Objectif | +|------|----------| +| G0 - Intention | Brief valide, non-goals explicites | +| G1 - Spec | Specs testables, matrice de risques | +| G2 - Architecture | Modules definis, interfaces documentees | +| G3 - Implementation | Code compile, tests unitaires passent | +| G4 - Integration | Tests HIL, smoke tests multi-cibles | +| G5 - Doc & Compliance | Docs completes, SBOM, standards | +| G6 - Release | Evidence pack final, tag, artefacts publies | + +## Structure + +``` +Kill_LIFE/ +├── agents/ # Definitions des agents (markdown) +├── specs/ # Specifications par feature +├── standards/ # Standards et regles de conformite +├── firmware/ # Code embarque PlatformIO (ESP32, STM32) +├── hardware/ # Schemas KiCad, contraintes PCB +├── tools/ +│ ├── ai/ # Outils IA (generation, review) +│ ├── compliance/ # Verification conformite +│ ├── gates/ # Scripts de validation des gates +│ ├── hw/ # Outils hardware +│ ├── mistral/ # Integration Mistral AI +│ └── cockpit/ # Dashboard local +├── openclaw/ # Module OpenClaw +├── docs/ # Documentation, evidence packs +├── test/ # Tests et validation +├── bmad/ # Methodologie BMAD +├── .github/ +│ ├── workflows/ # 18+ workflows CI/CD +│ ├── agents/ # Prompts agents GitHub +│ └── prompts/ # Templates de prompts +├── mcp.json # Configuration MCP server +├── Makefile # Commandes principales +└── mkdocs.yml # Documentation MkDocs +``` + +## Demarrage rapide + +### Prerequis + +- Python 3.10+ +- PlatformIO (firmware ESP32/STM32) +- KiCad (schemas hardware) + +### Installation + +```bash +git clone https://github.com/electron-rare/Kill_LIFE.git +cd Kill_LIFE + +# Installation complete +bash install_kill_life.sh + +# Ou installation minimale +pip install -r requirements-mistral.txt +``` + +### Commandes + +```bash +make help # Lister les commandes disponibles +make check # Verifier la conformite +make test # Lancer les tests +make docs # Generer la documentation MkDocs +``` + +## Integration Mistral AI + +Kill_LIFE utilise Mistral AI pour la generation de code et la review : + +```bash +# Configuration +export MISTRAL_API_KEY=your_key + +# Outils dans tools/mistral/ +python tools/mistral/generate.py --spec specs/my_feature.md +``` + +## Ecosysteme + +Ce repo fait partie de l'ecosysteme [Mascarade](https://github.com/electron-rare/mascarade) : + +- **[mascarade](https://github.com/electron-rare/mascarade)** -- Orchestrateur agentique, LLM routing +- **[mascarade-datasets](https://github.com/electron-rare/mascarade-datasets)** -- Datasets de fine-tuning +- **[mascarade-cockpit](https://github.com/electron-rare/mascarade-cockpit)** -- Console ops +- **[crazy_life](https://github.com/electron-rare/crazy_life)** -- Frontend cockpit +- **[Kill_LIFE](https://github.com/electron-rare/Kill_LIFE)** -- Ce repo + +## Licence + +MIT -- voir [licenses/MIT.txt](licenses/MIT.txt)