Kill_LIFE

Template de projet embarque IA-natif, spec-first, avec gates de qualite, evidence packs et outillage runtime pour firmware, CAD et conformite.

Principe

Kill_LIFE structure un projet embarque autour de specs testables, d'agents specialises, de gates de qualite et d'artefacts verifiables. Le depot couvre trois axes:

• firmware et CI locale/containeurisee
• CAD headless KiCad 10 first
• evidence, compliance et workflows canoniques

Le runtime operateur local ZeroClaw reste supporte pour les boucles agentiques et les integrations. LangGraph et AutoGen sont gardes comme patterns d'integration optionnels autour de ZeroClaw, pas comme chemins critiques du gate stable repo-local.

Structure utile

Kill_LIFE/
├── firmware/                    # Code PlatformIO
├── hardware/                    # Assets hardware et blocs
├── specs/                       # Specs et taches canoniques
├── workflows/                   # Workflows JSON canoniques + templates
├── tools/
│   ├── compliance/              # Validation compliance
│   ├── hw/                      # Stack CAD, MCP, exports, smoke
│   ├── mistral/                 # Safe patch et outils Mistral
│   └── ci/                      # Audit CI
├── deploy/cad/                  # Dockerfiles et compose CAD/runtime
├── docs/                        # Docs operateur, bridge, plans, workflows
├── test/                        # Tests Python
├── mcp.json                     # Profil MCP par defaut
└── mkdocs.yml                   # Site docs

Demarrage rapide

Prerequis

• Python 3.10+
• Docker + docker compose
• gh pour les operations GitHub
• PlatformIO en natif ou via la stack conteneurisee

Installation

git clone https://github.com/electron-rare/Kill_LIFE.git
cd Kill_LIFE
bash install_kill_life.sh

ZeroClaw natif (optionnel)

Le runtime operateur ZeroClaw peut aussi tourner nativement sur la machine operateur. Le chemin supporte dans ce repo est le binaire officiel installe dans ~/.cargo/bin, avec compatibilite maintenue pour zeroclaw/target/release/zeroclaw.

git clone https://github.com/zeroclaw-labs/zeroclaw.git zeroclaw
bash zeroclaw/bootstrap.sh --no-guided --prefer-prebuilt
mkdir -p "$HOME/.local/bin" zeroclaw/target/release
ln -sfn "$HOME/.cargo/bin/zeroclaw" "$HOME/.local/bin/zeroclaw"
ln -sfn "$HOME/.cargo/bin/zeroclaw" zeroclaw/target/release/zeroclaw
zeroclaw --version

Les launchers tools/ai/zeroclaw_*.sh resolvent maintenant la racine du repo dynamiquement et retombent sur command -v zeroclaw si besoin.

Posture operateur retenue:

• zeroclaw.saillant.cc = surface live du runtime natif quand la stack est demarree
• zeroclaw-docs.saillant.cc = runbook ZeroClaw statique
• langgraph.saillant.cc = runbook LangGraph statique
• la stack native reste demarrable a la demande via tools/ai/zeroclaw_stack_up.sh
• le fallback provider OpenRouter est supporte et valide sur un appel webhook reel

Chemin operateur supporte:

bash tools/ai/zeroclaw_stack_up.sh
bash tools/ai/zeroclaw_stack_down.sh

Le runtime ZeroClaw reste on-demand. Les runbooks et index d'integration servis via mascarade/edge-proxy viennent de tools/ai/integrations/. Ils restent consultables meme quand le runtime ZeroClaw n'est pas demarre.

Bootstrap Python repo-local

bash tools/bootstrap_python_env.sh

Options utiles:

• --venv-dir /tmp/kill-life-venv pour verifier le bootstrap sur une machine ou un environnement vierge
• --reinstall pour recreer proprement le venv cible

Le chemin supporte pour le Python du repo est ./.venv/bin/python.

Tests Python repo-local

bash tools/test_python.sh

Ce chemin couvre la suite Python repo-locale stable (setup_repo, mcp_runtime_status, openclaw_sanitizer, apply_safe_patch, validate_specs, tools/hw/schops/tests) sans dependre du python3 systeme. Les checks dependants du mirror specs ou des runtimes MCP restent des commandes d'integration separees.

Options utiles:

• --suite stable pour le chemin repo-local supporte par defaut
• --suite mcp pour les tests MCP locaux (knowledge-base, github-dispatch, nexar)
• --suite all pour enchainer les deux
• --bootstrap pour creer le venv cible avant de lancer les tests
• --list pour afficher exactement les commandes couvertes

Exemple de verification sur un venv temporaire:

bash tools/test_python.sh --bootstrap --venv-dir /tmp/kill-life-venv --suite stable

Verifications utiles

python3 tools/compliance/validate.py --strict
python3 tools/validate_specs.py --json
bash tools/hw/cad_stack.sh doctor
KILL_LIFE_PIO_MODE=container python3 tools/auto_check_ci_cd.py

Workflow catalog

Les workflows editables par crazy_life vivent dans workflows/ et sont valides contre workflows/workflow.schema.json.

• workflows/*.json : workflows canoniques
• workflows/templates/*.json : templates de creation
• .crazy-life/runs/ : etat des runs locaux
• .crazy-life/backups/workflows/ : revisions et restores

CAD et MCP

La stack CAD est documentee dans deploy/cad/README.md et pilotee par tools/hw/cad_stack.sh.

• cible actuelle: KiCad 10 first
• launcher MCP: tools/hw/run_kicad_mcp.sh
• configuration MCP: docs/MCP_SETUP.md et mcp.json

Ecosysteme

• crazy_life : repo canonique web/devops
• mascarade : repo compagnon/orchestration et bridge historique optionnel
• docs/MASCARADE_BRIDGE.md : articulation locale entre les depots

Contrat multi-repo:

• crazy_life publie la surface web/devops et le workflow editor.
• Kill_LIFE reste la source de verite pour workflows/*.json, le runtime, les evidence packs, le firmware, le CAD et la compliance.
• mascarade ne redevient pas la source canonique de release web; le bridge reste un mecanisme de sync seulement.

CI et release

• .github/workflows/ci.yml porte le gate repo-local stable: bootstrap Python + bash tools/test_python.sh --suite stable.
• .github/workflows/release_signing.yml reste le workflow de release versionnee; il attend un tag v* ou un workflow_dispatch avec release_tag explicite.
• GitHub Pages n'est pas un gate canonique pour la release Crazy Lane; les workflows Pages de Kill_LIFE restent des surfaces secondaires docs/evidence.

Licence

MIT. Voir licenses/MIT.txt.