electron-rare/Kill_LIFE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
Kill_LIFE/README_FR.md
T
Clément SAILLANT 5efb380da5 feat: automate yiacad PR review lane (#18) 
* feat: automate yiacad pr review lane

* fix: stabilize yiacad review and spec gates

* fix: scope kicad exports to repo hardware

* fix: ignore kicad block library sources in exports

* feat: Add infra VPS monitoring runbook and healthcheck scripts

- Created INFRA_VPS_RUNBOOK_2026.md detailing operational procedures for monitoring VPS services.
- Added infra_vps_healthcheck.sh script for automated health checks on DNS, TLS, TCP, and HTTP for VPS services.
- Introduced infra_vps_security_audit.sh for non-intrusive security checks on external VPS services.
- Established JSON schema for infra VPS inventory in infra_vps.schema.json.
- Developed integration for runtime status reporting in the Next.js API route.
- Implemented Playwright tests for smoke testing the application and ensuring core functionalities.
- Updated Makefile for development dependencies and testing commands.
- Created various test files for unit and end-to-end testing across different components.

* feat(agentics): update mesh agents, gates, prompts, and workflows
2026-03-29 17:14:16 +02:00

36 KiB
Raw Permalink Blame History

Kill_LIFE 🚀 — Control Plane IA-native, cockpit opérateur et lot pilote extensions

CI Licence MIT Compliance

Bannière Kill_LIFE

Bienvenue dans Kill_LIFE, le control plane public du programme agentique Kill_LIFE. Le repo concentre aujourd'hui le cockpit opérateur, la chaîne spec-first, les contrats runtime/MCP, les preuves d'exécution, et le lot pilote qui alimente les extensions VS Code soeurs kill-life-studio, kill-life-mesh et kill-life-operator.

La regle de lecture 2026-03-22 est simple:

  • ce README.md décrit le produit/programme et les décisions de consolidation
  • docs/index.md est la navigation opérateur canonique
  • tools/cockpit/README.md est l'entrée outillage/TUI canonique
  • specs/README.md reste la source de vérité de la chaîne spec-first
  • docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md porte l'audit structure, les risques, la matrice IA et la carte de fonctionnalites

La boucle courte de gouvernance locale est désormais:

lot_chain -> intelligence_tui(memory) -> runtime_ai_gateway(status)

Le programme d'integration intelligence actuellement actif se suit dans:

  • docs/plans/22_plan_integration_intelligence_agentique.md
  • docs/plans/22_todo_integration_intelligence_agentique.md
  • docs/plans/23_plan_yiacad_git_eda_platform.md
  • docs/plans/23_todo_yiacad_git_eda_platform.md
  • specs/04_tasks.md

Entrées canoniques

Surface Rôle Entrée recommandée
Produit / programme Vue d'ensemble, périmètre, stratégie README.md
Navigation opérateur Index docs, runbooks, preuves, routines docs/index.md
Cockpit / TUI Commandes shell, contrats cockpit-v1, santé runtime bash tools/cockpit/yiacad_operator_index.sh --action status
Gouvernance intelligence owners, mémoire et prochaines actions bash tools/cockpit/intelligence_tui.sh --action status --json
Gateway runtime/MCP/IA synthèse consolidée runtime, mesh et Mascarade bash tools/cockpit/runtime_ai_gateway.sh --action status --refresh --json
Chaîne spec-first Intake -> spec -> arch -> plan -> tasks specs/README.md
Audit consolidé forces, faiblesses, opportunités, risques, IA docs/KILL_LIFE_CONSOLIDATION_AUDIT_2026-03-22.md
Veille OSS benchmark MCP, orchestration, VS Code agents docs/WEB_RESEARCH_OPEN_SOURCE_2026-03-22.md

🧩 Présentation

Kill_LIFE n'est plus seulement un squelette embarqué. Le repo sert désormais de source de vérité publique pour un programme plus large: opérations locales, gouvernance tri-repo, runtime MCP/IA, lot YiACAD, et spécialisation progressive des extensions VS Code.

Le positionnement retenu pour cette passe de consolidation est:

  • Kill_LIFE = control plane, cockpit, contrats, preuves et référentiel documentaire
  • kill-life-studio = produit, specs, décisions, périmètre, roadmap
  • kill-life-mesh = orchestration multi-repo, handoffs, ownership, dépendances
  • kill-life-operator = exécution, checks, evidence, runbooks

« Bienvenue dans le meilleur des mondes : ici, chaque commit est validé, chaque gate est passé, et chaque agent sait que la vraie liberté, c'est d'avoir un evidence pack bien rangé. » — Aldous Huxley, version CI/CD

🧩 Architecture & Principes

  • Spec-first : Chaque évolution commence par une définition claire dans specs/ (Spec Generator FX).

    Schaeffer : Les agents du pipeline écoutent le bruit des specs comme une symphonie de sons trouvés.

  • Injection de standards : Standards versionnés et profils injectés (Agent OS).
  • Catalogue agents 2026 : 12 agents top-level pilotés par contrat avec write sets, rituels, gates, prompts et handoffs définis (agents/, specs/contracts/kill_life_agent_catalog.json).
  • Tool-first : Scripts reproductibles (tools/), evidence pack canonique dans docs/evidence/ et expose en artifact CI.
  • Pipeline hardware/firmware : Bulk edits, exports, tests, conformité, snapshots.
  • CAD headless : KiCad 10 first + FreeCAD + OpenSCAD via MCP, conteneurisés.
  • YiACAD : lot IA-native de fusion KiCad + FreeCAD (with logs dédiés et smoke canari).
  • Pilotage tri-repo : contract ready|degraded|blocked piloté par mesh_sync_preflight.sh + refonte_tui.sh.
  • Sécurité & conformité : Sanitisation, sorties sûres, sandboxing, scope guard, anti-prompt injection (OpenClaw Sandbox).
  • Runtime agentique : ZeroClaw en local on-demand, LangGraph et AutoGen comme patterns d'intégration optionnels.
Schéma des agents BMAD

« La réponse à la question ultime de la vie, de l'univers et du développement embarqué IA : 42 specs, 12 agents, et un pipeline qui ne panique jamais. » — Le README qui ne panique jamais 42

(Les particules font-elles l'amour ?)

✨ Fonctionnalités principales

  • Développement guidé par la spec : User stories, contraintes, architecture, plans, backlog.
  • Automatisation : Issue → PR avec tests unitaires, sanitisation, evidence pack.
  • Multi-cibles : ESP32, STM32, Linux, tests natifs.
  • Pipeline matériel : KiCad, exports SVG/ERC/DRC/BOM/netlist, bulk edits.
  • Conformité : Profils injectés, validation automatique.
  • OpenClaw : Labels & commentaires sanitisés, jamais de commit/push, sandbox obligatoire.
  • Workflow catalog : Workflows JSON éditables par crazy_life, validés contre un schéma JSON.
Pipeline hardware/firmware

🖥️ Schéma agentique (Mermaid)

flowchart TD
  Issue[Issue label ai:*] --> PR[Pull Request]
  PR --> Gate[Gate tests + conformité]
  Gate --> Evidence[Evidence Pack]
  Evidence --> CI[22 workflows CI/CD]
  CI --> Deploy[Déploiement multi-cible]
  PR --> Agents[12 agents canoniques]
  Agents --> Specs[specs/ — 21 specs]
  Agents --> Firmware[firmware/ PlatformIO]
  Agents --> Hardware[hardware/ KiCad]
  Agents --> Docs[docs/]
  Agents --> Compliance[compliance/]
  Agents --> Tools[tools/]
  Agents --> OpenClaw[openclaw/]
  Specs --> Standards[standards/]
  Firmware --> Tests[test/]
  Hardware --> MCP{7 serveurs MCP}
  MCP --> KiCad[KiCad MCP]
  MCP --> FreeCAD[FreeCAD MCP]
  MCP --> OpenSCAD[OpenSCAD MCP]
  MCP --> YiACAD[YiACAD lot]
  MCP --> HF[HuggingFace MCP]
  Compliance --> Evidence
  OpenClaw --> Sandbox[Sandbox]
  Agents -.-> ZeroClaw[ZeroClaw runtime]
  ZeroClaw -.-> LangGraph[LangGraph]
  ZeroClaw -.-> AutoGen[AutoGen]
  ZeroClaw -.-> N8N[n8n]

Parmegiani : Un bulk edit, c'est une métamorphose électronique, un peu comme un pack d'évidence qui se transforme en nuage de sons.

🗺️ Structure du projet

Arborescence du projet Kill_LIFE 
Kill_LIFE/
├── firmware/                    # Code PlatformIO (ESP32/STM32)
├── hardware/                    # Assets hardware et blocs KiCad
├── specs/                       # 21 specs et tâches canoniques (00_intake → 04_tasks + MCP/ZeroClaw/CAD)
├── workflows/                   # Workflows JSON canoniques + templates + schéma
├── agents/                      # 12 agents top-level backés par le catalogue
├── bmad/                        # Gates (S0, S1), rituels (kickoff), templates (handoff, status)
├── compliance/                  # Profils réglementaires, standards catalog, evidence
├── standards/                   # Standards globaux versionnés
├── openclaw/                    # Labels, sandbox, onboarding
├── tools/
│   ├── compliance/              # Validation compliance
│   ├── hw/                      # Stack CAD, MCP, exports, smoke, schops
│   ├── ai/                      # ZeroClaw launchers, intégrations (langgraph, autogen, n8n)
│   ├── mistral/                 # Safe patch et outils Mistral
│   └── ci/                      # Audit CI
├── web/                         # Frontend Next.js YiACAD (dashboard, editor, viewer, review)
├── deploy/cad/                  # Dockerfiles et compose CAD/runtime
├── docs/                        # Docs opérateur, bridge, plans, workflows
├── test/                        # Tests Python (stable + MCP)
├── .github/
│   ├── agents/                  # 12 définitions agents GitHub
│   ├── prompts/                 # Prompts start/plan backés par le catalogue + prompts partagés
│   └── workflows/               # 22 workflows CI/CD
├── KIKIFOU/                     # Diagnostic, diagramme, mapping, recommandations
├── mcp.json                     # 7 serveurs MCP configurés
└── mkdocs.yml                   # Site docs

Gouvernance refonte / IA-native

Refonte UI/UX Apple-native 2026

Bundle global YiACAD 2026

Chaîne de specs

Le workflow spec-first suit une séquence canonique dans specs/ :

00_intake.md → 01_spec.md → 02_arch.md → 03_plan.md → 04_tasks.md

Specs spécialisées : kicad_mcp_scope_spec.md, knowledge_base_mcp_spec.md, github_mcp_conversion_spec.md, cad_modeling_tasks.md, zeroclaw_dual_hw_orchestration_spec.md, mcp_agentics_target_backlog.md.

Contraintes : specs/constraints.yaml — source de vérité pour cibles, toolchain, sécurité IA et compliance.

Agents & prompts

Le catalogue canonique 2026 est défini dans specs/contracts/kill_life_agent_catalog.json puis reflété dans agents/ et .github/agents/.

Agent Rôle
PM-Mesh intake, planification, priorisation, gouvernance mesh
Arch-Mesh architecture, ADR, frontières de contrat
Docs-Research docs canoniques, navigation, recherche, narration catalogue
Runtime-Companion runtime IA, alignement MCP, provider bridges
QA-Compliance tests, schémas, gates release, evidence
Embedded-CAD KiCad, FreeCAD, lanes CAD/fabrication
Web-CAD-Platform Next.js, GraphQL, realtime, workers, review
UX-Lead UX YiACAD, shell natif, recherche design
Firmware implémentation et validation PlatformIO
SyncOps cockpit, logs, SSH, incidents, opérations mesh
Schema-Guard schémas de contrat et validation structurelle
KillLife-Bridge workflows et evidence bridge tri-repo

Chaque agent canonique possède maintenant un start_<agent>.prompt.md et un plan_wizard_<agent>.prompt.md, tandis que .github/prompts/plan_wizard_agents_management.prompt.md et .github/prompts/plan_wizard_agents_coordination.prompt.md restent partagés pour l'orchestration et la checklist globale.

BMAD (gates & rituels)

Le framework BMAD dans bmad/ structure la progression :

  • Gates : gate_s0.md (pré-spec), gate_s1.md (pré-implémentation)
  • Rituels : kickoff.md
  • Templates : handoff.md, status_update.md

Voir KIKIFOU/diagramme.md pour le diagramme complet et KIKIFOU/mapping.md pour la table de mapping.

Plan d'analyse repo courant:

Infrastructure opérationnelle:

  • Machines SSH opérateur (port SSH: 22, priorité opérationnelle: Tower -> KXKM -> CILS -> local -> root):

    Machine Utilisateur Rôle Port Script principal
    clems@192.168.0.120 clems Machine de pilotage / orchestration locale 22 run_alignment_daily.sh, ssh_healthcheck.sh
    kxkm@kxkm-ai kxkm Mac opérateur 22 run_alignment_daily.sh
    cils@100.126.225.111 cils Mac opérateur secondaire (photon, locké: pas de service essentiel) 22 run_alignment_daily.sh
    root@192.168.0.119 root Serveur système / exécution matérielle (réserve) 22 run_alignment_daily.sh

  • Politique de charge P2P: mesh_sync_preflight.sh --load-profile tower-first

    • ordre: Tower -> KXKM -> CILS -> local -> root
    • cils accepte uniquement le repo critique Kill_LIFE en mode verrouillé.

  • Repos GitHub actifs:

    • electron-rare/Kill_LIFE
    • electron-rare/mascarade
    • electron-rare/crazy-life (privé)

  • Snapshot machines/repos:

Health-check SSH (vérification machine)

bash tools/cockpit/ssh_healthcheck.sh --json
  • Vérification de connectivité par machine avec statut OK/KO par ligne.
  • Logs horodatés: artifacts/cockpit/ssh_healthcheck_<YYYYMMDD>_<HHMMSS>.log.
  • Contrat d’alignement opérationnel: docs/MACHINE_ALIGNMENT_CONTRACT_2026-03-20.md

Routine quotidienne:

bash tools/cockpit/run_alignment_daily.sh --json
bash tools/cockpit/run_alignment_daily.sh --skip-healthcheck --json
  • Lance health-check SSH + repo_refresh en mode header-only.
  • Intègre la mémoire opérationnelle: docs/MACHINE_SYNC_STATUS_2026-03-20.md et docs/MESH_SYNC_INCIDENT_REGISTER_2026-03-20.md.
  • En mode charge sensible, utiliser --mesh-load-profile photon-safe.
  • Écrit un log horodaté: artifacts/cockpit/machine_alignment_daily_<YYYYMMDD>_<HHMMSS>.log.
  • Purge auto configurable (--purge-days <N>, défaut 14).
  • Sur les machines non-pilotes, utiliser --skip-healthcheck si la clé SSH n’est pas prévue pour l’auto-check mutuel.

🚀 Installation & démarrage rapide

Prérequis

  • OS : Linux, macOS, Windows (WSL)
  • Python ≥ 3.10
  • Docker + docker compose
  • gh pour les opérations GitHub
  • PlatformIO en natif ou via la stack conteneurisée
  • KiCad (hardware)

Installation rapide

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

Voir INSTALL.md pour les détails.

Bootstrap Python repo-local

bash tools/bootstrap_python_env.sh

Options utiles :

  • --venv-dir /tmp/kill-life-venv pour vérifier le bootstrap sur un environnement vierge
  • --reinstall pour recréer proprement le venv cible

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

Tests Python

bash tools/test_python.sh
Suite Commande Contenu
stable --suite stable Tests repo-locaux (specs, compliance, sanitizer, safe patch, schops)
mcp --suite mcp Tests MCP locaux (knowledge-base, github-dispatch, nexar)
all --suite all Les deux suites enchaînées

Options : --bootstrap pour créer le venv avant, --list pour lister les commandes couvertes.

Vérifications utiles

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

tools/validate_specs.py inclut un preflight PyYAML avant d'appeler tools/compliance/validate.py et retourne un message d'installation explicite si la dependance manque.

🔧 Serveurs MCP

Le projet expose 7 serveurs MCP (Model Context Protocol) configurés dans mcp.json :

Serveur Type Rôle
kicad local Gestion de projet, schémas, PCB, bibliothèques, validation, exports, sourcing
validate-specs local Validation specs, compliance, RFC2119 (CLI + MCP stdio)
knowledge-base local Recherche, lecture, ajout de memos (docmost)
github-dispatch local Dispatch de workflows GitHub allowlistés
freecad local Modélisation 3D, rendu, export, validation
openscad local Modélisation paramétrique, export, validation
huggingface distant Accès au Hub HuggingFace (datasets, modèles, papers)

La stack CAD est documentée dans deploy/cad/README.md et pilotée par tools/hw/cad_stack.sh.

🤖 ZeroClaw & intégrations agentiques (optionnel)

Le runtime opérateur ZeroClaw peut tourner nativement sur la machine opérateur. Le launcher supporté essaie d'abord le binaire repo-local zeroclaw/target/release/zeroclaw, puis retombe sur command -v zeroclaw (typiquement ~/.cargo/bin/zeroclaw).

bash tools/ai/zeroclaw_stack_up.sh    # démarrer
bash tools/ai/zeroclaw_stack_down.sh  # arrêter

Les runbooks et intégrations vivent dans tools/ai/integrations/ :

Intégration Rôle
zeroclaw/ Runtime opérateur local, boucles agentiques
langgraph/ Pattern d'intégration LangGraph
autogen/ Pattern d'intégration AutoGen
n8n/ Orchestration no-code / workflows externes

Ces intégrations restent consultables même quand le runtime n'est pas démarré.

📦 Workflow catalog

Les workflows éditables par crazy_life vivent dans workflows/ et sont validés contre workflows/workflow.schema.json.

Workflow Fichier
Spec-first workflows/spec-first.json
Embedded CI local workflows/embedded-ci-local.json
Compliance release workflows/compliance-release.json
  • workflows/templates/*.json : templates de création
  • .crazy-life/runs/ : état des runs locaux généré par crazy_life si l'éditeur est utilisé
  • .crazy-life/backups/workflows/ : révisions/restores générés localement par crazy_life (non versionnés)

🦾 Workflows agents détaillés

1. Spécification → Implémentation Firmware

  1. Rédige la spec dans specs/.
  2. Ouvre une issue avec le label ai:spec.
  3. PM-Mesh et Arch-Mesh génèrent le plan et l'architecture.
  4. Firmware implémente le code dans firmware/.
  5. QA-Compliance ajoute les tests Unity et la validation contractuelle.
  6. Evidence pack généré automatiquement.
Evidence Pack

2. Bulk Edit Hardware KiCad

  1. Ouvre une issue type:systems + scope:hardware, puis ajoute ai:plan (ou ai:impl si le batch est déjà cadré).
  2. Embedded-CAD effectue le bulk edit via tools/hw/schops.
  3. Exporte ERC/DRC, BOM, netlist.
  4. Snapshot avant/après dans artifacts/hw/<timestamp>/.
Bulk Edit Party

3. Documentation & Conformité

  1. Ouvre une issue avec ai:plan puis route le write set vers l'owner canonique du catalogue.
  2. Docs-Research met à jour docs/, README.md et README_FR.md.
  3. QA-Compliance valide le profil de conformité et génère le rapport, avec relais doc si nécessaire.
Gate Validation

🛡️ Sécurité & conformité

  • OpenClaw : sandbox obligatoire, jamais d'accès aux secrets ou au code source.
  • Workflows CI : validation, sanitisation, scope guard, anti-prompt injection.
  • Evidence packs : tous les rapports dans artifacts/<domaine>/<timestamp>/.
  • Tests hardware reproductibles via scripts documentés.
OpenClaw Sandbox

CI Success CI Running CI Error CI Cancel CI Inactive

Chaîne de compliance

compliance/
├── active_profile.yaml          # Profil actif (ex: "prototype")
├── profiles/
│   ├── prototype.yaml           # Standards requis + evidence pour prototype
│   └── iot_wifi_eu.yaml         # Profil IoT WiFi marché EU
├── standards_catalog.yaml       # Catalogue de standards versionnés
├── plan.yaml                    # Produit, marché, radio, alimentation
└── evidence/
    ├── risk_assessment.md       # Évaluation des risques
    ├── security_architecture.md # Architecture de sécurité
    ├── test_plan_radio_emc.md   # Plan de test radio/EMC
    └── supply_chain_declarations.md

Contraintes projet (depuis specs/constraints.yaml) :

  • Orientation : ESP-first (cibles : esp32s3, esp32, esp32dev)
  • Firmware : PlatformIO + Unity (tests requis)
  • Hardware : KiCad ≥ 9 minimum, chemin préféré KiCad 10-first, bulk edits autorisés, ERC green requis
  • IA : un label ai:* adapte a l'etape est requis, secrets interdits, pas d'hypothese reseau
  • Compliance : profil actif injecté, validé par tools/compliance/validate.py

🌐 Écosystème

Repo Rôle Accès
Kill_LIFE Source de vérité : workflows, runtime, evidence packs, firmware, CAD, compliance 🌍 public
ai-agentic-embedded-base Compagnon local : miroir exporté des specs/ + seed firmware minimal, jamais source de vérité primaire local
crazy_life Surface web/devops et workflow editor 🔒 privé
mascarade Orchestration et bridge historique (sync uniquement) 🔒 privé

Datasets HuggingFace

8 datasets de fine-tuning publiés sur HuggingFace (JSON, 1K-10K entrées chacun) :

mascarade-stm32 · mascarade-spice · mascarade-iot · mascarade-power · mascarade-dsp · mascarade-emc · mascarade-kicad · mascarade-embedded

Articulation détaillée : docs/MASCARADE_BRIDGE.md

⚙️ CI & release

22 workflows GitHub Actions couvrent l'ensemble du cycle :

Catégorie Workflows
Gate principal ci.yml (bootstrap Python + suite stable)
Release release_signing.yml (tag v* ou workflow_dispatch)
Qualité badges.yml, evidence_pack.yml, repo_state.yml, repo_state_header_gate.yml
Sécurité secret_scan.yml, sbom_validation.yml, supply_chain.yml, incident_response.yml
Tests avancés api_contract.yml, model_validation.yml, performance_hil.yml
Infra dependency_update.yml, community_accessibility.yml
Pages jekyll-gh-pages.yml, static.yml (surfaces secondaires docs/evidence)
Orchestration zeroclaw_dual_orchestrator.yml

🤝 Contribuer

  1. Forke le dépôt et clone-le localement.
  2. Suis le guide d'onboarding (docs/index.md, RUNBOOK.md).
  3. Ajoute des exemples minimalistes pour chaque agent (voir agents/).
  4. Propose des blocks hardware, profils de conformité, tests.
  5. Ouvre une PR, passe les gates, fournis un evidence pack.
  6. Respecte les conventions de commit et de labelling (ai:*).

« Les particules rêvent-elles d'électron-ironique ? Peut-être font-elles l'amour dans le dossier hardware, pendant que les agents QA se demandent si la conformité est un rêve ou une réalité. » — Inspiré par Le Réplicant de K. Dick & Les particules font-elles l'amour

« J'ai vu des evidence packs briller dans l'obscurité près des gates S1… »

🔗 Liens utiles

❓ FAQ

Q : Comment démarrer rapidement ? R : bash install_kill_life.sh puis bash tools/bootstrap_python_env.sh.

Q : Comment lancer les tests ? R : bash tools/test_python.sh --suite stable

Q : Comment sécuriser OpenClaw ? R : Sandbox obligatoire, jamais d'accès aux secrets ou au code source.

Q : Comment contribuer ? R : Forke, suis le RUNBOOK, ouvre une PR avec evidence pack, respecte les labels ai:*.

Q : Où trouver la documentation complète ? R : docs/index.md, RUNBOOK.md, INSTALL.md.

📜 Licence

MIT. Voir licenses/MIT.txt.

Audit & Execution Plan (2026-03-10)

Snapshot

  • Priority: P2
  • Tech profile: other
  • Workflows: yes
  • Tests: yes
  • Debt markers: 6
  • Source files: 156

Corrections Prioritaires

  • Optimisation ciblée perf/maintenabilité
  • Ajouter/fiabiliser les commandes de vérification automatiques.
  • Clore les points bloquants avant optimisation avancée.

Optimisation

  • Identifier le hotspot principal et mesurer avant/après.
  • Réduire la complexité des modules les plus touchés.

Mémoire chantier

  • Control plane: /Users/electron/.codex/memories/electron_rare_chantier
  • Repo card: /Users/electron/.codex/memories/electron_rare_chantier/REPOS/Kill_LIFE.md

Delta mesh tri-repo 2026-03-20

Cette refonte opere desormais en mode maillé entre Kill_LIFE, mascarade et crazy_life.

Regles actives:

  • un lot doit declarer owner_repo, owner_agent, write_set, preflight, validations, evidence, sync_targets
  • aucun revert de changements externes
  • aucune propagation sans preflight de convergence
  • les MCP sont conformes en ready ou degraded; blocked doit etre justifie

Full operator lane (2026-03-20)

  • Workflow source of truth: workflows/embedded-operator-live.json
  • Live provider bridge:
    • tools/ops/operator_live_provider_smoke.js
    • tools/ops/operator_live_provider_smoke.py
  • TUI runbook: bash tools/cockpit/full_operator_lane.sh all
  • Patchset sync: bash tools/cockpit/full_operator_lane_sync.sh --json
  • Evidence contract: specs/contracts/operator_lane_evidence.schema.json
  • Operator doc: docs/FULL_OPERATOR_LANE_2026-03-20.md
  • Provider/runtime note: docs/PROVIDER_RUNTIME_COMPAT_2026-03-20.md
  • Validated on clems:
    • dry-run success
    • live success
    • provider/model observed: claude / claude-sonnet-4-6

Refonte globale YiACAD 2026

Delta 2026-03-21 - backend service YiACAD

  • Service local: docs/YIACAD_BACKEND_SERVICE_2026-03-21.md
  • Client service-first: python3 tools/cad/yiacad_backend_client.py --json-output health
  • TUI backend: bash tools/cockpit/yiacad_backend_service_tui.sh --action status

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.
Reference in New Issue View Git Blame Copy Permalink