From 9fa6acc5c77dc9b8329501f31313364d495375ba Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Cl=C3=A9ment=20SAILLANT?= <108685187+electron-rare@users.noreply.github.com> Date: Thu, 19 Feb 2026 07:59:49 +0100 Subject: [PATCH] =?UTF-8?q?README=20version=20tuto4noob=E2=80=AF:=20Pas=20?= =?UTF-8?q?=C3=A0=20pas=20pour=20survivre=20dans=20le=20chaos=20agentique.?= =?UTF-8?q?=20Suis=20les=20instructions,=20m=C3=AAme=20l=E2=80=99IA=20s?= =?UTF-8?q?=E2=80=99y=20perd=20parfois.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- DISCLAIMER.md | 117 +++++++++++++++++++++++ README.md | 225 +++++++++++++++++++++++++++++++++++---------- TUTO4NOOB.md | 88 ++++++++++++++++++ docs/QUICKSTART.md | 53 +++++++++++ 4 files changed, 436 insertions(+), 47 deletions(-) create mode 100644 DISCLAIMER.md create mode 100644 TUTO4NOOB.md create mode 100644 docs/QUICKSTART.md diff --git a/DISCLAIMER.md b/DISCLAIMER.md new file mode 100644 index 0000000..06adcc6 --- /dev/null +++ b/DISCLAIMER.md @@ -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é. diff --git a/README.md b/README.md index 37ab089..94750ec 100644 --- a/README.md +++ b/README.md @@ -1,10 +1,13 @@ # Kill_LIFE 🚀 — Modèle de Projet Embarqué IA-Natif - + + [![Build Status](https://img.shields.io/github/actions/workflow/status/electron-rare/Kill_LIFE/ci.yml?branch=main)](https://github.com/electron-rare/Kill_LIFE/actions) [![Licence MIT](https://img.shields.io/badge/license-MIT-blue)](licenses/MIT.txt) -[![Compliance](https://img.shields.io/badge/compliance-passed-brightgreen)](docs/COMPLIANCE.md) -[![Coverage](https://img.shields.io/badge/coverage-90%25-brightgreen)](docs/coverage_report.html) +[![Conformité 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/badge/coverage-90%25-brightgreen)](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 - -
+
Bannière Kill_LIFE
-
- Don’t Panic - Playlist apocalypse -
-
- Arborescence du projet 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)). - > _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/)). -
- Schéma des agents 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://www.openclaw.io/)). + >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 - -([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 + + + + - **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. -
- Pipeline hardware/firmware -
- **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[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] -``` -
-> _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 + + + 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é). +
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é + + - 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. +
+ --- + + ## 🛠️ 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. -
- Bulk Edit Party - Evidence Pack - Gate Validation - OpenClaw Sandbox -
- **.github/** : Workflows CI, scope guard, enforcement labels. - **licenses/** : MIT, CERN OHL v2, CC-BY 4.0. + +
+ + + --- ## 🦾 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é. + +
+ Arborescence du projet Kill_LIFE +
+--- > _« 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 +
+ 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. @@ -265,6 +386,8 @@ R : Voir [docs/index.md](docs/index.md), [RUNBOOK.md](RUNBOOK.md), [INSTALL.md]( ## 🦾 Workflows détaillés + + ### 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. + +
+ +--- + > _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é ? »_ + + diff --git a/TUTO4NOOB.md b/TUTO4NOOB.md new file mode 100644 index 0000000..07294cf --- /dev/null +++ b/TUTO4NOOB.md @@ -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. diff --git a/docs/QUICKSTART.md b/docs/QUICKSTART.md new file mode 100644 index 0000000..f0f528e --- /dev/null +++ b/docs/QUICKSTART.md @@ -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 !