Add French documentation for standards, integrations, cockpit, evaluations, and hardware tools

- Created README_FR.md files for various standards and profiles in the `standards` directory, detailing conventions and usage. - Added integration documentation for ZeroClaw, AutoGen, LangGraph, and n8n in the `tools/ai/integrations` directory, outlining their roles and usage. - Introduced a comprehensive README_FR.md for the `tools/cockpit` directory, detailing operator commands and health-check routines. - Added a README_FR.md for the `tools/evals` directory, providing a benchmark framework for electronic prompts. - Created a README_FR.md for the `tools/hw/schops` directory, explaining CLI operations for schematic management. - Added README_FR.md files for the `web` directory and its `project/pcb` subdirectory, outlining the web application structure and PCB viewer inputs.
2026-03-25 01:08:52 +01:00
parent f8c82b8544
commit a96780ba7e
73 changed files with 1936 additions and 384 deletions
@@ -734,3 +734,5 @@ Regles actives:
 - Surface de preuves: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
 - Surface de logs: `bash tools/cockpit/yiacad_logs_tui.sh --action status`.
 - Les routes directes historiques restent compatibles, mais ne sont plus l'entree publique recommandee.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -1,27 +1,29 @@
-# Spec-driven development (compat Spec Kit)
+# Spec-driven development (Spec Kit compatible)
-Ce repo adopte un style **spec-first** : avant de coder, on écrit la spec et le plan.
+This repo adopts a **spec-first** style: before coding, we write the spec and the plan.
-Pour rester compatible avec l'approche **Spec Kit**, on expose un dossier `.specify/` qui contient
+To remain compatible with the **Spec Kit** approach, we expose a `.specify/` folder that contains
-des templates minimalistes.
+minimalist templates.
-## Générer un dossier de spec
+## Generate a spec folder
 ```bash
 python tools/ai/specify_init.py --name <feature-or-epic>
 ```
