README version tuto4noob :
Pas à pas pour survivre dans le chaos agentique. Suis les instructions, même l’IA s’y perd parfois.
This commit is contained in:
Clément SAILLANT
+117
@@ -0,0 +1,117 @@
|
||||
|
||||
|
||||
# DISCLAIMER GLOBAL Kill_LIFE
|
||||
|
||||
---
|
||||
|
||||
## Usage & Responsabilité
|
||||
|
||||
Ce dépôt est fourni à des fins éducatives, expérimentales et open source. Toute utilisation, modification, diffusion ou intégration relève de la responsabilité exclusive de l’utilisateur.
|
||||
|
||||
- L’équipe du projet, ses contributeurs et partenaires déclinent toute responsabilité pour :
|
||||
- Dommages matériels, corporels, financiers, pertes de données, interruptions de service, ou tout autre préjudice direct ou indirect.
|
||||
- Mauvaise utilisation, modification, intégration ou interprétation du code, des schémas, des scripts ou de la documentation.
|
||||
- L’utilisateur doit vérifier toute action, branchement, ou modification avant exécution.
|
||||
- Ne modifiez jamais les workflows `.github/workflows/` sans validation humaine.
|
||||
- Prévoyez une clause de retrait en cas de violation de droits d’auteur.
|
||||
|
||||
---
|
||||
|
||||
## Sécurité (physique, logicielle, réseau)
|
||||
|
||||
- Respectez toutes les consignes de sécurité électrique, électronique, logicielle et réseau.
|
||||
- Ne branchez aucun matériel sans vérification préalable des schémas, docs et notices.
|
||||
- Les scripts, outils et agents sont fournis sans garantie de sécurité, conformité ou fiabilité.
|
||||
- L’utilisateur doit s’assurer de la conformité aux normes locales, nationales et internationales.
|
||||
- Recommandez un audit technique avant toute utilisation en production ou industrielle.
|
||||
|
||||
---
|
||||
|
||||
## RGPD, Confidentialité & Données personnelles
|
||||
|
||||
- Ce projet ne collecte pas de données personnelles par défaut.
|
||||
- Toute donnée ajoutée, traitée ou diffusée doit respecter le RGPD et toute législation applicable.
|
||||
- Ne stockez ni ne diffusez d’informations personnelles, confidentielles ou sensibles dans le dépôt.
|
||||
- L’utilisateur est responsable de la conformité de ses apports et de leur traitement.
|
||||
- Si des données personnelles sont ajoutées ou traitées, exigez :
|
||||
- Information et consentement des personnes concernées.
|
||||
- Droit d’accès, de rectification, d’effacement.
|
||||
- Registre des traitements.
|
||||
- Sécurisation des données (chiffrement, accès restreint).
|
||||
- Ajoutez une clause de notification en cas de violation de données.
|
||||
|
||||
---
|
||||
|
||||
## Propriété intellectuelle & droits d’auteur
|
||||
|
||||
- Le contenu du dépôt est soumis aux licences indiquées dans `licenses/`.
|
||||
- L’utilisateur doit respecter les droits d’auteur, de propriété intellectuelle et de licence.
|
||||
- Toute redistribution, modification ou intégration doit mentionner les auteurs et respecter les conditions de licence.
|
||||
- Pour tout ajout de contenu tiers, obtenez une autorisation écrite ou vérifiez la compatibilité de licence.
|
||||
|
||||
---
|
||||
|
||||
## Openclaw (Intégration observer-only)
|
||||
|
||||
- Openclaw n’automatise aucune écriture, ne modifie pas le contenu du dépôt, et ne traite pas de données personnelles.
|
||||
- Toute interaction via Openclaw doit respecter la confidentialité, la sécurité et la conformité RGPD.
|
||||
|
||||
---
|
||||
|
||||
## Agentics, Automatisation & IA
|
||||
|
||||
- Les agents (architect, doc, firmware, QA, etc.) sont des assistants virtuels, non responsables des décisions humaines.
|
||||
- Les suggestions, automatisations ou actions générées par les agents ou l’IA doivent être validées par un humain avant toute mise en production ou utilisation réelle.
|
||||
- L’utilisateur est responsable de l’interprétation, de la validation et de l’exécution des recommandations ou scripts générés.
|
||||
- Interdisez le traitement de données personnelles par l’IA sans conformité RGPD.
|
||||
- Documentez les actions automatisées et gardez une trace des validations humaines.
|
||||
|
||||
---
|
||||
|
||||
## Diffusion, compliance & export
|
||||
|
||||
- Respectez les lois locales, nationales et internationales (export, sécurité, propriété intellectuelle).
|
||||
- Pour tout usage commercial ou industriel, recommandez un audit de conformité (licences, normes, marquage CE/FCC).
|
||||
|
||||
---
|
||||
|
||||
## Limites d’assistance & de support
|
||||
|
||||
- Ce projet ne fournit aucun support technique, juridique, ou d’assistance garantie.
|
||||
- Toute aide, conseil ou documentation est fournie « en l’état », sans garantie d’exactitude, d’exhaustivité ou de pertinence.
|
||||
|
||||
---
|
||||
|
||||
## Clause de non-garantie
|
||||
|
||||
- Le dépôt, ses contenus, scripts, schémas, docs et outils sont fournis « en l’état », sans aucune garantie expresse ou implicite.
|
||||
- L’utilisateur assume tous les risques liés à l’utilisation, la modification ou l’intégration.
|
||||
|
||||
---
|
||||
|
||||
## Recommandations
|
||||
|
||||
- Ajoutez un contact juridique ou une adresse pour signaler un problème ou une violation.
|
||||
- Mettez à jour le disclaimer en cas de modification majeure ou d’ajout de fonctionnalités sensibles.
|
||||
- Pour une protection maximale, faites valider le dépôt par un avocat spécialisé et mettez en place un processus de revue juridique pour chaque contribution majeure.
|
||||
|
||||
---
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Synthèse d’analyse approfondie (2026)
|
||||
|
||||
- Le dépôt Kill_LIFE est structuré pour la traçabilité, la conformité et la modularité (specs, docs, firmware, hardware, tools, agents, openclaw).
|
||||
- Les workflows et scripts sont protégés, les evidence packs assurent la vérifiabilité.
|
||||
- Par défaut, aucune donnée personnelle n’est collectée, mais toute extension doit respecter le RGPD.
|
||||
- Les licences MIT, CERN-OHL, CC-BY-4.0 couvrent le code, les schémas et la documentation.
|
||||
- Les agents et automatisations sont des assistants, toute action doit être validée par un humain.
|
||||
- L’utilisateur doit vérifier la conformité locale, la sécurité et la compatibilité des licences.
|
||||
- Le projet ne fournit aucun support ou garantie.
|
||||
- Toute modification majeure doit être accompagnée d’un audit de conformité.
|
||||
- Recommandation : ajouter un contact juridique, mettre en place une revue juridique pour chaque contribution majeure, et faire valider le dépôt par un avocat spécialisé.
|
||||
|
||||
---
|
||||
|
||||
En utilisant ce dépôt, vous acceptez toutes ces conditions, reconnaissez avoir lu ce disclaimer, et dégagez l’équipe, ses contributeurs et partenaires de toute responsabilité.
|
||||
@@ -1,10 +1,13 @@
|
||||
# Kill_LIFE 🚀 — Modèle de Projet Embarqué IA-Natif
|
||||
|
||||
<!-- Badges personnalisés -->
|
||||
|
||||
<!-- Badges qualité & conformité -->
|
||||
[](https://github.com/electron-rare/Kill_LIFE/actions)
|
||||
[](licenses/MIT.txt)
|
||||
[](docs/COMPLIANCE.md)
|
||||
[](docs/coverage_report.html)
|
||||
[](docs/COMPLIANCE.md)
|
||||
[](docs/evidence/)
|
||||
[](docs/coverage_report.html)
|
||||
|
||||
|
||||
---
|
||||
|
||||
@@ -18,68 +21,160 @@ Bienvenue dans **Kill_LIFE**, le modèle open source pour systèmes embarqués I
|
||||
|
||||
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
|
||||
|
||||
<div align="center">
|
||||
<div align="center" style="margin: 16px 0;">
|
||||
<img src="docs/assets/banner_kill_life_generated.png" alt="Bannière Kill_LIFE" width="600" />
|
||||
</div>
|
||||
<div align="center" style="margin: 8px 0;">
|
||||
<img src="docs/assets/dont_panic_generated.png" alt="Don’t Panic" width="120" style="vertical-align:middle;margin:0 4px;" />
|
||||
<a href="https://www.youtube.com/playlist?list=PLApocalypse42" target="_blank">Playlist apocalypse</a>
|
||||
</div>
|
||||
<div align="center" style="margin: 8px 0;">
|
||||
<img src="docs/assets/arborescence_kill_life_generated.png" alt="Arborescence du projet Kill_LIFE" width="400" />
|
||||
</div>
|
||||
|
||||
## 🧩 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](https://www.youtube.com/watch?v=9bZkp7q19f0)).
|
||||
> _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/](agents/), [bmad/](bmad/)).
|
||||
<div align="center" style="margin: 8px 0;">
|
||||
<img src="docs/assets/agents_bmad_generated.png" alt="Schéma des agents BMAD" width="400" />
|
||||
</div>
|
||||
- **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://www.openclaw.io/)).
|
||||
>Schaeffer : Les agents du pipeline écoutent le bruit des specs comme une symphonie de sons trouvés.
|
||||
|
||||
<div align="center" style="margin: 18px 0;">
|
||||
<img src="docs/assets/agents_bmad_generated.png" alt="Schéma des agents BMAD" width="420" />
|
||||
</div>
|
||||
|
||||
|
||||
## 🏅 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
|
||||
|
||||
([Les particules font-elles l’amour ?](https://lelectron-fou.bandcamp.com/album/les-particules-font-elles-l-amour-la-physique))
|
||||
>
|
||||
> — 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
|
||||
|
||||
|
||||
|
||||
<img src="docs/assets/pipeline_hw_fw_generated.png" align="left" width="140" style="margin-right:50; margin-bottom:8px;"/>
|
||||
|
||||
- **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.
|
||||
<div align="center" style="margin: 8px 0;">
|
||||
<img src="docs/assets/pipeline_hw_fw_generated.png" alt="Pipeline hardware/firmware" width="400" />
|
||||
</div>
|
||||
- **Conformité** : Profils injectés, validation automatique.
|
||||
- **OpenClaw** : Labels & commentaires sanitisés, jamais de commit/push, sandbox obligatoire.
|
||||
|
||||
<br clear="left"/>
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🖥️ Schéma agentique (Mermaid)
|
||||
|
||||
<div align="center">
|
||||
|
||||
```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)]
|
||||
CI --> Deploy[Deploiement multi-cible]
|
||||
PR --> Agents[Agents (PM, Architect, Firmware, QA, Doc, HW)]
|
||||
Agents --> Specs[specs/]
|
||||
Agents --> Firmware[firmware/]
|
||||
Agents --> Hardware[hardware/]
|
||||
@@ -92,10 +187,26 @@ flowchart TD
|
||||
Hardware --> Exports[exports/]
|
||||
Compliance --> Evidence
|
||||
OpenClaw --> Sandbox[Sandbox]
|
||||
```
|
||||
|
||||
</div>
|
||||
> _Parmegiani : Un bulk edit, c’est une métamorphose électronique, un peu comme un pack d’évidence qui se transforme en nuage de sons._
|
||||
---
|
||||
|
||||
## 📋 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/)).
|
||||
|
||||
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._ <
|
||||
|
||||
---
|
||||
|
||||
@@ -113,11 +224,6 @@ Voir [KIKIFOU/mapping.md](KIKIFOU/mapping.md) pour une synthèse des dossiers et
|
||||
|
||||
### Prérequis
|
||||
|
||||
- OS : Linux, macOS, Windows (WSL)
|
||||
- Python ≥ 3.8
|
||||
- PlatformIO
|
||||
- KiCad (hardware)
|
||||
- Docker (optionnel)
|
||||
|
||||
### Installation rapide
|
||||
|
||||
@@ -126,6 +232,7 @@ git clone https://github.com/electron-rare/Kill_LIFE.git
|
||||
cd Kill_LIFE
|
||||
bash install_kill_life.sh
|
||||
```
|
||||
> 🚀 Pour démarrer rapidement, consultez le guide [docs/QUICKSTART.md](docs/QUICKSTART.md)
|
||||
|
||||
Voir [INSTALL.md](INSTALL.md) pour les détails.
|
||||
|
||||
@@ -133,6 +240,9 @@ Voir [INSTALL.md](INSTALL.md) pour les détails.
|
||||
|
||||
## 🤝 Contribuer
|
||||
|
||||
<img src="docs/assets/dont_panic_generated.png" align="left" width="210" style="margin-right:50; margin-bottom:8px;"/>
|
||||
|
||||
|
||||
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/)).
|
||||
@@ -142,6 +252,7 @@ Voir [INSTALL.md](INSTALL.md) pour les détails.
|
||||
7. Respecte les conventions de commit et de labelling (`ai:*`).
|
||||
8. Vérifie la conformité et la sécurité (voir section Sécurité).
|
||||
|
||||
<br clear="left"/>
|
||||
Pour toute question, consulte la [FAQ](docs/FAQ.md) ou ouvre une issue.
|
||||
|
||||
|
||||
@@ -164,6 +275,8 @@ _« J’ai vu des evidence packs briller dans l’obscurité près des gates S1
|
||||
---
|
||||
|
||||
## 🛡️ Sécurité & conformité
|
||||
<img src="docs/assets/evidence_pack_generated.png" align="left" width="210" style="margin-right:50; margin-bottom:8px;"/>
|
||||
|
||||
|
||||
- OpenClaw : sandbox obligatoire, jamais d’accès aux secrets ou au code source.
|
||||
- Workflows CI : validation, sanitisation, scope guard, anti-prompt injection.
|
||||
@@ -171,7 +284,11 @@ _« J’ai vu des evidence packs briller dans l’obscurité près des gates S1
|
||||
- Tests hardware reproductibles via scripts documentés.
|
||||
- Respect des conventions de labelling et de commit.
|
||||
|
||||
<br clear="left"/>
|
||||
|
||||
---
|
||||
<img src="docs/assets/openclaw_sandbox_generated.png" align="right" width="320" style="margin-right:50; margin-bottom:8px;"/>
|
||||
|
||||
|
||||
## 🛠️ Fonctions clés
|
||||
|
||||
@@ -183,15 +300,14 @@ _« J’ai vu des evidence packs briller dans l’obscurité près des gates S1
|
||||
- **firmware/** : PlatformIO, tests Unity, multi-cibles.
|
||||
- **hardware/** : KiCad, bulk edits, exports.
|
||||
- **openclaw/** : Labels, commentaires, sandbox.
|
||||
<div align="center" style="margin: 8px 0;">
|
||||
<img src="docs/assets/bulk_edit_party_generated.png" alt="Bulk Edit Party" width="200" />
|
||||
<img src="docs/assets/evidence_pack_generated.png" alt="Evidence Pack" width="200" />
|
||||
<img src="docs/assets/gate_validation_generated.png" alt="Gate Validation" width="200" />
|
||||
<img src="docs/assets/openclaw_sandbox_generated.png" alt="OpenClaw Sandbox" width="200" />
|
||||
</div>
|
||||
- **.github/** : Workflows CI, scope guard, enforcement labels.
|
||||
- **licenses/** : MIT, CERN OHL v2, CC-BY 4.0.
|
||||
|
||||
|
||||
<br clear="right"/>
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 🦾 Workflows agents
|
||||
@@ -208,8 +324,13 @@ _« J’ai vu des evidence packs briller dans l’obscurité près des gates S1
|
||||
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._
|
||||
> _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é.
|
||||
|
||||
<div align="center" style="margin: 18px 0;">
|
||||
<img src="docs/assets/arborescence_kill_life_generated.png" alt="Arborescence du projet Kill_LIFE" width="420" />
|
||||
</div>
|
||||
---
|
||||
> _« Un evidence pack peut-il rêver de conformité ? »_
|
||||
|
||||
---
|
||||
@@ -232,9 +353,9 @@ Tests hardware reproductibles via scripts documentés.
|
||||
- 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
|
||||
<div align="center" style="margin: 18px 0;">
|
||||
<img src="docs/assets/gate_validation_generated.png" alt="Gate Validation" width="180" style="margin:0 10px;" />
|
||||
</div>
|
||||
> _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.
|
||||
@@ -265,6 +386,8 @@ R : Voir [docs/index.md](docs/index.md), [RUNBOOK.md](RUNBOOK.md), [INSTALL.md](
|
||||
|
||||
## 🦾 Workflows détaillés
|
||||
|
||||
<img src="docs/assets/bulk_edit_party_generated.png" align="right" width="320" style="margin-right:50; margin-bottom:8px;"/>
|
||||
|
||||
### 1. Spécification → Implémentation Firmware
|
||||
|
||||
1. Rédige la spec dans `specs/`.
|
||||
@@ -273,7 +396,8 @@ R : Voir [docs/index.md](docs/index.md), [RUNBOOK.md](RUNBOOK.md), [INSTALL.md](
|
||||
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://webkaoss.herokuapp.com/) — science-fiction automatisée.
|
||||
|
||||
[Spec Generator](https://www.websynths.com/grooves/)
|
||||
|
||||
### 2. Bulk Edit Hardware KiCad
|
||||
|
||||
@@ -287,7 +411,14 @@ R : Voir [docs/index.md](docs/index.md), [RUNBOOK.md](RUNBOOK.md), [INSTALL.md](
|
||||
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.
|
||||
|
||||
<br clear="right"/>
|
||||
|
||||
---
|
||||
|
||||
> _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é ? »_
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,88 @@
|
||||
|
||||
|
||||
|
||||
# 🌀🌈 Tutoriel Kill_LIFE : mode ultra débutant 🌈🌀
|
||||
|
||||
---
|
||||
|
||||
> **Bienvenue dans l’univers Kill_LIFE !**
|
||||
>
|
||||
> Imagine un voyage électronique, où les circuits dansent, les agents discutent, et l’IA te guide à travers des galaxies de specs et de docs. Prends ta lampe à lave, ton casque, et laisse-toi porter par la vague !
|
||||
>
|
||||
> ✨ « Ce projet, c’est un trip : tu explores, tu crées, tu connectes. Mais attention, tout n’est pas rose : la sécurité, la conformité, c’est aussi important que les couleurs ! » ✨
|
||||
>
|
||||
> - Ne branche rien si tu n’es pas sûr, vérifie toujours les schémas et les docs.
|
||||
> - Ne modifie pas les fichiers `.github/workflows/` sans validation humaine.
|
||||
> - Ne partage pas d’informations personnelles, confidentielles ou sensibles.
|
||||
> - Si tu ajoutes des données (logs, utilisateurs, etc.), respecte le RGPD : demande le consentement, permets l’effacement.
|
||||
> - Toute action automatisée (agent, script, IA) doit être validée par un humain.
|
||||
> - Vérifie la conformité locale (normes électriques, sécurité, export, licences).
|
||||
> - L’équipe du projet, ses contributeurs et partenaires déclinent toute responsabilité pour tout dommage, perte, ou problème lié à l’utilisation du dépôt.
|
||||
> - Pour usage commercial ou industriel, fais un audit de conformité.
|
||||
|
||||
---
|
||||
|
||||
## 1. C’est quoi ce projet ?
|
||||
|
||||
Kill_LIFE, c’est un gros dossier pour faire des projets électroniques avec de l’intelligence artificielle. Tu peux l’utiliser sur plein de machines (ESP, STM, Linux).
|
||||
|
||||
---
|
||||
|
||||
## 2. Comment je commence ?
|
||||
|
||||
1. Ouvre le dossier dans VS Code (ou un autre éditeur).
|
||||
2. Ouvre un terminal (la fenêtre noire où tu tapes des commandes).
|
||||
3. Tape :
|
||||
```bash
|
||||
./install_kill_life.sh
|
||||
```
|
||||
(Si ça ne marche pas, lis le fichier [INSTALL.md](INSTALL.md) pour voir quoi faire.)
|
||||
|
||||
---
|
||||
|
||||
## 3. Où trouver les infos ?
|
||||
|
||||
- Le fichier [README.md](README.md) explique le projet.
|
||||
- Le dossier `docs/` contient des guides, des explications, des tutos.
|
||||
- Le dossier `specs/` contient les règles et les plans du projet.
|
||||
- Le dossier `firmware/` contient le code pour les machines.
|
||||
- Le dossier `hardware/` contient les schémas électroniques.
|
||||
- Le dossier `tools/` contient des petits programmes pour vérifier ou aider.
|
||||
|
||||
---
|
||||
|
||||
## 4. Je veux juste tester si tout va bien
|
||||
|
||||
Dans le terminal, tape :
|
||||
```bash
|
||||
python tools/validate_specs.py
|
||||
```
|
||||
Ça vérifie que les règles du projet sont OK.
|
||||
|
||||
---
|
||||
|
||||
## 5. Quelques conseils pour ne pas tout casser
|
||||
|
||||
- Ne touche pas au dossier `.github/workflows/` (c’est sensible !)
|
||||
- Si tu ne comprends pas un dossier, lis le fichier README dedans ou demande à quelqu’un.
|
||||
- Si tu veux modifier quelque chose, vérifie d’abord dans `docs/` ou `specs/`.
|
||||
|
||||
---
|
||||
|
||||
## 6. Si tu es perdu…
|
||||
|
||||
- Lis les fichiers dans `docs/` ou `specs/`.
|
||||
- Cherche un fichier qui s’appelle README.md ou index.md.
|
||||
- Demande à l’agent (dans le dossier `agents/`) ou à un humain.
|
||||
|
||||
---
|
||||
|
||||
## 7. Vocabulaire simple
|
||||
|
||||
- **Spec** : règle ou plan du projet
|
||||
- **Agent** : personnage (virtuel) qui aide pour une tâche
|
||||
- **Evidence pack** : dossier avec des preuves (logs, fichiers) pour montrer que tout marche
|
||||
|
||||
---
|
||||
|
||||
Voilà ! Tu peux commencer à explorer. Prends ton temps, lis les fichiers, et n’hésite pas à demander de l’aide.
|
||||
@@ -0,0 +1,53 @@
|
||||
# Quickstart – Onboarding Express
|
||||
|
||||
Bienvenue sur Kill_LIFE ! Voici comment démarrer en quelques minutes :
|
||||
|
||||
## ✅ Checklist Onboarding Express
|
||||
|
||||
- [ ] Cloner le dépôt
|
||||
- [ ] Installer les dépendances
|
||||
- [ ] Lancer un build/test minimal
|
||||
- [ ] Ouvrir la documentation locale (optionnel)
|
||||
- [ ] Lire le README.md et la FAQ
|
||||
|
||||
## 1. Cloner le dépôt
|
||||
```bash
|
||||
git clone https://github.com/electron-rare/Kill_LIFE.git
|
||||
cd Kill_LIFE
|
||||
```
|
||||
|
||||
## 2. Installer les dépendances (exemple Python)
|
||||
```bash
|
||||
pip install -r requirements-mistral.txt
|
||||
```
|
||||
|
||||
## 3. Build et test minimal (exemple PlatformIO)
|
||||
```bash
|
||||
cd firmware
|
||||
platformio run
|
||||
```
|
||||
|
||||
## 4. Lancer la documentation locale (optionnel)
|
||||
```bash
|
||||
mkdocs serve
|
||||
```
|
||||
|
||||
## 5. Aller plus loin
|
||||
- Lire le README.md pour la structure du projet
|
||||
- Explorer les dossiers `specs/`, `docs/`, `firmware/`, `hardware/`
|
||||
- Suivre les guides détaillés dans `docs/`
|
||||
- Consulter la [FAQ](docs/FAQ.md) pour les questions fréquentes
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contribuer
|
||||
|
||||
1. Forker le repo et créer une branche dédiée
|
||||
2. Proposer une PR en suivant le modèle (voir `docs/`)
|
||||
3. Passer les gates (checklists de conformité)
|
||||
4. Ajouter un evidence pack si besoin
|
||||
5. Demander une review ou de l’aide via une issue
|
||||
|
||||
Pour toute question, consulte la FAQ ou ouvre une issue !
|
||||
|
||||
Pour toute question, consulte la FAQ ou ouvre une issue !
|
||||
Reference in New Issue
Block a user