electron-rare/Kill_LIFE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
- 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.
This commit is contained in:
L'électron rare
2026-03-25 01:08:52 +01:00
parent f8c82b8544
commit a96780ba7e
73 changed files with 1936 additions and 384 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+357 -353
View File
File diff suppressed because it is too large Load Diff
README_FR.md
+2
View File
@@ -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>
ai-agentic-embedded-base/.specify/README.md
+13 -11
View File
@@ -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
des templates minimalistes.
To remain compatible with the **Spec Kit** approach, we expose a `.specify/` folder that contains
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.
- La PR doit référencer la spec (lien relatif).
- Les tests/exports (firmware CI + hardware CI) doivent être verts.
- One `specs/<name>/` folder per feature/epic.
- The PR must reference the spec (relative link).
- 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>
ai-agentic-embedded-base/.specify/README_FR.md
+29
View File
@@ -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>
ai-agentic-embedded-base/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/README_FR.md
+65
View File
@@ -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>
ai-agentic-embedded-base/bmad/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/bmad/README_FR.md
+9
View File
@@ -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>
ai-agentic-embedded-base/hardware/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/hardware/README_FR.md
+10
View File
@@ -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>
ai-agentic-embedded-base/hardware/blocks/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/hardware/blocks/README_FR.md
+11
View File
@@ -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>
ai-agentic-embedded-base/node_engine_architecture/universal_node_engine_starter/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/node_engine_architecture/universal_node_engine_starter/README_FR.md
+16
View File
@@ -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>
ai-agentic-embedded-base/specs/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/specs/README_FR.md
+86
View File
@@ -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>
ai-agentic-embedded-base/standards/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/standards/README_FR.md
+11
View File
@@ -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>
ai-agentic-embedded-base/standards/profiles/esp-first/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/standards/profiles/esp-first/README_FR.md
+7
View File
@@ -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>
ai-agentic-embedded-base/standards/profiles/stm32/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/standards/profiles/stm32/README_FR.md
+7
View File
@@ -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>
ai-agentic-embedded-base/tools/cockpit/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/tools/cockpit/README_FR.md
+11
View File
@@ -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>
ai-agentic-embedded-base/tools/hw/schops/README.md
+2
View File
@@ -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>
ai-agentic-embedded-base/tools/hw/schops/README_FR.md
+83
View File
@@ -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>
bmad/README.md
+2
View File
@@ -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>
bmad/README_FR.md
+12
View File
@@ -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>
deploy/cad/README.md
+2
View File
@@ -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>
deploy/cad/README_FR.md
+105
View File
@@ -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>
docs/plans/README.md
+2
View File
@@ -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>
docs/plans/README_FR.md
+39
View File
@@ -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>
docs/workflows/README.md
+2
View File
@@ -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>
docs/workflows/README_FR.md
+46
View File
@@ -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>
docs/workspace_audit_2026-03-24/README.md
+3
View File
@@ -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>
docs/workspace_audit_2026-03-24/README_FR.md
+3
View File
@@ -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>
hardware/README.md
+2
View File
@@ -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>
hardware/README_FR.md
+10
View File
@@ -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>
hardware/blocks/README.md
+2
View File
@@ -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>
hardware/blocks/README_FR.md
+11
View File
@@ -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>
openclaw/README.md
+3 -1
View File
@@ -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>
openclaw/README_FR.md
+36
View File
@@ -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>
openclaw/local_setup/README_VM_SANDBOX.md
+3 -1
View File
@@ -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>
openclaw/local_setup/README_VM_SANDBOX_FR.md
+51
View File
@@ -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>
openclaw/onboarding/README.md
+19 -17
View File
@@ -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
- 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é.
## Onboarding Box
- Read the openclaw/ README and the "OpenClaw Workflows & Security" section.
- Verify that your environment is sandboxed (no access to secrets/source code).
- Use `ai:*` labels for all actions.
- Publish only sanitized comments.
- Never modify `.github/workflows/` workflows without human validation.
- Check the FAQ and security guides.
## 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
## Contributor Checklist
- [ ] Sandbox enabled, no access to secrets/source code
- [ ] Actions limited to sanitized labels/comments
- [ ] Compliance with scope guard and conventions
- [ ] Evidence pack provided for any contribution
- [ ] Documentation updated
- [ ] 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>
openclaw/onboarding/README_FR.md
+23
View File
@@ -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>
specs/README.md
+2
View File
@@ -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>
specs/README_FR.md
+86
View File
@@ -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>
standards/README.md
+2
View File
@@ -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>
standards/README_FR.md
+11
View File
@@ -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>
standards/profiles/esp-first/README.md
+2
View File
@@ -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>
standards/profiles/esp-first/README_FR.md
+7
View File
@@ -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>
standards/profiles/stm32/README.md
+2
View File
@@ -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>
standards/profiles/stm32/README_FR.md
+7
View File
@@ -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>
tools/ai/integrations/README.md
+2
View File
@@ -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>
tools/ai/integrations/README_FR.md
+36
View File
@@ -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>
tools/ai/integrations/autogen/README.md
+2
View File
@@ -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>
tools/ai/integrations/autogen/README_FR.md
+21
View File
@@ -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>
tools/ai/integrations/langgraph/README.md
+2
View File
@@ -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>
tools/ai/integrations/langgraph/README_FR.md
+28
View File
@@ -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>
tools/ai/integrations/n8n/README.md
+2
View File
@@ -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>
tools/ai/integrations/n8n/README_FR.md
+50
View File
@@ -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>
tools/aperant
+1 -1
Submodule tools/aperant updated: 76fdbade6f...cba7a0270e
tools/cockpit/README.md
+2
View File
@@ -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>
tools/cockpit/README_FR.md
+358
View File
@@ -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>
tools/evals/README.md
+2
View File
@@ -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>
tools/evals/README_FR.md
+52
View File
@@ -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>
tools/hw/schops/README.md
+2
View File
@@ -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>
tools/hw/schops/README_FR.md
+83
View File
@@ -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>
web/README.md
+2
View File
@@ -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>
web/README_FR.md
+49
View File
@@ -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>
web/project/pcb/README.md
+2
View File
@@ -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>
web/project/pcb/README_FR.md
+6
View File
@@ -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>