-Cela crée :
+This creates:
-```
+```raw
 specs/<feature-or-epic>/
  00_prd.md
  01_tech_plan.md
  02_tasks.md
 ```
-## Règles
+## Rules
- Un dossier `specs/<name>/` par feature/epic.
+- One `specs/<name>/` folder per feature/epic.
- La PR doit référencer la spec (lien relatif).
+- The PR must reference the spec (relative link).
- Les tests/exports (firmware CI + hardware CI) doivent être verts.
+- Tests/exports (firmware CI + hardware CI) must be green.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,29 @@
 # Spec-driven development (compat Spec Kit)
 Ce repo adopte un style **spec-first** : avant de coder, on écrit la spec et le plan.
 Pour rester compatible avec l'approche **Spec Kit**, on expose un dossier `.specify/` qui contient
 des templates minimalistes.
 ## Générer un dossier de spec
 ```bash
 python tools/ai/specify_init.py --name <feature-or-epic>
 ```
 Cela crée :
 ```
 specs/<feature-or-epic>/
  00_prd.md
  01_tech_plan.md
  02_tasks.md
 ```
 ## Règles
 - Un dossier `specs/<name>/` par feature/epic.
 - La PR doit référencer la spec (lien relatif).
 - Les tests/exports (firmware CI + hardware CI) doivent être verts.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -61,3 +61,5 @@ python3 tools/compliance/validate.py
 ```
 Docs : `docs/COMPLIANCE.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,65 @@
 # ai-agentic-embedded-base
 Repo “de base” qui combine le meilleur de :
 - **Spec‑driven development** (Spec Kit) : une spécification comme source de vérité.  
 - **Standards injection** (Agent OS) : standards versionnés + profils.  
 - **BMAD / BMAD‑METHOD** : agents par rôles + rituels + gates + handoffs.  
 - **Agent Zero** : exécution transparente via outils locaux + logs + artifacts.
 > Ce dépôt est **orienté embarqué** (firmware + hardware KiCad) mais extensible multi‑target.
 ## TL;DR
 - Écris/itère la spec dans `specs/`
 - (optionnel) Génère un squelette de spec depuis `.specify/` : `python3 tools/ai/specify_init.py --name <feature>`
 - Applique les standards dans `standards/`
 - Exécute le cockpit : `python3 tools/cockpit/cockpit.py menu`
 - Pour l’automatisation GitHub : label `ai:codex` → Issue → PR
 ## Structure
 - `specs/` : intake → spec → arch → plan → tasks + contraintes
 - `standards/` : règles globales + profils (ESP / STM / multi)
 - `bmad/` : rôles, rituels, gates, templates de handoff
 - `agents/` : prompts agents (PM/Architect/FW/QA/Doc/HW)
 - `tools/` : cockpit + outils AI + outils hardware (schops)
 - `firmware/` : PlatformIO + Unity (tests)
 - `hardware/` : KiCad + blocks + rules
 - `.github/` : workflows (CI firmware/hardware/docs + Issue→PR Codex)
 ## KiCad local + IA
 Voir `docs/KICAD_AI_LOCAL.md`.
 ## Démarrage rapide
 ```bash
 # firmware
 cd firmware
 python -m pip install -U platformio
 pio run -e esp32s3_arduino
 pio test -e native
 # cockpit
 python3 tools/cockpit/cockpit.py menu
 ```
 ## Conventions de sortie
 Tous les scripts écrivent sous `artifacts/<domain>/<timestamp>/` (logs + exports + reports).
 ## V4 — KiCad agentique (bulk + previews + MCP)
 - `bash tools/hw/hw_gate.sh hardware/kicad` : exports SVG + ERC/DRC JSON + BOM/netlist
 - `python3 tools/watch/watch_hw.py` : watch mode (re-run gate on save)
 - `docs/MCP_SETUP.md` : configuration MCP (`kicad-sch-api` / `kicad-sch-mcp`) citeturn0search9
 ## Compliance (2 options)
 - **Prototype interne** : profil `prototype` (pas de CE/RED)
 - **Produit UE Wi‑Fi/BLE** : profil `iot_wifi_eu` (RED + cyber + RoHS/REACH/WEEE + ETSI)
 Changer de profil :
 ```bash
 python3 tools/compliance/use_profile.py prototype
 python3 tools/compliance/use_profile.py iot_wifi_eu
 python3 tools/compliance/validate.py
 ```
 Docs : `docs/COMPLIANCE.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -5,3 +5,5 @@ Objectif : éviter le “vibe coding” en gardant un flow reproductible.
 - `rituals/` : kickoff / daily / review
 - `gates/` : checklists de passage (S0/S1/S2…)
 - `templates/` : status updates + handoffs
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,9 @@
 # BMAD (agents par rôles + rituels + gates)
 Objectif : éviter le “vibe coding” en gardant un flow reproductible.
 - `roles/` : prompts de rôles (optionnel ici)
 - `rituals/` : kickoff / daily / review
 - `gates/` : checklists de passage (S0/S1/S2…)
 - `templates/` : status updates + handoffs
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -6,3 +6,5 @@
 ⚠️ Les fichiers KiCad réels sont à créer/committer depuis ton poste.
 Ce template fournit l’outillage (schops + gates + CI).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,10 @@
 # Hardware
 - `kicad/` : projets KiCad
 - `rules/` : règles champs/footprints/nets
 - `blocks/` : Design Blocks KiCad 10 (bibliothèque de briques)
 ⚠️ Les fichiers KiCad réels sont à créer/committer depuis ton poste.
 Ce template fournit l’outillage (schops + gates + CI).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -7,3 +7,5 @@ Créer une brique :
 Instancier une brique :
 - `schops block instantiate ...` (à implémenter selon ton workflow)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,11 @@
 # Design Blocks (KiCad 10)
 Créer une brique :
 - isoler un sous-schéma stable (ex: régulateur 3V3)
 - générer un block via `schops block-make ...`
 - versionner sous `hardware/blocks/<lib>.kicad_blocks/`
 Instancier une brique :
 - `schops block instantiate ...` (à implémenter selon ton workflow)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -12,3 +12,5 @@ Includes:
 This is a lightweight scaffold to start building a nodal orchestration engine
 for AI, CAD, electronics and hardware pipelines.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,16 @@
 # Universal Node Engine — Starter Repo
 Minimal starter for the Universal Node Engine architecture.
 Includes:
 - Node registry
 - Runtime engine
 - Simple scheduler
 - Example nodes
 - Basic web editor placeholder
 This is a lightweight scaffold to start building a nodal orchestration engine
 for AI, CAD, electronics and hardware pipelines.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -82,3 +82,5 @@ flowchart LR
 - `tools/cockpit/refonte_tui.sh`
 - `tools/cockpit/log_ops.sh`
 - `docs/AI_WORKFLOWS.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,86 @@
 # Specs (Spec-driven)
 Le dossier `specs/` est la source de vérité de la méthode Kill_LIFE. Il décrit la chaîne canonique `brief -> spec -> architecture -> plan -> tasks`, puis rattache chaque lot à un owner explicite et à une preuve exploitable par le cockpit, les plans et les extensions VS Code.
 Chaîne canonique:
 1. `00_intake.md` — idée brute + périmètre
 2. `01_spec.md` — besoin, critères d’acceptation
 3. `02_arch.md` — architecture + ADR
 4. `03_plan.md` — plan de réalisation
 5. `04_tasks.md` — backlog opérationnel
 Contraintes non-fonctionnelles:
 - `specs/constraints.yaml` (source de vérité)
 ## Contrat de lot canonique
 Tout lot nouveau ou restructuré doit exposer les champs suivants dans sa documentation, ses TODOs ou ses preuves dérivées:
 - `owner_repo`
 - `owner_agent`
 - `owner_subagent`
 - `write_set`
 - `status`
 - `evidence`
 Ce contrat est la charnière entre `Kill_LIFE`, `ai-agentic-embedded-base`, le cockpit shell/TUI et le trio d'extensions `kill-life-studio`, `kill-life-mesh`, `kill-life-operator`.
 ```mermaid
 flowchart LR
  Intake[00_intake.md] --> Spec[01_spec.md]
  Spec --> Arch[02_arch.md]
  Arch --> Plan[03_plan.md]
  Plan --> Tasks[04_tasks.md]
  Plan --> Cockpit[docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md]
  Tasks --> Mirror[tools/specs/sync_spec_mirror.sh]
  Mirror --> Validate[tools/validate_specs.py]
  Validate --> TUI[tools/cockpit/refonte_tui.sh]
  TUI --> AI[docs/AI_WORKFLOWS.md]
 ```
 ## Specs de référence supplémentaires
 - `github_mcp_conversion_spec.md`
 - `cad_modeling_tasks.md`
 - `kicad_mcp_scope_spec.md`
 - `mcp_agentics_target_backlog.md`
 - `mcp_tasks.md`
 - `knowledge_base_mcp_spec.md`
 - `zeroclaw_dual_hw_orchestration_spec.md`
 - `zeroclaw_dual_hw_todo.md`
 ## Exécutions utiles
 - Synchroniser les specs exportées:
  - `bash tools/specs/sync_spec_mirror.sh all --yes`
 - Vérifier le miroir:
  - `bash tools/specs/sync_spec_mirror.sh check`
 - Lancer la chaîne d’exécution:
  - `bash tools/cockpit/lot_chain.sh all --yes`
  - `bash tools/run_autonomous_next_lots.sh status`
  - `bash tools/run_autonomous_next_lots.sh run`
 - Valider la cohérence:
  - `bash tools/validate_specs.py --strict --require-mirror-sync`
 ## Politique canonique vs miroir
 - `Kill_LIFE/specs/` reste la source de vérité; toute modification part de ce dossier.
 - `ai-agentic-embedded-base/specs/` reste un miroir exporté; on ne l'édite pas directement, on le synchronise via `bash tools/specs/sync_spec_mirror.sh all --yes`.
 - Les surfaces `docs/`, `tools/`, `artifacts/` et `firmware/` restent canoniques dans `Kill_LIFE` sauf lot explicite contraire.
 - La fermeture d'un lot spec-first passe par deux commandes: `bash tools/specs/sync_spec_mirror.sh all --yes` puis `python3 tools/validate_specs.py --strict --require-mirror-sync`.
 ## Référentiels refonte à actualiser ensemble
 - `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md`
 - `docs/REFACTOR_MANIFEST_2026-03-20.md`
 - `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
 - `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
 - `docs/plans/12_plan_gestion_des_agents.md`
 - `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
 - `tools/cockpit/refonte_tui.sh`
 - `tools/cockpit/log_ops.sh`
 - `docs/AI_WORKFLOWS.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -7,3 +7,5 @@ Objectif : ne plus “ré-expliquer” tes conventions à chaque prompt.
 Usage recommandé :
 - Les agents lisent **toujours** `standards/global/*` + le profil actif.
 - Le profil actif est déclaré dans `specs/constraints.yaml` (ex: esp-first).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,11 @@
 # Standards (Agent OS style)
 Objectif : ne plus “ré-expliquer” tes conventions à chaque prompt.
 - `global/` : standards communs
 - `profiles/` : overrides selon le type de projet
 Usage recommandé :
 - Les agents lisent **toujours** `standards/global/*` + le profil actif.
 - Le profil actif est déclaré dans `specs/constraints.yaml` (ex: esp-first).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -3,3 +3,5 @@
 - UART debug obligatoire
 - Conso : deep sleep pris en compte dès le départ
 - Wi-Fi/BLE : désactivables via flags
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,7 @@
 # Profile: ESP-first
 - UART debug obligatoire
 - Conso : deep sleep pris en compte dès le départ
 - Wi-Fi/BLE : désactivables via flags
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -3,3 +3,5 @@
 - Dépendances minimales
 - HAL isolé, couches drivers strictes
 - Tests host/natif prioritaires
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,7 @@
 # Profile: STM32 industriel
 - Dépendances minimales
 - HAL isolé, couches drivers strictes
 - Tests host/natif prioritaires
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -7,3 +7,5 @@ Entrée unique pour piloter le repo en local.
 - `hw` : gates hardware (ERC/netlist/BOM)
 Tous les outputs → `artifacts/`.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,11 @@
 # Cockpit
 Entrée unique pour piloter le repo en local.
 - `menu` : menu simple
 - `gate_s0` : check “spec ready”
 - `fw` : build/test firmware
 - `hw` : gates hardware (ERC/netlist/BOM)
 Tous les outputs → `artifacts/`.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -79,3 +79,5 @@ python tools/hw/schops/schops.py block-make \
 python tools/hw/schops/schops.py block-ls --lib hardware/blocks/power.kicad_blocks
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,83 @@
 # schops (Schematic Ops)
 CLI local pour :
 - ERC/BOM/netlist via `kicad-cli`
 - bulk edits via `kicad-sch-api` (si installé)
 - Design Blocks KiCad 10 (structure + metadata)
 > Philosophie : **bulk edits safe** (backup + report) + exports déterministes (kicad-cli).
 ## Install (local)
 ```bash
 python -m venv .venv && source .venv/bin/activate
 python -m pip install -U pip
 python -m pip install -r tools/hw/schops/requirements.txt
 ```
 ## Usage
 ```bash
 python tools/hw/schops/schops.py --help
 ```
 ## Exports (kicad-cli)
 ```bash
 python tools/hw/schops/schops.py erc --schematic hardware/kicad/<proj>/<proj>.kicad_sch
 python tools/hw/schops/schops.py netlist --schematic hardware/kicad/<proj>/<proj>.kicad_sch
 python tools/hw/schops/schops.py bom --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --fields "Reference,Value,Footprint,${DNP}" \
  --group-by "Value,Footprint" \
  --exclude-dnp
 ```
 Les sorties vont dans `artifacts/hw/<timestamp>/`.
 ## Bulk edits (kicad-sch-api)
 ### Champs / propriétés
 Applique `hardware/rules/fields.yaml` (defaults + règles) et écrit un rapport JSON.
 ```bash
 python tools/hw/schops/schops.py apply-fields \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --rules hardware/rules/fields.yaml
 # review-only
 python tools/hw/schops/schops.py apply-fields --dry-run --schematic ... --rules ...
 ```
 ### Footprints
 ```bash
 python tools/hw/schops/schops.py apply-footprints \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --map hardware/rules/footprints.csv
 ```
 ### Renommage de nets (labels)
 ```bash
 python tools/hw/schops/schops.py rename-nets \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --rules hardware/rules/nets_rename.yaml
 ```
 ### Snapshot (pour diff)
 ```bash
 python tools/hw/schops/schops.py snapshot --schematic ... --name before.json
 # ... modifications ...
 python tools/hw/schops/schops.py snapshot --schematic ... --name after.json
 ```
 ## Design Blocks (KiCad 10)
 Les design blocks sont des dossiers `*.kicad_block` stockés dans une librairie `*.kicad_blocks`.
 ```bash
 python tools/hw/schops/schops.py block-make \
  --name buck_5v \
  --from-sheet hardware/kicad/buck/buck.kicad_sch \
  --lib hardware/blocks/power.kicad_blocks \
  --description "Buck 5V@2A" \
  --keywords "power,buck,5v"
 python tools/hw/schops/schops.py block-ls --lib hardware/blocks/power.kicad_blocks
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -8,3 +8,5 @@ Objectif : éviter le “vibe coding” en gardant un flow reproductible.
 - `rituals/` : kickoff / daily / review
 - `gates/` : checklists de passage (S0/S1/S2…)
 - `templates/` : status updates + handoffs
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,12 @@
 # Easter Egg musique expérimentale
 _« Les gates et rituels sont modulés comme un Oramics : chaque passage, chaque handoff, est une invention sonore. »_ — Daphne Oram
 # BMAD (agents par rôles + rituels + gates)
 Objectif : éviter le “vibe coding” en gardant un flow reproductible.
 - `roles/` : prompts de rôles (optionnel ici)
 - `rituals/` : kickoff / daily / review
 - `gates/` : checklists de passage (S0/S1/S2…)
 - `templates/` : status updates + handoffs
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -101,3 +101,5 @@ Statut:
 - la trajectoire MCP/agentics reste gouvernee dans `specs/mcp_agentics_target_backlog.md`
 - `mcp_tasks.md` porte le lot provenance MCP/CAD; `docs/KICAD_BENCHMARK_MATRIX.md` fixe la decision benchmark `KiAuto` / `kicad-automation-scripts`
 - `bash tools/tui/cad_mcp_audit.sh audit` reste le garde-fou minimal avant toute promotion documentaire ou operateur du lot MCP/CAD
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,105 @@
 # CAD Stack
 Last updated: 2026-03-14
 Stack Docker CAD/EDA integree directement dans `Kill_LIFE`.
 Important:
 - cette stack reste la base headless et containerisee;
 - YiACAD ajoute des surfaces GUI natives utilisateur dans KiCad et FreeCAD;
 - la strategie GUI/native est documentee dans `docs/CAD_AI_NATIVE_GUI_RUNBOOK_2026-03-20.md`, `docs/CAD_AI_NATIVE_HOOKS_2026-03-20.md` et `docs/YIACAD_APPLE_UI_UX_AUDIT_2026-03-20.md`.
 Backlogs canoniques associes:
 - plan modelling local: `docs/plans/16_plan_cad_modeling_stack.md`
 - TODO modelling local: `specs/cad_modeling_tasks.md`
 - backlog cible MCP/agentics: `specs/mcp_agentics_target_backlog.md`
 - backlog MCP/provenance: `specs/mcp_tasks.md`
 - benchmark KiCad adjacent: `docs/KICAD_BENCHMARK_MATRIX.md`
 ## Direction retenue
 - `KiCad headless`: `kicad-cli` via une image KiCad 10
 - `KiCad MCP`: `tools/hw/run_kicad_mcp.sh` et l'alias `tools/hw/cad_stack.sh mcp`
 - `FreeCAD headless`: `FreeCADCmd`
 - `OpenSCAD headless`: `openscad`
 - `PlatformIO`: `pio` dans un conteneur Python leger
 ## Provenance outillage CAD
 - `officiel`: surface publiee par le projet ou l'organisation qui own l'outil
 - `community valide`: projet tiers etabli, retenu comme reference ou benchmark
 - `custom local`: wrapper, launcher ou garde-fou maintenu dans `Kill_LIFE`
 | Surface / outil | Provenance | Statut | Usage retenu |
 | --- | --- | --- | --- |
 | `KiCad.app` + `kicad-cli` + image KiCad 10 | officiel | supporte | source de verite headless pour ERC/DRC/export |
 | `FreeCADCmd` + releases FreeCAD | officiel | supporte | modelling headless et backend du serveur `freecad` |
 | `OpenSCAD` CLI + releases/snapshots | officiel | supporte | rendu/export headless et backend du serveur `openscad` |
 | `KiAuto` | community valide | benchmark outille | appoint opt-in si un lot concret demande plus de checks/export que `kicad-cli` + `kicad-mcp` |
 | `kicad-automation-scripts` | community valide | benchmark classe | reference historique pour patterns Docker/doc; pas de promotion runtime par defaut |
 | `InteractiveHtmlBom` | community valide | reference utile | BOM interactive offline si la couche doc/fabrication le justifie |
 | `tools/hw/cad_stack.sh`, `tools/hw/run_kicad_mcp.sh`, `tools/run_freecad_mcp.sh`, `tools/run_openscad_mcp.sh`, `tools/tui/cad_mcp_audit.sh`, `tools/tui/kicad_benchmark_review.sh` | custom local | supporte | wrappers, garde-fou et helper doc benchmark operateur `Kill_LIFE` |
 Le classement `custom local` ne change jamais la source de verite runtime: les wrappers `Kill_LIFE` restent bornes par les binaires officiels detectes ou par les fallbacks conteneurises supportes.
 ## Usage rapide
 ```bash
 tools/hw/cad_stack.sh up
 tools/hw/cad_stack.sh doctor
 tools/hw/cad_stack.sh kicad-cli version
 tools/hw/cad_stack.sh freecad-cmd -c "import FreeCAD; print('.'.join(FreeCAD.Version()[:3]))"
 tools/hw/cad_stack.sh openscad --version
 tools/hw/cad_stack.sh pio system info
 tools/hw/cad_stack.sh mcp
 bash tools/tui/kicad_benchmark_review.sh report
 bash tools/tui/kicad_benchmark_review.sh purge --yes
 python3 tools/hw/freecad_smoke.py --json
 python3 tools/hw/openscad_smoke.py --json
 ```
 Le workspace monte dans les conteneurs est la racine de `Kill_LIFE` par defaut.
 ## Statut modelling local
 - `FreeCAD`: supporte en headless, avec smoke versionne `python3 tools/hw/freecad_smoke.py --json`
 - `OpenSCAD`: supporte en headless, avec smoke versionne `python3 tools/hw/openscad_smoke.py --json`
 Limites explicites:
 - la stack Docker documentee ici reste headless par nature
 - l'UI graphique YiACAD ne passe pas par ces conteneurs, mais par les surfaces natives utilisateur KiCad/FreeCAD
 - les serveurs MCP `FreeCAD` et `OpenSCAD` restent des surfaces MCP separees; ils ne remplacent ni les wrappers CLI locaux ni les surfaces GUI YiACAD
 ## MCP CAD locaux
 Launchers supportes:
 ```bash
 bash tools/run_freecad_mcp.sh --doctor
 bash tools/run_openscad_mcp.sh --doctor
 python3 tools/freecad_mcp_smoke.py --json
 python3 tools/openscad_mcp_smoke.py --json
 ```
 Statut:
 - `freecad`: supporte en `stdio` local, visible aussi dans `python3 tools/mcp_runtime_status.py --json`
 - `openscad`: supporte en `stdio` local, visible aussi dans `python3 tools/mcp_runtime_status.py --json`
 ## Variables utiles
 - `KICAD_DOCKER_IMAGE`: image KiCad 10 a utiliser
 - `CAD_WORKSPACE_DIR`: workspace monte dans `/workspace`
 - `KILL_LIFE_RUNTIME_HOME` ou `KILL_LIFE_RUNTIME_BASE_DIR`: surcharge du runtime home des wrappers locaux et MCP
 ## Gouvernance
 - la couche modelling locale `FreeCAD/OpenSCAD` reste gouvernee dans `specs/cad_modeling_tasks.md`
 - la trajectoire MCP/agentics reste gouvernee dans `specs/mcp_agentics_target_backlog.md`
 - `mcp_tasks.md` porte le lot provenance MCP/CAD; `docs/KICAD_BENCHMARK_MATRIX.md` fixe la decision benchmark `KiAuto` / `kicad-automation-scripts`
 - `bash tools/tui/cad_mcp_audit.sh audit` reste le garde-fou minimal avant toute promotion documentaire ou operateur du lot MCP/CAD
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -35,3 +35,5 @@ Ces plans sont des **runbooks** : tu peux les suivre tels quels, ou les transfor
 ---
 Astuce : si tu veux exécuter ces plans “à la chaîne” en mode agentique, commence par créer une issue “Program” et découpe en sous‑issues (ou en checklists), puis applique les labels `ai:*` progressivement.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,39 @@
 # Plans opérationnels
 Ces plans sont des **runbooks** : tu peux les suivre tels quels, ou les transformer en issues/epics. Ils sont pensés pour fonctionner avec :
 - Labels `ai:*` + scope guard
 - Evidence pack (preuves CI/HW)
 - Sécurité anti‑prompt‑injection
 ## Table des matières
 1. [Plan première entrée](01_plan_premiere_entree.md)
 2. [Plan brainstorming](02_plan_brainstorming.md)
 3. [Plan de specification](03_plan_specification.md)
 4. [Plan mise à jour agentics](04_plan_mise_a_jour_agentics.md)
 5. [Plan de roadmap hardware/firmware](05_plan_roadmap_hw_fw.md)
 6. [Plan d’intégration CI/CD](06_plan_integration_cicd.md)
 7. [Plan de gestion des specs](07_plan_gestion_specs.md)
 8. [Plan de conformité & sécurité](08_plan_conformite_securite.md)
 9. [Plan de bulk edit hardware](09_plan_bulk_edit_hardware.md)
 10. [Plan de documentation & onboarding](10_plan_documentation_onboarding.md)
 11. [Plan de contribution & feedback](11_plan_contribution_feedback.md)
 12. [Plan de gestion des agents](12_plan_gestion_des_agents.md)
 13. [Plan de troubleshooting](13_plan_troubleshooting.md)
 14. [Plan de release & versioning](14_plan_release_versioning.md)
 15. [Plan d'alignement MCP local](15_plan_mcp_runtime_alignment.md)
 16. [Plan de stack CAD modelling locale](16_plan_cad_modeling_stack.md)
 17. [Plan cible MCP + agentics + A2A](17_plan_target_architecture_mcp_agentics_2028.md)
 18. [Plan d'enchainement autonome des lots utiles](18_plan_enchainement_autonome_des_lots_utiles.md)
 19. [TODO mesh tri-repo](19_todo_mesh_tri_repo.md)
 20. [Plan refonte UI/UX YiACAD Apple-native](20_plan_refonte_ui_ux_yiacad_apple_native.md)
 21. [Plan refonte globale YiACAD](21_plan_refonte_globale_yiacad.md)
 22. [Plan integration intelligence agentique](22_plan_integration_intelligence_agentique.md)
 23. [TODO integration intelligence agentique](22_todo_integration_intelligence_agentique.md)
 ---
 Astuce : si tu veux exécuter ces plans “à la chaîne” en mode agentique, commence par créer une issue “Program” et découpe en sous‑issues (ou en checklists), puis applique les labels `ai:*` progressivement.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -42,3 +42,5 @@ Voir : `docs/evidence/evidence_pack.md`.
 Raccourci d'usage :
 - si le besoin est de valider un workflow, un runtime local ou un export avant CI, partir de la séquence `local`
 - si le besoin est de suivre un dispatch allowlisté, un check GitHub ou un evidence pack CI, partir de la séquence `github`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,46 @@
 # Workflows professionnels (opérationnels)
 Ces workflows sont conçus pour ressembler aux pratiques **cabinet de conseil**, **bureau d’études**, **design produit**, **studio créatif**, **R&D**, **industrialisation / compliance** — tout en restant compatibles avec le pipeline agentique du repo :
 - labels `type:*` pour classer l’intention métier,
 - labels `ai:*` pour déclencher l’automatisation (Issue → PR),
 - **scope guard** et **label enforcement** pour sécuriser les actions,
 - **evidence pack** pour tracer les décisions et résultats.
 ## Menu
 - 🧑‍💼 [Cabinet de conseil](consulting.md)
 - 🏗 [Bureau d’études / Ingénierie système](systems_engineering.md)
 - 🎨 [Design produit / UX](design.md)
 - 🎭 [Créatif / narration / contenu](creative.md)
 - 🧪 [R&D / spikes time-boxés](rnd_spikes.md)
 - 🛡 [Compliance / QA / Release](compliance_release.md)
 ## Règle simple (anti-chaos)
 1) **Crée une issue** avec un template (`.github/ISSUE_TEMPLATE/`).
 2) **Triage** : ajoute `prio:*`, `risk:*`, `scope:*`, et garde seulement un `type:*`.
 3) **Déclenche l’automatisation** en ajoutant le bon label `ai:*` :
   - `ai:spec` → formaliser exigences (RFC2119 + critères d’acceptation)
   - `ai:plan` → architecture + options + ADR
   - `ai:tasks` → backlog exécutable
   - `ai:impl` → impl + tests minimaux
   - `ai:qa` → durcissement tests/edge
   - `ai:docs` → docs + runbooks
 ⚠️ Si tu suspects une injection / comportement bizarre : ajoute `ai:hold`.
 ## Evidence pack
 Voir : `docs/evidence/evidence_pack.md`.
 ## Séquences opératoires canoniques
 - Local / cockpit / restore : `docs/KILL_LIFE_WORKFLOW_LOCAL_SEQUENCE_2026-03-11.md`
 - GitHub / dispatch / CI / artifacts : `docs/KILL_LIFE_WORKFLOW_GITHUB_SEQUENCE_2026-03-11.md`
 Raccourci d'usage :
 - si le besoin est de valider un workflow, un runtime local ou un export avant CI, partir de la séquence `local`
 - si le besoin est de suivre un dispatch allowlisté, un check GitHub ou un evidence pack CI, partir de la séquence `github`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,3 @@
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,3 @@
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -6,3 +6,5 @@
 ⚠️ Les fichiers KiCad réels sont à créer/committer depuis ton poste.
 Ce template fournit l’outillage (schops + gates + CI).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,10 @@
 # Hardware
 - `kicad/` : projets KiCad
 - `rules/` : règles champs/footprints/nets
 - `blocks/` : Design Blocks KiCad 10 (bibliothèque de briques)
 ⚠️ Les fichiers KiCad réels sont à créer/committer depuis ton poste.
 Ce template fournit l’outillage (schops + gates + CI).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -7,3 +7,5 @@ Créer une brique :
 Instancier une brique :
 - `schops block instantiate ...` (à implémenter selon ton workflow)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,11 @@
 # Design Blocks (KiCad 10)
 Créer une brique :
 - isoler un sous-schéma stable (ex: régulateur 3V3)
 - générer un block via `schops block-make ...`
 - versionner sous `hardware/blocks/<lib>.kicad_blocks/`
 Instancier une brique :
 - `schops block instantiate ...` (à implémenter selon ton workflow)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -31,4 +31,6 @@ Consultez le guide onboarding contributeur : [onboarding/README.md](onboarding/R
 Consultez aussi le guide pas-à-pas, FAQ et bonnes pratiques : [onboarding/guide_contributeur.md](onboarding/guide_contributeur.md)
 Découvrez des exemples d’utilisation : [onboarding/exemples.md](onboarding/exemples.md)
 Accédez aux supports visuels, tutoriels vidéo et scripts de test : [onboarding/supports_visuels.md](onboarding/supports_visuels.md)
-Intégrez OpenClaw en local (VM sandboxée) : [onboarding/guide_vm_sandbox.md](onboarding/guide_vm_sandbox.md)
+Intégrez OpenClaw en local (VM sandboxée) : [onboarding/guide_vm_sandbox.md](onboarding/guide_vm_sandbox.md)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,36 @@
 # OpenClaw Integration
 This repository includes optional integration points for **OpenClaw**, a local
 agent runtime that allows an operator to trigger automations via chat or other
 human‑in‑the‑loop interfaces. In this template, OpenClaw is used solely as
 a *viewer* and *label manager*:
 * OpenClaw **does not commit or push code**. Any actions that modify the
  repository must be performed via GitHub Agentic Workflows (gh‑aw) with
  safe‑outputs. This keeps the write surface minimal and auditable.
 * The only allowed actions are adding/removing `ai:*` labels on issues and
  pull requests, and posting sanitized status comments. All comments are
  processed through `tools/ai/sanitize_issue.py` before being sent.
 * OpenClaw must run in a sandbox or disposable environment with no access to
  secrets, following the principle of least privilege. Running OpenClaw on
  the same machine as your source code or CI system is *strongly
  discouraged*【57263998884462†L355-L419】.
 Refer to `docs/security/anti_prompt_injection_policy.md` for more details on
 the defensive measures and threat model.
 ## Workflows & Sécurité OpenClaw
 OpenClaw fonctionne strictement en mode observateur : il ne commite ni ne modifie le code source.
 Pour contribuer ou intégrer OpenClaw :
 Pour toute question, ouvrir une issue ou consulter la FAQ.
 Consultez le guide onboarding contributeur : [onboarding/README.md](onboarding/README.md)
 Consultez aussi le guide pas-à-pas, FAQ et bonnes pratiques : [onboarding/guide_contributeur.md](onboarding/guide_contributeur.md)
 Découvrez des exemples d’utilisation : [onboarding/exemples.md](onboarding/exemples.md)
 Accédez aux supports visuels, tutoriels vidéo et scripts de test : [onboarding/supports_visuels.md](onboarding/supports_visuels.md)
 Intégrez OpenClaw en local (VM sandboxée) : [onboarding/guide_vm_sandbox.md](onboarding/guide_vm_sandbox.md)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -46,4 +46,6 @@ Automatiser l’installation, la sécurisation et la validation d’OpenClaw dan
 - Installer curl, git, nodejs, npm, build-essential dans la VM (via install_packages.sh)
 - Puis enchaîner sur le scan des secrets/tokens/code source
-Pour continuer, souhaitez-vous lancer l’installation des paquets dans la VM (via scp/ssh) ou simuler l’exécution ?
+Pour continuer, souhaitez-vous lancer l’installation des paquets dans la VM (via scp/ssh) ou simuler l’exécution ?
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,51 @@
 # Synthèse : Intégration locale OpenClaw en VM sandboxée
 ## Objectif
 Automatiser l’installation, la sécurisation et la validation d’OpenClaw dans une VM Ubuntu Minimal, sans risque pour le dépôt principal.
 ## Étapes automatisées
 1. **Préparation VM**
   - Installation VirtualBox/QEMU/LXD
   - Téléchargement image Ubuntu Server 24.04 LTS Minimal
   - Création VM (2 Go RAM, 10-20 Go disque, sans interface graphique)
 2. **Installation système**
   - Installation manuelle d’Ubuntu Minimal (console VM)
   - Mise à jour système
   - Installation paquets requis : `install_packages.sh`
 3. **Sécurité & conformité**
   - Scan secrets/tokens/code source : `scan_secrets.sh`
   - Vérification montages : `check_mounts.sh`
   - Politique observer-only : `check_observer_only.sh`
 4. **Installation OpenClaw**
   - Installation via curl : `curl -fsSL https://openclaw.ai/install.sh | bash`
   - Vérification binaire : `check_openclaw.sh`
   - Tests doctor/help : `openclaw_check.sh`
 5. **Onboarding & simulation**
   - Simulation onboarding : `onboarding_simulation.sh` (lance tous les guides/tests)
 6. **Destruction VM & traçabilité**
   - Destruction/réinitialisation : `destroy_vm.sh`
   - Documentation : compléter `onboarding/vm_test_report.md`
 ## Scripts à utiliser
 - Tous les scripts sont dans `openclaw/local_setup/`
 - Instructions centralisées dans `install_vm_openclaw.sh`
 ## Validation
 - Suivre le script principal, transférer les scripts dans la VM, exécuter chaque étape.
 - Compléter le rapport de test.
 ---
 ## Prochaine étape todo
 - Installer curl, git, nodejs, npm, build-essential dans la VM (via install_packages.sh)
 - Puis enchaîner sur le scan des secrets/tokens/code source
 Pour continuer, souhaitez-vous lancer l’installation des paquets dans la VM (via scp/ssh) ou simuler l’exécution ?
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -1,21 +1,23 @@
-# Onboarding contributeur OpenClaw
+# OpenClaw Contributor Onboarding
-Bienvenue ! Pour intégrer OpenClaw dans un projet Kill_LIFE ou contribuer :
+Welcome! To integrate OpenClaw into a Kill_LIFE project or contribute:
-## Encart onboarding
+## Onboarding Box
- Lisez le README openclaw/ et la section "Workflows & Sécurité OpenClaw".
+- Read the openclaw/ README and the "OpenClaw Workflows & Security" section.
- Vérifiez que votre environnement est sandboxé (pas d'accès aux secrets/code source).
+- Verify that your environment is sandboxed (no access to secrets/source code).
- Utilisez les labels `ai:*` pour toutes actions.
+- Use `ai:*` labels for all actions.
- Publiez uniquement des commentaires sanitisés.
+- Publish only sanitized comments.
- Ne modifiez jamais les workflows `.github/workflows/` sans validation humaine.
+- Never modify `.github/workflows/` workflows without human validation.
- Consultez la FAQ et les guides sécurité.
+- Check the FAQ and security guides.
-## Checklist contributeur
+## Contributor Checklist
- [ ] Sandbox activée, aucun accès aux secrets/code source
+- [ ] Sandbox enabled, no access to secrets/source code
- [ ] Actions limitées à labels/commentaires sanitisés
+- [ ] Actions limited to sanitized labels/comments
- [ ] Respect du scope guard et des conventions
+- [ ] Compliance with scope guard and conventions
- [ ] Evidence pack fourni pour toute contribution
+- [ ] Evidence pack provided for any contribution
- [ ] Documentation mise à jour
+- [ ] Documentation updated
- [ ] Validation humaine pour toute modification sensible
+- [ ] Human validation for any sensitive modification
-Pour toute question ou problème, ouvrez une issue ou contactez l’équipe.
+For any question or issue, open an issue or contact the team.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,23 @@
 # Onboarding contributeur OpenClaw
 Bienvenue ! Pour intégrer OpenClaw dans un projet Kill_LIFE ou contribuer :
 ## Encart onboarding
 - Lisez le README openclaw/ et la section "Workflows & Sécurité OpenClaw".
 - Vérifiez que votre environnement est sandboxé (pas d'accès aux secrets/code source).
 - Utilisez les labels `ai:*` pour toutes actions.
 - Publiez uniquement des commentaires sanitisés.
 - Ne modifiez jamais les workflows `.github/workflows/` sans validation humaine.
 - Consultez la FAQ et les guides sécurité.
 ## Checklist contributeur
 - [ ] Sandbox activée, aucun accès aux secrets/code source
 - [ ] Actions limitées à labels/commentaires sanitisés
 - [ ] Respect du scope guard et des conventions
 - [ ] Evidence pack fourni pour toute contribution
 - [ ] Documentation mise à jour
 - [ ] Validation humaine pour toute modification sensible
 Pour toute question ou problème, ouvrez une issue ou contactez l’équipe.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -82,3 +82,5 @@ flowchart LR
 - `tools/cockpit/refonte_tui.sh`
 - `tools/cockpit/log_ops.sh`
 - `docs/AI_WORKFLOWS.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,86 @@
 # Specs (Spec-driven)
 Le dossier `specs/` est la source de vérité de la méthode Kill_LIFE. Il décrit la chaîne canonique `brief -> spec -> architecture -> plan -> tasks`, puis rattache chaque lot à un owner explicite et à une preuve exploitable par le cockpit, les plans et les extensions VS Code.
 Chaîne canonique:
 1. `00_intake.md` — idée brute + périmètre
 2. `01_spec.md` — besoin, critères d’acceptation
 3. `02_arch.md` — architecture + ADR
 4. `03_plan.md` — plan de réalisation
 5. `04_tasks.md` — backlog opérationnel
 Contraintes non-fonctionnelles:
 - `specs/constraints.yaml` (source de vérité)
 ## Contrat de lot canonique
 Tout lot nouveau ou restructuré doit exposer les champs suivants dans sa documentation, ses TODOs ou ses preuves dérivées:
 - `owner_repo`
 - `owner_agent`
 - `owner_subagent`
 - `write_set`
 - `status`
 - `evidence`
 Ce contrat est la charnière entre `Kill_LIFE`, `ai-agentic-embedded-base`, le cockpit shell/TUI et le trio d'extensions `kill-life-studio`, `kill-life-mesh`, `kill-life-operator`.
 ```mermaid
 flowchart LR
  Intake[00_intake.md] --> Spec[01_spec.md]
  Spec --> Arch[02_arch.md]
  Arch --> Plan[03_plan.md]
  Plan --> Tasks[04_tasks.md]
  Plan --> Cockpit[docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md]
  Tasks --> Mirror[tools/specs/sync_spec_mirror.sh]
  Mirror --> Validate[tools/validate_specs.py]
  Validate --> TUI[tools/cockpit/refonte_tui.sh]
  TUI --> AI[docs/AI_WORKFLOWS.md]
 ```
 ## Specs de référence supplémentaires
 - `github_mcp_conversion_spec.md`
 - `cad_modeling_tasks.md`
 - `kicad_mcp_scope_spec.md`
 - `mcp_agentics_target_backlog.md`
 - `mcp_tasks.md`
 - `knowledge_base_mcp_spec.md`
 - `zeroclaw_dual_hw_orchestration_spec.md`
 - `zeroclaw_dual_hw_todo.md`
 ## Exécutions utiles
 - Synchroniser les specs exportées:
  - `bash tools/specs/sync_spec_mirror.sh all --yes`
 - Vérifier le miroir:
  - `bash tools/specs/sync_spec_mirror.sh check`
 - Lancer la chaîne d’exécution:
  - `bash tools/cockpit/lot_chain.sh all --yes`
  - `bash tools/run_autonomous_next_lots.sh status`
  - `bash tools/run_autonomous_next_lots.sh run`
 - Valider la cohérence:
  - `bash tools/validate_specs.py --strict --require-mirror-sync`
 ## Politique canonique vs miroir
 - `Kill_LIFE/specs/` reste la source de vérité; toute modification part de ce dossier.
 - `ai-agentic-embedded-base/specs/` reste un miroir exporté; on ne l'édite pas directement, on le synchronise via `bash tools/specs/sync_spec_mirror.sh all --yes`.
 - Les surfaces `docs/`, `tools/`, `artifacts/` et `firmware/` restent canoniques dans `Kill_LIFE` sauf lot explicite contraire.
 - La fermeture d'un lot spec-first passe par deux commandes: `bash tools/specs/sync_spec_mirror.sh all --yes` puis `python3 tools/validate_specs.py --strict --require-mirror-sync`.
 ## Référentiels refonte à actualiser ensemble
 - `docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-21.md`
 - `docs/REFACTOR_MANIFEST_2026-03-20.md`
 - `docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-20.md`
 - `docs/AGENT_SPEC_MODULE_MATRIX_2026-03-20.md`
 - `docs/plans/12_plan_gestion_des_agents.md`
 - `docs/plans/18_plan_enchainement_autonome_des_lots_utiles.md`
 - `tools/cockpit/refonte_tui.sh`
 - `tools/cockpit/log_ops.sh`
 - `docs/AI_WORKFLOWS.md`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -7,3 +7,5 @@ Objectif : ne plus “ré-expliquer” tes conventions à chaque prompt.
 Usage recommandé :
 - Les agents lisent **toujours** `standards/global/*` + le profil actif.
 - Le profil actif est déclaré dans `specs/constraints.yaml` (ex: esp-first).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,11 @@
 # Standards (Agent OS style)
 Objectif : ne plus “ré-expliquer” tes conventions à chaque prompt.
 - `global/` : standards communs
 - `profiles/` : overrides selon le type de projet
 Usage recommandé :
 - Les agents lisent **toujours** `standards/global/*` + le profil actif.
 - Le profil actif est déclaré dans `specs/constraints.yaml` (ex: esp-first).
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -3,3 +3,5 @@
 - UART debug obligatoire
 - Conso : deep sleep pris en compte dès le départ
 - Wi-Fi/BLE : désactivables via flags
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,7 @@
 # Profile: ESP-first
 - UART debug obligatoire
 - Conso : deep sleep pris en compte dès le départ
 - Wi-Fi/BLE : désactivables via flags
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -3,3 +3,5 @@
 - Dépendances minimales
 - HAL isolé, couches drivers strictes
 - Tests host/natif prioritaires
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,7 @@
 # Profile: STM32 industriel
 - Dépendances minimales
 - HAL isolé, couches drivers strictes
 - Tests host/natif prioritaires
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -32,3 +32,5 @@ Available runbooks:
 - [`n8n/README.md`](n8n/README.md)
 - [`langgraph/README.md`](langgraph/README.md)
 - [`autogen/README.md`](autogen/README.md)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,36 @@
 # ZeroClaw Integrations
 ZeroClaw remains in scope as the local operator stack for Kill_LIFE.
 This directory is synced by `tools/ai/zeroclaw_stack_up.sh` into
 `artifacts/zeroclaw/integrations/`, then served by the follow UI.
 Current integration posture:
 - `ZeroClaw`: kept as the local operator stack entrypoint.
 - `n8n`: kept as an external automation bridge and workflow handoff surface.
 - `LangGraph`: kept as an optional orchestration pattern, not the default runtime.
 - `AutoGen`: kept as an optional multi-agent experimentation path.
 These integrations are intentionally documented as operator runbooks. They are
 not required for the canonical repo-local stable path.
 Operator posture:
 - `ZeroClaw` runtime is started on demand via `tools/ai/zeroclaw_stack_up.sh`.
 - `zeroclaw.saillant.cc` is the live runtime surface when the native stack is up.
 - `zeroclaw-docs.saillant.cc` serves the ZeroClaw runbooks behind the
  authenticated `edge-proxy`.
 - `langgraph.saillant.cc` serves the LangGraph runbook behind the authenticated
  `edge-proxy`.
 - When the local `ZeroClaw` runtime is stopped, `zeroclaw.saillant.cc` should
  present an operator-friendly offline page instead of raw proxy errors.
 Available runbooks:
 - [`zeroclaw/README.md`](zeroclaw/README.md)
 - [`n8n/README.md`](n8n/README.md)
 - [`langgraph/README.md`](langgraph/README.md)
 - [`autogen/README.md`](autogen/README.md)
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -17,3 +17,5 @@ Current posture:
 If revived as code, keep it isolated from the stable repo-local CI path and
 document the trigger conditions explicitly.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,21 @@
 # AutoGen Runbook
 `AutoGen` stays available as an optional multi-agent experimentation path
 alongside `ZeroClaw`.
 Use it when you want:
 - ad hoc multi-agent roleplay or decomposition
 - experimentation outside the canonical repo workflow path
 - quick prototypes before turning a flow into a tracked workflow or MCP tool
 Current posture:
 - retained as a documented integration
 - not part of the canonical stable gate
 - should remain outside critical firmware/CAD/release paths by default
 If revived as code, keep it isolated from the stable repo-local CI path and
 document the trigger conditions explicitly.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -24,3 +24,5 @@ Recommended role split:
 If this path is reactivated, add the concrete graph app or runner as tracked
 artifacts in `tools/ai/` or a dedicated submodule, then link it from here.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,28 @@
 # LangGraph Runbook
 `LangGraph` stays in scope as an optional orchestration layer around
 `ZeroClaw`.
 Use it when you want:
 - explicit graph-shaped control flow
 - checkpointed or resumable orchestration
 - a graph runtime separated from the canonical repo workflows
 Current posture in Kill_LIFE:
 - `ZeroClaw` remains the local operator stack.
 - `LangGraph` is retained as an integration pattern, not as the default
  runtime path.
 - No `LangGraph` service is wired into the main `mascarade` stack by default.
 Recommended role split:
 - `ZeroClaw`: local gateway, operator UX, prompts, pairing, follow UI
 - `LangGraph`: optional orchestration graph for complex flows
 - repo workflows / evidence: canonical tracked outputs
 If this path is reactivated, add the concrete graph app or runner as tracked
 artifacts in `tools/ai/` or a dedicated submodule, then link it from here.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -46,3 +46,5 @@ Historical workflow names:
 - `zeroclaw_orchestrator_workflow`
 - `zeroclaw_pr_autotriage_workflow`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,50 @@
 # n8n Runbook
 `n8n` stays in scope as the low-code workflow bridge around ZeroClaw, not as
 the canonical source of truth for runtime state.
 Use it for:
 - operator-triggered chains around `zeroclaw` webhooks
 - import/export of automation flows
 - glue logic around notifications, reviews, or dispatch
 Current posture:
 - ZeroClaw exposes the runbook from `/integrations/n8n/README.md`.
 - The historical JSON workflow names are kept as references, but the canonical
  runtime path is the ZeroClaw gateway plus repo workflows.
 - If you need concrete n8n workflow files again, regenerate them as explicit
  tracked artifacts instead of relying on dead links.
 Current local validation commands:
 ```bash
 bash tools/ai/zeroclaw_integrations_lot.sh verify
 bash tools/ai/zeroclaw_integrations_up.sh
 bash tools/ai/zeroclaw_integrations_status.sh --json
 bash tools/ai/zeroclaw_integrations_import_n8n.sh --json
 ```
 Current runtime bootstrap:
 - `bash tools/ai/zeroclaw_integrations_up.sh` auto-provisions the local `mascarade-n8n` container if Docker is running but the container is still missing.
 - Official runtime basis: `docker.n8n.io/n8nio/n8n` on port `5678`, with a persistent volume per container name.
 - Readiness is validated through `http://127.0.0.1:5678/healthz` in addition to the editor root URL, because first boot and editor startup can lag behind the health endpoint.
 - Workflow activation path: reuse the tracked workflow when it is already active, otherwise prefer `n8n publish:workflow --id=<ID>` after import, with legacy fallback `n8n update:workflow --id=<ID> --active=true`.
 - Activation proof now checks `n8n list:workflow --active=true --onlyId`, so `active=true` is no longer assumed.
 - Runtime scripts fail fast on local Docker CLI timeouts and report a blocker instead of hanging indefinitely.
 - If the local DB already contains the tracked workflow with the exact stored nodes/connections and `active=true`, the import script now skips the CLI path and returns success immediately.
 - Recovery note: if local SQLite state is corrupted or still contains an obsolete workflow revision, preserve the volume backup and reset only the n8n DB files before reprovisioning the container.
 Tracked smoke artifact:
 - `tools/ai/integrations/n8n/kill_life_smoke_workflow.json`
  - current trigger: yearly `Schedule Trigger`, so the workflow stays activable without creating noisy frequent runs
 Historical workflow names:
 - `zeroclaw_orchestrator_workflow`
 - `zeroclaw_pr_autotriage_workflow`
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -354,3 +354,5 @@ Contrat JSON commun `cockpit-v1`:
 - distinction retenue:
  - audit statique = cohérence source des surfaces
  - handoff runtime léger = disponibilité réelle du point de reprise canonique
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,358 @@
 # Cockpit
 Entrée outillage/TUI canonique pour piloter `Kill_LIFE` en local.
 ## Entrées recommandées
 - `bash tools/cockpit/yiacad_operator_index.sh --action status` : point d'entrée opérateur public
 - `bash tools/cockpit/intelligence_tui.sh --action status --json` : point d'entrée gouvernance intelligence/agents/MCP/IA
 - `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json` : synthèse canonique runtime/MCP/IA, avec surface auxiliaire `firmware_cad`, à partir de la mémoire intelligence, du mesh, de Mascarade et des preuves firmware/CAD
 - `bash tools/cockpit/refonte_tui.sh --action status` : raccourcis historiques et lots de refonte
 - `bash tools/cockpit/full_operator_lane.sh status --json` : lane opérateur consolidée
 - `bash tools/cockpit/run_alignment_daily.sh --json` : routine quotidienne santé + preuves
 Les sorties JSON cockpit convergent vers le contrat `cockpit-v1`: `contract_version`, `component`, `action`, `status`, `contract_status`, `artifacts`, `degraded_reasons`, `next_steps`.
 ## Surfaces principales
 - `menu` : menu simple
 - `gate_s0` : check “spec ready”
 - `fw` : build/test firmware
 - `hw` : gates hardware (ERC/netlist/BOM)
 - `mesh_sync_preflight.sh` : snapshot tri-repo (`Kill_LIFE`, `mascarade`, `crazy_life`) local + SSH, statut `ready|degraded|blocked`
 - `mesh_health_check.sh` : rapprochement consolidé `mesh_sync_preflight` + `readme_repo_coherence` + `log_ops` (avec `mesh_host_order`).
 - `log_ops.sh` : synthèse JSON, purge contrôlée et inventaire des artefacts de logs.
 - `lots-status` : état des lots locaux utiles + prochaine vraie question + resynchronisation de `docs/plans/18_*`
 - `lots-run` : enchaîne les lots auto-fix, la lane `autonomous_next_lots`, les validations, puis met à jour le suivi.
 - `run_next_lots_autonomously.sh` : enchaîne automatiquement tous les lots utiles détectés, un à un.
 - `runtime_ai_gateway.sh` : agrège la mémoire `intelligence_tui`, le mesh health et le runtime Mascarade/Ollama en un statut unique `ready|degraded|blocked`, expose une surface auxiliaire `firmware_cad`, publie `firmware_cad_summary_short_latest.json`, et dégrade vite le mode `--refresh` si une probe dépasse son timeout.
 - `bash tools/ai/zeroclaw_integrations_lot.sh verify` : validate ZeroClaw/n8n + smoke workflow.
 - `bash tools/ai/zeroclaw_integrations_lot.sh verify` remonte désormais un échec si le runtime n8n reste `degraded` ou `blocked`.
 - `ssh_healthcheck.sh` : check en lot de connectivite SSH sur les machines operateurs.
 - `mascarade_runtime_health.sh` : health-check live Mascarade/Ollama, smoke agent low-cost, artefacts JSON `latest.*`.
 - `mascarade_logs_tui.sh` : lecture, analyse, inventaire et purge contrôlée des artefacts Mascarade/Ollama.
 - `mascarade_incidents_tui.sh` : vue TUI dédiée des incidents Mascarade/Ollama (`summary|watch|brief|registry|queue|daily`).
 - `render_mascarade_incident_brief.sh` : export Markdown court des incidents/runtime Mascarade/Ollama pour la revue opérateur.
 - `mascarade_incident_registry.sh` : registre Markdown/JSON horodaté des incidents Mascarade/Ollama à partir des artefacts cockpit/opérateur.
 - `render_mascarade_incident_queue.sh` : file d’incidents Markdown/JSON triée par priorité, sévérité puis récence pour la revue opérateur.
 - `render_mascarade_incident_watch.sh` : watchboard Markdown/JSON ultra-court avec rollup priorité/sévérité, top queue et prochaines actions.
 - `render_mascarade_watch_history.sh` : historique Markdown/JSON des watchboards pour suivre l’évolution des `P1/P2/P3` et `high/medium/low` sur plusieurs runs.
 - `render_daily_operator_summary.sh` : synthèse quotidienne Markdown/JSON pour l’opérateur à partir du daily log, du brief, du registre et de la queue.
 - `full_operator_lane.sh` : runbook TUI `status|dry-run|live|all|logs|purge` pour la lane operateur.
 - `bash tools/cockpit/full_operator_lane.sh logs --json --logs-action summary|latest|list|purge` : surface native lane operateur pour piloter les logs Mascarade/Ollama.
 - `full_operator_lane_sync.sh` : propagation conservative du patchset operateur vers les lanes mesh, avec option `--mode clems-live`.
 - `yiacad-fusion` : préparation et smoke de la couche IA-native CAD (KiCad + FreeCAD) avec logs dédiés.
 - `intelligence_tui.sh` : index TUI de la gouvernance intelligence (audit, spec, plan, TODO, research, owners, memory, next-actions, logs) couvrant le lot 22 et le plan 23 `web/`.
 - `bash tools/cockpit/intelligence_tui.sh --action scorecard --json` : score de fragmentation documentaire, maturite par lane et artefacts `scorecard_latest.*`.
 - `bash tools/cockpit/intelligence_tui.sh --action comparison --json` : comparaison inter-repos entre `Kill_LIFE`, `ai-agentic-embedded-base`, `kill-life-studio`, `kill-life-mesh` et `kill-life-operator`.
 - `bash tools/cockpit/intelligence_tui.sh --action recommendations --json` : file de recommandations IA priorisee issue de l'audit et de la veille OSS.
 - `intelligence_program_tui.sh` : alias de compatibilité vers `intelligence_tui.sh` pour les anciens runbooks.
 - `lot_chain.sh` rafraîchit `intelligence_tui --action memory --json` avant d’écrire son statut et ses prochains choix manuels.
 - `bash tools/cockpit/refonte_tui.sh --action yiacad-fusion[:prepare|smoke|status|logs|clean-logs]` : exécute le lot YiACAD (préparation, vérification, statut, logs, purge).
 - `bash tools/cockpit/refonte_tui.sh --action intelligence|intelligence:plan|intelligence:todo|intelligence:research` : pont de compatibilité depuis la TUI refonte.
 - `bash tools/cockpit/intelligence_tui.sh --action memory --json` : écrit `artifacts/cockpit/intelligence_program/latest.json` et `latest.md` pour la continuité opérateur.
 - `bash tools/cockpit/intelligence_tui.sh --action scorecard|comparison|recommendations --json` : met aussi à jour les artefacts `scorecard_latest.*`, `repo_comparison_latest.*` et `recommendation_queue_latest.*`.
 - `bash tools/cockpit/intelligence_tui.sh --action next-actions` : derive les prochaines actions prioritaires depuis `TODO 22`, `TODO 23`, puis `specs/04_tasks.md`.
 - `bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json` : met à jour et lit la passerelle consolidée runtime/MCP/IA.
 - `bash tools/cad/install_yiacad_native_gui.sh install` : installe le plugin KiCad et le workbench FreeCAD de YiACAD.
 - `weekly-summary` : synthèse hebdomadaire opératoire pour lots, logs et état machine.
 - `bash tools/cockpit/refonte_tui.sh --action weekly-summary` : génère `artifacts/cockpit/weekly_refonte_summary.md`.
 - Journaux YiACAD: `artifacts/cad-fusion/`.
 - `bash tools/cockpit/yiacad_uiux_tui.sh --action logs-summary|logs-list|logs-latest|purge-logs` : lecture/analyse/purge des logs UI/UX.
 - `bash tools/cockpit/yiacad_uiux_tui.sh --action program-audit|next-spec|next-feature-map` : audit global YiACAD, spec du lot suivant et feature map Mermaid.
 - `bash tools/cockpit/yiacad_refonte_tui.sh --action status|backend-architecture|audit|ai-assessment|feature-map|spec|plan|todo|research|logs-summary|logs-list|logs-latest|purge-logs` : bundle global YiACAD (audit, backend, IA, plan, TODO, veille, logs).
 - `bash tools/cockpit/yiacad_operator_index.sh --action incident-watch|incident-history` : raccourcis opérateur très courts vers le watchboard Mascarade et son historique.
 - `bash tools/cockpit/machine_registry.sh --action summary|list|show --json` : registre canonique machines/capacités/placements.
 - `mesh_sync_preflight.sh` consomme le registre canonique pour les rôles, ports, priorités de charge, placements et cible de réserve.
 - `refonte_tui.sh --action mesh-preflight` : exécution TUI du préflight mesh.
 - `refonte_tui.sh --action mesh-preflight --mesh-load-profile photon-safe` : même préflight en mode allègement CILS.
 - `refonte_tui.sh --action ssh-health` : exécution TUI du health-check SSH.
 - `refonte_tui.sh --action mascarade-health` : exécution TUI du health-check Mascarade/Ollama.
 - `refonte_tui.sh --action mascarade-logs` : raccourci TUI vers `full_operator_lane.sh logs --logs-action summary`.
 - `refonte_tui.sh --action mascarade-logs-summary|mascarade-logs-latest|mascarade-logs-list|mascarade-logs-purge` : raccourcis TUI directs vers la surface logs native opérateur.
 - `refonte_tui.sh --action mascarade-incidents|mascarade-incidents-watch|mascarade-incidents-brief|mascarade-incidents-registry|mascarade-incidents-queue|mascarade-incidents-daily` : vues TUI directes pour le watchboard, le brief, le registre, la queue et la synthèse quotidienne Mascarade.
 - `refonte_tui.sh --action log-ops` : résumé centralisée logs avec JSON.
 - `refonte_tui.sh --action logs` : affichage + analyse courte des logs récents.
 - `refonte_tui.sh --action weekly-summary` : synthèse markdown prête pour revue d’agent / opérateur.
 - `refonte_tui.sh --action clean-logs --days 14 --yes-auto` : purge ciblée de logs plus anciens en mode non interactif
 - `mesh_sync_preflight.sh` : vérification convergence tri-repo (commande canonique)
 Note:
 - `lots-run` peut sortir avec le code `3` quand la chaîne est saine mais qu'un vrai choix opérateur reste nécessaire.
 - Tous les outputs → `artifacts/`.
 ## 1) Health-check SSH (script de routine)
 - Script: `bash tools/cockpit/ssh_healthcheck.sh --json`
 - Cibles standard (priorité P2P):
 | Machine | Port | Priorité | Rôle |
 | --- | --- | --- | --- |
 | `clems@192.168.0.120` | 22 | 1 | Machine de pilotage / orchestration locale |
 | `kxkm@kxkm-ai` | 22 | 2 | Mac opérateur |
 | `cils@100.126.225.111` | 22 | 3 | Mac opérateur secondaire (photon, non essentiel) |
 | `root@192.168.0.119` | 22 | 4 | Serveur système / exécution matérielle (réserve) |
 - Référence de preuve: `artifacts/cockpit/ssh_healthcheck_<YYYYMMDD>_<HHMMSS>.log`
 - Politique P2P de charge (réseau 4 cibles): priorité `Tower -> KXKM -> CILS -> local -> root`,
  chargement dynamique par score `load_ratio = loadavg / CPUs` + priorité statique.
  `cils` est verrouillé en `tower-first`: seuls les snapshots critiques `Kill_LIFE` sont lancés par défaut.
  mode `photon-safe` force `cils` en "no load": tout précheck applicatif distant CILS est ignoré (`cils-lockdown-photon-safe`).
  Les hôtes non critiques surchargés (`load_ratio > 1.8`) sont marqués en `degraded` sur cette passe.
  Les sorties SSH inattendues / non conformes ne cassent plus la passe: elles sont marquées `unreachable` ou `degraded` et restent dans le journal JSON.
  Priorité opérationnelle: `Tower` (`clems`) -> `KXKM` -> `CILS` (quota contrôlé) -> `local` -> `root` (réserve).
  - `bash tools/cockpit/mesh_sync_preflight.sh --load-profile tower-first`
  - `bash tools/cockpit/mesh_sync_preflight.sh --load-profile photon-safe`
  - `bash tools/cockpit/mesh_sync_preflight.sh --photon-safe`
 ## 2) Routine quotidienne recommandée (runbook)
 1. health-check SSH ciblé
 2. health-check Mascarade/Ollama live
 3. refresh header repo (refresh docs d'état)
 4. lecture + purge de logs via `tools/cockpit/log_ops.sh`
 5. préflight mesh avec stratégie de charge (tower-first par défaut)
 Exemple:
 ```bash
 bash tools/cockpit/ssh_healthcheck.sh --json
 bash tools/cockpit/mascarade_runtime_health.sh --json
 bash tools/repo_state/repo_refresh.sh --header-only
 bash tools/cockpit/log_ops.sh --action summary --json
 bash tools/cockpit/mesh_health_check.sh --json
 ```
 Consolidé journalier:
 ```bash
 bash tools/cockpit/run_alignment_daily.sh --json --mesh-load-profile tower-first
 bash tools/cockpit/log_ops.sh --action summary --json
 bash tools/cockpit/render_weekly_refonte_summary.sh
 ```
 Forcer le mode photon-safe:
 ```bash
 bash tools/cockpit/run_alignment_daily.sh --json --skip-healthcheck --mesh-load-profile photon-safe --skip-log-ops
 ```
 Si l’hôte est saturé, le preflight mesh peut être désactivé au passage:
 ```bash
 bash tools/cockpit/run_alignment_daily.sh --json --skip-mesh --skip-healthcheck
 ```
 Purge contrôlée:
 ```bash
 bash tools/cockpit/log_ops.sh --action purge --apply --retention-days 14
 ```
 `run_alignment_daily` expose maintenant un résumé JSON dédié `mascarade_health_status`, `mascarade_runtime_status`, `mascarade_provider`, `mascarade_model`, `mascarade_health_artifact`, `log_ops_summary_status`, `log_ops_stale`, `log_ops_purge_status` et `log_ops_purged`, et propose la purge de logs en contrôle de routine.
 `run_alignment_daily` capture aussi désormais `mascarade_logs_status`, `mascarade_logs_artifact`, `mascarade_brief_status`, `mascarade_brief_artifact` et `mascarade_brief_markdown`, afin que `machine_alignment_daily_latest.log` embarque un snapshot logs/runtime Mascarade/Ollama et un brief opérateur court.
 `run_alignment_daily` exporte aussi désormais `mascarade_registry_status`, `mascarade_registry_artifact`, `mascarade_registry_markdown`, `mascarade_queue_status`, `mascarade_queue_artifact`, `mascarade_queue_markdown`, `daily_operator_summary_status`, `daily_operator_summary_artifact` et `daily_operator_summary_markdown`.
 `run_alignment_daily` exporte aussi désormais `mascarade_watch_status`, `mascarade_watch_artifact` et `mascarade_watch_markdown` pour fournir un artefact de garde plus court que la synthèse quotidienne complète.
 `run_alignment_daily` exporte aussi désormais `mascarade_watch_history_status`, `mascarade_watch_history_artifact` et `mascarade_watch_history_markdown` pour garder une trace courte de l’évolution des priorités sur plusieurs runs.
 `run_alignment_daily` recalcule maintenant son `result` et son `contract_status` après la génération de la synthèse opérateur quotidienne, afin que le statut final reflète aussi un échec ou une dégradation sur `daily_operator_summary`.
 `render_daily_operator_summary.sh` et `render_weekly_refonte_summary.sh` intègrent désormais aussi la `mascarade incident queue`, afin que la priorisation opératoire apparaisse dans l’handoff quotidien comme dans la synthèse hebdomadaire.
 `render_daily_operator_summary.sh` affiche aussi un rollup ultra-court `priority P1/P2/P3` et `severity high/medium/low` pour accélérer la lecture opérateur.
 `render_mascarade_watch_history.sh` fournit désormais un mini registre temporel des watchboards pour suivre l’évolution des incidents courts sans relire chaque artefact daily.
 `full_operator_lane.sh` capture aussi automatiquement un snapshot `logs --logs-action latest` après `dry-run|live|all`, afin de conserver l’état Mascarade/Ollama le plus récent dans les artefacts opérateur.
 `full_operator_lane.sh` embarque désormais aussi la file d’incidents Mascarade (`mascarade_queue_*`), le watchboard court (`mascarade_watch_*`) et la synthèse opérateur quotidienne (`daily_operator_summary_*`) dans son contrat JSON natif.
 `full_operator_lane.sh --json` expose aussi désormais `priority_counts` et `severity_counts` au niveau top-level pour une lecture immédiate côté opérateur ou automation.
 `render_weekly_refonte_summary.sh` rafraîchit désormais aussi le brief, le registre, la queue, le watchboard incident et son historique Mascarade/Ollama avant de générer la synthèse hebdomadaire.
 Contrat JSON commun `cockpit-v1`:
 - champs communs introduits sur les sorties JSON cockpit/TUI ciblées: `contract_version`, `component`, `action`, `status`, `contract_status`, `artifacts`, `degraded_reasons`, `next_steps`
 - helper partagé: `tools/cockpit/json_contract.sh`
 - `mesh_sync_preflight.sh --json` expose aussi `registry_file`, `registry_status` et des `host_profiles` enrichis (`id`, `placement`, `reserve_only`)
 - `run_alignment_daily.sh --json` expose aussi `mascarade_health_status`, `mascarade_runtime_status`, `mascarade_provider`, `mascarade_model` et `mascarade_health_artifact`
 ## 3) Delta mesh tri-repo 2026-03-20
 - `mesh_sync_preflight.sh`: vérifie convergence multi-machines/multi-repos.
 - `log_ops.sh`: synthèse et purge contrôlée des logs avec sortie JSON exploitable.
 ## Delta 2026-03-21 - entree operateur YiACAD
 - `bash tools/cockpit/yiacad_operator_index.sh --action status|uiux|global|backend|proofs|logs-summary|logs-list|logs-latest|purge-logs` : entree operateur stable entre la lane UI/UX, la lane globale et le backend service.
 - `backend-proof`, `review-session`, `review-history` et `review-taxonomy` restent compatibles mais pointent vers les routes canoniques.
 ## Delta 2026-03-21 - backend service YiACAD
 - `bash tools/cockpit/yiacad_backend_service_tui.sh --action status|health|logs-summary|logs-list|logs-latest|purge-logs` : surface operatoire du backend service YiACAD.
 - Elle est la destination canonique de `backend` depuis l'index opérateur.
 ## 2026-03-21 - Canonical operator entry
 - Entree publique recommandee: `bash tools/cockpit/yiacad_operator_index.sh --action status`.
 - Surface de preuves: `bash tools/cockpit/yiacad_proofs_tui.sh --action status`.
 - Surface de logs: `bash tools/cockpit/yiacad_logs_tui.sh --action status`.
 - Les routes directes historiques restent compatibles, mais ne sont plus l'entree publique recommandee.
 ## Delta 2026-03-21 - Mascarade Tower / dispatch mesh
 - `tower` (`clems@192.168.0.120`) est maintenant normalise comme premiere cible lourde Mascarade/Ollama.
 - Runtime:
  - `bash tools/ops/deploy_mascarade_tower_runtime.sh --action status --json`
  - `bash tools/ops/deploy_mascarade_tower_runtime.sh --action apply --json`
 - Seed agents Tower:
  - `bash tools/ops/sync_mascarade_agents_tower.sh --action plan --json`
  - `bash tools/ops/sync_mascarade_agents_tower.sh --action sync --apply --json`
 - Dispatch mesh:
  - `bash tools/cockpit/mascarade_dispatch_mesh.sh --action summary --json`
  - `bash tools/cockpit/mascarade_dispatch_mesh.sh --action route --profile tower-code --json`
  - `bash tools/cockpit/mascarade_dispatch_mesh.sh --action route --profile kxkm-analysis --json`
 - Politique P2P retenue:
  - charges lourdes: `tower -> kxkm -> local -> cils -> root-reserve`
  - texte interactif / docs: `kxkm -> tower -> local -> cils -> root-reserve`
 - Contrats:
  - `specs/contracts/mascarade_model_profiles.tower.json`
  - `specs/contracts/mascarade_dispatch.mesh.json`
 ## Delta 2026-03-21 - contrat produit ops / Mascarade / kill_life
 - Contrat commun:
  - `specs/contracts/ops_mascarade_kill_life.contract.json`
 - Doc de cadrage:
  - `docs/OPS_MASCARADE_KILL_LIFE_PRODUCT_CONTRACT_2026-03-21.md`
 - Objectif:
  - `ops` montre l'etat reel et declenche l'action
  - `Mascarade` recommande avec `trust_level` et routing explicites
  - `kill_life` persiste `resume_ref`, decision et handoff
 - Prochain lot recommande:
  - projeter `status`, `decision`, `owner`, `artifacts`, `next_step`, `resume_ref`, `trust_level`, `routing` et `memory_entry` dans les sorties JSON cockpit prioritaires
 ## Delta 2026-03-21 - projection contrat produit
 - Writer memoire:
  - `bash tools/cockpit/write_kill_life_memory_entry.sh --component run_alignment_daily --json`
 - `full_operator_lane.sh --json` expose maintenant aussi:
  - `owner`
  - `decision`
  - `resume_ref`
  - `trust_level`
  - `routing`
  - `memory_entry`
 - `run_alignment_daily.sh --json` expose maintenant aussi:
  - `owner`
  - `decision`
  - `resume_ref`
  - `trust_level`
  - `routing`
  - `memory_entry`
 - la continuité `kill_life` est matérialisée dans:
  - `artifacts/cockpit/kill_life_memory/latest.json`
  - `artifacts/cockpit/kill_life_memory/latest.md`
 ## Delta 2026-03-21 - surfaces Mascarade courtes alignées
 - `mascarade_runtime_health.sh --json` expose maintenant aussi:
  - `owner`
  - `decision`
  - `resume_ref`
  - `trust_level`
  - `routing`
  - `memory_entry`
 - `mascarade_incidents_tui.sh --json` relit désormais la continuité `kill_life` latest et remonte:
  - `resume_ref`
  - `trust_level`
  - `routing`
  - `memory_entry`
 - `render_daily_operator_summary.sh` et `render_weekly_refonte_summary.sh` affichent aussi la reprise `kill_life` dans le Markdown de handoff.
 ## Delta 2026-03-21 - surfaces Mascarade très courtes alignées
 - `render_mascarade_incident_brief.sh`, `render_mascarade_incident_queue.sh`, `render_mascarade_incident_watch.sh` et `render_mascarade_watch_history.sh` relisent aussi désormais:
  - `trust_level`
  - `resume_ref`
  - `routing`
  - `memory_entry`
 - les résumés Markdown Mascarade n'obligent plus à basculer vers une autre surface pour comprendre la reprise opérateur.
 ## Delta 2026-03-21 - correction mémoire kill_life et dernières surfaces
 - `write_kill_life_memory_entry.sh` exporte désormais correctement les `artifacts` vers sa charge Python.
 - `mascarade_incident_registry.sh` relit maintenant aussi:
  - `trust_level`
  - `resume_ref`
  - `routing`
  - `memory_entry`
 - `mascarade_logs_tui.sh` remonte désormais ces champs sur les vues `summary`, `list` et `latest`.
 ## Delta 2026-03-21 - gouvernance et points d'entrée
 - `yiacad_operator_index.sh` affiche maintenant explicitement la continuité `kill_life` dans son statut:
  - `artifacts/cockpit/kill_life_memory/latest.md`
  - `artifacts/cockpit/daily_operator_summary_latest.md`
 - `intelligence_tui.sh --action memory` relie aussi la mémoire de gouvernance à la mémoire de reprise `kill_life`.
 ## Delta 2026-03-21 - chaînes de pilotage cockpit
 - `refonte_tui.sh --action status` pointe désormais aussi vers:
  - `artifacts/cockpit/kill_life_memory/latest.json`
  - `artifacts/cockpit/kill_life_memory/latest.md`
  - `artifacts/cockpit/daily_operator_summary_latest.md`
 - `lot_chain.sh` publie maintenant la continuité `kill_life` dans:
  - `artifacts/cockpit/useful_lots_status.md`
  - le bloc `AUTO LOT-CHAIN PLAN` de `specs/03_plan.md`
  - le bloc `AUTO LOT-CHAIN TASKS` de `specs/04_tasks.md`
 - objectif:
  - garder le même point de reprise entre la TUI courte, la chaîne de lots et les handoffs cockpit
 ## Delta 2026-03-21 - audit statique du contrat produit
 - `bash tools/cockpit/product_contract_audit.sh`
 - sorties:
  - `artifacts/cockpit/product_contract_audit/latest.json`
  - `artifacts/cockpit/product_contract_audit/latest.md`
 - objectif:
  - vérifier sans relance runtime que les surfaces cockpit et les points d'entrée gardent visibles les ancrages `resume_ref`, `trust_level`, `routing` et `memory_entry`
 - cartographie associée:
  - `docs/OPS_MASCARADE_KILL_LIFE_FEATURE_MAP_2026-03-21.md`
 ## Delta 2026-03-21 - handoff produit minimal
 - `bash tools/cockpit/render_product_contract_handoff.sh`
 - sorties:
  - `artifacts/cockpit/product_contract_handoff/latest.json`
  - `artifacts/cockpit/product_contract_handoff/latest.md`
 - objectif:
  - agréger l'audit de contrat, la mémoire `kill_life` latest et le handoff quotidien dans un seul brief opérateur court
 ## Delta 2026-03-21 - handoff produit auto-régénérant
 - `bash tools/cockpit/render_product_contract_handoff.sh`
  - défaut: tente de régénérer les prérequis légers `kill_life` et `daily_operator_summary`
  - mode strict: `bash tools/cockpit/render_product_contract_handoff.sh --no-refresh`
 - champs JSON ajoutés:
  - `degraded_reasons`
  - `prereqs_refreshed`
  - `kill_life_refresh_status`
  - `daily_refresh_status`
  - `markdown_file`
  - `latest_markdown_file`
 - intégration dans les chemins opérateur:
  - `run_alignment_daily.sh --json`
  - `full_operator_lane.sh --json`
  - `yiacad_operator_index.sh --action status`
  - `refonte_tui.sh --action status`
 - garde-fou:
  - `product_contract_audit.sh` vérifie maintenant aussi la présence du handoff et son exposition dans les points d'entrée opérateur
 - distinction retenue:
  - audit statique = cohérence source des surfaces
  - handoff runtime léger = disponibilité réelle du point de reprise canonique
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -48,3 +48,5 @@ export MISTRAL_API_KEY="708zM4biF4WjZIAROJh2roFiAPK9O7kG"
 export ANTHROPIC_API_KEY="sk-ant-api03-..."
 export OPENAI_API_KEY="sk-proj-..."
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,52 @@
 # T-MA-021 — Benchmark Multi-Provider Mascarade
 Benchmark comparatif base models vs fine-tuned sur prompts métier électronique.
 ## Structure
 ```
 evals/
 ├── benchmark_providers.py    # Runner principal (Mistral, Anthropic, OpenAI)
 ├── prompts/
 │   └── metier_100_template.jsonl  # 20 prompts template (à étendre à 100)
 └── results/                  # Résultats des runs (gitignored)
 ```
 ## Usage
 ```bash
 # Dry run (pas d'appels API)
 python benchmark_providers.py --prompts prompts/metier_100_template.jsonl --dry-run
 # Run Mistral uniquement
 python benchmark_providers.py --prompts prompts/metier_100_template.jsonl --providers mistral
 # Run complet 3 providers
 python benchmark_providers.py --prompts prompts/metier_100_template.jsonl --providers mistral,anthropic,openai
 # Avec rate limiting adapté au free tier Anthropic (5 RPM)
 python benchmark_providers.py --prompts prompts/metier_100_template.jsonl --providers anthropic --rate-limit 13
 ```
 ## Format prompts (JSONL)
 ```json
 {"id": "K001", "domain": "kicad", "prompt": "...", "system": "...", "difficulty": "medium"}
 ```
 ## Domaines couverts
 - **KiCad** (K001-K040): Schéma, PCB, DRC, symboles, empreintes
 - **SPICE** (S001-S030): Simulation, netlists, analyse AC/DC/transitoire
 - **Embedded** (E001-E020): Firmware STM32/ESP32, drivers, protocoles
 - **Mixed** (M001-M010): Architecture hardware+firmware complète
 ## Env vars
 ```bash
 export MISTRAL_API_KEY="708zM4biF4WjZIAROJh2roFiAPK9O7kG"
 export ANTHROPIC_API_KEY="sk-ant-api03-..."
 export OPENAI_API_KEY="sk-proj-..."
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -79,3 +79,5 @@ python tools/hw/schops/schops.py block-make \
 python tools/hw/schops/schops.py block-ls --lib hardware/blocks/power.kicad_blocks
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,83 @@
 # schops (Schematic Ops)
 CLI local pour :
 - ERC/BOM/netlist via `kicad-cli`
 - bulk edits via `kicad-sch-api` (si installé)
 - Design Blocks KiCad 10 (structure + metadata)
 > Philosophie : **bulk edits safe** (backup + report) + exports déterministes (kicad-cli).
 ## Install (local)
 ```bash
 python -m venv .venv && source .venv/bin/activate
 python -m pip install -U pip
 python -m pip install -r tools/hw/schops/requirements.txt
 ```
 ## Usage
 ```bash
 python tools/hw/schops/schops.py --help
 ```
 ## Exports (kicad-cli)
 ```bash
 python tools/hw/schops/schops.py erc --schematic hardware/kicad/<proj>/<proj>.kicad_sch
 python tools/hw/schops/schops.py netlist --schematic hardware/kicad/<proj>/<proj>.kicad_sch
 python tools/hw/schops/schops.py bom --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --fields "Reference,Value,Footprint,${DNP}" \
  --group-by "Value,Footprint" \
  --exclude-dnp
 ```
 Les sorties vont dans `artifacts/hw/<timestamp>/`.
 ## Bulk edits (kicad-sch-api)
 ### Champs / propriétés
 Applique `hardware/rules/fields.yaml` (defaults + règles) et écrit un rapport JSON.
 ```bash
 python tools/hw/schops/schops.py apply-fields \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --rules hardware/rules/fields.yaml
 # review-only
 python tools/hw/schops/schops.py apply-fields --dry-run --schematic ... --rules ...
 ```
 ### Footprints
 ```bash
 python tools/hw/schops/schops.py apply-footprints \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --map hardware/rules/footprints.csv
 ```
 ### Renommage de nets (labels)
 ```bash
 python tools/hw/schops/schops.py rename-nets \
  --schematic hardware/kicad/<proj>/<proj>.kicad_sch \
  --rules hardware/rules/nets_rename.yaml
 ```
 ### Snapshot (pour diff)
 ```bash
 python tools/hw/schops/schops.py snapshot --schematic ... --name before.json
 # ... modifications ...
 python tools/hw/schops/schops.py snapshot --schematic ... --name after.json
 ```
 ## Design Blocks (KiCad 10)
 Les design blocks sont des dossiers `*.kicad_block` stockés dans une librairie `*.kicad_blocks`.
 ```bash
 python tools/hw/schops/schops.py block-make \
  --name buck_5v \
  --from-sheet hardware/kicad/buck/buck.kicad_sch \
  --lib hardware/blocks/power.kicad_blocks \
  --description "Buck 5V@2A" \
  --keywords "power,buck,5v"
 python tools/hw/schops/schops.py block-ls --lib hardware/blocks/power.kicad_blocks
 ```
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -45,3 +45,5 @@ Environment:
 - copy values from `.env.example`
 - `REDIS_URL` is required for the queue/worker path
 - `KIBOT_CONFIG` is optional until a real KiBot recipe is added to the project
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,49 @@
 # YiACAD Web
 This directory hosts the web-facing YiACAD scaffold:
 - `app/` provides the Next.js frontend and GraphQL route handler.
 - `components/` holds the Excalidraw canvas, KiCanvas viewer shell, project tree, and realtime status cards.
 - `project/` is the Git-tracked source-of-truth for `.excalidraw` diagrams and local KiCad inputs.
 - `realtime/server.mjs` launches the separate Yjs websocket server with persistence.
 Product routes:
 - `/` project dashboard
 - `/diagram` Excalidraw editor
 - `/pcb` KiCanvas viewer lane
 - `/review` PR review surface
 Key commands:
 - `npm install`
 - `npm run dev`
 - `npm run dev:realtime`
 - `npm run worker:eda`
 - `npm run vendor:kicanvas`
 The current realtime layer exposes a Yjs room and transport status.
 Binding Excalidraw scene data into the CRDT document is intentionally left as the next incremental lot.
 AI / intelligence overlay:
 - keep Git as the source of truth
 - keep Yjs as collaboration transport only
 - keep workers as the execution boundary
 - introduce review assist only as a read-only overlay once Git/CI/artifact read models are real
 Queue and workers:
 - GraphQL enqueues EDA jobs through Redis-backed `BullMQ`
 - `npm run worker:eda` consumes the queue and calls existing repo tools
 - `kicad-headless` uses `tools/cad/yiacad_native_ops.py`
 - `kibot` prefers a real `kibot` binary when configured, then falls back to `tools/cockpit/fab_package_tui.sh`
 - `kiauto-checks` is wired as a real queue pipeline and requires `KIAUTO_BIN`
 Environment:
 - copy values from `.env.example`
 - `REDIS_URL` is required for the queue/worker path
 - `KIBOT_CONFIG` is optional until a real KiBot recipe is added to the project
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -2,3 +2,5 @@
 Drop `.kicad_pcb`, `.kicad_sch`, and optional `.kicad_pro` files into this directory.
 The project service will expose them through `/api/project-files/...` so KiCanvas can load them.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
@@ -0,0 +1,6 @@
 # YiACAD PCB Viewer Inputs
 Drop `.kicad_pcb`, `.kicad_sch`, and optional `.kicad_pro` files into this directory.
 The project service will expose them through `/api/project-files/...` so KiCanvas can load them.
 <iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>
		`@@ -0,0 +1,3 @@`


							`<iframe src="https://github.com/sponsors/electron-rare/card" title="Sponsor electron-rare" height="225" width="600" style="border: 0;"></iframe>`